idnits 2.17.1 draft-ietf-regext-data-escrow-08.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 (Apr 27, 2020) is 1460 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 Apr 27, 2020 5 Expires: October 29, 2020 7 Registry Data Escrow Specification 8 draft-ietf-regext-data-escrow-08 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 October 29, 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . 6 59 5.2. Rebuilding the registry from data escrow deposits . . . . 8 60 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 61 6.1. RDE Schema . . . . . . . . . . . . . . . . . . . . . . . 8 62 7. Internationalization Considerations . . . . . . . . . . . . . 10 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 65 9.1. Implementation in the gTLD space . . . . . . . . . . . . 12 66 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 68 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 69 13. Change History . . . . . . . . . . . . . . . . . . . . . . . 13 70 13.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 13 71 13.2. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 14 72 13.3. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 15 73 13.4. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 15 74 13.5. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . 16 79 13.10. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 16 80 13.11. Changes from 10 to 11 . . . . . . . . . . . . . . . . . 16 81 13.12. Changes from 11 to REGEXT 00 . . . . . . . . . . . . . . 16 82 13.13. Changes from version REGEXT 00 to REGEXT 01 . . . . . . 16 83 13.14. Changes from version REGEXT 01 to REGEXT 02 . . . . . . 16 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 . . . . . . 17 87 13.18. Changes from version REGEXT 05 to REGEXT 06 . . . . . . 17 88 13.19. Changes from version REGEXT 06 to REGEXT 07 . . . . . . 17 89 13.20. Changes from version REGEXT 07 to REGEXT 08 . . . . . . 17 90 14. Example of a Full Deposit . . . . . . . . . . . . . . . . . . 18 91 15. Example of a Differential Deposit . . . . . . . . . . . . . . 18 92 16. Example of a Incremental Deposit . . . . . . . . . . . . . . 19 93 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 17.1. Normative References . . . . . . . . . . . . . . . . . . 20 95 17.2. Informative References . . . . . . . . . . . . . . . . . 21 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 98 1. Introduction 100 Registry Data Escrow is the process by which a registry periodically 101 submits data deposits to a third-party called an escrow agent. These 102 deposits comprise the minimum data needed by a third-party to resume 103 operations if the registry cannot function and is unable or unwilling 104 to facilitate an orderly transfer of service. For example, for a 105 domain name registry or registrar, the data to be deposited would 106 include all the objects related to registered domain names, e.g., 107 names, contacts, name servers, etc. 109 The goal of data escrow is higher resiliency of registration 110 services, for the benefit of Internet users. The beneficiaries of a 111 registry are not just those registering information there, but also 112 the users of services relying on the registry data. 114 In the context of domain name registries, registration data escrow is 115 a requirement for generic top-level domains (e.g., Specification 2 of 116 the ICANN Base Registry Agreement, see [ICANN-GTLD-RA-20170731]) and 117 some country code top-level domain managers are also currently 118 escrowing data. There is also a similar requirement for ICANN- 119 accredited domain registrars. 121 This document specifies a format for data escrow deposits independent 122 of the objects being escrowed. An independent specification is 123 required for each type of registry/set of objects that is expected to 124 be escrowed. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 Deposit. Deposits can be of three kinds: Full, Differential or 135 Incremental. For all kinds of deposits, the universe of registry 136 objects to be considered for data escrow are those objects necessary 137 in order to offer the registry services. 139 Differential Deposit. Contains data that reflects all transactions 140 involving the database that were not reflected in the last previous 141 Full, Incremental or Differential Deposit, as the case may be. 142 Differential Deposit files will contain information from all database 143 objects that were added, modified or deleted since the previous 144 deposit was completed as of its defined Timeline Watermark. 146 Domain Name. See definition of Domain name in [RFC8499]. 148 Escrow Agent. The organization designated by the registry or the 149 third-party beneficiary to receive and guard data escrow deposits 150 from the registry. 152 Full Deposit. Contains the registry data that reflects the current 153 and complete registry database and will consist of data that reflects 154 the state of the registry as of a defined Timeline Watermark for the 155 deposit. 157 Incremental Deposit. Contains data that reflects all transactions 158 involving the database that were not reflected in the last previous 159 Full Deposit. Incremental Deposit files will contain information 160 from all database objects that were added, modified or deleted since 161 the previous Full Deposit was completed as of its defined Timeline 162 Watermark. If the Timeline Watermark of an Incremental Deposit were 163 to cover (i.e., one or more Incremental or Differential Deposits 164 exist for the period between the Timeline Watermark of a Full and an 165 Incremental or Differential Deposit) the Timeline Watermark of 166 another Incremental or Differential Deposit since the last Full 167 Deposit, the more recent deposit MUST contain all the transactions of 168 the earlier deposit. 170 Registrar. See definition of Registrar in [RFC8499]. 172 Registry. See definition of Registry in [RFC8499]. 174 Third-Party Beneficiary. Is the organization that, under 175 extraordinary circumstances, would receive the escrow deposits the 176 registry transferred to the escrow agent. This organization could be 177 a backup registry, registry regulator, contracting party of the 178 registry, etc. 180 Timeline Watermark. Point in time on which to base the collecting of 181 database objects for a deposit. Deposits are expected to be 182 consistent to that point in time. 184 Top-Level Domain. See definition of Top-Level Domain (TLD) in 185 [RFC8499]. 187 3. Problem Scope 189 In the past few years, the issue of registry continuity has been 190 carefully considered in the gTLD and ccTLD space. Various 191 organizations have carried out risk analyses and developed business 192 continuity plans to deal with those risks, should they materialize. 194 One of the solutions considered and used, especially in the gTLD 195 space, is Registry Data Escrow as a way to ensure the continuity of 196 registry services in the extreme case of registry failure. 198 So far, almost every registry that uses Registry Data Escrow has its 199 own specification. It is anticipated that more registries will be 200 implementing escrow especially with an increasing number of domain 201 registries coming into service, adding complexity to this issue. 203 It would seem beneficial to have a standardized specification for 204 Registry Data Escrow that can be used by any registry to submit its 205 deposits. 207 While the domain name industry has been the main target for this 208 specification, it has been designed to be as general as possible. 210 Specifications covering the objects used by registration 211 organizations shall identify the format and contents of the deposits 212 a registry has to make, such that a different registry would be able 213 to rebuild the registration services of the former, without its help, 214 in a timely manner, with minimum disruption to its users. 216 Since the details of the registration services provided vary from 217 registry to registry, specifications covering the objects used by 218 registration organizations shall provide mechanisms that allow its 219 extensibility to accommodate variations and extensions of the 220 registration services. 222 Given the requirement for confidentiality and the importance of 223 accuracy of the information that is handled in order to offer 224 registration services, parties using this specification shall define 225 confidentiality and integrity mechanisms for handling the 226 registration data. 228 Specifications covering the objects used by registration 229 organizations shall not include in the specification transient 230 objects that can be recreated by the new registry, particularly those 231 of delicate confidentiality, e.g., DNSSEC KSK/ZSK private keys. 233 Details that are a matter of policy should be identified as such for 234 the benefit of the implementers. 236 Non-technical issues concerning data escrow, such as whether to 237 escrow data and under which purposes the data may be used, are 238 outside of scope of this document. 240 4. Conventions Used in This Document 242 The XML namespace prefix "rde" is used for the namespace 243 "urn:ietf:params:xml:ns:rde-1.0", but implementations MUST NOT depend 244 on it; instead, they should employ a proper namespace-aware XML 245 parser and serializer to interpret and output the XML documents. 247 The XML namespace prefix "rdeObj1" and "rdeObj2" with the 248 corresponding namespaces "urn:example:params:xml:ns:rdeObj1-1.0" and 249 "urn:example:params:xml:ns:rdeObj2-1.0" are used as example data 250 escrow objects. 252 4.1. Date and Time 254 Numerous fields indicate "dates", such as the creation and expiry 255 dates for objects. These fields SHALL contain timestamps indicating 256 the date and time in UTC, specified in Internet Date/Time Format (see 257 [RFC3339], Section 5.6) with the time-offset specified as "Z". 259 5. Protocol Description 261 The following is a format for data escrow deposits as produced by a 262 registry. The deposits are represented in XML. Only the format of 263 the objects deposited is defined. Nothing is prescribed about the 264 method used to transfer such deposits between the registry and the 265 escrow agent or vice versa. 267 The protocol intends to be object agnostic allowing the "overload" of 268 abstract elements using the "substitutionGroup" attribute of the XML 269 Schema element to define the actual elements of an object to be 270 escrowed. 272 The specification for each object to be escrowed MUST declare the 273 identifier to be used to reference the object to be deleted or added/ 274 modified. 276 5.1. Root element 278 The container or root element for a Registry Data Escrow deposit is 279 . 281 The element contains the following attributes: 283 o A REQUIRED "type" attribute that is used to identify the kind of 284 deposit: 286 * FULL: Full. 288 * INCR: Incremental. 290 * DIFF: Differential. 292 o A REQUIRED "id" attribute that is used to uniquely identify the 293 escrow deposit. Each registry is responsible for maintaining its 294 own escrow deposits' identifier space to ensure uniqueness. 296 o A "prevId" attribute that can be used to identify the previous 297 Incremental, Differential or Full Deposit. This attribute is 298 REQUIRED in Differential Deposits ("DIFF" type), is OPTIONAL in 299 Incremental Deposits ("INCR" type), and is not used in Full 300 Deposits ("FULL" type). 302 o An OPTIONAL "resend" attribute that is incremented each time the 303 escrow deposit failed the verification procedure at the receiving 304 party and a new escrow deposit needs to be generated by the 305 registry for that specific date. The first time a deposit is 306 generated the attribute is either omitted or MUST be "0". If a 307 deposit needs to be generated again, the attribute MUST be set to 308 "1", and so on. 310 The element contains the following the child elements: 312 5.1.1. Child element 314 A REQUIRED element contains the date-time corresponding 315 to the Timeline Watermark of the deposit. 317 5.1.2. Child element 319 This element contains auxiliary information of the data escrow 320 deposit. 322 A REQUIRED element contains the following child elements: 324 o A REQUIRED element that identifies the RDE protocol 325 version, this value MUST be 1.0. 327 o One or more elements that contain namespace URIs 328 representing the and element objects. 330 5.1.3. Child element 332 For Differential Deposits, this element contains the list of objects 333 that have been deleted since the previous deposit of any type. For 334 Incremental Deposits, this element contains the list of objects that 335 have been deleted since the previous Full Deposit. 337 This section of the deposit MUST NOT be present in Full Deposits. 339 5.1.4. Child element 341 For Full Deposits this element contains all objects. For 342 Differential Deposits, this element contains the list of objects that 343 have been added or modified since the previous deposit of any type. 344 For Incremental Deposits, this element contains the list of objects 345 that have been added or modified since the previous Full Deposit. 347 5.2. Rebuilding the registry from data escrow deposits 349 When applying Incremental or Differential Deposits (when rebuilding 350 the registry from data escrow deposits), the relative order of the 351 and elements is important because dependencies 352 may exist between the objects. All the elements MUST be 353 applied first, in the order that they appear. All the 354 elements MUST be applied next, in the order that they appear. 356 If an object is present in the or section of 357 several deposits (e.g. Full and Differential) the registry data from 358 the latest deposit (as defined by the Timeline Watermark) SHOULD be 359 used when rebuilding the registry. An object SHOULD NOT exist 360 multiple times either in the or elements in a 361 single deposit. 363 When rebuilding a registry, the section MUST be ignored if 364 present in a Full Deposit. 366 6. Formal Syntax 368 RDE is specified in XML Schema notation. The formal syntax presented 369 here is a complete schema representation of RDE suitable for 370 automated validation of RDE XML instances. 372 The BEGIN and END tags are not part of the schema; they are used to 373 note the beginning and ending of the schema for URI registration 374 purposes. 376 6.1. RDE Schema 378 BEGIN 379 380 384 385 386 Registry Data Escrow schema 387 388 390 391 393 394 395 396 397 398 399 400 401 402 403 404 405 407 408 409 410 411 412 413 415 416 417 418 419 420 422 423 424 425 426 427 429 430 431 432 433 434 436 437 438 439 440 441 443 444 445 446 447 448 449 450 452 453 454 455 456 457 459 460 461 462 463 464 465 467 468 END 470 7. Internationalization Considerations 472 Data escrow deposits are represented in XML, which provides native 473 support for encoding information using the Unicode character set and 474 its more compact representations including UTF-8. Conformant XML 475 processors recognize both UTF-8 and UTF-16. Though XML includes 476 provisions to identify and use other character encodings through use 477 of an "encoding" attribute in an declaration, use of UTF-8 is 478 RECOMMENDED. 480 8. IANA Considerations 482 This document uses URNs to describe XML namespaces and XML schemas 483 conforming to a registry mechanism described in [RFC3688]. Two URI 484 assignments have been registered by the IANA. 486 Registration request for the RDE namespace: 488 URI: urn:ietf:params:xml:ns:rde-1.0 490 Registrant Contact: IESG 492 Note to RFC Editor: Please remove the email address from the RFC 493 after IANA records it. 495 XML: None. Namespace URIs do not represent an XML specification. 497 Registration request for the RDE XML schema: 499 URI: urn:ietf:params:xml:schema:rde-1.0 501 Registrant Contact: IESG 503 Note to RFC Editor: Please remove the email address from the RFC 504 after IANA records it. 506 See the "Formal Syntax" section of this document. 508 9. Implementation Status 510 Note to RFC Editor: Please remove this section and the reference to 511 RFC 7942 [RFC7942] before publication. 513 This section records the status of known implementations of the 514 protocol defined by this specification at the time of posting of this 515 Internet-Draft, and is based on a proposal described in RFC 7942 516 [RFC7942]. The description of implementations in this section is 517 intended to assist the IETF in its decision processes in progressing 518 drafts to RFCs. Please note that the listing of any individual 519 implementation here does not imply endorsement by the IETF. 520 Furthermore, no effort has been spent to verify the information 521 presented here that was supplied by IETF contributors. This is not 522 intended as, and must not be construed to be, a catalog of available 523 implementations or their features. Readers are advised to note that 524 other implementations may exist. 526 According to RFC 7942 [RFC7942], "this will allow reviewers and 527 working groups to assign due consideration to documents that have the 528 benefit of running code, which may serve as evidence of valuable 529 experimentation and feedback that have made the implemented protocols 530 more mature. It is up to the individual working groups to use this 531 information as they see fit". 533 9.1. Implementation in the gTLD space 535 Organization: ICANN 537 Name: ICANN Registry Agreement 539 Description: the ICANN Base Registry Agreement requires Registries, 540 Data Escrow Agents, and ICANN to implement this specification. ICANN 541 receives daily notifications from Data Escrow Agents confirming that 542 more than 1,200 gTLDs are sending deposits that comply with this 543 specification. ICANN receives on a weekly basis per gTLD, from more 544 than 1,200 gTLD registries, a Bulk Registration Data Access file that 545 also complies with this specification. In addition, ICANN is aware 546 of Registry Service Provider transitions using data files that 547 conform to this specification. 549 Level of maturity: production. 551 Coverage: all aspects of this specification are implemented. 553 Version compatibility: versions 03 - 08 are known to be implemented. 555 Contact: gustavo.lozano@icann.org 557 URL: https://www.icann.org/resources/pages/registries/registries- 558 agreements-en 560 10. Security Considerations 562 This specification does not define the security mechanisms to be used 563 in the transmission of the data escrow deposits, since it only 564 specifies the minimum necessary to enable the rebuilding of a 565 registry from deposits without intervention from the original 566 registry. 568 Depending on local policies, some elements or, most likely, the whole 569 deposit will be considered confidential. As such, the registry 570 transmitting the data to the escrow agent SHOULD take all the 571 necessary precautions such as encrypting the data itself and/or the 572 transport channel to avoid inadvertent disclosure of private data. 574 Authentication of the parties passing data escrow deposit files is 575 also of the utmost importance. The escrow agent MUST properly 576 authenticate the identity of the registry before accepting data 577 escrow deposits. In a similar manner, the registry MUST authenticate 578 the identity of the escrow agent before submitting any data. 580 Additionally, the registry and the escrow agent MUST use integrity 581 checking mechanisms to ensure the data transmitted is what the source 582 intended. Validation of the contents by the escrow agent is 583 RECOMMENDED to ensure not only that the file was transmitted 584 correctly from the registry, but also that the contents are 585 "meaningful". 587 Note: if Transport Layer Security (TLS) is used when providing an 588 escrow services, the recommendations in [RFC7525] MUST be 589 implemented. 591 11. Privacy Considerations 593 This specification defines a format that may be used to escrow 594 personal data. The process of data escrow is governed by a legal 595 document agreed by the parties, and such legal document must ensure 596 that privacy-sensitive and/or personal data receives the required 597 protection. 599 12. Acknowledgments 601 Special suggestions that have been incorporated into this document 602 were provided by James Gould, Edward Lewis, Jaap Akkerhuis, Lawrence 603 Conroy, Marc Groeneweg, Michael Young, Chris Wright, Patrick Mevzek, 604 Stephen Morris, Scott Hollenbeck, Stephane Bortzmeyer, Warren Kumari, 605 Paul Hoffman, Vika Mpisane, Bernie Hoeneisen, Jim Galvin, Andrew 606 Sullivan, Hiro Hotta, Christopher Browne, Daniel Kalchev, David 607 Conrad, James Mitchell, Francisco Obispo, Bhadresh Modi and Alexander 608 Mayrhofer. 610 Shoji Noguchi and Francisco Arias participated as co-authors until 611 version 07 providing invaluable support for this document. 613 13. Change History 615 [[RFC Editor: Please remove this section.]] 617 13.1. Changes from 00 to 01 619 1. Included DNSSEC elements as part of the basic element 620 as defined in RFC 5910. 622 2. Included RGP elements as part of the basic element as 623 defined in RFC 3915. 625 3. Added support for IDNs and IDN variants. 627 4. Eliminated the element and all its subordinate 628 objects, except . 630 5. Renamed to and included it directly 631 under root element. 633 6. Renamed root element to . 635 7. Added element under element. 637 8. Added element under element. 639 9. Reversed the order of the and elements. 641 10. Removed minOccurs="0". 643 11. Added element under root element. 645 12. Added element under element. 647 13. Removed element from element. 649 14. Populated the "Security Considerations" section. 651 15. Populated the "Internationalization Considerations" section. 653 16. Populated the "Extension Example" section. 655 17. Added element under element. 657 18. Added element under element. 659 19. Added element under root element. 661 20. Fixed some typographical errors and omissions. 663 13.2. Changes from 01 to 02 665 1. Added definition for "canonical" in the "IDN variants Handling" 666 section. 668 2. Clarified that "blocked" and "reserved" IDN variants are 669 optional. 671 3. Made optional. 673 4. Introduced substitutionGroup as the mechanism for extending the 674 protocol. 676 5. Moved element to be child of . 678 6. Text improvements in the Introduction, Terminology, and Problem 679 Scope per Jay's suggestion. 681 7. Removed from and added instead, 682 which include all the data from the last (pending/processed) 683 transfer request. 685 8. Removed from and added instead, 686 which include all the data from the last (pending/processed) 687 transfer request. 689 9. Fixed some typographical errors and omissions. 691 13.3. Changes from 02 to 03 693 1. Separated domain name objects from protocol. 695 2. Moved elements to be child of and 696 , additionally removed element from 697 ,, , and 698 elements. 700 3. Modified the definition of and . 702 4. Added element under element. 704 5. Fixed some typographical errors and omissions. 706 13.4. Changes from 03 to 04 708 1. Removed objects. 710 2. Populated the "Extension Guidelines" section. 712 3. Fixed some typographical errors and omissions. 714 13.5. Changes from 04 to 05 716 1. Fixes to the XSD. 718 2. Extension Guidelines moved to dnrd-mappings draft. 720 3. Fixed some typographical errors and omissions. 722 13.6. Changes from 05 to 06 724 1. Fix resend definition. 726 13.7. Changes from 06 to 07 728 1. Editorial updates. 730 2. schemaLocation removed from RDE Schema. 732 13.8. Changes from 07 to 08 734 1. Ping update. 736 13.9. Changes from 08 to 09 738 1. Ping update. 740 13.10. Changes from 09 to 10 742 1. Implementation Status section was added. 744 13.11. Changes from 10 to 11 746 1. Ping update. 748 13.12. Changes from 11 to REGEXT 00 750 1. Internet Draft (I-D) adopted by the REGEXT WG. 752 13.13. Changes from version REGEXT 00 to REGEXT 01 754 1. Privacy consideration section was added. 756 13.14. Changes from version REGEXT 01 to REGEXT 02 758 1. Updated the Security Considerations section to make the language 759 normative. 761 2. Updated the rde XML schema to remove the dependency with the 762 eppcom namespace reference. 764 3. Editorial updates. 766 4. Remove the reference to RFC 5730. 768 5. Added complete examples of deposits. 770 13.15. Changes from version REGEXT 02 to REGEXT 03 772 1. The section changed from MUST to SHOULD, in order to 773 accommodate an Incremental or Differential Deposit that only 774 includes deletes. 776 2. Editorial updates. 778 13.16. Changes from version REGEXT 03 to REGEXT 04 780 1. Moved [RFC8499] to the Normative References section. 782 13.17. Changes from version REGEXT 04 to REGEXT 05 784 1. Changes based on the feedback provided here: 785 https://mailarchive.ietf.org/arch/msg/regext/ 786 UNo6YxapgjyerAYv0223zEuzjFk 788 2. The examples of deposits were moved to their own sections. 790 3. elements definition moved to section 5.1. 792 4. The DIFF example was modified to make it more representative of a 793 differential deposit. 795 13.18. Changes from version REGEXT 05 to REGEXT 06 797 1. Normative references for XLM, XML Schema added. 799 2. Text added to define that version MUST be 1.0. 801 3. Normative SHOULD replaced should in the second paragraph in the 802 security section. 804 13.19. Changes from version REGEXT 06 to REGEXT 07 806 1. Registration contact changed in section 8. 808 13.20. Changes from version REGEXT 07 to REGEXT 08 810 1. Changes based on the feedback provided here: 811 https://mailarchive.ietf.org/arch/msg/regext/hDLz2ym4oR-ukA4Fm- 812 QJ8FzaxxE 814 2. Changes based on the feedback provided here: 815 https://mailarchive.ietf.org/arch/msg/regext/780Xw- 816 z1RMRb79nmZ6ABmRTo1fU 818 3. Changes based on the feedback provided here: 819 https://mailarchive.ietf.org/arch/msg/regext/ 820 YnPnrSedrCcgQ2AXbjBTuQzqMds 822 4. Changes based on the feedback provided here: 823 https://mailarchive.ietf.org/arch/msg/regext/ 824 BiV0NHi_k7cYwTiLdLwVgqEcFuo 826 14. Example of a Full Deposit 828 Example of a Full Deposit with the two example objects rdeObj1 and 829 rdeObj2: 831 832 838 2019-10-17T23:59:59Z 839 840 1.0 841 urn:example:params:xml:ns:rdeObj1-1.0 842 urn:example:params:xml:ns:rdeObj2-1.0 843 844 845 846 EXAMPLE 847 848 849 fsh8013-EXAMPLE 850 851 852 854 15. Example of a Differential Deposit 856 Example of a Differential Deposit with the two example objects 857 rdeObj1 and rdeObj2: 859 860 866 2019-10-18T23:59:59Z 867 868 1.0 869 urn:example:params:xml:ns:rdeObj1-1.0 870 urn:example:params:xml:ns:rdeObj2-1.0 871 872 873 874 EXAMPLE2 875 876 877 sh8014-EXAMPLE 878 879 880 882 16. Example of a Incremental Deposit 884 Example of an Incremental Deposit with the two example objects 885 rdeObj1 and rdeObj2: 887 888 894 2020-03-16T23:59:59Z 895 896 1.0 897 urn:example:params:xml:ns:rdeObj1-1.0 898 urn:example:params:xml:ns:rdeObj2-1.0 899 900 901 902 EXAMPLE1 903 904 905 fsh8013-EXAMPLE 906 907 908 909 910 EXAMPLE2 911 912 913 sh8014-EXAMPLE 914 915 916 918 17. References 920 17.1. Normative References 922 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 923 Requirement Levels", BCP 14, RFC 2119, 924 DOI 10.17487/RFC2119, March 1997, 925 . 927 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 928 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 929 . 931 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 932 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 933 May 2017, . 935 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 936 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 937 January 2019, . 939 [W3C.REC-xml-20081126] 940 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 941 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 942 Edition) REC-xml-20081126", November 2008, 943 . 945 [W3C.REC-xmlschema-1-20041028] 946 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 947 "XML Schema Part 1: Structures Second Edition REC- 948 xmlschema-1-20041028", October 2004, 949 . 951 [W3C.REC-xmlschema-2-20041028] 952 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 953 Second Edition REC-xmlschema-2-20041028", October 2004, 954 . 956 17.2. Informative References 958 [ICANN-GTLD-RA-20170731] 959 ICANN, "Base Registry Agreement 2017-07-31", July 2017, 960 . 963 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 964 DOI 10.17487/RFC3688, January 2004, 965 . 967 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 968 "Recommendations for Secure Use of Transport Layer 969 Security (TLS) and Datagram Transport Layer Security 970 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 971 2015, . 973 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 974 Code: The Implementation Status Section", BCP 205, 975 RFC 7942, DOI 10.17487/RFC7942, July 2016, 976 . 978 Author's Address 979 Gustavo Lozano 980 Internet Corporation for Assigned Names and Numbers 981 12025 Waterfront Drive, Suite 300 982 Los Angeles 90292 983 United States of America 985 Phone: +1.310.823.9358 986 Email: gustavo.lozano@icann.org