1 Internet Engineering Task Force (IETF) G. Lozano
2 Request for Comments: 8909 ICANN
3 Category: Standards Track November 2020
4 ISSN: 2070-1721
5
6
7 Registry Data Escrow Specification
8
9 Abstract
10
11 This document specifies the format and contents of data escrow
12 deposits targeted primarily for domain name registries. The
13 specification is designed to be independent of the underlying objects
14 that are being escrowed, and therefore it could also be used for
15 purposes other than domain name registries.
16
17 Status of This Memo
18
19 This is an Internet Standards Track document.
20
21 This document is a product of the Internet Engineering Task Force
22 (IETF). It represents the consensus of the IETF community. It has
23 received public review and has been approved for publication by the
24 Internet Engineering Steering Group (IESG). Further information on
25 Internet Standards is available in Section 2 of RFC 7841.
26
27 Information about the current status of this document, any errata,
28 and how to provide feedback on it may be obtained at
29 https://www.rfc-editor.org/info/rfc8909.
30
31 Copyright Notice
32
33 Copyright (c) 2020 IETF Trust and the persons identified as the
34 document authors. All rights reserved.
35
36 This document is subject to BCP 78 and the IETF Trust's Legal
37 Provisions Relating to IETF Documents
38 (https://trustee.ietf.org/license-info) in effect on the date of
39 publication of this document. Please review these documents
40 carefully, as they describe your rights and restrictions with respect
41 to this document. Code Components extracted from this document must
42 include Simplified BSD License text as described in Section 4.e of
43 the Trust Legal Provisions and are provided without warranty as
44 described in the Simplified BSD License.
45
46 Table of Contents
47
48 1. Introduction
49 2. Terminology
50 3. Problem Scope
51 4. Conventions Used in This Document
52 4.1. Date and Time
53 5. Protocol Description
54 5.1. Root Element <deposit>
55 5.2. Rebuilding the Registry from Data Escrow Deposits
56 6. Formal Syntax
57 6.1. RDE Schema
58 7. Internationalization Considerations
59 8. IANA Considerations
60 9. Security Considerations
61 10. Privacy Considerations
62 11. Example of a Full Deposit
63 12. Example of a Differential Deposit
64 13. Example of an Incremental Deposit
65 14. References
66 14.1. Normative References
67 14.2. Informative References
68 Acknowledgments
69 Author's Address
70
71 1. Introduction
72
73 Registry Data Escrow (RDE) is the process by which a registry
74 periodically submits data deposits to a third party called an escrow
75 agent. These deposits comprise the minimum data needed by a third
76 party to resume operations if the registry cannot function and is
77 unable or unwilling to facilitate an orderly transfer of service.
78 For example, for a domain name registry or registrar, the data to be
79 deposited would include all of the objects related to registered
80 domain names, e.g., names, contacts, name servers.
81
82 The goal of data escrow is higher resiliency of registration
83 services, for the benefit of Internet users. The beneficiaries of a
84 registry are not just those registering information there but also
85 the users of services relying on the registry data.
86
87 In the context of domain name registries, registration data escrow is
88 a requirement for generic Top-Level Domains (gTLDs) (e.g.,
89 Specification 2 of the ICANN Base Registry Agreement; see
90 [ICANN-GTLD-RA-20170731]), and some country code TLD (ccTLD) managers
91 are also currently escrowing data. There is also a similar
92 requirement for ICANN-accredited domain registrars.
93
94 This document specifies a format for data escrow deposits independent
95 of the objects being escrowed. An independent specification is
96 required for each type of registry/set of objects that is expected to
97 be escrowed.
98
99 The format for data escrow deposits is specified using version 1.0 of
100 the Extensible Markup Language (XML) as described in
101 [W3C.REC-xml-20081126], and XML Schema notation as described in
102 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028].
103
104 Readers are advised to read Section 2 ("Terminology") carefully to
105 understand the precise meanings of Differential and Incremental
106 Deposits, as the definitions used in this document are different from
107 the definitions typically used in the domain of data backups.
108
109 2. Terminology
110
111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
113 "OPTIONAL" in this document are to be interpreted as described in
114 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
115 capitals, as shown here.
116
117 Deposit: There are three kinds of deposits: Full, Differential, and
118 Incremental. For all three kinds of deposits, the universe of
119 registry objects to be considered for data escrow is comprised of
120 any objects required to offer the registry services.
121
122 Differential Deposit: A Differential Deposit contains data that
123 reflects all transactions involving the database that were not
124 reflected in the last previous Full, Incremental, or Differential
125 Deposit, as the case may be. Differential Deposit files will
126 contain information from all database objects that were added,
127 modified, or deleted since the previous deposit was completed as
128 of its defined Timeline Watermark.
129
130 Domain Name: See the definition of "domain name" in [RFC8499].
131
132 Escrow Agent: An escrow agent is the organization designated by the
133 registry or the third-party beneficiary to receive and guard data
134 escrow deposits from the registry.
135
136 Full Deposit: A Full Deposit contains the registry data that
137 reflects the current and complete registry database and will
138 consist of data that reflects the state of the registry as of a
139 defined Timeline Watermark for the deposit.
140
141 Incremental Deposit: An Incremental Deposit contains data that
142 reflects all transactions involving the database that were not
143 reflected in the last previous Full Deposit. Incremental Deposit
144 files will contain information from all database objects that were
145 added, modified, or deleted since the previous Full Deposit was
146 completed as of its defined Timeline Watermark. If the Timeline
147 Watermark of an Incremental Deposit were to cover the Timeline
148 Watermark of another Incremental or Differential Deposit since the
149 last Full Deposit (i.e., one or more Incremental or Differential
150 Deposits exist for the period between the Timeline Watermark of a
151 Full Deposit and an Incremental or Differential Deposit), the more
152 recent deposit MUST contain all of the transactions of the earlier
153 deposit.
154
155 Registrar: See the definition of "registrar" in [RFC8499].
156
157 Registry: See the definition of "registry" in [RFC8499].
158
159 Third-Party Beneficiary: A third-party beneficiary is the
160 organization that, under extraordinary circumstances, would
161 receive the escrow deposits the registry transferred to the escrow
162 agent. This organization could be a backup registry, registry
163 regulator, contracting party of the registry, etc.
164
165 Timeline Watermark: The Timeline Watermark is the point in time on
166 which to base the collecting of database objects for a deposit.
167 Deposits are expected to be consistent with that point in time.
168
169 Top-Level Domain (TLD): See the definition of "Top-Level Domain" in
170 [RFC8499].
171
172 3. Problem Scope
173
174 In the past few years, the issue of registry continuity has been
175 carefully considered in the gTLD and ccTLD spaces. Various
176 organizations have carried out risk analyses and developed business
177 continuity plans to deal with those risks, should they materialize.
178
179 One of the solutions considered and used, especially in the gTLD
180 space, is Registry Data Escrow as a way to ensure the continuity of
181 registry services in the extreme case of registry failure.
182
183 So far, almost every registry that uses Registry Data Escrow has its
184 own specification. It is anticipated that more registries will be
185 implementing escrow, especially with an increasing number of domain
186 registries coming into service, adding complexity to this issue.
187
188 It would seem beneficial to have a standardized specification for
189 Registry Data Escrow that can be used by any registry to submit its
190 deposits.
191
192 While the domain name industry has been the main target for this
193 specification, it has been designed to be as general as possible.
194
195 Specifications covering the objects used by registration
196 organizations shall identify the format and contents of the deposits
197 a registry has to make, such that a different registry would be able
198 to rebuild the registration services of the former, without its help,
199 in a timely manner and with minimum disruption to its users.
200
201 Since the details of the registration services provided vary from
202 registry to registry, specifications covering the objects used by
203 registration organizations shall provide mechanisms that allow
204 extensibility to accommodate variations and extensions of the
205 registration services.
206
207 Given the requirement for confidentiality and the importance of
208 accuracy of the information that is handled in order to offer
209 registration services, parties using this specification shall define
210 confidentiality and integrity mechanisms for handling the
211 registration data.
212
213 Specifications covering the objects used by registration
214 organizations shall not include in the specification transient
215 objects that can be recreated by the new registry, particularly those
216 of delicate confidentiality, e.g., DNSSEC KSK/ZSK (Key Signing Key /
217 Zone Signing Key) private keys.
218
219 Details that are a matter of policy should be identified as such for
220 the benefit of the implementers.
221
222 Non-technical issues concerning data escrow, such as whether to
223 escrow data and for what purposes the data may be used, are outside
224 the scope of this document.
225
226 Parties using this specification shall use a signaling mechanism to
227 control the transmission, reception, and validation of data escrow
228 deposits. The definition of such a signaling mechanism is outside
229 the scope of this document.
230
231 4. Conventions Used in This Document
232
233 The XML namespace prefix "rde" is used for the namespace
234 "urn:ietf:params:xml:ns:rde-1.0", but implementations MUST NOT depend
235 on it; instead, they should employ a proper namespace-aware XML
236 parser and serializer to interpret and output the XML documents.
237
238 The XML namespace prefixes "rdeObj1" and "rdeObj2", with the
239 corresponding namespaces "urn:example:params:xml:ns:rdeObj1-1.0" and
240 "urn:example:params:xml:ns:rdeObj2-1.0", are used as example data
241 escrow objects.
242
243 4.1. Date and Time
244
245 Numerous fields indicate "dates", such as the creation and expiry
246 dates for objects. These fields SHALL contain timestamps indicating
247 the date and time in UTC, specified in Internet Date/Time Format (see
248 [RFC3339], Section 5.6) with the time-offset parameter specified as
249 "Z".
250
251 5. Protocol Description
252
253 The format for data escrow deposits as produced by a registry is
254 defined below. The deposits are represented in XML (Section 6).
255 Only the format of the objects deposited is defined. This document
256 does not prescribe the method used to transfer such deposits between
257 the registry and the escrow agent or vice versa.
258
259 The protocol intends to be object agnostic, allowing the "overload"
260 of abstract elements using the "substitutionGroup" attribute
261 [W3C.REC-xmlschema-1-20041028] of the XML Schema element to define
262 the actual elements of an object to be escrowed.
263
264 The specification for each object to be escrowed MUST declare the
265 identifier to be used to reference the object to be deleted or added/
266 modified.
267
268 5.1. Root Element <deposit>
269
270 The container or root element for a Registry Data Escrow deposit is
271 <deposit>.
272
273 The <deposit> element contains the following attributes:
274
275 * A REQUIRED "type" attribute that is used to identify the kind of
276 deposit:
277
278 - FULL: Full.
279
280 - INCR: Incremental.
281
282 - DIFF: Differential.
283
284 * A REQUIRED "id" attribute that is used to uniquely identify the
285 escrow deposit. Each registry is responsible for maintaining its
286 own escrow deposits' identifier space to ensure uniqueness.
287
288 * A "prevId" attribute that can be used to identify the previous
289 Incremental, Differential, or Full Deposit. This attribute is
290 REQUIRED in Differential Deposits ("DIFF" type), is OPTIONAL in
291 Incremental Deposits ("INCR" type), and is not used in Full
292 Deposits ("FULL" type).
293
294 * An OPTIONAL "resend" attribute that is incremented each time the
295 escrow deposit failed the verification procedure at the receiving
296 party and a new escrow deposit needs to be generated by the
297 registry for that specific date. The first time a deposit is
298 generated, the attribute either (1) is omitted or (2) MUST be "0".
299 If a deposit needs to be generated again, the attribute MUST be
300 set to "1", and so on.
301
302 The <deposit> element contains the following child elements:
303
304 5.1.1. Child <watermark> Element
305
306 A REQUIRED <watermark> element contains the date-time [RFC3339]
307 corresponding to the Timeline Watermark of the deposit.
308
309 5.1.2. Child <rdeMenu> Element
310
311 This element contains auxiliary information regarding the data escrow
312 deposit.
313
314 A REQUIRED <rdeMenu> element contains the following child elements:
315
316 * A REQUIRED <version> element that identifies the RDE protocol
317 version. This value MUST be 1.0.
318
319 * One or more <objURI> elements that contain namespace URIs
320 representing the <contents> and <deletes> element objects.
321
322 5.1.3. Child <deletes> Element
323
324 For Differential Deposits, this element contains the list of objects
325 that have been deleted since the previous deposit of any type. For
326 Incremental Deposits, this element contains the list of objects that
327 have been deleted since the previous Full Deposit.
328
329 This section of the deposit MUST NOT be present in Full Deposits.
330
331 5.1.4. Child <contents> Element
332
333 For Full Deposits, this element contains all objects. For
334 Differential Deposits, this element contains the list of objects that
335 have been added or modified since the previous deposit of any type.
336 For Incremental Deposits, this element contains the list of objects
337 that have been added or modified since the previous Full Deposit.
338
339 5.2. Rebuilding the Registry from Data Escrow Deposits
340
341 When applying Incremental or Differential Deposits (when rebuilding
342 the registry from data escrow deposits), the relative order of the
343 <deletes> and <contents> elements is important because dependencies
344 may exist between the objects. All of the <deletes> elements MUST be
345 applied first, in the order in which they appear. All of the
346 <contents> elements MUST be applied next, in the order in which they
347 appear.
348
349 If an object is present in the <contents> or <deletes> section of
350 several deposits (e.g., Full and Differential), the registry data
351 from the latest deposit (as defined by the Timeline Watermark) SHOULD
352 be used when rebuilding the registry. An object SHOULD NOT exist
353 multiple times in either the <contents> or <deletes> elements in a
354 single deposit.
355
356 When rebuilding a registry, the <deletes> section MUST be ignored if
357 present in a Full Deposit.
358
359 6. Formal Syntax
360
361 RDE is specified in XML Schema notation. The formal syntax presented
362 here is a complete schema representation of RDE suitable for
363 automated validation of RDE XML instances.
364
365 The <CODE BEGINS> and <CODE ENDS> tags are not part of the schema;
366 they are used to note the beginning and ending of the schema for URI
367 registration purposes.
368
369 6.1. RDE Schema
370
371 <CODE BEGINS>
372 <?xml version="1.0" encoding="UTF-8"?>
373 <schema targetNamespace="urn:ietf:params:xml:ns:rde-1.0"
374 xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
375 xmlns="http://www.w3.org/2001/XMLSchema"
376 elementFormDefault="qualified">
377
378 <annotation>
379 <documentation>
380 Registry Data Escrow schema
381 </documentation>
382 </annotation>
383
384 <!-- Root element -->
385 <element name="deposit" type="rde:escrowDepositType"/>
386
387 <!-- RDE types -->
388 <complexType name="escrowDepositType">
389 <sequence>
390 <element name="watermark" type="dateTime"/>
391 <element name="rdeMenu" type="rde:rdeMenuType"/>
392 <element name="deletes" type="rde:deletesType" minOccurs="0"/>
393 <element name="contents" type="rde:contentsType"
394 minOccurs="0"/>
395 </sequence>
396 <attribute name="type" type="rde:depositTypeType"
397 use="required"/>
398 <attribute name="id" type="rde:depositIdType" use="required"/>
399 <attribute name="prevId" type="rde:depositIdType"/>
400 <attribute name="resend" type="unsignedShort" default="0"/>
401 </complexType>
402
403 <!-- Menu type -->
404 <complexType name="rdeMenuType">
405 <sequence>
406 <element name="version" type="rde:versionType"/>
407 <element name="objURI" type="anyURI" maxOccurs="unbounded"/>
408 </sequence>
409 </complexType>
410
411 <!-- Deletes type -->
412 <complexType name="deletesType">
413 <sequence minOccurs="0" maxOccurs="unbounded">
414 <element ref="rde:delete"/>
415 </sequence>
416 </complexType>
417
418 <element name="delete" type="rde:deleteType" abstract="true"/>
419 <complexType name="deleteType">
420 <complexContent>
421 <restriction base="anyType"/>
422 </complexContent>
423 </complexType>
424
425 <!-- Contents type -->
426 <complexType name="contentsType">
427 <sequence minOccurs="0" maxOccurs="unbounded">
428 <element ref="rde:content"/>
429 </sequence>
430 </complexType>
431
432 <element name="content" type="rde:contentType" abstract="true"/>
433 <complexType name="contentType">
434 <complexContent>
435 <restriction base="anyType"/>
436 </complexContent>
437 </complexType>
438
439 <!-- Type of deposit -->
440 <simpleType name="depositTypeType">
441 <restriction base="token">
442 <enumeration value="FULL"/>
443 <enumeration value="INCR"/>
444 <enumeration value="DIFF"/>
445 </restriction>
446 </simpleType>
447
448 <!-- Deposit identifier type -->
449 <simpleType name="depositIdType">
450 <restriction base="token">
451 <pattern value="\w{1,13}"/>
452 </restriction>
453 </simpleType>
454
455 <!-- A RDE version number is a dotted pair of decimal numbers -->
456 <simpleType name="versionType">
457 <restriction base="token">
458 <pattern value="[1-9]+\.[0-9]+"/>
459 <enumeration value="1.0"/>
460 </restriction>
461 </simpleType>
462
463 </schema>
464 <CODE ENDS>
465
466 7. Internationalization Considerations
467
468 Data escrow deposits are represented in XML, which provides native
469 support for encoding information using the Unicode character set and
470 its more compact representations, including UTF-8. Conformant XML
471 processors recognize both UTF-8 and UTF-16. Though XML includes
472 provisions to identify and use other character encodings through the
473 use of an "encoding" attribute in an <?xml?> declaration, the use of
474 UTF-8 is RECOMMENDED.
475
476 8. IANA Considerations
477
478 This document uses URNs to describe XML namespaces and XML schemas
479 conforming to a registry mechanism described in [RFC3688]. Two URI
480 assignments have been registered by the IANA.
481
482 Registration for the RDE namespace:
483
484 URI: urn:ietf:params:xml:ns:rde-1.0
485 Registrant Contact: IESG
486 XML: None. Namespace URIs do not represent an XML specification.
487
488 Registration for the RDE XML schema:
489
490 URI: urn:ietf:params:xml:schema:rde-1.0
491 Registrant Contact: IESG
492
493 See Section 6 ("Formal Syntax") of this document.
494
495 9. Security Considerations
496
497 This specification does not define the security mechanisms to be used
498 in the transmission of the data escrow deposits, since it only
499 specifies the minimum necessary to enable the rebuilding of a
500 registry from deposits without intervention from the original
501 registry.
502
503 Depending on local policies, some elements -- or, most likely, the
504 whole deposit -- will be considered confidential. As such, the
505 parties SHOULD take all necessary precautions, such as encrypting the
506 data at rest and in transit to avoid inadvertent disclosure of
507 private data. Regardless of the precautions taken by the parties
508 regarding data at rest and in transit, authentication credentials
509 MUST NOT be escrowed.
510
511 Authentication of the parties passing data escrow deposit files is
512 also of the utmost importance. The escrow agent MUST properly
513 authenticate the identity of the registry before accepting data
514 escrow deposits. Similarly, the registry MUST authenticate the
515 identity of the escrow agent before submitting any data.
516
517 Additionally, the registry and the escrow agent MUST use integrity-
518 checking mechanisms to ensure that the data transmitted is what the
519 source intended. Validation of the contents by the escrow agent is
520 RECOMMENDED to ensure not only that the file was transmitted
521 correctly from the registry but also that the contents are
522 "meaningful".
523
524 | Note: If Transport Layer Security (TLS) is used when providing
525 | an escrow service, the recommendations in [RFC7525] MUST be
526 | implemented.
527
528 10. Privacy Considerations
529
530 This specification defines a format that may be used to escrow
531 personal data. The process of data escrow is governed by a legal
532 document agreed upon by the parties, and such a legal document must
533 ensure that privacy-sensitive and/or personal data receives the
534 required protection.
535
536 11. Example of a Full Deposit
537
538 Example of a Full Deposit with the two example objects rdeObj1 and
539 rdeObj2:
540
541 <?xml version="1.0" encoding="UTF-8"?>
542 <rde:deposit
543 xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
544 xmlns:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0"
545 xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0"
546 type="FULL"
547 id="20191018001">
548 <rde:watermark>2019-10-17T23:59:59Z</rde:watermark>
549 <rde:rdeMenu>
550 <rde:version>1.0</rde:version>
551 <rde:objURI>urn:example:params:xml:ns:rdeObj1-1.0</rde:objURI>
552 <rde:objURI>urn:example:params:xml:ns:rdeObj2-1.0</rde:objURI>
553 </rde:rdeMenu>
554 <rde:contents>
555 <rdeObj1:rdeObj1>
556 <rdeObj1:name>EXAMPLE</rdeObj1:name>
557 </rdeObj1:rdeObj1>
558 <rdeObj2:rdeObj2>
559 <rdeObj2:id>fsh8013-EXAMPLE</rdeObj2:id>
560 </rdeObj2:rdeObj2>
561 </rde:contents>
562 </rde:deposit>
563
564 12. Example of a Differential Deposit
565
566 Example of a Differential Deposit with the two example objects
567 rdeObj1 and rdeObj2:
568
569 <?xml version="1.0" encoding="UTF-8"?>
570 <rde:deposit
571 xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
572 xmlns:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0"
573 xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0"
574 type="DIFF"
575 id="20191019001" prevId="20191018001">
576 <rde:watermark>2019-10-18T23:59:59Z</rde:watermark>
577 <rde:rdeMenu>
578 <rde:version>1.0</rde:version>
579 <rde:objURI>urn:example:params:xml:ns:rdeObj1-1.0</rde:objURI>
580 <rde:objURI>urn:example:params:xml:ns:rdeObj2-1.0</rde:objURI>
581 </rde:rdeMenu>
582 <rde:contents>
583 <rdeObj1:rdeObj1>
584 <rdeObj1:name>EXAMPLE2</rdeObj1:name>
585 </rdeObj1:rdeObj1>
586 <rdeObj2:rdeObj2>
587 <rdeObj2:id>sh8014-EXAMPLE</rdeObj2:id>
588 </rdeObj2:rdeObj2>
589 </rde:contents>
590 </rde:deposit>
591
592 13. Example of an Incremental Deposit
593
594 Example of an Incremental Deposit with the two example objects
595 rdeObj1 and rdeObj2:
596
597 <?xml version="1.0" encoding="UTF-8"?>
598 <rde:deposit
599 xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
600 xmlns:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0"
601 xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0"
602 type="INCR"
603 id="20200317001" prevId="20200314001">
604 <rde:watermark>2020-03-16T23:59:59Z</rde:watermark>
605 <rde:rdeMenu>
606 <rde:version>1.0</rde:version>
607 <rde:objURI>urn:example:params:xml:ns:rdeObj1-1.0</rde:objURI>
608 <rde:objURI>urn:example:params:xml:ns:rdeObj2-1.0</rde:objURI>
609 </rde:rdeMenu>
610 <rde:deletes>
611 <rdeObj1:delete>
612 <rdeObj1:name>EXAMPLE1</rdeObj1:name>
613 </rdeObj1:delete>
614 <rdeObj2:delete>
615 <rdeObj2:id>fsh8013-EXAMPLE</rdeObj2:id>
616 </rdeObj2:delete>
617 </rde:deletes>
618 <rde:contents>
619 <rdeObj1:rdeObj1>
620 <rdeObj1:name>EXAMPLE2</rdeObj1:name>
621 </rdeObj1:rdeObj1>
622 <rdeObj2:rdeObj2>
623 <rdeObj2:id>sh8014-EXAMPLE</rdeObj2:id>
624 </rdeObj2:rdeObj2>
625 </rde:contents>
626 </rde:deposit>
627
628 14. References
629
630 14.1. Normative References
631
632 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
633 Requirement Levels", BCP 14, RFC 2119,
634 DOI 10.17487/RFC2119, March 1997,
635 <https://www.rfc-editor.org/info/rfc2119>.
636
637 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
638 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
639 <https://www.rfc-editor.org/info/rfc3339>.
640
641 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
642 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
643 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
644
645 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
646 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
647 January 2019, <https://www.rfc-editor.org/info/rfc8499>.
648
649 [W3C.REC-xml-20081126]
650 Bray, T., Ed., Paoli, J., Ed., Sperberg-McQueen, C.M.,
651 Ed., Maler, E., Ed., and F. Yergeau, Ed., "Extensible
652 Markup Language (XML) 1.0 (Fifth Edition)", REC-xml-
653 20081126, November 2008,
654 <https://www.w3.org/TR/2008/REC-xml-20081126/>.
655
656 [W3C.REC-xmlschema-1-20041028]
657 Thompson, H.S., Ed., Beech, D., Ed., Maloney, M., Ed., and
658 N. Mendelsohn, Ed., "XML Schema Part 1: Structures Second
659 Edition", REC-xmlschema-1-20041028, October 2004,
660 <https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/>.
661
662 [W3C.REC-xmlschema-2-20041028]
663 Biron, P. V., Ed. and A. Malhotra, Ed., "XML Schema Part
664 2: Datatypes Second Edition", REC-xmlschema-2-20041028,
665 October 2004,
666 <https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.
667
668 14.2. Informative References
669
670 [ICANN-GTLD-RA-20170731]
671 ICANN, "Base Registry Agreement", 31 July 2017,
672 <https://newgtlds.icann.org/sites/default/files/
673 agreements/agreement-approved-31jul17-en.pdf>.
674
675 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
676 DOI 10.17487/RFC3688, January 2004,
677 <https://www.rfc-editor.org/info/rfc3688>.
678
679 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
680 "Recommendations for Secure Use of Transport Layer
681 Security (TLS) and Datagram Transport Layer Security
682 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
683 2015, <https://www.rfc-editor.org/info/rfc7525>.
684
685 Acknowledgments
686
687 Special suggestions that were incorporated into this document were
688 provided by James Gould, Edward Lewis, Jaap Akkerhuis, Lawrence
689 Conroy, Marc Groeneweg, Michael Young, Chris Wright, Patrick Mevzek,
690 Stephen Morris, Scott Hollenbeck, Stephane Bortzmeyer, Warren Kumari,
691 Paul Hoffman, Vika Mpisane, Bernie Hoeneisen, Jim Galvin, Andrew
692 Sullivan, Hiro Hotta, Christopher Browne, Daniel Kalchev, David
693 Conrad, James Mitchell, Francisco Obispo, Bhadresh Modi, and
694 Alexander Mayrhofer.
695
696 Shoji Noguchi and Francisco Arias participated as coauthors through
697 version 07 of draft-arias-noguchi-registry-data-escrow (the precursor
698 to this document) and provided invaluable support for this document.
699
700 Author's Address
701
702 Gustavo Lozano
703 Internet Corporation for Assigned Names and Numbers
704 12025 Waterfront Drive, Suite 300
705 Los Angeles, CA 90292
706 United States of America
707
708 Phone: +1.310.823.9358
709 Email: gustavo.lozano@icann.org
710
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.