idnits 2.17.1 draft-ietf-regext-data-escrow-00.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 18, 2019) is 1767 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 18, 2019 5 Expires: December 20, 2019 7 Registry Data Escrow Specification 8 draft-ietf-regext-data-escrow-00 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 December 20, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 5 58 5.1. Root element . . . . . . . . . . . . . . . . . 6 59 5.2. Child element . . . . . . . . . . . . . . . . 7 60 5.3. Child element . . . . . . . . . . . . . . . . . 7 61 5.4. Child element . . . . . . . . . . . . . . . . . 8 62 5.5. Child element . . . . . . . . . . . . . . . . 8 63 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 64 6.1. RDE Schema . . . . . . . . . . . . . . . . . . . . . . . 9 65 7. Internationalization Considerations . . . . . . . . . . . . . 12 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 68 9.1. Implementation in the gTLD space . . . . . . . . . . . . 13 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 71 12. Change History . . . . . . . . . . . . . . . . . . . . . . . 15 72 12.1. Changes from version 00 to 01 . . . . . . . . . . . . . 15 73 12.2. Changes from version 01 to 02 . . . . . . . . . . . . . 16 74 12.3. Changes from version 02 to 03 . . . . . . . . . . . . . 16 75 12.4. Changes from version 03 to 04 . . . . . . . . . . . . . 17 76 12.5. Changes from version 04 to 05 . . . . . . . . . . . . . 17 77 12.6. Changes from version 05 to 06 . . . . . . . . . . . . . 17 78 12.7. Changes from version 06 to 07 . . . . . . . . . . . . . 17 79 12.8. Changes from version 07 to 08 . . . . . . . . . . . . . 17 80 12.9. Changes from version 08 to 09 . . . . . . . . . . . . . 17 81 12.10. Changes from version 09 to 10 . . . . . . . . . . . . . 17 82 12.11. Changes from version 10 to 11 . . . . . . . . . . . . . 18 83 12.12. Changes from version 11 to 00 . . . . . . . . . . . . . 18 84 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 86 13.2. Informative References . . . . . . . . . . . . . . . . . 18 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 89 1. Introduction 91 Registry Data Escrow is the process by which an Registry periodically 92 submits data deposits to a third party called an Escrow Agent. These 93 deposits comprise the minimum data needed by a third party to resume 94 operations if the registry can not function and is unable or 95 unwilling to facilitate an orderly transfer of service. For example, 96 for a domain name registry or registrar the data to be deposited 97 would include all the objects related to registered domain names, 98 e.g., names, contacts, name servers, etc. 100 The goal of data escrow is higher resiliency of registration 101 services, for the benefit of Internet users. The beneficiaries of a 102 registry are not just those registering information there, but all 103 relying parties that need to identify the owners of objects. 105 In the context of domain name registries, registration data escrow is 106 a requirement for generic top-level domains and some country code 107 top-level domain managers are also currently escrowing data. There 108 is also a similar requirement for ICANN-accredited domain registrars. 110 This document specifies a format for data escrow deposits independent 111 of the objects being escrowed. A specification is required for each 112 type of registry/set of objects that is expected to be escrowed. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in BCP 14, [RFC2119]. 120 DEPOSIT. Deposits can be of three kinds: Full, Differential or 121 Incremental. For all kinds of Deposits, the Universe of Registry 122 objects to be considered for data escrow are those objects necessary 123 in order to offer the Registry Services. 125 DIFFERENTIAL DEPOSIT. Contains data that reflects all transactions 126 involving the database that were not reflected in the last previous 127 Full, Incremental or Differential Deposit, as the case may be. 128 Differential deposit files will contain information from all database 129 objects that were added, modified or deleted since the previous 130 Deposit was completed as of its defined Timeline Watermark. 132 ESCROW AGENT. The organization designated by the Registry or the 133 Third-Party Beneficiary to receive and guard Data Escrow Deposits 134 from the Registry. 136 FULL DEPOSIT. Contains the Registry Data that reflects the current 137 and complete Registry Database and will consist of data that reflects 138 the state of the registry as of a defined Timeline Watermark for the 139 deposit. 141 INCREMENTAL DEPOSIT. Contains data that reflects all transactions 142 involving the database that were not reflected in the last previous 143 Full Deposit. Incremental Deposit files will contain information 144 from all database objects that were added, modified or deleted since 145 the previous Full Deposit was completed as of its defined Timeline 146 Watermark. If the Timeline Watermark of an Incremental Deposit were 147 to cover the Watermark of another (Incremental or Differential) 148 Deposit since the last Full Deposit, the more recent Deposit MUST 149 contain all the transactions of the earlier Deposit. 151 REGISTRY. A registration organization providing registration 152 services for a certain type of objects, e.g., domain names, IP number 153 resources, routing information. 155 THIRD-PARTY BENEFICIARY. Is the organization that, under 156 extraordinary circumstances, would receive the escrow Deposits the 157 Registry transferred to the Escrow Agent. This organization could be 158 a backup Registry, Registry regulator, contracting party of the 159 Registry, etc. 161 TIMELINE WATERMARK. Point in time on which to base the collecting of 162 database objects for a Deposit. Deposits are expected to be 163 consistent to that point in time. 165 3. Problem Scope 167 In the past few years, the issue of Registry continuity has been 168 carefully considered in the gTLD and ccTLD space. Various 169 organizations have carried out risk analyses and developed business 170 continuity plans to deal with those risks, should they materialize. 172 One of the solutions considered and used, especially in the gTLD 173 space, is Registry Data Escrow as a way to ensure the Continuity of 174 Registry Services in the extreme case of Registry failure. 176 So far, almost every Registry that uses Registry Data Escrow has its 177 own specification. It is anticipated that more Registries will be 178 implementing escrow especially with an increasing number of domain 179 registries coming into service, adding complexity to this issue. 181 It would seem beneficial to have a standardized specification for 182 Registry Data Escrow that can be used by any Registry to submit its 183 deposits. 185 While the main motivation for developing this solution is rooted on 186 the domain name industry, the specification has been designed to be 187 as general as possible. This allows other types of registries to use 188 the base specification and develop their own specifications covering 189 the objects used by other registration organizations. 191 A solution to the problem at hand SHALL clearly identify the format 192 and contents of the deposits a Registry has to make, such that a 193 different Registry would be able to rebuild the registration services 194 of the former, without its help, in a timely manner, with minimum 195 disruption to its users. 197 Since the details of the registration services provided vary from 198 Registry to Registry, the solution SHALL provide mechanisms that 199 allow its extensibility to accommodate variations and extensions of 200 the registration services. 202 Given the requirement for confidentiality and the importance of 203 accuracy of the information that is handled in order to offer 204 registration services, the solution SHALL define confidentiality and 205 integrity mechanisms for handling the registration data. 207 The solution SHALL NOT include in the specification transient objects 208 that can be recreated by the new Registry, particularly those of 209 delicate confidentiality, e.g., DNSSEC KSK/ZSK private keys. 211 Details that are a matter of policy SHOULD be identified as such for 212 the benefit of the implementers. 214 Non-technical issues concerning Data Escrow, such as whether to 215 escrow data and under which purposes the data may be used, are 216 outside of scope of this document. 218 4. General Conventions 220 4.1. Date and Time 222 Numerous fields indicate "dates", such as the creation and expiry 223 dates for objects. These fields SHALL contain timestamps indicating 224 the date and time in UTC, specified in Internet Date/Time Format (see 225 [RFC3339], Section 5.6) with the time-offset specified as "Z". 227 5. Protocol Description 229 The following is a format for Data Escrow deposits as produced by a 230 Registry. The deposits are represented in XML. Only the format of 231 the objects deposited is defined, nothing is prescribed about the 232 method used to transfer such deposits between the Registry and the 233 Escrow Agent or vice versa. 235 The protocol intends to be object agnostic allowing the "overload" of 236 abstract elements using the "substitutionGroup" attribute to define 237 the actual elements of an object to be escrowed. 239 5.1. Root element 241 The container or root element for a Registry Data Escrow deposits is 242 . This element contains the following child elements: 243 watermark, deletes and contents. This element also contains the 244 following attributes: 246 o A REQUIRED "type" attribute that is used to identify the kind of 247 deposit: FULL, INCR (Incremental) or DIFF (Differential). 249 o A REQUIRED "id" attribute that is used to uniquely identify the 250 escrow deposit. Each registry is responsible for maintaining its 251 own escrow deposits identifier space to ensure uniqueness, e.g., 252 using identifiers as described in Section 2.8 of [RFC5730]. 254 o An OPTIONAL "prevId" attribute that can be used to identify the 255 previous incremental, differential or full escrow deposit. This 256 attribute MUST be used in Differential Deposits ("DIFF" type). 258 o An OPTIONAL "resend" attribute that is incremented each time the 259 escrow deposit failed the verification procedure at the receiving 260 party and a new escrow deposit needs to be generated by the 261 Registry for that specific date. The first time a deposit is 262 generated the attribute is either omitted or MUST be "0". If a 263 deposit needs to be generated again, the attribute MUST be set to 264 "1", and so on. 266 Example of root element object: 268 269 274 2010-10-18T00:00:00Z 275 276 ... 277 278 279 ... 280 281 283 5.2. Child element 285 A REQUIRED element contains the data-time corresponding 286 to the Timeline Watermark of the deposit. 288 Example of element object: 290 291 296 2010-10-18T00:00:00Z 297 ... 298 300 5.3. Child element 302 This element contains auxiliary information of the data escrow 303 deposit. 305 A REQUIRED element contains the following child elements: 307 o A REQUIRED element that identifies the RDE protocol 308 version. 310 o One or more elements that contain namespace URIs 311 representing the and element objects. 313 Example of element object: 315 316 320 1.0 321 urn:ietf:params:xml:ns:rdeContact-1.0 322 urn:ietf:params:xml:ns:rdeHost-1.0 323 urn:ietf:params:xml:ns:rdeDomain-1.0 324 urn:ietf:params:xml:ns:rdeRegistrar-1.0 325 urn:ietf:params:xml:ns:rdeIDN-1.0 326 urn:ietf:params:xml:ns:rdeNNDN-1.0 327 urn:ietf:params:xml:ns:rdeEppParams-1.0 328 329 ... 330 331 5.4. Child element 333 This element SHOULD be present in deposits of type Incremental or 334 Differential. It contains the list of objects that were deleted 335 since the base previous deposit. Each object in this section SHALL 336 contain an ID for the object deleted. 338 This section of the deposit SHOULD NOT be present in Full deposits. 339 When rebuilding a registry it SHOULD be ignored if present in a Full 340 deposit. 342 The specification for each object to be escrowed MUST declare the 343 identifier to be used to reference the object to be deleted. 345 Example of element object: 347 348 352 353 foo.test 354 bar.test 355 356 357 sh8013-TEST 358 co8013-TEST 359 360 361 ... 362 364 5.5. Child element 366 This element of the deposit contains the objects in the deposit. It 367 MUST be present in all type of deposits. It contains the data for 368 the objects to be escrowed. The actual objects have to be specified 369 individually. 371 In the case of Incremental or Differential deposits, the objects 372 indicate whether the object was added or modified after the base 373 previous deposit. In order to distinguish between one and the other, 374 it will be sufficient to check existence of the referenced object in 375 the base previous deposit. 377 When applying Incremental or Differential deposits (when rebuilding 378 the registry from data escrow deposits) the relative order of the 379 elements is important, as is the relative order of the 380 elements. All the elements MUST be applied 381 first, in the order that they appear. All the elements 382 MUST be applied next, in the order that they appear. 384 If an object is present in the section of several Deposits 385 (e.g. Full and Differential) the registry data from the latest 386 Deposit (as defined by the Timeline Watermark) SHOULD be used when 387 rebuilding the registry. 389 Example of element object: 391 392 396 ... 397 398 399 Object1 specific. 400 ... 401 402 403 Object2 specific. 404 ... 405 406 407 ... 408 409 ... 410 412 6. Formal Syntax 414 6.1. RDE Schema 416 Copyright (c) 2011 IETF Trust and the persons identified as authors 417 of the code. All rights reserved. 419 Redistribution and use in source and binary forms, with or without 420 modification, are permitted provided that the following conditions 421 are met: 423 o Redistributions of source code must retain the above copyright 424 notice, this list of conditions and the following disclaimer. 426 o Redistributions in binary form must reproduce the above copyright 427 notice, this list of conditions and the following disclaimer in 428 the documentation and/or other materials provided with the 429 distribution. 431 o Neither the name of Internet Society, IETF or IETF Trust, nor the 432 names of specific contributors, may be used to endorse or promote 433 products derived from this software without specific prior written 434 permission. 436 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 437 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 438 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 439 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 440 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 441 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 442 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 443 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 444 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 445 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 446 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 448 BEGIN 449 450 456 457 458 Registry Data Escrow schema 459 460 462 464 465 467 468 469 470 471 472 473 475 476 477 478 479 480 482 483 484 485 486 487 488 490 491 492 493 494 495 497 498 499 500 501 502 504 505 506 507 508 509 511 512 513 514 515 516 518 519 520 521 522 523 524 525 527 528 529 530 531 532 534 535 536 537 538 539 540 542 543 544 545 546 547 548 549 550 END 552 7. Internationalization Considerations 554 Data Escrow deposits are represented in XML, which provides native 555 support for encoding information using the Unicode character set and 556 its more compact representations including UTF-8. Conformant XML 557 processors recognize both UTF-8 and UTF-16. Though XML includes 558 provisions to identify and use other character encodings through use 559 of an "encoding" attribute in an declaration, use of UTF-8 is 560 RECOMMENDED. 562 8. IANA Considerations 564 This document uses URNs to describe XML namespaces and XML schemas 565 conforming to a registry mechanism described in [RFC3688]. Two URI 566 assignments have been registered by the IANA. 568 Registration request for the RDE namespace: 570 URI: urn:ietf:params:xml:ns:rde-1.0 571 Registrant Contact: See the "Author's Address" section of this 572 document. 574 XML: None. Namespace URIs do not represent an XML specification. 576 Registration request for the RDE XML schema: 578 URI: urn:ietf:params:xml:schema:rde-1.0 580 Registrant Contact: See the "Author's Address" section of this 581 document. 583 See the "Formal Syntax" section of this document. 585 9. Implementation Status 587 Note to RFC Editor: Please remove this section and the reference to 588 RFC 7942 [RFC7942] before publication. 590 This section records the status of known implementations of the 591 protocol defined by this specification at the time of posting of this 592 Internet-Draft, and is based on a proposal described in RFC 7942 593 [RFC7942]. The description of implementations in this section is 594 intended to assist the IETF in its decision processes in progressing 595 drafts to RFCs. Please note that the listing of any individual 596 implementation here does not imply endorsement by the IETF. 597 Furthermore, no effort has been spent to verify the information 598 presented here that was supplied by IETF contributors. This is not 599 intended as, and must not be construed to be, a catalog of available 600 implementations or their features. Readers are advised to note that 601 other implementations may exist. 603 According to RFC 7942 [RFC7942], "this will allow reviewers and 604 working groups to assign due consideration to documents that have the 605 benefit of running code, which may serve as evidence of valuable 606 experimentation and feedback that have made the implemented protocols 607 more mature. It is up to the individual working groups to use this 608 information as they see fit". 610 9.1. Implementation in the gTLD space 612 Organization: ICANN 614 Name: ICANN Registry Agreement 616 Description: the ICANN Base Registry Agreement requires Registries, 617 Data Escrow Agents, and ICANN to implement this specification. ICANN 618 receives daily notifications from Data Escrow Agents confirming that 619 more than 1,200 gTLDs are sending deposits that comply with this 620 specification. ICANN receives on a weekly basis per gTLD, from more 621 than 1,200 gTLD registries, a Bulk Registration Data Access file that 622 also complies with this specification. In addition, ICANN is aware 623 of Registry Service Provider transitions using data files that 624 conform to this specification. 626 Level of maturity: production. 628 Coverage: all aspects of this specification are implemented. 630 Version compatibility: versions 03 - 08 are known to be implemented. 632 Contact: gustavo.lozano@icann.org 634 URL: https://www.icann.org/resources/pages/registries/registries- 635 agreements-en 637 10. Security Considerations 639 This specification does not define the security mechanisms to be used 640 in the transmission of the data escrow deposits, since it only 641 specifies the minimum necessary to enable the rebuilding of a 642 Registry from deposits without intervention from the original 643 Registry. 645 Depending on local policies, some elements or most likely, the whole 646 deposit will be considered confidential. As such the Registry 647 transmitting the data to the Escrow Agent must take all the necessary 648 precautions like encrypting the data itself and/or the transport 649 channel to avoid inadvertent disclosure of private data. 651 Mutual authentication of both parties passing data escrow deposit 652 files is of the utmost importance. The Escrow Agent should properly 653 authenticate the identity of the Registry before accepting data 654 escrow deposits. In a similar manner, the Registry should 655 authenticate the identity of the Escrow Agent before submitting any 656 data. 658 Additionally, the Registry and the Escrow Agent should use integrity 659 checking mechanisms to ensure the data transmitted is what the source 660 intended. It is recommended that specifications defining format and 661 semantics for particular business models define an algorithm that 662 Escrow Agents and Third-Party Beneficiaries could use to validate the 663 contents of the data escrow deposit. 665 11. Acknowledgments 667 Special suggestions that have been incorporated into this document 668 were provided by James Gould, Edward Lewis, Jaap Akkerhuis, Lawrence 669 Conroy, Marc Groeneweg, Michael Young, Chris Wright, Patrick Mevzek, 670 Stephen Morris, Scott Hollenbeck, Stephane Bortzmeyer, Warren Kumari, 671 Paul Hoffman, Vika Mpisane, Bernie Hoeneisen, Jim Galvin, Andrew 672 Sullivan, Hiro Hotta, Christopher Browne, Daniel Kalchev, David 673 Conrad, James Mitchell, Francisco Obispo, Bhadresh Modi and Alexander 674 Mayrhofer. 676 Shoji Noguchi and Francisco Arias participated as co-authors until 677 version 07 providing invaluable support for this document. 679 12. Change History 681 12.1. Changes from version 00 to 01 683 1. Included DNSSEC elements as part of the basic element 684 as defined in RFC 5910. 686 2. Included RGP elements as part of the basic element as 687 defined in RFC 3915. 689 3. Added support for IDNs and IDN variants. 691 4. Eliminated the element and all its subordinate 692 objects, except . 694 5. Renamed to and included it directly 695 under root element. 697 6. Renamed root element to . 699 7. Added element under element. 701 8. Added element under element. 703 9. Reversed the order of the and elements. 705 10. Removed minOccurs="0". 707 11. Added element under root element. 709 12. Added element under element. 711 13. Removed element from element. 713 14. Populated the "Security Considerations" section. 715 15. Populated the "Internationalization Considerations" section. 717 16. Populated the "Extension Example" section. 719 17. Added element under element. 721 18. Added element under element. 723 19. Added element under root element. 725 20. Fixed some typographical errors and omissions. 727 12.2. Changes from version 01 to 02 729 1. Added definition for "canonical" in the "IDN variants Handling" 730 section. 732 2. Clarified that "blocked" and "reserved" IDN variants are 733 optional. 735 3. Made optional. 737 4. Introduced substitutionGroup as the mechanism for extending the 738 protocol. 740 5. Moved element to be child of 742 6. Text improvements in the Introduction, Terminology, and Problem 743 Scope per Jay's suggestion. 745 7. Removed from and added instead, 746 which include all the data from the last (pending/processed) 747 transfer request 749 8. Removed from and added instead, 750 which include all the data from the last (pending/processed) 751 transfer request 753 9. Fixed some typographical errors and omissions. 755 12.3. Changes from version 02 to 03 757 1. Separated domain name objects from protocol. 759 2. Moved elements to be child of and 760 , additionally removed element from 761 ,, , and 762 elements. 764 3. Modified the definition of and . 766 4. Added element under element. 768 5. Fixed some typographical errors and omissions. 770 12.4. Changes from version 03 to 04 772 1. Removed objects. 774 2. Populated the "Extension Guidelines" section. 776 3. Fixed some typographical errors and omissions. 778 12.5. Changes from version 04 to 05 780 1. Fixes to the XSD 782 2. Extension Guidelines moved to dnrd-mappings draft 784 3. Fixed some typographical errors and omissions. 786 12.6. Changes from version 05 to 06 788 1. Fix resend definition. 790 12.7. Changes from version 06 to 07 792 1. Editorial updates. 794 2. schemaLocation removed from RDE Schema. 796 12.8. Changes from version 07 to 08 798 1. Ping update 800 12.9. Changes from version 08 to 09 802 1. Ping update. 804 12.10. Changes from version 09 to 10 806 1. Implementation Status section was added 808 12.11. Changes from version 10 to 11 810 1. Ping update. 812 12.12. Changes from version 11 to 00 814 1. Internet Draft (I-D) adopted by the REGEXT WG. 816 13. References 818 13.1. Normative References 820 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 821 Requirement Levels", BCP 14, RFC 2119, 822 DOI 10.17487/RFC2119, March 1997, 823 . 825 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 826 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 827 . 829 13.2. Informative References 831 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 832 DOI 10.17487/RFC3688, January 2004, 833 . 835 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 836 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 837 . 839 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 840 Code: The Implementation Status Section", BCP 205, 841 RFC 7942, DOI 10.17487/RFC7942, July 2016, 842 . 844 Author's Address 846 Gustavo Lozano 847 Internet Corporation for Assigned Names and Numbers 848 12025 Waterfront Drive, Suite 300 849 Los Angeles 90292 850 United States of America 852 Phone: +1.310.823.9358 853 Email: gustavo.lozano@icann.org