idnits 2.17.1 draft-ietf-regext-data-escrow-07.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 07, 2020) is 1480 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) Summary: 1 error (**), 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 Apr 07, 2020 5 Expires: October 9, 2020 7 Registry Data Escrow Specification 8 draft-ietf-regext-data-escrow-07 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 October 9, 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. General Conventions . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 58 5.1. Root element . . . . . . . . . . . . . . . . . 6 59 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 60 6.1. RDE Schema . . . . . . . . . . . . . . . . . . . . . . . 8 61 7. Internationalization Considerations . . . . . . . . . . . . . 10 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 64 9.1. Implementation in the gTLD space . . . . . . . . . . . . 11 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 67 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 68 13. Change History . . . . . . . . . . . . . . . . . . . . . . . 13 69 13.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 13 70 13.2. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 14 71 13.3. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 15 72 13.4. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 15 73 13.5. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 15 74 13.6. Changes from 05 to 06 . . . . . . . . . . . . . . . . . 15 75 13.7. Changes from 06 to 07 . . . . . . . . . . . . . . . . . 15 76 13.8. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 15 77 13.9. Changes from 08 to 09 . . . . . . . . . . . . . . . . . 16 78 13.10. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 16 79 13.11. Changes from 10 to 11 . . . . . . . . . . . . . . . . . 16 80 13.12. Changes from 11 to REGEXT 00 . . . . . . . . . . . . . . 16 81 13.13. Changes from version REGEXT 00 to REGEXT 01 . . . . . . 16 82 13.14. Changes from version REGEXT 01 to REGEXT 02 . . . . . . 16 83 13.15. Changes from version REGEXT 02 to REGEXT 03 . . . . . . 16 84 13.16. Changes from version REGEXT 03 to REGEXT 04 . . . . . . 16 85 13.17. Changes from version REGEXT 04 to REGEXT 05 . . . . . . 17 86 13.18. Changes from version REGEXT 05 to REGEXT 06 . . . . . . 17 87 13.19. Changes from version REGEXT 06 to REGEXT 07 . . . . . . 17 88 14. Example of a Full Deposit . . . . . . . . . . . . . . . . . . 17 89 15. Example of a Differential Deposit . . . . . . . . . . . . . . 18 90 16. Example of a Incremental Deposit . . . . . . . . . . . . . . 19 91 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 17.1. Normative References . . . . . . . . . . . . . . . . . . 20 93 17.2. Informative References . . . . . . . . . . . . . . . . . 21 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 96 1. Introduction 98 Registry Data Escrow is the process by which a registry periodically 99 submits data deposits to a third-party called an escrow agent. These 100 deposits comprise the minimum data needed by a third-party to resume 101 operations if the registry cannot function and is unable or unwilling 102 to facilitate an orderly transfer of service. For example, for a 103 domain name registry or registrar, the data to be deposited would 104 include all the objects related to registered domain names, e.g., 105 names, contacts, name servers, etc. 107 The goal of data escrow is higher resiliency of registration 108 services, for the benefit of Internet users. The beneficiaries of a 109 registry are not just those registering information there, but all 110 relying parties that need to identify the owners of objects. 112 In the context of domain name registries, registration data escrow is 113 a requirement for generic top-level domains and some country code 114 top-level domain managers are also currently escrowing data. There 115 is also a similar requirement for ICANN-accredited domain registrars. 117 This document specifies a format for data escrow deposits independent 118 of the objects being escrowed. A specification is required for each 119 type of registry/set of objects that is expected to be escrowed. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 Deposit. Deposits can be of three kinds: Full, Differential or 130 Incremental. For all kinds of deposits, the universe of registry 131 objects to be considered for data escrow are those objects necessary 132 in order to offer the registry services. 134 Differential Deposit. Contains data that reflects all transactions 135 involving the database that were not reflected in the last previous 136 Full, Incremental or Differential Deposit, as the case may be. 137 Differential Deposit files will contain information from all database 138 objects that were added, modified or deleted since the previous 139 deposit was completed as of its defined Timeline Watermark. 141 Domain Name. See definition of Domain name in [RFC8499]. 143 Escrow Agent. The organization designated by the registry or the 144 third-party beneficiary to receive and guard data escrow deposits 145 from the registry. 147 Full Deposit. Contains the registry data that reflects the current 148 and complete registry database and will consist of data that reflects 149 the state of the registry as of a defined Timeline Watermark for the 150 deposit. 152 Incremental Deposit. Contains data that reflects all transactions 153 involving the database that were not reflected in the last previous 154 Full Deposit. Incremental Deposit files will contain information 155 from all database objects that were added, modified or deleted since 156 the previous Full Deposit was completed as of its defined Timeline 157 Watermark. If the Timeline Watermark of an Incremental Deposit were 158 to cover the Timeline Watermark of another (Incremental or 159 Differential) Deposit since the last Full Deposit, the more recent 160 deposit MUST contain all the transactions of the earlier deposit. 162 Registrar. See definition of Registrar in [RFC8499]. 164 Registry. See definition of Registry in [RFC8499]. 166 Third-Party Beneficiary. Is the organization that, under 167 extraordinary circumstances, would receive the escrow deposits the 168 registry transferred to the escrow agent. This organization could be 169 a backup registry, registry regulator, contracting party of the 170 registry, etc. 172 Timeline Watermark. Point in time on which to base the collecting of 173 database objects for a deposit. Deposits are expected to be 174 consistent to that point in time. 176 Top-Level Domain. See definition of Top-Level Domain (TLD) in 177 [RFC8499]. 179 3. Problem Scope 181 In the past few years, the issue of registry continuity has been 182 carefully considered in the gTLD and ccTLD space. Various 183 organizations have carried out risk analyses and developed business 184 continuity plans to deal with those risks, should they materialize. 186 One of the solutions considered and used, especially in the gTLD 187 space, is Registry Data Escrow as a way to ensure the continuity of 188 registry services in the extreme case of registry failure. 190 So far, almost every registry that uses Registry Data Escrow has its 191 own specification. It is anticipated that more registries will be 192 implementing escrow especially with an increasing number of domain 193 registries coming into service, adding complexity to this issue. 195 It would seem beneficial to have a standardized specification for 196 Registry Data Escrow that can be used by any registry to submit its 197 deposits. 199 While the domain name industry has been the main target for this 200 specification, it has been designed to be as general as possible. 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 namespaces "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 . 269 The element 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 A "prevId" attribute that can be used to identify the previous 279 Incremental, Differential or Full Deposit. This attribute is 280 REQUIRED in Differential Deposits ("DIFF" type), is OPTIONAL in 281 Incremental Deposits ("INCR" type), and is not used in Full 282 Deposits ("FULL" type). 284 o An OPTIONAL "resend" attribute that is incremented each time the 285 escrow deposit failed the verification procedure at the receiving 286 party and a new escrow deposit needs to be generated by the 287 registry for that specific date. The first time a deposit is 288 generated the attribute is either omitted or MUST be "0". If a 289 deposit needs to be generated again, the attribute MUST be set to 290 "1", and so on. 292 The element contains the following the child elements: 294 5.1.1. Child element 296 A REQUIRED element contains the data-time corresponding 297 to the Timeline Watermark of the deposit. 299 5.1.2. Child element 301 This element contains auxiliary information of the data escrow 302 deposit. 304 A REQUIRED element contains the following child elements: 306 o A REQUIRED element that identifies the RDE protocol 307 version, this value MUST be 1.0. 309 o One or more elements that contain namespace URIs 310 representing the and element objects. 312 5.1.3. Child element 314 This element SHOULD be present in deposits of type Incremental or 315 Differential. It contains the list of objects that were deleted 316 since the base previous deposit. Each object in this section SHALL 317 contain an ID for the object deleted. 319 This section of the deposit MUST NOT be present in Full Deposits. 320 When rebuilding a registry it MUST be ignored if present in a Full 321 Deposit. 323 The specification for each object to be escrowed MUST declare the 324 identifier to be used to reference the object to be deleted. 326 5.1.4. Child element 328 This element of the deposit contains the objects in the deposit. It 329 SHOULD be present in all type of deposits. It contains the data for 330 the objects to be escrowed. The actual objects have to be specified 331 individually. 333 In the case of Incremental or Differential Deposits, the objects 334 indicate whether the object was added or modified after the base 335 previous deposit. In order to distinguish between one and the other, 336 it will be sufficient to check existence of the referenced object in 337 the previous deposit. 339 When applying Incremental or Differential Deposits (when rebuilding 340 the registry from data escrow deposits) the relative order of the 341 elements is important, as is the relative order of the 342 elements. All the elements MUST be applied 343 first, in the order that they appear. All the elements 344 MUST be applied next, in the order that they appear. 346 If an object is present in the section of several deposits 347 (e.g. Full and Differential) the registry data from the latest 348 deposit (as defined by the Timeline Watermark) SHOULD be used when 349 rebuilding the registry. 351 6. Formal Syntax 353 6.1. RDE Schema 355 BEGIN 356 357 362 363 364 Registry Data Escrow schema 365 366 368 369 371 372 373 374 375 376 377 378 379 380 381 382 384 386 387 388 389 390 391 392 394 395 396 397 398 399 401 402 403 404 405 406 408 409 410 411 412 413 415 416 417 418 419 420 422 423 424 425 426 427 428 429 431 432 433 434 435 436 438 439 440 441 442 443 444 446 447 448 449 450 451 452 454 455 456 457 458 459 460 461 462 END 464 7. Internationalization Considerations 466 Data escrow deposits are represented in XML, which provides native 467 support for encoding information using the Unicode character set and 468 its more compact representations including UTF-8. Conformant XML 469 processors recognize both UTF-8 and UTF-16. Though XML includes 470 provisions to identify and use other character encodings through use 471 of an "encoding" attribute in an declaration, use of UTF-8 is 472 RECOMMENDED. 474 8. IANA Considerations 476 This document uses URNs to describe XML namespaces and XML schemas 477 conforming to a registry mechanism described in [RFC3688]. Two URI 478 assignments have been registered by the IANA. 480 Registration request for the RDE namespace: 482 URI: urn:ietf:params:xml:ns:rde-1.0 484 Registrant Contact: IETF 486 XML: None. Namespace URIs do not represent an XML specification. 488 Registration request for the RDE XML schema: 490 URI: urn:ietf:params:xml:schema:rde-1.0 492 Registrant Contact: IETF 494 See the "Formal Syntax" section of this document. 496 9. Implementation Status 498 Note to RFC Editor: Please remove this section and the reference to 499 RFC 7942 [RFC7942] before publication. 501 This section records the status of known implementations of the 502 protocol defined by this specification at the time of posting of this 503 Internet-Draft, and is based on a proposal described in RFC 7942 504 [RFC7942]. The description of implementations in this section is 505 intended to assist the IETF in its decision processes in progressing 506 drafts to RFCs. Please note that the listing of any individual 507 implementation here does not imply endorsement by the IETF. 508 Furthermore, no effort has been spent to verify the information 509 presented here that was supplied by IETF contributors. This is not 510 intended as, and must not be construed to be, a catalog of available 511 implementations or their features. Readers are advised to note that 512 other implementations may exist. 514 According to RFC 7942 [RFC7942], "this will allow reviewers and 515 working groups to assign due consideration to documents that have the 516 benefit of running code, which may serve as evidence of valuable 517 experimentation and feedback that have made the implemented protocols 518 more mature. It is up to the individual working groups to use this 519 information as they see fit". 521 9.1. Implementation in the gTLD space 523 Organization: ICANN 525 Name: ICANN Registry Agreement 526 Description: the ICANN Base Registry Agreement requires Registries, 527 Data Escrow Agents, and ICANN to implement this specification. ICANN 528 receives daily notifications from Data Escrow Agents confirming that 529 more than 1,200 gTLDs are sending deposits that comply with this 530 specification. ICANN receives on a weekly basis per gTLD, from more 531 than 1,200 gTLD registries, a Bulk Registration Data Access file that 532 also complies with this specification. In addition, ICANN is aware 533 of Registry Service Provider transitions using data files that 534 conform to this specification. 536 Level of maturity: production. 538 Coverage: all aspects of this specification are implemented. 540 Version compatibility: versions 03 - 08 are known to be implemented. 542 Contact: gustavo.lozano@icann.org 544 URL: https://www.icann.org/resources/pages/registries/registries- 545 agreements-en 547 10. Security Considerations 549 This specification does not define the security mechanisms to be used 550 in the transmission of the data escrow deposits, since it only 551 specifies the minimum necessary to enable the rebuilding of a 552 registry from deposits without intervention from the original 553 registry. 555 Depending on local policies, some elements or, most likely, the whole 556 deposit will be considered confidential. As such, the registry 557 transmitting the data to the escrow agent SHOULD take all the 558 necessary precautions such as encrypting the data itself and/or the 559 transport channel to avoid inadvertent disclosure of private data. 561 Authentication of the parties passing data escrow deposit files is 562 also of the utmost importance. The escrow agent SHOULD properly 563 authenticate the identity of the registry before accepting data 564 escrow deposits. In a similar manner, the registry SHOULD 565 authenticate the identity of the escrow agent before submitting any 566 data. 568 Additionally, the registry and the escrow agent SHOULD use integrity 569 checking mechanisms to ensure the data transmitted is what the source 570 intended. Validation of the contents by the escrow agent is 571 RECOMMENDED to ensure not only that the file was transmitted 572 correctly from the registry, but also that the contents are 573 "meaningful". 575 11. Privacy Considerations 577 This specification defines a format that may be used to escrow 578 personal data. The process of data escrow is governed by a legal 579 document agreed by the parties, and such legal document must regulate 580 the particularities regarding the protection of personal data. 582 12. Acknowledgments 584 Special suggestions that have been incorporated into this document 585 were provided by James Gould, Edward Lewis, Jaap Akkerhuis, Lawrence 586 Conroy, Marc Groeneweg, Michael Young, Chris Wright, Patrick Mevzek, 587 Stephen Morris, Scott Hollenbeck, Stephane Bortzmeyer, Warren Kumari, 588 Paul Hoffman, Vika Mpisane, Bernie Hoeneisen, Jim Galvin, Andrew 589 Sullivan, Hiro Hotta, Christopher Browne, Daniel Kalchev, David 590 Conrad, James Mitchell, Francisco Obispo, Bhadresh Modi and Alexander 591 Mayrhofer. 593 Shoji Noguchi and Francisco Arias participated as co-authors until 594 version 07 providing invaluable support for this document. 596 13. Change History 598 [[RFC Editor: Please remove this section.]] 600 13.1. Changes from 00 to 01 602 1. Included DNSSEC elements as part of the basic element 603 as defined in RFC 5910. 605 2. Included RGP elements as part of the basic element as 606 defined in RFC 3915. 608 3. Added support for IDNs and IDN variants. 610 4. Eliminated the element and all its subordinate 611 objects, except . 613 5. Renamed to and included it directly 614 under root element. 616 6. Renamed root element to . 618 7. Added element under element. 620 8. Added element under element. 622 9. Reversed the order of the and elements. 624 10. Removed minOccurs="0". 626 11. Added element under root element. 628 12. Added element under element. 630 13. Removed element from element. 632 14. Populated the "Security Considerations" section. 634 15. Populated the "Internationalization Considerations" section. 636 16. Populated the "Extension Example" section. 638 17. Added element under element. 640 18. Added element under element. 642 19. Added element under root element. 644 20. Fixed some typographical errors and omissions. 646 13.2. Changes from 01 to 02 648 1. Added definition for "canonical" in the "IDN variants Handling" 649 section. 651 2. Clarified that "blocked" and "reserved" IDN variants are 652 optional. 654 3. Made optional. 656 4. Introduced substitutionGroup as the mechanism for extending the 657 protocol. 659 5. Moved element to be child of . 661 6. Text improvements in the Introduction, Terminology, and Problem 662 Scope per Jay's suggestion. 664 7. Removed from and added instead, 665 which include all the data from the last (pending/processed) 666 transfer request. 668 8. Removed from and added instead, 669 which include all the data from the last (pending/processed) 670 transfer request. 672 9. Fixed some typographical errors and omissions. 674 13.3. Changes from 02 to 03 676 1. Separated domain name objects from protocol. 678 2. Moved elements to be child of and 679 , additionally removed element from 680 ,, , and 681 elements. 683 3. Modified the definition of and . 685 4. Added element under element. 687 5. Fixed some typographical errors and omissions. 689 13.4. Changes from 03 to 04 691 1. Removed objects. 693 2. Populated the "Extension Guidelines" section. 695 3. Fixed some typographical errors and omissions. 697 13.5. Changes from 04 to 05 699 1. Fixes to the XSD. 701 2. Extension Guidelines moved to dnrd-mappings draft. 703 3. Fixed some typographical errors and omissions. 705 13.6. Changes from 05 to 06 707 1. Fix resend definition. 709 13.7. Changes from 06 to 07 711 1. Editorial updates. 713 2. schemaLocation removed from RDE Schema. 715 13.8. Changes from 07 to 08 717 1. Ping update. 719 13.9. Changes from 08 to 09 721 1. Ping update. 723 13.10. Changes from 09 to 10 725 1. Implementation Status section was added. 727 13.11. Changes from 10 to 11 729 1. Ping update. 731 13.12. Changes from 11 to REGEXT 00 733 1. Internet Draft (I-D) adopted by the REGEXT WG. 735 13.13. Changes from version REGEXT 00 to REGEXT 01 737 1. Privacy consideration section was added. 739 13.14. Changes from version REGEXT 01 to REGEXT 02 741 1. Updated the Security Considerations section to make the language 742 normative. 744 2. Updated the rde XML schema to remove the dependency with the 745 eppcom namespace reference. 747 3. Editorial updates. 749 4. Remove the reference to RFC 5730. 751 5. Added complete examples of deposits. 753 13.15. Changes from version REGEXT 02 to REGEXT 03 755 1. The section changed from MUST to SHOULD, in order to 756 accommodate an Incremental or Differential Deposit that only 757 includes deletes. 759 2. Editorial updates. 761 13.16. Changes from version REGEXT 03 to REGEXT 04 763 1. Moved [RFC8499] to the Normative References section. 765 13.17. Changes from version REGEXT 04 to REGEXT 05 767 1. Changes based on the feedback provided here: 768 https://mailarchive.ietf.org/arch/msg/regext/ 769 UNo6YxapgjyerAYv0223zEuzjFk 771 2. The examples of deposits were moved to their own sections. 773 3. elements definition moved to section 5.1. 775 4. The DIFF example was modified to make it more representative of a 776 differential deposit. 778 13.18. Changes from version REGEXT 05 to REGEXT 06 780 1. Normative references for XLM, XML Schema added. 782 2. Text added to define that version MUST be 1.0. 784 3. Normative SHOULD replaced should in the second paragraph in the 785 security section. 787 13.19. Changes from version REGEXT 06 to REGEXT 07 789 1. Registration contact changed in section 8. 791 14. Example of a Full Deposit 793 Example of a Full Deposit with the two example objects rdeObj1 and 794 rdeObj2: 796 797 803 2019-10-18T00:00:00Z 804 805 1.0 806 urn:ietf:params:xml:ns:rdeObj1-1.0 807 urn:ietf:params:xml:ns:rdeObj2-1.0 808 809 810 811 EXAMPLE 812 813 814 fsh8013-EXAMPLE 815 816 817 819 15. Example of a Differential Deposit 821 Example of a Differential Deposit with the two example objects 822 rdeObj1 and rdeObj2: 824 825 831 2019-10-18T00:00:00Z 832 833 1.0 834 urn:ietf:params:xml:ns:rdeObj1-1.0 835 urn:ietf:params:xml:ns:rdeObj2-1.0 836 837 838 839 EXAMPLE2 840 841 842 sh8014-EXAMPLE 843 844 845 847 16. Example of a Incremental Deposit 849 Example of an Incremental Deposit with the two example objects 850 rdeObj1 and rdeObj2: 852 853 859 2019-10-18T00:00:00Z 860 861 1.0 862 urn:ietf:params:xml:ns:rdeObj1-1.0 863 urn:ietf:params:xml:ns:rdeObj2-1.0 864 865 866 867 EXAMPLE1 868 869 870 fsh8013-EXAMPLE 871 872 873 874 875 EXAMPLE2 876 877 878 sh8014-EXAMPLE 879 880 881 883 17. References 885 17.1. Normative References 887 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 888 Requirement Levels", BCP 14, RFC 2119, 889 DOI 10.17487/RFC2119, March 1997, 890 . 892 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 893 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 894 . 896 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 897 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 898 May 2017, . 900 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 901 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 902 January 2019, . 904 [W3C.REC-xml-20081126] 905 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 906 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 907 Edition) REC-xml-20081126", November 2008, 908 . 910 [W3C.REC-xmlschema-1-20041028] 911 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 912 "XML Schema Part 1: Structures Second Edition REC- 913 xmlschema-1-20041028", October 2004, 914 . 916 [W3C.REC-xmlschema-2-20041028] 917 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 918 Second Edition REC-xmlschema-2-20041028", October 2004, 919 . 921 17.2. Informative References 923 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 924 DOI 10.17487/RFC3688, January 2004, 925 . 927 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 928 Code: The Implementation Status Section", BCP 205, 929 RFC 7942, DOI 10.17487/RFC7942, July 2016, 930 . 932 Author's Address 934 Gustavo Lozano 935 Internet Corporation for Assigned Names and Numbers 936 12025 Waterfront Drive, Suite 300 937 Los Angeles 90292 938 United States of America 940 Phone: +1.310.823.9358 941 Email: gustavo.lozano@icann.org