idnits 2.17.1 draft-ietf-regext-data-escrow-03.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 (Dec 16, 2019) is 1591 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 informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 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 Dec 16, 2019 5 Expires: June 18, 2020 7 Registry Data Escrow Specification 8 draft-ietf-regext-data-escrow-03 10 Abstract 12 This document specifies the format and contents of data escrow 13 deposits targeted primarily for domain name registries. However, the 14 specification was designed to be independent of the underlying 15 objects that are being escrowed, therefore it could 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 June 18, 2020. 35 Copyright Notice 37 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. General Conventions . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 58 5.1. Root element . . . . . . . . . . . . . . . . . 6 59 5.2. Child element . . . . . . . . . . . . . . . . 9 60 5.3. Child element . . . . . . . . . . . . . . . . . 9 61 5.4. Child element . . . . . . . . . . . . . . . . . 10 62 5.5. Child element . . . . . . . . . . . . . . . . 10 63 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 64 6.1. RDE Schema . . . . . . . . . . . . . . . . . . . . . . . 10 65 7. Internationalization Considerations . . . . . . . . . . . . . 13 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 68 9.1. Implementation in the gTLD space . . . . . . . . . . . . 15 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 71 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 72 13. Change History . . . . . . . . . . . . . . . . . . . . . . . 16 73 13.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 16 74 13.2. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 17 75 13.3. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 18 76 13.4. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 18 77 13.5. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 18 78 13.6. Changes from 05 to 06 . . . . . . . . . . . . . . . . . 19 79 13.7. Changes from 06 to 07 . . . . . . . . . . . . . . . . . 19 80 13.8. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 19 81 13.9. Changes from 08 to 09 . . . . . . . . . . . . . . . . . 19 82 13.10. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 19 83 13.11. Changes from 10 to 11 . . . . . . . . . . . . . . . . . 19 84 13.12. Changes from 11 to REGEXT 00 . . . . . . . . . . . . . . 19 85 13.13. Changes from version REGEXT 00 to REGEXT 01 . . . . . . 19 86 13.14. Changes from version REGEXT 01 to REGEXT 02 . . . . . . 19 87 13.15. Changes from version REGEXT 02 to REGEXT 03 . . . . . . 20 88 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 14.1. Normative References . . . . . . . . . . . . . . . . . . 20 90 14.2. Informative References . . . . . . . . . . . . . . . . . 20 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 Registry Data Escrow is the process by which a registry periodically 96 submits data deposits to a third-party called an escrow agent. These 97 deposits comprise the minimum data needed by a third-party to resume 98 operations if the registry cannot function and is unable or unwilling 99 to facilitate an orderly transfer of service. For example, for a 100 domain name registry or registrar, the data to be deposited would 101 include all the objects related to registered domain names, e.g., 102 names, contacts, name servers, etc. 104 The goal of data escrow is higher resiliency of registration 105 services, for the benefit of Internet users. The beneficiaries of a 106 registry are not just those registering information there, but all 107 relying parties that need to identify the owners of objects. 109 In the context of domain name registries, registration data escrow is 110 a requirement for generic top-level domains and some country code 111 top-level domain managers are also currently escrowing data. There 112 is also a similar requirement for ICANN-accredited domain registrars. 114 This document specifies a format for data escrow deposits independent 115 of the objects being escrowed. A specification is required for each 116 type of registry/set of objects that is expected to be escrowed. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 Deposit. Deposits can be of three kinds: Full, Differential or 127 Incremental. For all kinds of deposits, the universe of registry 128 objects to be considered for data escrow are those objects necessary 129 in order to offer the registry services. 131 Differential Deposit. Contains data that reflects all transactions 132 involving the database that were not reflected in the last previous 133 Full, Incremental or Differential Deposit, as the case may be. 134 Differential Deposit files will contain information from all database 135 objects that were added, modified or deleted since the previous 136 deposit was completed as of its defined Timeline Watermark. 138 Domain Name. See definition of Domain name in [RFC8499]. 140 Escrow Agent. The organization designated by the registry or the 141 third-party beneficiary to receive and guard data escrow deposits 142 from the registry. 144 Full Deposit. Contains the registry data that reflects the current 145 and complete registry database and will consist of data that reflects 146 the state of the registry as of a defined Timeline Watermark for the 147 deposit. 149 Incremental Deposit. Contains data that reflects all transactions 150 involving the database that were not reflected in the last previous 151 Full Deposit. Incremental Deposit files will contain information 152 from all database objects that were added, modified or deleted since 153 the previous Full Deposit was completed as of its defined Timeline 154 Watermark. If the Timeline Watermark of an Incremental Deposit were 155 to cover the Timeline Watermark of another (Incremental or 156 Differential) Deposit since the last Full Deposit, the more recent 157 deposit MUST contain all the transactions of the earlier deposit. 159 Registrar. See definition of Registrar in [RFC8499]. 161 Registry. See definition of Registry in [RFC8499]. 163 Third-Party Beneficiary. Is the organization that, under 164 extraordinary circumstances, would receive the escrow deposits the 165 registry transferred to the escrow agent. This organization could be 166 a backup registry, registry regulator, contracting party of the 167 registry, etc. 169 Timeline Watermark. Point in time on which to base the collecting of 170 database objects for a deposit. Deposits are expected to be 171 consistent to that point in time. 173 Top-Level Domain. See definition of Top-Level Domain (TLD) in 174 [RFC8499]. 176 3. Problem Scope 178 In the past few years, the issue of registry continuity has been 179 carefully considered in the gTLD and ccTLD space. Various 180 organizations have carried out risk analyses and developed business 181 continuity plans to deal with those risks, should they materialize. 183 One of the solutions considered and used, especially in the gTLD 184 space, is Registry Data Escrow as a way to ensure the continuity of 185 registry services in the extreme case of registry failure. 187 So far, almost every registry that uses Registry Data Escrow has its 188 own specification. It is anticipated that more registries will be 189 implementing escrow especially with an increasing number of domain 190 registries coming into service, adding complexity to this issue. 192 It would seem beneficial to have a standardized specification for 193 Registry Data Escrow that can be used by any registry to submit its 194 deposits. 196 While the main motivation for developing this specification is rooted 197 on the domain name industry, the specification has been designed to 198 be as general as possible. This allows other types of registries to 199 use this base specification and develop their own specifications 200 covering the objects used by other registration organizations. 202 Specifications covering the objects used by registration 203 organizations shall identify the format and contents of the deposits 204 a registry has to make, such that a different registry would be able 205 to rebuild the registration services of the former, without its help, 206 in a timely manner, with minimum disruption to its users. 208 Since the details of the registration services provided vary from 209 registry to registry, specifications covering the objects used by 210 registration organizations shall provide mechanisms that allow its 211 extensibility to accommodate variations and extensions of the 212 registration services. 214 Given the requirement for confidentiality and the importance of 215 accuracy of the information that is handled in order to offer 216 registration services, parties using this specification shall define 217 confidentiality and integrity mechanisms for handling the 218 registration data. 220 Specifications covering the objects used by registration 221 organizations shall not include in the specification transient 222 objects that can be recreated by the new registry, particularly those 223 of delicate confidentiality, e.g., DNSSEC KSK/ZSK private keys. 225 Details that are a matter of policy should be identified as such for 226 the benefit of the implementers. 228 Non-technical issues concerning data escrow, such as whether to 229 escrow data and under which purposes the data may be used, are 230 outside of scope of this document. 232 4. General Conventions 234 The XML namespace prefix "rde" is used for the namespace 235 "urn:ietf:params:xml:ns:rde-1.0", but implementations MUST NOT depend 236 on it; instead, they should employ a proper namespace-aware XML 237 parser and serializer to interpret and output the XML documents. 239 The XML namespace prefix "rdeObj1" and "rdeObj2" with the 240 corresponding namespace "urn:ietf:params:xml:ns:rdeObj1-1.0" and 241 "urn:ietf:params:xml:ns:rdeObj2-1.0" are used as example data escrow 242 objects. 244 4.1. Date and Time 246 Numerous fields indicate "dates", such as the creation and expiry 247 dates for objects. These fields SHALL contain timestamps indicating 248 the date and time in UTC, specified in Internet Date/Time Format (see 249 [RFC3339], Section 5.6) with the time-offset specified as "Z". 251 5. Protocol Description 253 The following is a format for data escrow deposits as produced by a 254 registry. The deposits are represented in XML. Only the format of 255 the objects deposited is defined, nothing is prescribed about the 256 method used to transfer such deposits between the registry and the 257 escrow agent or vice versa. 259 The protocol intends to be object agnostic allowing the "overload" of 260 abstract elements using the "substitutionGroup" attribute of the XML 261 Schema element to define the actual elements of an object to be 262 escrowed. 264 5.1. Root element 266 The container or root element for a Registry Data Escrow deposit is 267 . This element contains the following child elements: 268 , , and elements. This 269 element also contains the following attributes: 271 o A REQUIRED "type" attribute that is used to identify the kind of 272 deposit: FULL (Full), INCR (Incremental) or DIFF (Differential). 274 o A REQUIRED "id" attribute that is used to uniquely identify the 275 escrow deposit. Each registry is responsible for maintaining its 276 own escrow deposits identifier space to ensure uniqueness. 278 o An OPTIONAL "prevId" attribute that can be used to identify the 279 previous Incremental, Differential or Full Deposit. This 280 attribute MUST be used in Differential Deposits ("DIFF" type). 282 o An OPTIONAL "resend" attribute that is incremented each time the 283 escrow deposit failed the verification procedure at the receiving 284 party and a new escrow deposit needs to be generated by the 285 registry for that specific date. The first time a deposit is 286 generated the attribute is either omitted or MUST be "0". If a 287 deposit needs to be generated again, the attribute MUST be set to 288 "1", and so on. 290 Example of a Full Deposit with the two example objects rdeObj1 and 291 rdeObj2: 293 294 300 2019-10-18T00:00:00Z 301 302 1.0 303 urn:ietf:params:xml:ns:rdeObj1-1.0 304 urn:ietf:params:xml:ns:rdeObj2-1.0 305 306 307 308 EXAMPLE 309 310 311 fsh8013-EXAMPLE 312 313 314 316 Example of a Differential Deposit with the two example objects 317 rdeObj1 and rdeObj2: 319 320 326 2019-10-18T00:00:00Z 327 328 1.0 329 urn:ietf:params:xml:ns:rdeObj1-1.0 330 urn:ietf:params:xml:ns:rdeObj2-1.0 331 332 333 334 EXAMPLE1 335 336 337 fsh8013-EXAMPLE 338 339 340 341 342 EXAMPLE2 343 344 345 sh8014-EXAMPLE 346 347 348 350 Example of an Incremental Deposit with the two example objects 351 rdeObj1 and rdeObj2: 353 354 360 2019-10-18T00:00:00Z 361 362 1.0 363 urn:ietf:params:xml:ns:rdeObj1-1.0 364 urn:ietf:params:xml:ns:rdeObj2-1.0 365 366 367 368 EXAMPLE1 369 370 371 fsh8013-EXAMPLE 372 373 374 375 376 EXAMPLE2 377 378 379 sh8014-EXAMPLE 380 381 382 384 5.2. Child element 386 A REQUIRED element contains the data-time corresponding 387 to the Timeline Watermark of the deposit. 389 5.3. Child element 391 This element contains auxiliary information of the data escrow 392 deposit. 394 A REQUIRED element contains the following child elements: 396 o A REQUIRED element that identifies the RDE protocol 397 version. 399 o One or more elements that contain namespace URIs 400 representing the and element objects. 402 5.4. Child element 404 This element SHOULD be present in deposits of type Incremental or 405 Differential. It contains the list of objects that were deleted 406 since the base previous deposit. Each object in this section SHALL 407 contain an ID for the object deleted. 409 This section of the deposit SHOULD NOT be present in Full Deposits. 410 When rebuilding a registry it SHOULD be ignored if present in a Full 411 Deposit. 413 The specification for each object to be escrowed MUST declare the 414 identifier to be used to reference the object to be deleted. 416 5.5. Child element 418 This element of the deposit contains the objects in the deposit. It 419 SHOULD be present in all type of deposits. It contains the data for 420 the objects to be escrowed. The actual objects have to be specified 421 individually. 423 In the case of Incremental or Differential Deposits, the objects 424 indicate whether the object was added or modified after the base 425 previous deposit. In order to distinguish between one and the other, 426 it will be sufficient to check existence of the referenced object in 427 the previous deposit. 429 When applying Incremental or Differential Deposits (when rebuilding 430 the registry from data escrow deposits) the relative order of the 431 elements is important, as is the relative order of the 432 elements. All the elements MUST be applied 433 first, in the order that they appear. All the elements 434 MUST be applied next, in the order that they appear. 436 If an object is present in the section of several deposits 437 (e.g. Full and Differential) the registry data from the latest 438 deposit (as defined by the Timeline Watermark) SHOULD be used when 439 rebuilding the registry. 441 6. Formal Syntax 443 6.1. RDE Schema 445 Copyright (c) 2019 IETF Trust and the persons identified as authors 446 of the code. All rights reserved. 448 Redistribution and use in source and binary forms, with or without 449 modification, are permitted provided that the following conditions 450 are met: 452 o Redistributions of source code must retain the above copyright 453 notice, this list of conditions and the following disclaimer. 455 o Redistributions in binary form must reproduce the above copyright 456 notice, this list of conditions and the following disclaimer in 457 the documentation and/or other materials provided with the 458 distribution. 460 o Neither the name of Internet Society, IETF or IETF Trust, nor the 461 names of specific contributors, may be used to endorse or promote 462 products derived from this software without specific prior written 463 permission. 465 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 466 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 467 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 468 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 469 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 470 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 471 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 472 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 473 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 474 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 475 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 477 BEGIN 478 479 484 485 486 Registry Data Escrow schema 487 488 490 491 493 494 495 496 497 498 499 500 501 502 503 504 505 507 508 509 510 511 512 513 515 516 517 518 519 520 522 523 524 525 526 527 529 530 531 532 533 534 536 537 538 539 540 541 543 544 545 546 547 548 549 550 552 553 554 555 556 557 559 560 561 562 563 564 565 567 568 569 570 571 572 573 575 576 577 578 579 580 581 582 583 END 585 7. Internationalization Considerations 587 Data escrow deposits are represented in XML, which provides native 588 support for encoding information using the Unicode character set and 589 its more compact representations including UTF-8. Conformant XML 590 processors recognize both UTF-8 and UTF-16. Though XML includes 591 provisions to identify and use other character encodings through use 592 of an "encoding" attribute in an declaration, use of UTF-8 is 593 RECOMMENDED. 595 8. IANA Considerations 597 This document uses URNs to describe XML namespaces and XML schemas 598 conforming to a registry mechanism described in [RFC3688]. Two URI 599 assignments have been registered by the IANA. 601 Registration request for the RDE namespace: 603 URI: urn:ietf:params:xml:ns:rde-1.0 605 Registrant Contact: See the "Author's Address" section of this 606 document. 608 XML: None. Namespace URIs do not represent an XML specification. 610 Registration request for the RDE XML schema: 612 URI: urn:ietf:params:xml:schema:rde-1.0 614 Registrant Contact: See the "Author's Address" section of this 615 document. 617 See the "Formal Syntax" section of this document. 619 9. Implementation Status 621 Note to RFC Editor: Please remove this section and the reference to 622 RFC 7942 [RFC7942] before publication. 624 This section records the status of known implementations of the 625 protocol defined by this specification at the time of posting of this 626 Internet-Draft, and is based on a proposal described in RFC 7942 627 [RFC7942]. The description of implementations in this section is 628 intended to assist the IETF in its decision processes in progressing 629 drafts to RFCs. Please note that the listing of any individual 630 implementation here does not imply endorsement by the IETF. 631 Furthermore, no effort has been spent to verify the information 632 presented here that was supplied by IETF contributors. This is not 633 intended as, and must not be construed to be, a catalog of available 634 implementations or their features. Readers are advised to note that 635 other implementations may exist. 637 According to RFC 7942 [RFC7942], "this will allow reviewers and 638 working groups to assign due consideration to documents that have the 639 benefit of running code, which may serve as evidence of valuable 640 experimentation and feedback that have made the implemented protocols 641 more mature. It is up to the individual working groups to use this 642 information as they see fit". 644 9.1. Implementation in the gTLD space 646 Organization: ICANN 648 Name: ICANN Registry Agreement 650 Description: the ICANN Base Registry Agreement requires Registries, 651 Data Escrow Agents, and ICANN to implement this specification. ICANN 652 receives daily notifications from Data Escrow Agents confirming that 653 more than 1,200 gTLDs are sending deposits that comply with this 654 specification. ICANN receives on a weekly basis per gTLD, from more 655 than 1,200 gTLD registries, a Bulk Registration Data Access file that 656 also complies with this specification. In addition, ICANN is aware 657 of Registry Service Provider transitions using data files that 658 conform to this specification. 660 Level of maturity: production. 662 Coverage: all aspects of this specification are implemented. 664 Version compatibility: versions 03 - 08 are known to be implemented. 666 Contact: gustavo.lozano@icann.org 668 URL: https://www.icann.org/resources/pages/registries/registries- 669 agreements-en 671 10. Security Considerations 673 This specification does not define the security mechanisms to be used 674 in the transmission of the data escrow deposits, since it only 675 specifies the minimum necessary to enable the rebuilding of a 676 registry from deposits without intervention from the original 677 registry. 679 Depending on local policies, some elements or most likely, the whole 680 deposit will be considered confidential. As such the registry 681 transmitting the data to the escrow agent SHOULD take all the 682 necessary precautions like encrypting the data itself and/or the 683 transport channel to avoid inadvertent disclosure of private data. 685 It is also of the utmost importance the authentication of the parties 686 passing data escrow deposit files. The escrow agent SHOULD properly 687 authenticate the identity of the registry before accepting data 688 escrow deposits. In a similar manner, the registry SHOULD 689 authenticate the identity of the escrow agent before submitting any 690 data. 692 Additionally, the registry and the escrow agent SHOULD use integrity 693 checking mechanisms to ensure the data transmitted is what the source 694 intended. Validation of the contents by the escrow agent is 695 RECOMMENDED to ensure not only the file was transmitted correctly 696 from the registry, but also the contents are also "meaningful". 698 11. Privacy Considerations 700 This specification defines a format that may be used to escrow 701 personal data. The process of data escrow is governed by a legal 702 document agreed by the parties, and such legal document must regulate 703 the particularities regarding the protection of personal data. 705 12. Acknowledgments 707 Special suggestions that have been incorporated into this document 708 were provided by James Gould, Edward Lewis, Jaap Akkerhuis, Lawrence 709 Conroy, Marc Groeneweg, Michael Young, Chris Wright, Patrick Mevzek, 710 Stephen Morris, Scott Hollenbeck, Stephane Bortzmeyer, Warren Kumari, 711 Paul Hoffman, Vika Mpisane, Bernie Hoeneisen, Jim Galvin, Andrew 712 Sullivan, Hiro Hotta, Christopher Browne, Daniel Kalchev, David 713 Conrad, James Mitchell, Francisco Obispo, Bhadresh Modi and Alexander 714 Mayrhofer. 716 Shoji Noguchi and Francisco Arias participated as co-authors until 717 version 07 providing invaluable support for this document. 719 13. Change History 721 [[RFC Editor: Please remove this section.]] 723 13.1. Changes from 00 to 01 725 1. Included DNSSEC elements as part of the basic element 726 as defined in RFC 5910. 728 2. Included RGP elements as part of the basic element as 729 defined in RFC 3915. 731 3. Added support for IDNs and IDN variants. 733 4. Eliminated the element and all its subordinate 734 objects, except . 736 5. Renamed to and included it directly 737 under root element. 739 6. Renamed root element to . 741 7. Added element under element. 743 8. Added element under element. 745 9. Reversed the order of the and elements. 747 10. Removed minOccurs="0". 749 11. Added element under root element. 751 12. Added element under element. 753 13. Removed element from element. 755 14. Populated the "Security Considerations" section. 757 15. Populated the "Internationalization Considerations" section. 759 16. Populated the "Extension Example" section. 761 17. Added element under element. 763 18. Added element under element. 765 19. Added element under root element. 767 20. Fixed some typographical errors and omissions. 769 13.2. Changes from 01 to 02 771 1. Added definition for "canonical" in the "IDN variants Handling" 772 section. 774 2. Clarified that "blocked" and "reserved" IDN variants are 775 optional. 777 3. Made optional. 779 4. Introduced substitutionGroup as the mechanism for extending the 780 protocol. 782 5. Moved element to be child of . 784 6. Text improvements in the Introduction, Terminology, and Problem 785 Scope per Jay's suggestion. 787 7. Removed from and added instead, 788 which include all the data from the last (pending/processed) 789 transfer request. 791 8. Removed from and added instead, 792 which include all the data from the last (pending/processed) 793 transfer request. 795 9. Fixed some typographical errors and omissions. 797 13.3. Changes from 02 to 03 799 1. Separated domain name objects from protocol. 801 2. Moved elements to be child of and 802 , additionally removed element from 803 ,, , and 804 elements. 806 3. Modified the definition of and . 808 4. Added element under element. 810 5. Fixed some typographical errors and omissions. 812 13.4. Changes from 03 to 04 814 1. Removed objects. 816 2. Populated the "Extension Guidelines" section. 818 3. Fixed some typographical errors and omissions. 820 13.5. Changes from 04 to 05 822 1. Fixes to the XSD. 824 2. Extension Guidelines moved to dnrd-mappings draft. 826 3. Fixed some typographical errors and omissions. 828 13.6. Changes from 05 to 06 830 1. Fix resend definition. 832 13.7. Changes from 06 to 07 834 1. Editorial updates. 836 2. schemaLocation removed from RDE Schema. 838 13.8. Changes from 07 to 08 840 1. Ping update. 842 13.9. Changes from 08 to 09 844 1. Ping update. 846 13.10. Changes from 09 to 10 848 1. Implementation Status section was added. 850 13.11. Changes from 10 to 11 852 1. Ping update. 854 13.12. Changes from 11 to REGEXT 00 856 1. Internet Draft (I-D) adopted by the REGEXT WG. 858 13.13. Changes from version REGEXT 00 to REGEXT 01 860 1. Privacy consideration section was added. 862 13.14. Changes from version REGEXT 01 to REGEXT 02 864 1. Updated the Security Considerations section to make the language 865 normative. 867 2. Updated the rde XML schema to remove the dependency with the 868 eppcom namespace reference. 870 3. Editorial updates. 872 4. Remove the reference to RFC 5730. 874 5. Added complete examples of deposits. 876 13.15. Changes from version REGEXT 02 to REGEXT 03 878 1. The section changed from MUST to SHOULD, in order to 879 accommodate an Incremental or Differential Deposit that only 880 includes deletes. 882 2. Editorial updates. 884 14. References 886 14.1. Normative References 888 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 889 Requirement Levels", BCP 14, RFC 2119, 890 DOI 10.17487/RFC2119, March 1997, 891 . 893 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 894 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 895 . 897 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 898 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 899 May 2017, . 901 14.2. Informative References 903 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 904 DOI 10.17487/RFC3688, January 2004, 905 . 907 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 908 Code: The Implementation Status Section", BCP 205, 909 RFC 7942, DOI 10.17487/RFC7942, July 2016, 910 . 912 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 913 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 914 January 2019, . 916 Author's Address 917 Gustavo Lozano 918 Internet Corporation for Assigned Names and Numbers 919 12025 Waterfront Drive, Suite 300 920 Los Angeles 90292 921 United States of America 923 Phone: +1.310.823.9358 924 Email: gustavo.lozano@icann.org