idnits 2.17.1 draft-ietf-regext-data-escrow-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Jun 1, 2020) is 1397 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Lozano 3 Internet-Draft ICANN 4 Intended status: Standards Track Jun 1, 2020 5 Expires: December 3, 2020 7 Registry Data Escrow Specification 8 draft-ietf-regext-data-escrow-10 10 Abstract 12 This document specifies the format and contents of data escrow 13 deposits targeted primarily for domain name registries. The 14 specification is designed to be independent of the underlying objects 15 that are being escrowed and therefore it could also be used for 16 purposes other than domain name registries. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 3, 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Conventions Used in This Document . . . . . . . . . . . . . . 6 56 4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 58 5.1. Root element . . . . . . . . . . . . . . . . . 7 59 5.2. Rebuilding the registry from data escrow deposits . . . . 8 60 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 61 6.1. RDE Schema . . . . . . . . . . . . . . . . . . . . . . . 9 62 7. Internationalization Considerations . . . . . . . . . . . . . 11 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 65 9.1. Implementation in the gTLD space . . . . . . . . . . . . 12 66 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 68 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 69 13. Change History . . . . . . . . . . . . . . . . . . . . . . . 14 70 13.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 14 71 13.2. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 15 72 13.3. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 16 73 13.4. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 16 74 13.5. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 16 75 13.6. Changes from 05 to 06 . . . . . . . . . . . . . . . . . 16 76 13.7. Changes from 06 to 07 . . . . . . . . . . . . . . . . . 16 77 13.8. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 16 78 13.9. Changes from 08 to 09 . . . . . . . . . . . . . . . . . 17 79 13.10. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 17 80 13.11. Changes from 10 to 11 . . . . . . . . . . . . . . . . . 17 81 13.12. Changes from 11 to REGEXT 00 . . . . . . . . . . . . . . 17 82 13.13. Changes from version REGEXT 00 to REGEXT 01 . . . . . . 17 83 13.14. Changes from version REGEXT 01 to REGEXT 02 . . . . . . 17 84 13.15. Changes from version REGEXT 02 to REGEXT 03 . . . . . . 17 85 13.16. Changes from version REGEXT 03 to REGEXT 04 . . . . . . 17 86 13.17. Changes from version REGEXT 04 to REGEXT 05 . . . . . . 18 87 13.18. Changes from version REGEXT 05 to REGEXT 06 . . . . . . 18 88 13.19. Changes from version REGEXT 06 to REGEXT 07 . . . . . . 18 89 13.20. Changes from version REGEXT 07 to REGEXT 08 . . . . . . 18 90 13.21. Changes from version REGEXT 08 to REGEXT 09 . . . . . . 19 91 13.22. Changes from version REGEXT 09 to REGEXT 10 . . . . . . 19 92 14. Example of a Full Deposit . . . . . . . . . . . . . . . . . . 19 93 15. Example of a Differential Deposit . . . . . . . . . . . . . . 20 94 16. Example of a Incremental Deposit . . . . . . . . . . . . . . 20 95 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 96 17.1. Normative References . . . . . . . . . . . . . . . . . . 21 97 17.2. Informative References . . . . . . . . . . . . . . . . . 22 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 101 1. Introduction 103 Registry Data Escrow is the process by which a registry periodically 104 submits data deposits to a third-party called an escrow agent. These 105 deposits comprise the minimum data needed by a third-party to resume 106 operations if the registry cannot function and is unable or unwilling 107 to facilitate an orderly transfer of service. For example, for a 108 domain name registry or registrar, the data to be deposited would 109 include all the objects related to registered domain names, e.g., 110 names, contacts, name servers, etc. 112 The goal of data escrow is higher resiliency of registration 113 services, for the benefit of Internet users. The beneficiaries of a 114 registry are not just those registering information there, but also 115 the users of services relying on the registry data. 117 In the context of domain name registries, registration data escrow is 118 a requirement for generic top-level domains (e.g., Specification 2 of 119 the ICANN Base Registry Agreement, see [ICANN-GTLD-RA-20170731]) and 120 some country code top-level domain managers are also currently 121 escrowing data. There is also a similar requirement for ICANN- 122 accredited domain registrars. 124 This document specifies a format for data escrow deposits independent 125 of the objects being escrowed. An independent specification is 126 required for each type of registry/set of objects that is expected to 127 be escrowed. 129 The format for data escrow deposits is specified using the Extensible 130 Markup Language (XML) 1.0 as described in [W3C.REC-xml-20081126] and 131 XML Schema notation as described in [W3C.REC-xmlschema-1-20041028] 132 and [W3C.REC-xmlschema-2-20041028]. 134 Readers are advised to read the terminology section carefully to 135 understand the precise meanings of Differential and Incremental 136 Deposits as the definitions used in this document are different from 137 the definitions typically used in the domain of data backups. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 Deposit. Deposits can be of three kinds: Full, Differential or 148 Incremental. For all kinds of deposits, the universe of registry 149 objects to be considered for data escrow are those objects necessary 150 in order to offer the registry services. 152 Differential Deposit. Contains data that reflects all transactions 153 involving the database that were not reflected in the last previous 154 Full, Incremental or Differential Deposit, as the case may be. 155 Differential Deposit files will contain information from all database 156 objects that were added, modified or deleted since the previous 157 deposit was completed as of its defined Timeline Watermark. 159 Domain Name. See definition of Domain name in [RFC8499]. 161 Escrow Agent. The organization designated by the registry or the 162 third-party beneficiary to receive and guard data escrow deposits 163 from the registry. 165 Full Deposit. Contains the registry data that reflects the current 166 and complete registry database and will consist of data that reflects 167 the state of the registry as of a defined Timeline Watermark for the 168 deposit. 170 Incremental Deposit. Contains data that reflects all transactions 171 involving the database that were not reflected in the last previous 172 Full Deposit. Incremental Deposit files will contain information 173 from all database objects that were added, modified or deleted since 174 the previous Full Deposit was completed as of its defined Timeline 175 Watermark. If the Timeline Watermark of an Incremental Deposit were 176 to cover (i.e., one or more Incremental or Differential Deposits 177 exist for the period between the Timeline Watermark of a Full and an 178 Incremental or Differential Deposit) the Timeline Watermark of 179 another Incremental or Differential Deposit since the last Full 180 Deposit, the more recent deposit MUST contain all the transactions of 181 the earlier deposit. 183 Registrar. See definition of Registrar in [RFC8499]. 185 Registry. See definition of Registry in [RFC8499]. 187 Third-Party Beneficiary. Is the organization that, under 188 extraordinary circumstances, would receive the escrow deposits the 189 registry transferred to the escrow agent. This organization could be 190 a backup registry, registry regulator, contracting party of the 191 registry, etc. 193 Timeline Watermark. Point in time on which to base the collecting of 194 database objects for a deposit. Deposits are expected to be 195 consistent to that point in time. 197 Top-Level Domain. See definition of Top-Level Domain (TLD) in 198 [RFC8499]. 200 3. Problem Scope 202 In the past few years, the issue of registry continuity has been 203 carefully considered in the gTLD and ccTLD space. Various 204 organizations have carried out risk analyses and developed business 205 continuity plans to deal with those risks, should they materialize. 207 One of the solutions considered and used, especially in the gTLD 208 space, is Registry Data Escrow as a way to ensure the continuity of 209 registry services in the extreme case of registry failure. 211 So far, almost every registry that uses Registry Data Escrow has its 212 own specification. It is anticipated that more registries will be 213 implementing escrow especially with an increasing number of domain 214 registries coming into service, adding complexity to this issue. 216 It would seem beneficial to have a standardized specification for 217 Registry Data Escrow that can be used by any registry to submit its 218 deposits. 220 While the domain name industry has been the main target for this 221 specification, it has been designed to be as general as possible. 223 Specifications covering the objects used by registration 224 organizations shall identify the format and contents of the deposits 225 a registry has to make, such that a different registry would be able 226 to rebuild the registration services of the former, without its help, 227 in a timely manner, with minimum disruption to its users. 229 Since the details of the registration services provided vary from 230 registry to registry, specifications covering the objects used by 231 registration organizations shall provide mechanisms that allow its 232 extensibility to accommodate variations and extensions of the 233 registration services. 235 Given the requirement for confidentiality and the importance of 236 accuracy of the information that is handled in order to offer 237 registration services, parties using this specification shall define 238 confidentiality and integrity mechanisms for handling the 239 registration data. 241 Specifications covering the objects used by registration 242 organizations shall not include in the specification transient 243 objects that can be recreated by the new registry, particularly those 244 of delicate confidentiality, e.g., DNSSEC KSK/ZSK private keys. 246 Details that are a matter of policy should be identified as such for 247 the benefit of the implementers. 249 Non-technical issues concerning data escrow, such as whether to 250 escrow data and under which purposes the data may be used, are 251 outside of scope of this document. 253 Parties using this specification shall use a signaling mechanism to 254 control the transmission, reception and validation of data escrow 255 deposits. The definition of such a signaling mechanism is out of the 256 scope of this document. 258 4. Conventions Used in This Document 260 The XML namespace prefix "rde" is used for the namespace 261 "urn:ietf:params:xml:ns:rde-1.0", but implementations MUST NOT depend 262 on it; instead, they should employ a proper namespace-aware XML 263 parser and serializer to interpret and output the XML documents. 265 The XML namespace prefix "rdeObj1" and "rdeObj2" with the 266 corresponding namespaces "urn:example:params:xml:ns:rdeObj1-1.0" and 267 "urn:example:params:xml:ns:rdeObj2-1.0" are used as example data 268 escrow objects. 270 4.1. Date and Time 272 Numerous fields indicate "dates", such as the creation and expiry 273 dates for objects. These fields SHALL contain timestamps indicating 274 the date and time in UTC, specified in Internet Date/Time Format (see 275 [RFC3339], Section 5.6) with the time-offset specified as "Z". 277 5. Protocol Description 279 The following is a format for data escrow deposits as produced by a 280 registry. The deposits are represented in XML. Only the format of 281 the objects deposited is defined. Nothing is prescribed about the 282 method used to transfer such deposits between the registry and the 283 escrow agent or vice versa. 285 The protocol intends to be object agnostic allowing the "overload" of 286 abstract elements using the "substitutionGroup" attribute of the XML 287 Schema element to define the actual elements of an object to be 288 escrowed. 290 The specification for each object to be escrowed MUST declare the 291 identifier to be used to reference the object to be deleted or added/ 292 modified. 294 5.1. Root element 296 The container or root element for a Registry Data Escrow deposit is 297 . 299 The element contains the following attributes: 301 o A REQUIRED "type" attribute that is used to identify the kind of 302 deposit: 304 * FULL: Full. 306 * INCR: Incremental. 308 * DIFF: Differential. 310 o A REQUIRED "id" attribute that is used to uniquely identify the 311 escrow deposit. Each registry is responsible for maintaining its 312 own escrow deposits' identifier space to ensure uniqueness. 314 o A "prevId" attribute that can be used to identify the previous 315 Incremental, Differential or Full Deposit. This attribute is 316 REQUIRED in Differential Deposits ("DIFF" type), is OPTIONAL in 317 Incremental Deposits ("INCR" type), and is not used in Full 318 Deposits ("FULL" type). 320 o An OPTIONAL "resend" attribute that is incremented each time the 321 escrow deposit failed the verification procedure at the receiving 322 party and a new escrow deposit needs to be generated by the 323 registry for that specific date. The first time a deposit is 324 generated the attribute is either omitted or MUST be "0". If a 325 deposit needs to be generated again, the attribute MUST be set to 326 "1", and so on. 328 The element contains the following the child elements: 330 5.1.1. Child element 332 A REQUIRED element contains the date-time corresponding 333 to the Timeline Watermark of the deposit. 335 5.1.2. Child element 337 This element contains auxiliary information of the data escrow 338 deposit. 340 A REQUIRED element contains the following child elements: 342 o A REQUIRED element that identifies the RDE protocol 343 version, this value MUST be 1.0. 345 o One or more elements that contain namespace URIs 346 representing the and element objects. 348 5.1.3. Child element 350 For Differential Deposits, this element contains the list of objects 351 that have been deleted since the previous deposit of any type. For 352 Incremental Deposits, this element contains the list of objects that 353 have been deleted since the previous Full Deposit. 355 This section of the deposit MUST NOT be present in Full Deposits. 357 5.1.4. Child element 359 For Full Deposits this element contains all objects. For 360 Differential Deposits, this element contains the list of objects that 361 have been added or modified since the previous deposit of any type. 362 For Incremental Deposits, this element contains the list of objects 363 that have been added or modified since the previous Full Deposit. 365 5.2. Rebuilding the registry from data escrow deposits 367 When applying Incremental or Differential Deposits (when rebuilding 368 the registry from data escrow deposits), the relative order of the 369 and elements is important because dependencies 370 may exist between the objects. All the elements MUST be 371 applied first, in the order that they appear. All the 372 elements MUST be applied next, in the order that they appear. 374 If an object is present in the or section of 375 several deposits (e.g. Full and Differential) the registry data from 376 the latest deposit (as defined by the Timeline Watermark) SHOULD be 377 used when rebuilding the registry. An object SHOULD NOT exist 378 multiple times either in the or elements in a 379 single deposit. 381 When rebuilding a registry, the section MUST be ignored if 382 present in a Full Deposit. 384 6. Formal Syntax 386 RDE is specified in XML Schema notation. The formal syntax presented 387 here is a complete schema representation of RDE suitable for 388 automated validation of RDE XML instances. 390 The BEGIN and END tags are not part of the schema; they are used to 391 note the beginning and ending of the schema for URI registration 392 purposes. 394 6.1. RDE Schema 396 BEGIN 397 398 403 404 405 Registry Data Escrow schema 406 407 409 410 412 413 414 415 416 417 418 419 420 421 422 423 424 426 427 428 429 430 431 433 435 436 437 438 439 440 442 443 444 445 446 447 449 450 451 452 453 454 456 457 458 459 460 461 463 464 465 466 467 468 469 470 472 473 474 475 476 477 479 480 481 482 483 484 485 487 488 END 490 7. Internationalization Considerations 492 Data escrow deposits are represented in XML, which provides native 493 support for encoding information using the Unicode character set and 494 its more compact representations including UTF-8. Conformant XML 495 processors recognize both UTF-8 and UTF-16. Though XML includes 496 provisions to identify and use other character encodings through use 497 of an "encoding" attribute in an declaration, use of UTF-8 is 498 RECOMMENDED. 500 8. IANA Considerations 502 This document uses URNs to describe XML namespaces and XML schemas 503 conforming to a registry mechanism described in [RFC3688]. Two URI 504 assignments have been registered by the IANA. 506 Registration request for the RDE namespace: 508 URI: urn:ietf:params:xml:ns:rde-1.0 510 Registrant Contact: IESG 512 Note to RFC Editor: Please remove the email address from the RFC 513 after IANA records it. 515 XML: None. Namespace URIs do not represent an XML specification. 517 Registration request for the RDE XML schema: 519 URI: urn:ietf:params:xml:schema:rde-1.0 521 Registrant Contact: IESG 523 Note to RFC Editor: Please remove the email address from the RFC 524 after IANA records it. 526 See the "Formal Syntax" section of this document. 528 9. Implementation Status 530 Note to RFC Editor: Please remove this section and the reference to 531 RFC 7942 [RFC7942] before publication. 533 This section records the status of known implementations of the 534 protocol defined by this specification at the time of posting of this 535 Internet-Draft, and is based on a proposal described in RFC 7942 536 [RFC7942]. The description of implementations in this section is 537 intended to assist the IETF in its decision processes in progressing 538 drafts to RFCs. Please note that the listing of any individual 539 implementation here does not imply endorsement by the IETF. 540 Furthermore, no effort has been spent to verify the information 541 presented here that was supplied by IETF contributors. This is not 542 intended as, and must not be construed to be, a catalog of available 543 implementations or their features. Readers are advised to note that 544 other implementations may exist. 546 According to RFC 7942 [RFC7942], "this will allow reviewers and 547 working groups to assign due consideration to documents that have the 548 benefit of running code, which may serve as evidence of valuable 549 experimentation and feedback that have made the implemented protocols 550 more mature. It is up to the individual working groups to use this 551 information as they see fit". 553 9.1. Implementation in the gTLD space 555 Organization: ICANN 557 Name: ICANN Registry Agreement 559 Description: the ICANN Base Registry Agreement requires Registries, 560 Data Escrow Agents, and ICANN to implement this specification. ICANN 561 receives daily notifications from Data Escrow Agents confirming that 562 more than 1,200 gTLDs are sending deposits that comply with this 563 specification. ICANN receives on a weekly basis per gTLD, from more 564 than 1,200 gTLD registries, a Bulk Registration Data Access file that 565 also complies with this specification. In addition, ICANN is aware 566 of Registry Service Provider transitions using data files that 567 conform to this specification. 569 Level of maturity: production. 571 Coverage: all aspects of this specification are implemented. 573 Version compatibility: versions 03 - 08 are known to be implemented. 575 Contact: gustavo.lozano@icann.org 576 URL: https://www.icann.org/resources/pages/registries/registries- 577 agreements-en 579 10. Security Considerations 581 This specification does not define the security mechanisms to be used 582 in the transmission of the data escrow deposits, since it only 583 specifies the minimum necessary to enable the rebuilding of a 584 registry from deposits without intervention from the original 585 registry. 587 Depending on local policies, some elements, or, most likely, the 588 whole deposit will be considered confidential. As such, the parties 589 SHOULD take all the necessary precautions such as encrypting the data 590 at rest and in transit to avoid inadvertent disclosure of private 591 data. Regardless of the precautions taken by the parties regarding 592 data at rest and in transit, authentication credentials MUST NOT be 593 escrowed. 595 Authentication of the parties passing data escrow deposit files is 596 also of the utmost importance. The escrow agent MUST properly 597 authenticate the identity of the registry before accepting data 598 escrow deposits. In a similar manner, the registry MUST authenticate 599 the identity of the escrow agent before submitting any data. 601 Additionally, the registry and the escrow agent MUST use integrity 602 checking mechanisms to ensure the data transmitted is what the source 603 intended. Validation of the contents by the escrow agent is 604 RECOMMENDED to ensure not only that the file was transmitted 605 correctly from the registry, but also that the contents are 606 "meaningful". 608 Note: if Transport Layer Security (TLS) is used when providing an 609 escrow services, the recommendations in [RFC7525] MUST be 610 implemented. 612 11. Privacy Considerations 614 This specification defines a format that may be used to escrow 615 personal data. The process of data escrow is governed by a legal 616 document agreed by the parties, and such legal document must ensure 617 that privacy-sensitive and/or personal data receives the required 618 protection. 620 12. Acknowledgments 622 Special suggestions that have been incorporated into this document 623 were provided by James Gould, Edward Lewis, Jaap Akkerhuis, Lawrence 624 Conroy, Marc Groeneweg, Michael Young, Chris Wright, Patrick Mevzek, 625 Stephen Morris, Scott Hollenbeck, Stephane Bortzmeyer, Warren Kumari, 626 Paul Hoffman, Vika Mpisane, Bernie Hoeneisen, Jim Galvin, Andrew 627 Sullivan, Hiro Hotta, Christopher Browne, Daniel Kalchev, David 628 Conrad, James Mitchell, Francisco Obispo, Bhadresh Modi and Alexander 629 Mayrhofer. 631 Shoji Noguchi and Francisco Arias participated as co-authors until 632 version 07 providing invaluable support for this document. 634 13. Change History 636 [[RFC Editor: Please remove this section.]] 638 13.1. Changes from 00 to 01 640 1. Included DNSSEC elements as part of the basic element 641 as defined in RFC 5910. 643 2. Included RGP elements as part of the basic element as 644 defined in RFC 3915. 646 3. Added support for IDNs and IDN variants. 648 4. Eliminated the element and all its subordinate 649 objects, except . 651 5. Renamed to and included it directly 652 under root element. 654 6. Renamed root element to . 656 7. Added element under element. 658 8. Added element under element. 660 9. Reversed the order of the and elements. 662 10. Removed minOccurs="0". 664 11. Added element under root element. 666 12. Added element under element. 668 13. Removed element from element. 670 14. Populated the "Security Considerations" section. 672 15. Populated the "Internationalization Considerations" section. 674 16. Populated the "Extension Example" section. 676 17. Added element under element. 678 18. Added element under element. 680 19. Added element under root element. 682 20. Fixed some typographical errors and omissions. 684 13.2. Changes from 01 to 02 686 1. Added definition for "canonical" in the "IDN variants Handling" 687 section. 689 2. Clarified that "blocked" and "reserved" IDN variants are 690 optional. 692 3. Made optional. 694 4. Introduced substitutionGroup as the mechanism for extending the 695 protocol. 697 5. Moved element to be child of . 699 6. Text improvements in the Introduction, Terminology, and Problem 700 Scope per Jay's suggestion. 702 7. Removed from and added instead, 703 which include all the data from the last (pending/processed) 704 transfer request. 706 8. Removed from and added instead, 707 which include all the data from the last (pending/processed) 708 transfer request. 710 9. Fixed some typographical errors and omissions. 712 13.3. Changes from 02 to 03 714 1. Separated domain name objects from protocol. 716 2. Moved elements to be child of and 717 , additionally removed element from 718 ,, , and 719 elements. 721 3. Modified the definition of and . 723 4. Added element under element. 725 5. Fixed some typographical errors and omissions. 727 13.4. Changes from 03 to 04 729 1. Removed objects. 731 2. Populated the "Extension Guidelines" section. 733 3. Fixed some typographical errors and omissions. 735 13.5. Changes from 04 to 05 737 1. Fixes to the XSD. 739 2. Extension Guidelines moved to dnrd-mappings draft. 741 3. Fixed some typographical errors and omissions. 743 13.6. Changes from 05 to 06 745 1. Fix resend definition. 747 13.7. Changes from 06 to 07 749 1. Editorial updates. 751 2. schemaLocation removed from RDE Schema. 753 13.8. Changes from 07 to 08 755 1. Ping update. 757 13.9. Changes from 08 to 09 759 1. Ping update. 761 13.10. Changes from 09 to 10 763 1. Implementation Status section was added. 765 13.11. Changes from 10 to 11 767 1. Ping update. 769 13.12. Changes from 11 to REGEXT 00 771 1. Internet Draft (I-D) adopted by the REGEXT WG. 773 13.13. Changes from version REGEXT 00 to REGEXT 01 775 1. Privacy consideration section was added. 777 13.14. Changes from version REGEXT 01 to REGEXT 02 779 1. Updated the Security Considerations section to make the language 780 normative. 782 2. Updated the rde XML schema to remove the dependency with the 783 eppcom namespace reference. 785 3. Editorial updates. 787 4. Remove the reference to RFC 5730. 789 5. Added complete examples of deposits. 791 13.15. Changes from version REGEXT 02 to REGEXT 03 793 1. The section changed from MUST to SHOULD, in order to 794 accommodate an Incremental or Differential Deposit that only 795 includes deletes. 797 2. Editorial updates. 799 13.16. Changes from version REGEXT 03 to REGEXT 04 801 1. Moved [RFC8499] to the Normative References section. 803 13.17. Changes from version REGEXT 04 to REGEXT 05 805 1. Changes based on the feedback provided here: 806 https://mailarchive.ietf.org/arch/msg/regext/ 807 UNo6YxapgjyerAYv0223zEuzjFk 809 2. The examples of deposits were moved to their own sections. 811 3. elements definition moved to section 5.1. 813 4. The DIFF example was modified to make it more representative of a 814 differential deposit. 816 13.18. Changes from version REGEXT 05 to REGEXT 06 818 1. Normative references for XLM, XML Schema added. 820 2. Text added to define that version MUST be 1.0. 822 3. Normative SHOULD replaced should in the second paragraph in the 823 security section. 825 13.19. Changes from version REGEXT 06 to REGEXT 07 827 1. Registration contact changed in section 8. 829 13.20. Changes from version REGEXT 07 to REGEXT 08 831 1. Changes based on the feedback provided here: 832 https://mailarchive.ietf.org/arch/msg/regext/hDLz2ym4oR-ukA4Fm- 833 QJ8FzaxxE 835 2. Changes based on the feedback provided here: 836 https://mailarchive.ietf.org/arch/msg/regext/780Xw- 837 z1RMRb79nmZ6ABmRTo1fU 839 3. Changes based on the feedback provided here: 840 https://mailarchive.ietf.org/arch/msg/regext/ 841 YnPnrSedrCcgQ2AXbjBTuQzqMds 843 4. Changes based on the feedback provided here: 844 https://mailarchive.ietf.org/arch/msg/regext/ 845 BiV0NHi_k7cYwTiLdLwVgqEcFuo 847 13.21. Changes from version REGEXT 08 to REGEXT 09 849 1. Changes based on the feedback provided here: 850 https://mailarchive.ietf.org/arch/msg/regext/x_8twvi- 851 MS4dDDRfAZfNJH92UaQ 853 2. Changes based on the feedback provided here: 854 https://mailarchive.ietf.org/arch/msg/regext/ 855 B3QTxUCWUE4R_QharAQlA3041j0 857 13.22. Changes from version REGEXT 09 to REGEXT 10 859 1. Changes based on the feedback provided here: 860 https://mailarchive.ietf.org/arch/msg/regext/ 861 UaMNvl1xh60ldjpqHHYc3TNsfhg 863 14. Example of a Full Deposit 865 Example of a Full Deposit with the two example objects rdeObj1 and 866 rdeObj2: 868 869 875 2019-10-17T23:59:59Z 876 877 1.0 878 urn:example:params:xml:ns:rdeObj1-1.0 879 urn:example:params:xml:ns:rdeObj2-1.0 880 881 882 883 EXAMPLE 884 885 886 fsh8013-EXAMPLE 887 888 889 891 15. Example of a Differential Deposit 893 Example of a Differential Deposit with the two example objects 894 rdeObj1 and rdeObj2: 896 897 903 2019-10-18T23:59:59Z 904 905 1.0 906 urn:example:params:xml:ns:rdeObj1-1.0 907 urn:example:params:xml:ns:rdeObj2-1.0 908 909 910 911 EXAMPLE2 912 913 914 sh8014-EXAMPLE 915 916 917 919 16. Example of a Incremental Deposit 921 Example of an Incremental Deposit with the two example objects 922 rdeObj1 and rdeObj2: 924 925 931 2020-03-16T23:59:59Z 932 933 1.0 934 urn:example:params:xml:ns:rdeObj1-1.0 935 urn:example:params:xml:ns:rdeObj2-1.0 936 937 938 939 EXAMPLE1 940 941 942 fsh8013-EXAMPLE 943 944 945 946 947 EXAMPLE2 948 949 950 sh8014-EXAMPLE 951 952 953 955 17. References 957 17.1. Normative References 959 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 960 Requirement Levels", BCP 14, RFC 2119, 961 DOI 10.17487/RFC2119, March 1997, 962 . 964 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 965 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 966 . 968 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 969 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 970 May 2017, . 972 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 973 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 974 January 2019, . 976 [W3C.REC-xml-20081126] 977 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 978 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 979 Edition) REC-xml-20081126", November 2008, 980 . 982 [W3C.REC-xmlschema-1-20041028] 983 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 984 "XML Schema Part 1: Structures Second Edition REC- 985 xmlschema-1-20041028", October 2004, 986 . 988 [W3C.REC-xmlschema-2-20041028] 989 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 990 Second Edition REC-xmlschema-2-20041028", October 2004, 991 . 993 17.2. Informative References 995 [ICANN-GTLD-RA-20170731] 996 ICANN, "Base Registry Agreement 2017-07-31", July 2017, 997 . 1000 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1001 DOI 10.17487/RFC3688, January 2004, 1002 . 1004 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1005 "Recommendations for Secure Use of Transport Layer 1006 Security (TLS) and Datagram Transport Layer Security 1007 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1008 2015, . 1010 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1011 Code: The Implementation Status Section", BCP 205, 1012 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1013 . 1015 Author's Address 1016 Gustavo Lozano 1017 Internet Corporation for Assigned Names and Numbers 1018 12025 Waterfront Drive, Suite 300 1019 Los Angeles 90292 1020 United States of America 1022 Phone: +1.310.823.9358 1023 Email: gustavo.lozano@icann.org