draft-ietf-regext-data-escrow-04.txt   draft-ietf-regext-data-escrow-05.txt 
Network Working Group G. Lozano Network Working Group G. Lozano
Internet-Draft ICANN Internet-Draft ICANN
Intended status: Standards Track Jan 08, 2020 Intended status: Standards Track Feb 28, 2020
Expires: July 11, 2020 Expires: August 31, 2020
Registry Data Escrow Specification Registry Data Escrow Specification
draft-ietf-regext-data-escrow-04 draft-ietf-regext-data-escrow-05
Abstract Abstract
This document specifies the format and contents of data escrow This document specifies the format and contents of data escrow
deposits targeted primarily for domain name registries. However, the deposits targeted primarily for domain name registries. However, the
specification was designed to be independent of the underlying specification was designed to be independent of the underlying
objects that are being escrowed, therefore it could be used for objects that are being escrowed, therefore it could be used for
purposes other than domain name registries. purposes other than domain name registries.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 11, 2020. This Internet-Draft will expire on August 31, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 10 skipping to change at page 2, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 4
4. General Conventions . . . . . . . . . . . . . . . . . . . . . 6 4. General Conventions . . . . . . . . . . . . . . . . . . . . . 5
4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
5.1. Root element <deposit> . . . . . . . . . . . . . . . . . 6 5.1. Root element <deposit> . . . . . . . . . . . . . . . . . 6
5.2. Child <watermark> element . . . . . . . . . . . . . . . . 9 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Child <rdeMenu> element . . . . . . . . . . . . . . . . . 9 6.1. RDE Schema . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Child <deletes> element . . . . . . . . . . . . . . . . . 10 7. Internationalization Considerations . . . . . . . . . . . . . 10
5.5. Child <contents> element . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
6.1. RDE Schema . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Implementation in the gTLD space . . . . . . . . . . . . 11
7. Internationalization Considerations . . . . . . . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Implementation in the gTLD space . . . . . . . . . . . . 15 13. Change History . . . . . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 13.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 13
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 13.2. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 14
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 13.3. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 15
13. Change History . . . . . . . . . . . . . . . . . . . . . . . 16 13.4. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 15
13.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 16 13.5. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 15
13.2. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 17 13.6. Changes from 05 to 06 . . . . . . . . . . . . . . . . . 15
13.3. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 18 13.7. Changes from 06 to 07 . . . . . . . . . . . . . . . . . 15
13.4. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 18 13.8. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 15
13.5. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 18 13.9. Changes from 08 to 09 . . . . . . . . . . . . . . . . . 16
13.6. Changes from 05 to 06 . . . . . . . . . . . . . . . . . 19 13.10. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 16
13.7. Changes from 06 to 07 . . . . . . . . . . . . . . . . . 19 13.11. Changes from 10 to 11 . . . . . . . . . . . . . . . . . 16
13.8. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 19 13.12. Changes from 11 to REGEXT 00 . . . . . . . . . . . . . . 16
13.9. Changes from 08 to 09 . . . . . . . . . . . . . . . . . 19 13.13. Changes from version REGEXT 00 to REGEXT 01 . . . . . . 16
13.10. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 19 13.14. Changes from version REGEXT 01 to REGEXT 02 . . . . . . 16
13.11. Changes from 10 to 11 . . . . . . . . . . . . . . . . . 19 13.15. Changes from version REGEXT 02 to REGEXT 03 . . . . . . 16
13.12. Changes from 11 to REGEXT 00 . . . . . . . . . . . . . . 19 13.16. Changes from version REGEXT 03 to REGEXT 04 . . . . . . 16
13.13. Changes from version REGEXT 00 to REGEXT 01 . . . . . . 19 13.17. Changes from version REGEXT 04 to REGEXT 05 . . . . . . 17
13.14. Changes from version REGEXT 01 to REGEXT 02 . . . . . . 19 14. Example of a Full Deposit . . . . . . . . . . . . . . . . . . 17
13.15. Changes from version REGEXT 02 to REGEXT 03 . . . . . . 20 15. Example of a Differential Deposit . . . . . . . . . . . . . . 17
13.16. Changes from version REGEXT 03 to REGEXT 04 . . . . . . 20 16. Example of a Incremental Deposit . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
14.1. Normative References . . . . . . . . . . . . . . . . . . 20 17.1. Normative References . . . . . . . . . . . . . . . . . . 19
14.2. Informative References . . . . . . . . . . . . . . . . . 20 17.2. Informative References . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Registry Data Escrow is the process by which a registry periodically Registry Data Escrow is the process by which a registry periodically
submits data deposits to a third-party called an escrow agent. These submits data deposits to a third-party called an escrow agent. These
deposits comprise the minimum data needed by a third-party to resume deposits comprise the minimum data needed by a third-party to resume
operations if the registry cannot function and is unable or unwilling operations if the registry cannot function and is unable or unwilling
to facilitate an orderly transfer of service. For example, for a to facilitate an orderly transfer of service. For example, for a
domain name registry or registrar, the data to be deposited would domain name registry or registrar, the data to be deposited would
include all the objects related to registered domain names, e.g., include all the objects related to registered domain names, e.g.,
skipping to change at page 5, line 14 skipping to change at page 5, line 14
So far, almost every registry that uses Registry Data Escrow has its So far, almost every registry that uses Registry Data Escrow has its
own specification. It is anticipated that more registries will be own specification. It is anticipated that more registries will be
implementing escrow especially with an increasing number of domain implementing escrow especially with an increasing number of domain
registries coming into service, adding complexity to this issue. registries coming into service, adding complexity to this issue.
It would seem beneficial to have a standardized specification for It would seem beneficial to have a standardized specification for
Registry Data Escrow that can be used by any registry to submit its Registry Data Escrow that can be used by any registry to submit its
deposits. deposits.
While the main motivation for developing this specification is rooted While the domain name industry has been the main target for this
on the domain name industry, the specification has been designed to specification, it has been designed to be as general as possible.
be as general as possible. This allows other types of registries to
use this base specification and develop their own specifications
covering the objects used by other registration organizations.
Specifications covering the objects used by registration Specifications covering the objects used by registration
organizations shall identify the format and contents of the deposits organizations shall identify the format and contents of the deposits
a registry has to make, such that a different registry would be able a registry has to make, such that a different registry would be able
to rebuild the registration services of the former, without its help, to rebuild the registration services of the former, without its help,
in a timely manner, with minimum disruption to its users. in a timely manner, with minimum disruption to its users.
Since the details of the registration services provided vary from Since the details of the registration services provided vary from
registry to registry, specifications covering the objects used by registry to registry, specifications covering the objects used by
registration organizations shall provide mechanisms that allow its registration organizations shall provide mechanisms that allow its
skipping to change at page 6, line 13 skipping to change at page 6, line 6
outside of scope of this document. outside of scope of this document.
4. General Conventions 4. General Conventions
The XML namespace prefix "rde" is used for the namespace The XML namespace prefix "rde" is used for the namespace
"urn:ietf:params:xml:ns:rde-1.0", but implementations MUST NOT depend "urn:ietf:params:xml:ns:rde-1.0", but implementations MUST NOT depend
on it; instead, they should employ a proper namespace-aware XML on it; instead, they should employ a proper namespace-aware XML
parser and serializer to interpret and output the XML documents. parser and serializer to interpret and output the XML documents.
The XML namespace prefix "rdeObj1" and "rdeObj2" with the The XML namespace prefix "rdeObj1" and "rdeObj2" with the
corresponding namespace "urn:ietf:params:xml:ns:rdeObj1-1.0" and corresponding namespaces "urn:ietf:params:xml:ns:rdeObj1-1.0" and
"urn:ietf:params:xml:ns:rdeObj2-1.0" are used as example data escrow "urn:ietf:params:xml:ns:rdeObj2-1.0" are used as example data escrow
objects. objects.
4.1. Date and Time 4.1. Date and Time
Numerous fields indicate "dates", such as the creation and expiry Numerous fields indicate "dates", such as the creation and expiry
dates for objects. These fields SHALL contain timestamps indicating dates for objects. These fields SHALL contain timestamps indicating
the date and time in UTC, specified in Internet Date/Time Format (see the date and time in UTC, specified in Internet Date/Time Format (see
[RFC3339], Section 5.6) with the time-offset specified as "Z". [RFC3339], Section 5.6) with the time-offset specified as "Z".
skipping to change at page 6, line 40 skipping to change at page 6, line 33
escrow agent or vice versa. escrow agent or vice versa.
The protocol intends to be object agnostic allowing the "overload" of The protocol intends to be object agnostic allowing the "overload" of
abstract elements using the "substitutionGroup" attribute of the XML abstract elements using the "substitutionGroup" attribute of the XML
Schema element to define the actual elements of an object to be Schema element to define the actual elements of an object to be
escrowed. escrowed.
5.1. Root element <deposit> 5.1. Root element <deposit>
The container or root element for a Registry Data Escrow deposit is The container or root element for a Registry Data Escrow deposit is
<deposit>. This element contains the following child elements: <deposit>.
<watermark>, <rdeMenu>, <deletes> and <contents> elements. This
element also contains the following attributes: The <deposit> element contains the following attributes:
o A REQUIRED "type" attribute that is used to identify the kind of o A REQUIRED "type" attribute that is used to identify the kind of
deposit: FULL (Full), INCR (Incremental) or DIFF (Differential). deposit: FULL (Full), INCR (Incremental) or DIFF (Differential).
o A REQUIRED "id" attribute that is used to uniquely identify the o A REQUIRED "id" attribute that is used to uniquely identify the
escrow deposit. Each registry is responsible for maintaining its escrow deposit. Each registry is responsible for maintaining its
own escrow deposits identifier space to ensure uniqueness. own escrow deposits' identifier space to ensure uniqueness.
o An OPTIONAL "prevId" attribute that can be used to identify the o A "prevId" attribute that can be used to identify the previous
previous Incremental, Differential or Full Deposit. This Incremental, Differential or Full Deposit. This attribute is
attribute MUST be used in Differential Deposits ("DIFF" type). REQUIRED in Differential Deposits ("DIFF" type), is OPTIONAL in
Incremental Deposits ("INCR" type), and is not used in Full
Deposits ("FULL" type).
o An OPTIONAL "resend" attribute that is incremented each time the o An OPTIONAL "resend" attribute that is incremented each time the
escrow deposit failed the verification procedure at the receiving escrow deposit failed the verification procedure at the receiving
party and a new escrow deposit needs to be generated by the party and a new escrow deposit needs to be generated by the
registry for that specific date. The first time a deposit is registry for that specific date. The first time a deposit is
generated the attribute is either omitted or MUST be "0". If a generated the attribute is either omitted or MUST be "0". If a
deposit needs to be generated again, the attribute MUST be set to deposit needs to be generated again, the attribute MUST be set to
"1", and so on. "1", and so on.
Example of a Full Deposit with the two example objects rdeObj1 and The <deposit> element contains the following the child elements:
rdeObj2:
<?xml version="1.0" encoding="UTF-8"?>
<rde:deposit
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns:rdeObj1="urn:ietf:params:xml:ns:rdeObj1-1.0"
xmlns:rdeObj2="urn:ietf:params:xml:ns:rdeObj2-1.0"
type="FULL"
id="20191017001">
<rde:watermark>2019-10-18T00:00:00Z</rde:watermark>
<rde:rdeMenu>
<rde:version>1.0</rde:version>
<rde:objURI>urn:ietf:params:xml:ns:rdeObj1-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeObj2-1.0</rde:objURI>
</rde:rdeMenu>
<rde:contents>
<rdeObj1:rdeObj1>
<rdeObj1:name>EXAMPLE</rdeObj1:name>
</rdeObj1:rdeObj1>
<rdeObj2:rdeObj2>
<rdeObj2:id>fsh8013-EXAMPLE</rdeObj2:id>
</rdeObj2:rdeObj2>
</rde:contents>
</rde:deposit>
Example of a Differential Deposit with the two example objects
rdeObj1 and rdeObj2:
<?xml version="1.0" encoding="UTF-8"?>
<rde:deposit
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns:rdeObj1="urn:ietf:params:xml:ns:rdeObj1-1.0"
xmlns:rdeObj2="urn:ietf:params:xml:ns:rdeObj2-1.0"
type="DIFF"
id="20191017001" prevId="20191016001">
<rde:watermark>2019-10-18T00:00:00Z</rde:watermark>
<rde:rdeMenu>
<rde:version>1.0</rde:version>
<rde:objURI>urn:ietf:params:xml:ns:rdeObj1-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeObj2-1.0</rde:objURI>
</rde:rdeMenu>
<rde:deletes>
<rdeObj1:delete>
<rdeObj1:name>EXAMPLE1</rdeObj1:name>
</rdeObj1:delete>
<rdeObj2:delete>
<rdeObj2:id>fsh8013-EXAMPLE</rdeObj2:id>
</rdeObj2:delete>
</rde:deletes>
<rde:contents>
<rdeObj1:rdeObj1>
<rdeObj1:name>EXAMPLE2</rdeObj1:name>
</rdeObj1:rdeObj1>
<rdeObj2:rdeObj2>
<rdeObj2:id>sh8014-EXAMPLE</rdeObj2:id>
</rdeObj2:rdeObj2>
</rde:contents>
</rde:deposit>
Example of an Incremental Deposit with the two example objects
rdeObj1 and rdeObj2:
<?xml version="1.0" encoding="UTF-8"?>
<rde:deposit
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns:rdeObj1="urn:ietf:params:xml:ns:rdeObj1-1.0"
xmlns:rdeObj2="urn:ietf:params:xml:ns:rdeObj2-1.0"
type="INCR"
id="20191017001" prevId="20191010001">
<rde:watermark>2019-10-18T00:00:00Z</rde:watermark>
<rde:rdeMenu>
<rde:version>1.0</rde:version>
<rde:objURI>urn:ietf:params:xml:ns:rdeObj1-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeObj2-1.0</rde:objURI>
</rde:rdeMenu>
<rde:deletes>
<rdeObj1:delete>
<rdeObj1:name>EXAMPLE1</rdeObj1:name>
</rdeObj1:delete>
<rdeObj2:delete>
<rdeObj2:id>fsh8013-EXAMPLE</rdeObj2:id>
</rdeObj2:delete>
</rde:deletes>
<rde:contents>
<rdeObj1:rdeObj1>
<rdeObj1:name>EXAMPLE2</rdeObj1:name>
</rdeObj1:rdeObj1>
<rdeObj2:rdeObj2>
<rdeObj2:id>sh8014-EXAMPLE</rdeObj2:id>
</rdeObj2:rdeObj2>
</rde:contents>
</rde:deposit>
5.2. Child <watermark> element 5.1.1. Child <watermark> element
A REQUIRED <watermark> element contains the data-time corresponding A REQUIRED <watermark> element contains the data-time corresponding
to the Timeline Watermark of the deposit. to the Timeline Watermark of the deposit.
5.3. Child <rdeMenu> element 5.1.2. Child <rdeMenu> element
This element contains auxiliary information of the data escrow This element contains auxiliary information of the data escrow
deposit. deposit.
A REQUIRED <rdeMenu> element contains the following child elements: A REQUIRED <rdeMenu> element contains the following child elements:
o A REQUIRED <version> element that identifies the RDE protocol o A REQUIRED <version> element that identifies the RDE protocol
version. version.
o One or more <objURI> elements that contain namespace URIs o One or more <objURI> elements that contain namespace URIs
representing the <contents> and <deletes> element objects. representing the <contents> and <deletes> element objects.
5.4. Child <deletes> element 5.1.3. Child <deletes> element
This element SHOULD be present in deposits of type Incremental or This element SHOULD be present in deposits of type Incremental or
Differential. It contains the list of objects that were deleted Differential. It contains the list of objects that were deleted
since the base previous deposit. Each object in this section SHALL since the base previous deposit. Each object in this section SHALL
contain an ID for the object deleted. contain an ID for the object deleted.
This section of the deposit SHOULD NOT be present in Full Deposits. This section of the deposit MUST NOT be present in Full Deposits.
When rebuilding a registry it SHOULD be ignored if present in a Full When rebuilding a registry it MUST be ignored if present in a Full
Deposit. Deposit.
The specification for each object to be escrowed MUST declare the The specification for each object to be escrowed MUST declare the
identifier to be used to reference the object to be deleted. identifier to be used to reference the object to be deleted.
5.5. Child <contents> element 5.1.4. Child <contents> element
This element of the deposit contains the objects in the deposit. It This element of the deposit contains the objects in the deposit. It
SHOULD be present in all type of deposits. It contains the data for SHOULD be present in all type of deposits. It contains the data for
the objects to be escrowed. The actual objects have to be specified the objects to be escrowed. The actual objects have to be specified
individually. individually.
In the case of Incremental or Differential Deposits, the objects In the case of Incremental or Differential Deposits, the objects
indicate whether the object was added or modified after the base indicate whether the object was added or modified after the base
previous deposit. In order to distinguish between one and the other, previous deposit. In order to distinguish between one and the other,
it will be sufficient to check existence of the referenced object in it will be sufficient to check existence of the referenced object in
skipping to change at page 10, line 48 skipping to change at page 8, line 24
If an object is present in the <contents> section of several deposits If an object is present in the <contents> section of several deposits
(e.g. Full and Differential) the registry data from the latest (e.g. Full and Differential) the registry data from the latest
deposit (as defined by the Timeline Watermark) SHOULD be used when deposit (as defined by the Timeline Watermark) SHOULD be used when
rebuilding the registry. rebuilding the registry.
6. Formal Syntax 6. Formal Syntax
6.1. RDE Schema 6.1. RDE Schema
Copyright (c) 2019 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
o Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
o Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
o Neither the name of Internet Society, IETF or IETF Trust, nor the
names of specific contributors, may be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
BEGIN BEGIN
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:rde-1.0" <schema targetNamespace="urn:ietf:params:xml:ns:rde-1.0"
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0" xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"> elementFormDefault="qualified">
<annotation> <annotation>
<documentation> <documentation>
Registry Data Escrow schema Registry Data Escrow schema
skipping to change at page 15, line 43 skipping to change at page 12, line 33
agreements-en agreements-en
10. Security Considerations 10. Security Considerations
This specification does not define the security mechanisms to be used This specification does not define the security mechanisms to be used
in the transmission of the data escrow deposits, since it only in the transmission of the data escrow deposits, since it only
specifies the minimum necessary to enable the rebuilding of a specifies the minimum necessary to enable the rebuilding of a
registry from deposits without intervention from the original registry from deposits without intervention from the original
registry. registry.
Depending on local policies, some elements or most likely, the whole Depending on local policies, some elements or, most likely, the whole
deposit will be considered confidential. As such the registry deposit will be considered confidential. As such, the registry
transmitting the data to the escrow agent SHOULD take all the transmitting the data to the escrow agent should take all the
necessary precautions like encrypting the data itself and/or the necessary precautions such as encrypting the data itself and/or the
transport channel to avoid inadvertent disclosure of private data. transport channel to avoid inadvertent disclosure of private data.
It is also of the utmost importance the authentication of the parties Authentication of the parties passing data escrow deposit files is
passing data escrow deposit files. The escrow agent SHOULD properly also of the utmost importance. The escrow agent SHOULD properly
authenticate the identity of the registry before accepting data authenticate the identity of the registry before accepting data
escrow deposits. In a similar manner, the registry SHOULD escrow deposits. In a similar manner, the registry SHOULD
authenticate the identity of the escrow agent before submitting any authenticate the identity of the escrow agent before submitting any
data. data.
Additionally, the registry and the escrow agent SHOULD use integrity Additionally, the registry and the escrow agent SHOULD use integrity
checking mechanisms to ensure the data transmitted is what the source checking mechanisms to ensure the data transmitted is what the source
intended. Validation of the contents by the escrow agent is intended. Validation of the contents by the escrow agent is
RECOMMENDED to ensure not only the file was transmitted correctly RECOMMENDED to ensure not only that the file was transmitted
from the registry, but also the contents are also "meaningful". correctly from the registry, but also that the contents are
"meaningful".
11. Privacy Considerations 11. Privacy Considerations
This specification defines a format that may be used to escrow This specification defines a format that may be used to escrow
personal data. The process of data escrow is governed by a legal personal data. The process of data escrow is governed by a legal
document agreed by the parties, and such legal document must regulate document agreed by the parties, and such legal document must regulate
the particularities regarding the protection of personal data. the particularities regarding the protection of personal data.
12. Acknowledgments 12. Acknowledgments
skipping to change at page 20, line 17 skipping to change at page 17, line 5
1. The <contents> section changed from MUST to SHOULD, in order to 1. The <contents> section changed from MUST to SHOULD, in order to
accommodate an Incremental or Differential Deposit that only accommodate an Incremental or Differential Deposit that only
includes deletes. includes deletes.
2. Editorial updates. 2. Editorial updates.
13.16. Changes from version REGEXT 03 to REGEXT 04 13.16. Changes from version REGEXT 03 to REGEXT 04
1. Moved [RFC8499] to the Normative References section. 1. Moved [RFC8499] to the Normative References section.
14. References 13.17. Changes from version REGEXT 04 to REGEXT 05
14.1. Normative References 1. Changes based on the feedback provided here:
https://mailarchive.ietf.org/arch/msg/regext/
UNo6YxapgjyerAYv0223zEuzjFk
2. The examples of deposits were moved to their own sections.
3. <deposit> elements definition moved to section 5.1.
4. The DIFF example was modified to make it more representative of a
differential deposit.
14. Example of a Full Deposit
Example of a Full Deposit with the two example objects rdeObj1 and
rdeObj2:
<?xml version="1.0" encoding="UTF-8"?>
<rde:deposit
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns:rdeObj1="urn:ietf:params:xml:ns:rdeObj1-1.0"
xmlns:rdeObj2="urn:ietf:params:xml:ns:rdeObj2-1.0"
type="FULL"
id="20191017001">
<rde:watermark>2019-10-18T00:00:00Z</rde:watermark>
<rde:rdeMenu>
<rde:version>1.0</rde:version>
<rde:objURI>urn:ietf:params:xml:ns:rdeObj1-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeObj2-1.0</rde:objURI>
</rde:rdeMenu>
<rde:contents>
<rdeObj1:rdeObj1>
<rdeObj1:name>EXAMPLE</rdeObj1:name>
</rdeObj1:rdeObj1>
<rdeObj2:rdeObj2>
<rdeObj2:id>fsh8013-EXAMPLE</rdeObj2:id>
</rdeObj2:rdeObj2>
</rde:contents>
</rde:deposit>
15. Example of a Differential Deposit
Example of a Differential Deposit with the two example objects
rdeObj1 and rdeObj2:
<?xml version="1.0" encoding="UTF-8"?>
<rde:deposit
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns:rdeObj1="urn:ietf:params:xml:ns:rdeObj1-1.0"
xmlns:rdeObj2="urn:ietf:params:xml:ns:rdeObj2-1.0"
type="DIFF"
id="20191017001" prevId="20191016001">
<rde:watermark>2019-10-18T00:00:00Z</rde:watermark>
<rde:rdeMenu>
<rde:version>1.0</rde:version>
<rde:objURI>urn:ietf:params:xml:ns:rdeObj1-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeObj2-1.0</rde:objURI>
</rde:rdeMenu>
<rde:contents>
<rdeObj1:rdeObj1>
<rdeObj1:name>EXAMPLE2</rdeObj1:name>
</rdeObj1:rdeObj1>
<rdeObj2:rdeObj2>
<rdeObj2:id>sh8014-EXAMPLE</rdeObj2:id>
</rdeObj2:rdeObj2>
</rde:contents>
</rde:deposit>
16. Example of a Incremental Deposit
Example of an Incremental Deposit with the two example objects
rdeObj1 and rdeObj2:
<?xml version="1.0" encoding="UTF-8"?>
<rde:deposit
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns:rdeObj1="urn:ietf:params:xml:ns:rdeObj1-1.0"
xmlns:rdeObj2="urn:ietf:params:xml:ns:rdeObj2-1.0"
type="INCR"
id="20191017001" prevId="20191010001">
<rde:watermark>2019-10-18T00:00:00Z</rde:watermark>
<rde:rdeMenu>
<rde:version>1.0</rde:version>
<rde:objURI>urn:ietf:params:xml:ns:rdeObj1-1.0</rde:objURI>
<rde:objURI>urn:ietf:params:xml:ns:rdeObj2-1.0</rde:objURI>
</rde:rdeMenu>
<rde:deletes>
<rdeObj1:delete>
<rdeObj1:name>EXAMPLE1</rdeObj1:name>
</rdeObj1:delete>
<rdeObj2:delete>
<rdeObj2:id>fsh8013-EXAMPLE</rdeObj2:id>
</rdeObj2:delete>
</rde:deletes>
<rde:contents>
<rdeObj1:rdeObj1>
<rdeObj1:name>EXAMPLE2</rdeObj1:name>
</rdeObj1:rdeObj1>
<rdeObj2:rdeObj2>
<rdeObj2:id>sh8014-EXAMPLE</rdeObj2:id>
</rdeObj2:rdeObj2>
</rde:contents>
</rde:deposit>
17. References
17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
14.2. Informative References 17.2. Informative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
 End of changes. 23 change blocks. 
194 lines changed or deleted 175 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/