idnits 2.17.1 draft-arias-noguchi-registry-data-escrow-01.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 (October 25, 2010) is 4932 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-3166-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU-E164' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Arias 3 Internet-Draft ICANN 4 Intended status: Standards Track S. Noguchi 5 Expires: April 28, 2011 JPRS 6 October 25, 2010 8 Domain Name Data Escrow Specification 9 draft-arias-noguchi-registry-data-escrow-01 11 Abstract 13 This document specifies the format and contents of Data Escrow 14 deposits for Domain Name Registration Organizations. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 28, 2011. 33 Copyright Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 5 53 4. General Conventions . . . . . . . . . . . . . . . . . . . . . 6 54 4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 6 55 4.2. Country names . . . . . . . . . . . . . . . . . . . . . . 6 56 4.3. Telephone numbers . . . . . . . . . . . . . . . . . . . . 6 57 4.4. IP addresses . . . . . . . . . . . . . . . . . . . . . . . 6 58 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6 59 5.1. Root element . . . . . . . . . . . . . . . . . . 6 60 5.2. Child element . . . . . . . . . . . . . . . . 7 61 5.3. Child element . . . . . . . . . . . . . . . . 8 62 5.4. Child element . . . . . . . . . . . . . . . . . 9 63 5.5. Child element . . . . . . . . . . . . . . . . . 10 64 6. Object Description . . . . . . . . . . . . . . . . . . . . . . 11 65 6.1. RDE Domain Object . . . . . . . . . . . . . . . . . . . . 11 66 6.2. RDE Host Object . . . . . . . . . . . . . . . . . . . . . 13 67 6.3. RDE Contact Object . . . . . . . . . . . . . . . . . . . . 13 68 6.4. RDE Registrar Object . . . . . . . . . . . . . . . . . . . 15 69 6.5. RDE IDN Table Reference . . . . . . . . . . . . . . . . . 17 70 6.6. RDE IDN object . . . . . . . . . . . . . . . . . . . . . . 18 71 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19 72 7.1. RDE Schema . . . . . . . . . . . . . . . . . . . . . . . . 19 73 7.2. RDE Domain Object . . . . . . . . . . . . . . . . . . . . 23 74 7.3. RDE Host Object . . . . . . . . . . . . . . . . . . . . . 26 75 7.4. RDE Contact Object . . . . . . . . . . . . . . . . . . . . 28 76 7.5. RDE Registrar Object . . . . . . . . . . . . . . . . . . . 30 77 7.6. RDE IDN and IDN Table Reference Objects . . . . . . . . . 32 78 8. Extension Example . . . . . . . . . . . . . . . . . . . . . . 34 79 9. Internationalization Considerations . . . . . . . . . . . . . 37 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 82 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 83 13. Change History . . . . . . . . . . . . . . . . . . . . . . . . 40 84 13.1. Changes from version 00 to 01 . . . . . . . . . . . . . . 40 85 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 86 14.1. Normative References . . . . . . . . . . . . . . . . . . . 41 87 14.2. Informative References . . . . . . . . . . . . . . . . . . 42 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 90 1. Introduction 92 Registration Data Escrow is the process by which an Internet 93 Registration Organization (e.g., a registry, registrar, etc.) 94 periodically submits data deposits to a contracted third party called 95 an Escrow Agent. These deposits comprise all the data needed to 96 resume operations if the registration organization could not function 97 as a result of a catastrophe or a financial situation. For a domain 98 name registry or registrar the data to be deposited includes all the 99 objects related to registered domain names, e.g., contacts, name 100 servers, etc. 102 The purpose of data escrow is to permit quick resumption of 103 registration service by another registration organization after a 104 catastrophe. The goal is higher resiliency of registration services, 105 for the benefit of Internet users. The beneficiaries of a 106 registration organization are not just those registering information 107 there, but all relying parties that need to identify the owners of 108 objects. 110 In the context of domain name registries, registration data escrow is 111 a requirement for the current generic top-level domains and it is 112 expected to be for new registries. Some country code top-level 113 domain managers are also currently escrowing data. There is also a 114 similar requirement for ICANN's generic top-level domain accredited 115 registrars. 117 This document specifies a format and contents of Data Escrow deposits 118 for Domain Name Registration Organizations. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in BCP 14, RFC 2119 125 [RFC2119]. 127 DEPOSIT. Deposits can be of three kinds: Full, Differential or 128 Incremental. For all kinds of Deposits, the Universe of Registry 129 objects to be considered for data escrow are those objects necessary 130 in order to offer the Registry Services. 132 DIFFERENTIAL DEPOSIT. Contains data that reflects all transactions 133 involving the database that were not reflected in the last previous 134 Full, Incremental or Differential Deposit, as the case may be. 135 Differential deposit files will contain information from all database 136 objects that were added, modified or deleted since the previous 137 Deposit was completed as of its defined Timeline Watermark. 139 ESCROW AGENT. The organization contracted by the Registry or the 140 Third-Party Beneficiary to receive and guard Data Escrow Deposits 141 from the Registry. 143 FULL DEPOSIT. Contains the Registry Data that reflects the current 144 and complete Registry Database and will consist of data that reflects 145 the state of the registry as of a defined Timeline Watermark for the 146 deposit. 148 INCREMENTAL DEPOSIT. Contains data that reflects all transactions 149 involving the database that were not reflected in the last previous 150 Full Deposit. Incremental Deposit files will contain information 151 from all database objects that were added, modified or deleted since 152 the previous Full Deposit was completed as of its defined Timeline 153 Watermark. If the Timeline Watermark of an Incremental Deposit were 154 to cover the Watermark of another (Incremental or Differential) 155 Deposit since the last Full Deposit, the former Deposit MUST contain 156 the transactions of the later Deposit. 158 REGISTRY. The organization providing Registry Services for a RCDN. 160 REGISTRY-CLASS DOMAIN NAME (RCDN): Refers to a top-level domain (TLD) 161 or any other domain name at any level in the DNS tree for which a 162 Registry (either directly or through and affiliate company) provides 163 Registry services to other organizations or individuals. For 164 example: .COM, .ORG, .BIZ, .CO.JP, .ORG.MX. 166 REGISTRY SERVICES. Services offered by the Registry critical to the 167 following tasks: the receipt of data from registrars concerning 168 registrations of domain names and name servers; provision to 169 registrars of status information relating to the DNS servers for the 170 RCDN; dissemination of RCDN zone files; operation of the Registry DNS 171 servers; and dissemination of contact and other information 172 concerning DNS registrations in the RCDN. Any other products or 173 services that only a Registry is capable of providing, by reason of 174 its designation as the Registry. Typical examples of Registry 175 Services are: DNS resolution for the RCDN, WHOIS and EPP. 177 THIRD-PARTY BENEFICIARY. Is the organization that, under 178 extraordinary circumstances, would receive the escrow Deposits the 179 Registry transferred to the Escrow Agent. This organization could be 180 a backup Registry, Registry regulator, contracting party of the 181 Registry, etc. 183 TIMELINE WATERMARK. Point in time on which to base the collecting of 184 database objects for a Deposit. Deposits are expected to be 185 consistent to that point in time. 187 3. Problem Scope 189 Since a few years ago, the issue of Registry continuity has been 190 carefully considered in the gTLD and ccTLD space. Various 191 organizations have made risk analysis 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 also anticipated that more Registries will 200 be implementing Escrow especially with the advent of the new gTLD 201 program. 203 Now, it would seem beneficial to have a standardized specification 204 for Registry Data Escrow that can be used by any Registry to submit 205 its Deposits and, in case, to use those deposits to operate Registry 206 Services for a RCDN that has to be transitioned of Registry operator. 208 A solution to the problem at hand SHALL clearly identify the format 209 and contents of the Deposits a Registry has to make, such that 210 another different Registry would be able to rebuild the Registry 211 Services of the former, without its help, in a timely manner, with 212 minimum harm to the Registrants, Registrars and Internet users. 214 Since the list and details of Registry Services vary from Registry to 215 Registry, the solution SHALL provide mechanisms that allow its 216 extensibility to accommodate variations and extensions of the 217 Registry Services. 219 Given the confidentiality and importance of some of the information 220 that is handled in order to offer the Registry Services, the solution 221 SHALL define confidentiality and integrity mechanisms when handling 222 the Registry data. 224 The solution SHALL NOT include in the specification those objects of 225 such delicate confidentiality that it is best to leave them out of 226 the Deposits, e.g., DNSSEC KSK/ZSK private keys. 228 Details that are a matter of policy SHOULD be identified as such for 229 the benefit of the implementers. 231 Legal issues around Data Escrow and the overall question of the use 232 Registry Data Escrow are outside of scope of this document. 234 4. General Conventions 236 4.1. Date and Time 238 Numerous fields indicate "dates", such as the creation and expiry 239 dates for domains. These fields SHALL contain timestamps indicating 240 the date and time in UTC as specified in [RFC3339], with no offset 241 from the zero meridian. 243 4.2. Country names 245 Country identifiers SHALL be represented using two character 246 identifiers as specified in [ISO-3166-1]. 248 4.3. Telephone numbers 250 Telephone numbers (both voice and fax) SHALL be formatted based on 251 structures defined in [ITU-E164]. Telephone numbers described in 252 this specification are character strings that MUST begin with a plus 253 sign ("+", ASCII value 0x002B), followed by a country code defined in 254 [ITU-E164], followed by a dot (".", ASCII value 0x002E), followed by 255 a sequence of digits representing the telephone number. 257 4.4. IP addresses 259 IP addresses syntax MUST conform either to, Internet Protocol 260 [RFC0791], for IPv4 addresses, or IP Version 6 Addressing 261 Architecture [RFC4291], for IPv6 addresses. 263 5. Protocol Description 265 The following is a format for Data Escrow deposits as produced by an 266 Internet Domain Registry. Only the format of the objects deposited 267 is defined, nothing is prescribed about the way to transfer such 268 deposits between the Registry and the Escrow Agent or vice versa. 269 The format is based on EPP [RFC5730] and related RFCs by Scott 270 Hollenbeck. 272 5.1. Root element 274 The container or root element for a Registry Data Escrow deposits is 275 . This element contains the following child elements: 276 watermark, deletes and contents. This element also contains the 277 following attributes: 279 o A "type" attribute that MUST be used to identify the kind of 280 deposit: FULL, INCR (Incremental) or DIFF (Differential). 282 o An "id" attribute that MUST be used to uniquely identify the 283 escrow deposit. Each registry is responsible for maintaining its 284 own escrow deposits identifier space to ensure uniqueness. 286 o An OPTIONAL "prevId" attribute that can be used to identify the 287 previous incremental, differential or full escrow deposit. This 288 attribute MUST be used in Differential Deposits ("DIFF" type). 290 o An OPTIONAL "resend" attribute that is used to identify resend 291 attempts in case of previous failure. The first time a deposit is 292 attempted to be sent, the attribute MUST be zero; The second 293 attempt to send (first resend attempt) the attribute MUST be set 294 to one; and so on. This would be used when for example, the 295 previous deposit was not received complete, it failed verification 296 at the receiving party, etc. 298 Example of root element object: 300 301 306 2010-10-18T00:00:00Z 307 308 ... 309 310 311 ... 312 313 314 ... 315 316 318 5.2. Child element 320 A element contains the data-time correspondent to the 321 Timeline Watermark of the deposit. 323 Example of element object: 325 326 331 2010-10-18T00:00:00Z 332 ... 333 335 5.3. Child element 337 An OPTIONAL element contains some EPP parameters that may 338 be helpful when rebuilding a registry from the escrow deposits. The 339 element SHOULD be included in Deposits if the registry uses EPP. 341 The syntax and content of the children elements is as 342 explained in section 2.4 of [RFC5730]. The children of the 343 are as follows: 345 o One or more elements that indicate the EPP versions 346 supported by the registry. 348 o One or more elements that indicate the identifiers of the 349 text response languages supported by the registry's EPP server. 351 o One or more elements that contain namespace URIs 352 representing the objects that the registry's EPP server is capable 353 of managing. 355 o An OPTIONAL element that contains one or more 356 elements that contain namespace URIs representing object 357 extensions supported by the registry's EPP server. 359 o A element that contains child elements used to describe the 360 server's privacy policy for data collection and management. See 361 section 2.4 of [RFC5730] for more details. 363 Example of element object: 365 366 370 1.0 371 en 372 urn:ietf:params:xml:ns:domain-1.0 373 urn:ietf:params:xml:ns:contact-1.0 374 urn:ietf:params:xml:ns:host-1.0 375 376 urn:ietf:params:xml:ns:rgp-1.0 377 urn:ietf:params:xml:ns:secDNS-1.1 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 ... 397 399 5.4. Child element 401 This section SHOULD only be present in deposits of type Incremental 402 or Differential. It contains the list of objects that were deleted 403 since the base previous deposit. Each object in this section 404 contains an ID for the object deleted. For domains and hosts it will 405 be the fully qualified domain name. 407 This section of the deposit SHOULD NOT be present in Full deposits. 408 When rebuilding a registry it SHOULD be ignored if present in a Full 409 deposit. 411 Elements that MAY appear in this section are: delContact, delHost, 412 delDomain and/or delRegistrar. It MAY also contain an extension 413 element allowing extending the element. 415 Example of element object: 417 418 422 sh8013-TEST 423 ... 424 ns1.example.test 425 ... 426 example.test 427 ... 428 agnt0001-TEST 429 430 ... 431 433 5.5. Child element 435 This section of the deposit contains the actual objects in the 436 deposit. It MAY contain elements: contact, host, domain, registrar, 437 idnTableRef and idn as defined in Section 6. This element MAY also 438 contain an extension element allowing extending the format. 440 In the case of Incremental or Differential deposits, the objects 441 indicate whether the object was added or modified after the base 442 previous deposit. In order to distinguish between one and the other, 443 it will be sufficient to check existence of the referenced object in 444 the base previous deposit. 446 When applying Incremental or Differential deposits, i.e., when 447 rebuilding the registry from data escrow deposits, the order of the 448 and elements is important. First, all the 449 deletes MUST be applied and then the adds and updates, i.e., first 450 apply what is in and later what is in . 452 Example of element object: 454 455 459 460 ... 461 462 463 ... 464 465 466 ... 467 468 469 ... 470 471 472 ... 473 474 475 ... 476 477 478 ... 479 481 6. Object Description 483 This section describes the base objects defined in EPP: domains, 484 hosts and contacts with the addition of registrars, idnTableRefs and 485 idns. 487 6.1. RDE Domain Object 489 The RDE domain object is based on the EPP domain name mapping in 490 [RFC5731]. There are two elements used in this format related to 491 domains: the domain object per se, used inside the element 492 and the delDomain object used inside the element. 494 6.1.1. object 496 The domain element is based on the EPP domain response for an 497 authorized client (see Section 3.1.2. of [RFC5731]). 499 Example of domain object: 501 ... 502 503 pinguino.test 504 Dpinguino-TEST 505 506 507 jd1234 508 sh8013 509 sh8013 510 511 ns1.example.com 512 ns1.example.net 513 514 ns1.pinguino.test 515 ns2.pinguino.test 516 clientX 517 clientY 518 1999-04-03T22:00:00.0Z 519 clientX 520 2009-12-03T09:05:00.0Z 521 2015-04-03T22:00:00.0Z 522 2010-04-08T09:28:00.0Z 523 524 2fooBAR 525 526 527 604800 528 529 12345 530 7 531 1 532 93358db22e956a451eb5ae8d2ec39526ca6a87b9 533 534 535 536 537 ... 539 6.1.2. object 541 The delDomain element contains the fully qualified domain name of a 542 domain that was deleted. 544 Example of object: 546 ... 547 example.test 548 ... 550 6.2. RDE Host Object 552 The RDE host object is based on the EPP host name mapping in 553 [RFC5732]. There are two elements used in this format related to 554 hosts: the host object per se, used inside the element and 555 the delHost object used inside the element. 557 6.2.1. object 559 The RDE domain object is based on the EPP host response for an 560 authorized client (see Section 3.1.2. of [RFC5732]). 562 Example of object: 564 ... 565 566 ns1.example.test 567 Hns1_example_test-TEST 568 569 570 192.0.2.2 571 192.0.2.29 572 1080:0:0:0:8:800:200C:417A 573 clientY 574 clientX 575 1999-05-08T12:10:00.0Z 576 clientX 577 2009-10-03T09:34:00.0Z 578 2007-01-08T09:19:00.0Z 579 580 ... 582 6.2.2. object 584 The delHost element contains the fully qualified domain name of a 585 host that was deleted. 587 Example of object: 589 ... 590 ns1.example.test 591 ... 593 6.3. RDE Contact Object 595 The RDE contact object is based on the EPP contact name mapping in 596 [RFC5733]. There are two elements used in this format related to 597 contacts: the contact object per se, used inside the 598 element and the delContact object used inside the element. 600 6.3.1. object 602 The contact object is based on the EPP contact response for an 603 authorized client (see Section 3.1.2. of [RFC5733]). 605 Example object: 607 ... 608 609 sh8013 610 Csh8013-TEST 611 612 613 614 John Doe 615 Example Inc. 616 617 123 Example Dr. 618 Suite 100 619 Dulles 620 VA 621 20166-6503 622 US 623 624 625 +1.7035555555 626 +1.7035555556 627 jdoe@example.test 628 clientY 629 clientX 630 2009-09-13T08:01:00.0Z 631 clientX 632 2009-11-26T09:10:00.0Z 633 2010-03-18T19:28:00.0Z 634 635 2fooBAR 636 637 638 639 640 641 642 ... 644 6.3.2. object 646 The delContact element contains the id of a contact that was deleted. 648 Example of object: 650 ... 651 sh8013 652 ... 654 6.4. RDE Registrar Object 656 The RDE registrar object is based on the EPP contact name mapping 657 previously described. There are two elements used in this format 658 related to registrars: the registrar object per se, used inside the 659 element and the delRegistrar object used inside the 660 element. 662 6.4.1. object 664 The element contains the following child elements: 666 o An element that contains the Registry-unique identifier of 667 the registrar object. This has a superordinate relationship 668 to a subordinate , or of domain, contact and 669 host objects. 671 o An OPTIONAL element that contains the ID assigned by 672 ICANN. 674 o One or two elements that contain postal- address 675 information. Two elements are provided so that address 676 information can be provided in both internationalized and 677 localized forms; a "type" attribute is used to identify the two 678 forms. If an internationalized form (type="int") is provided, 679 element content MUST be represented in a subset of UTF-8 that can 680 be represented in the 7-bit US-ASCII character set. If a 681 localized form (type="loc") is provided, element content MAY be 682 represented in unrestricted UTF-8. The element 683 contains the following child elements: 685 * An OPTIONAL element that contains the name of the 686 organization with which the registrar is affiliated. 688 * A element that contains address information associated 689 with the registrar. The element contains the following 690 child elements: 692 + One, two, or three OPTIONAL elements that contain 693 the registrar's street address. 695 + A element that contains the registrar's city. 697 + An OPTIONAL element that contains the registrar's state 698 or province. 700 + An OPTIONAL element that contains the registrar's 701 postal code. 703 + A element that contains the registrar's country code. 705 o An OPTIONAL element that contains the registrar's voice 706 telephone number. 708 o An OPTIONAL element that contains the registrar's facsimile 709 telephone number. 711 o A element that contains the registrar's email address. 713 o A element that contains the registrar's URL. 715 o One or more OPTIONAL elements that contain identifiers 716 for the human or organizational social information objects 717 associated with the registrar object. 719 o A element that contains the date and time of registrar- 720 object creation. 722 o A element that contains the date and time of the most 723 recent RDE registrar-object modification. This element MUST NOT 724 be present if the rdeRegistrar object has never been modified. 726 o An element that contains authorization information 727 associated with the registar object to allow access to registry 728 systems. This specification describes password-based 729 authorization information, though other mechanisms are possible. 731 Example of object: 733 ... 734 735 clientX 736 RclientX-TEST 737 738 John Doe 739 Example Inc. 740 741 123 Example Dr. 742 Suite 100 743 Dulles 744 VA 745 20166-6503 746 US 747 748 749 +1.7035555555 750 +1.7035555556 751 jdoe@example.test 752 http://www.example.test 753 rr0013 754 rr0012 755 2005-04-23T11:49:00.0Z 756 2009-02-17T17:51:00.0Z 757 758 tHisaPaSSw 759 760 761 ... 763 6.4.2. object 765 The delRegistrar element contains the id of a registrar that was 766 deleted. 768 Example of object: 770 ... 771 clientZ 772 ... 774 6.5. RDE IDN Table Reference 776 The RDE Internationalized Domain Names (IDN) Table reference is a 777 pseudobject that is used to provide a short reference to the IDN 778 Table used in IDN registrations. The element has an 779 "id" attribute that is used to uniquely identify an IDN Table stored 780 externally. 782 The has only one child element, that contains the 783 URL of the IDN table that is being referenced. 785 Example of object: 787 ... 788 789 http://www.iana.org/domains/idn-tables/tables/cl_latn_1.0.html 790 791 ... 793 6.6. RDE IDN object 795 6.6.1. IDN variants Handling 797 Depending on the Registration Policy in place in the Registry; for a 798 particular IDN, there may be multiple variant domains either 799 registered, reserved or blocked: 801 1. If the IDN variant is actually registered, bundled with its 802 canonical domain name in the Registry system, the variant SHALL 803 be tagged as "registered". 805 2. If only the holder of the canonical domain name is allowed to 806 register the IDN variant but it is not actually registered, the 807 variant SHALL be tagged as "reserved". 809 3. If the IDN variant is considered undesirable for registration, 810 the variant SHALL be tagged as "blocked". 812 6.6.2. object 814 The element contains the following child elements: 816 o An element that contains the ASCII Compatible Encoding 817 (ACE) of an IDN. 819 o An OPTIONAL element that contains the name of the IDN in 820 Unicode character set. It SHOULD be provided if available. 822 o A element that indicates the type of variant this IDN is: 823 registered, reserved, blocked or canonical; see Section 6.6.1 825 o An element that references the IDN Table used for the 826 IDN. This corresponds to the "id" attribute of the 827 element. 829 o An OPTIONAL element that contains the ROID of the 830 corresponding domain object, if there is one. It MUST be provided 831 if the domain object exists. 833 o A element that contains the ROID of the canonical 834 domain name. It MUST be provided if the IDN is NOT the canonical 835 domain name. 837 o An OPTIONAL element that allows extending the IDN 838 object. 840 Example of object: 842 ... 843 844 xn--pingino-q2a.test 845 pingueino.test 846 reserved 847 cl-es 848 Dpinguino-TEST 849 850 ... 852 6.6.3. object 854 The element contains the ACE of an IDN that was deleted, 855 i.e., the . 857 Example of object: 859 ... 860 xn--pingino-q2a.test 861 ... 863 7. Formal Syntax 865 Six schemas are presented here. The first schema is the base RDE 866 schema. The second schema defines domain object for RDE. The third 867 schema defines host object for RDE. The fourth schema defines 868 contact object for RDE. The fifth schema defines registrar object 869 for RDE. The last schema defines the idnTableRef and IDN objects. 871 7.1. RDE Schema 873 Copyright (c) 2010 IETF Trust and the persons identified as authors 874 of the code. All rights reserved. 876 Redistribution and use in source and binary forms, with or without 877 modification, are permitted provided that the following conditions 878 are met: 880 o Redistributions of source code must retain the above copyright 881 notice, this list of conditions and the following disclaimer. 883 o Redistributions in binary form must reproduce the above copyright 884 notice, this list of conditions and the following disclaimer in 885 the documentation and/or other materials provided with the 886 distribution. 888 o Neither the name of Internet Society, IETF or IETF Trust, nor the 889 names of specific contributors, may be used to endorse or promote 890 products derived from this software without specific prior written 891 permission. 893 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 894 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 895 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 896 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 897 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 898 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 899 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 900 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 901 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 902 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 903 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 905 BEGIN 906 908 921 924 926 928 930 932 934 936 939 940 941 Registry Data Escrow schema 942 943 945 948 950 953 954 955 956 958 960 961 963 964 966 968 970 973 975 976 977 979 981 983 986 989 991 993 994 996 997 998 1000 1002 1004 1006 1008 1009 1011 1014 1015 1016 1017 1018 1019 1020 1021 1024 1025 1026 1027 1028 1030 1033 1034 1035 1037 1038 1040 1043 1044 1045 1047 1049 1051 1053 1054 1055 1057 1060 1061 END 1063 7.2. RDE Domain Object 1065 Copyright (c) 2010 IETF Trust and the persons identified as authors 1066 of the code. All rights reserved. 1068 Redistribution and use in source and binary forms, with or without 1069 modification, are permitted provided that the following conditions 1070 are met: 1072 o Redistributions of source code must retain the above copyright 1073 notice, this list of conditions and the following disclaimer. 1075 o Redistributions in binary form must reproduce the above copyright 1076 notice, this list of conditions and the following disclaimer in 1077 the documentation and/or other materials provided with the 1078 distribution. 1080 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1081 names of specific contributors, may be used to endorse or promote 1082 products derived from this software without specific prior written 1083 permission. 1085 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1086 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1087 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1088 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1089 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1090 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1091 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1092 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1093 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1094 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1095 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1097 BEGIN 1098 1100 1110 1113 1115 1118 1120 1122 1125 1126 1127 Registry Data Escrow Domain provisioning schema 1128 1129 1131 1134 1135 1136 1137 1138 1140 1142 1144 1146 1148 1150 1151 1153 1155 1157 1159 1161 1163 1165 1167 1169 1171 1172 1174 1177 1178 END 1180 7.3. RDE Host Object 1182 Copyright (c) 2010 IETF Trust and the persons identified as authors 1183 of the code. All rights reserved. 1185 Redistribution and use in source and binary forms, with or without 1186 modification, are permitted provided that the following conditions 1187 are met: 1189 o Redistributions of source code must retain the above copyright 1190 notice, this list of conditions and the following disclaimer. 1192 o Redistributions in binary form must reproduce the above copyright 1193 notice, this list of conditions and the following disclaimer in 1194 the documentation and/or other materials provided with the 1195 distribution. 1197 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1198 names of specific contributors, may be used to endorse or promote 1199 products derived from this software without specific prior written 1200 permission. 1202 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1203 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1204 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1205 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1206 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1207 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1208 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1209 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1210 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1211 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1212 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1214 BEGIN 1215 1217 1225 1228 1230 1232 1235 1236 1237 Registry Data Escrow host provisioning schema 1238 1239 1241 1244 1245 1246 1247 1248 1250 1252 1253 1254 1255 1257 1259 1261 1263 1264 1266 1269 1270 END 1272 7.4. RDE Contact Object 1274 Copyright (c) 2010 IETF Trust and the persons identified as authors 1275 of the code. All rights reserved. 1277 Redistribution and use in source and binary forms, with or without 1278 modification, are permitted provided that the following conditions 1279 are met: 1281 o Redistributions of source code must retain the above copyright 1282 notice, this list of conditions and the following disclaimer. 1284 o Redistributions in binary form must reproduce the above copyright 1285 notice, this list of conditions and the following disclaimer in 1286 the documentation and/or other materials provided with the 1287 distribution. 1289 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1290 names of specific contributors, may be used to endorse or promote 1291 products derived from this software without specific prior written 1292 permission. 1294 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1295 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1296 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1297 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1298 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1299 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1300 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1301 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1302 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1303 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1304 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1306 BEGIN 1307 1309 1317 1320 1322 1324 1327 1328 1329 Registry Data Escrow contact provisioning schema 1330 1331 1333 1336 1337 1338 1339 1340 1342 1344 1346 1348 1349 1350 1351 1352 1354 1356 1359 1361 1363 1365 1366 1368 1371 1372 END 1374 7.5. RDE Registrar Object 1376 Copyright (c) 2010 IETF Trust and the persons identified as authors 1377 of the code. All rights reserved. 1379 Redistribution and use in source and binary forms, with or without 1380 modification, are permitted provided that the following conditions 1381 are met: 1383 o Redistributions of source code must retain the above copyright 1384 notice, this list of conditions and the following disclaimer. 1386 o Redistributions in binary form must reproduce the above copyright 1387 notice, this list of conditions and the following disclaimer in 1388 the documentation and/or other materials provided with the 1389 distribution. 1391 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1392 names of specific contributors, may be used to endorse or promote 1393 products derived from this software without specific prior written 1394 permission. 1396 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1397 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1398 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1399 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1400 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1401 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1402 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1403 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1404 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1405 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1406 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1408 BEGIN 1409 1411 1421 1424 1426 1428 1430 1433 1434 1435 Registry Data Escrow registrar provisioning schema 1436 1437 1439 1442 1443 1444 1445 1446 1448 1450 1452 1454 1457 1459 1461 1462 1464 1466 1468 1469 1471 1474 1475 END 1477 7.6. RDE IDN and IDN Table Reference Objects 1479 Copyright (c) 2010 IETF Trust and the persons identified as authors 1480 of the code. All rights reserved. 1482 Redistribution and use in source and binary forms, with or without 1483 modification, are permitted provided that the following conditions 1484 are met: 1486 o Redistributions of source code must retain the above copyright 1487 notice, this list of conditions and the following disclaimer. 1489 o Redistributions in binary form must reproduce the above copyright 1490 notice, this list of conditions and the following disclaimer in 1491 the documentation and/or other materials provided with the 1492 distribution. 1494 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1495 names of specific contributors, may be used to endorse or promote 1496 products derived from this software without specific prior written 1497 permission. 1499 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1500 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1501 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1502 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1503 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1504 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1505 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1506 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1507 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1508 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1509 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1511 BEGIN 1512 1514 1522 1525 1527 1529 1532 1533 1534 Registry Data Escrow IDN schema 1535 1536 1538 1541 1542 1543 1544 1546 1547 1548 1550 1552 1554 1555 1557 1558 1559 1560 1561 1562 1564 1565 1566 1567 1568 1569 1570 1571 1573 1576 1577 END 1579 8. Extension Example 1581 Consider the following XML Schema for an extension example: 1583 BEGIN 1584 1586 1594 1597 1600 1601 1602 Example Extension #1 1603 1604 1606 1609 1610 1612 1613 1614 1615 1616 1617 1618 1619 1621 1622 1623 1625 1628 1629 END 1630 The following is an example deposit that includes the "idData" and 1631 "delIdData" elements: 1633 BEGIN 1634 1636 1644 2010-10-16T00:00:00Z 1646 1647 ns1.example.test 1648 1649 B54321Y 1650 C94820X 1651 1652 1654 1656 1657 1658 a12345z 1659 SH8013-REP 1660 G01348919 1661 MX 1662 1663 1664 b56243x 1665 SH8013-REP 1666 G937434319 1667 JP 1668 1669 1671 1672 1673 END 1675 9. Internationalization Considerations 1677 Data Escrow deposits are represented in XML, which provides native 1678 support for encoding information using the Unicode character set and 1679 its more compact representations including UTF-8. Conformant XML 1680 processors recognize both UTF-8 and UTF-16. Though XML includes 1681 provisions to identify and use other character encodings through use 1682 of an "encoding" attribute in an declaration, use of UTF-8 is 1683 RECOMMENDED. 1685 10. IANA Considerations 1687 This document uses URNs to describe XML namespaces and XML schemas 1688 conforming to a registry mechanism described in [RFC3688]. Two URI 1689 assignments have been registered by the IANA. 1691 Registration request for the RDE namespace: 1693 URI: urn:ietf:params:xml:ns:rde-1.0 1695 Registrant Contact: See the "Author's Address" section of this 1696 document. 1698 XML: None. Namespace URIs do not represent an XML specification. 1700 Registration request for the RDE XML schema: 1702 URI: urn:ietf:params:xml:schema:rde-1.0 1704 Registrant Contact: See the "Author's Address" section of this 1705 document. 1707 See the "Formal Syntax" section of this document. 1709 Registration request for the RDE domain namespace: 1711 URI: urn:ietf:params:xml:ns:rdeDomain-1.0 1713 Registrant Contact: See the "Author's Address" section of this 1714 document. 1716 XML: None. Namespace URIs do not represent an XML specification. 1718 Registration request for the RDE domain XML schema: 1720 URI: urn:ietf:params:xml:schema:rdeDomain-1.0 1721 Registrant Contact: See the "Author's Address" section of this 1722 document. 1724 See the "Formal Syntax" section of this document. 1726 Registration request for the RDE host namespace: 1728 URI: urn:ietf:params:xml:ns:rdeHost-1.0 1730 Registrant Contact: See the "Author's Address" section of this 1731 document. 1733 XML: None. Namespace URIs do not represent an XML specification. 1735 Registration request for the RDE host XML schema: 1737 URI: urn:ietf:params:xml:schema:rdeHost-1.0 1739 Registrant Contact: See the "Author's Address" section of this 1740 document. 1742 See the "Formal Syntax" section of this document. 1744 Registration request for the RDE contact namespace: 1746 URI: urn:ietf:params:xml:ns:rdeContact-1.0 1748 Registrant Contact: See the "Author's Address" section of this 1749 document. 1751 XML: None. Namespace URIs do not represent an XML specification. 1753 Registration request for the RDE contact XML schema: 1755 URI: urn:ietf:params:xml:schema:rdeContact-1.0 1757 Registrant Contact: See the "Author's Address" section of this 1758 document. 1760 See the "Formal Syntax" section of this document. 1762 Registration request for the RDE registrar namespace: 1764 URI: urn:ietf:params:xml:ns:rdeRegistrar-1.0 1766 Registrant Contact: See the "Author's Address" section of this 1767 document. 1769 XML: None. Namespace URIs do not represent an XML specification. 1771 Registration request for the RDE registrar XML schema: 1773 URI: urn:ietf:params:xml:schema:rdeRegistrar-1.0 1775 Registrant Contact: See the "Author's Address" section of this 1776 document. 1778 See the "Formal Syntax" section of this document. 1780 Registration request for the RDE IDN namespace: 1782 URI: urn:ietf:params:xml:ns:rdeIDN-1.0 1784 Registrant Contact: See the "Author's Address" section of this 1785 document. 1787 XML: None. Namespace URIs do not represent an XML specification. 1789 Registration request for the RDE registrar XML schema: 1791 URI: urn:ietf:params:xml:schema:rdeIDN-1.0 1793 Registrant Contact: See the "Author's Address" section of this 1794 document. 1796 See the "Formal Syntax" section of this document. 1798 11. Security Considerations 1800 This specification does not define the security mechanisms to be used 1801 in the transmission of the data escrow deposits, since it only 1802 specifies the minimum necessary to enable the rebuilding of a 1803 Registry from deposits without intervention from the original 1804 Registry. 1806 Depending on local policies, some elements or most likely, the whole 1807 deposit will be considered confidential. As such the Registry 1808 transmitting the data to the Escrow Agent SHOULD take all the 1809 necessary precautions like encrypting the data itself and/or the 1810 transport channel to avoid inadvertent disclosure of private data. 1812 It is also of the utmost importance the authentication of the parties 1813 passing data escrow deposit files. The Escrow Agent SHOULD properly 1814 authenticate the identity of the Registry before accepting data 1815 escrow deposits. In a similar manner, the Registry SHOULD 1816 authenticate the identity of the Escrow Agent before submitting any 1817 data. 1819 Additionally, the Registry and the Escrow Agent SHOULD use integrity 1820 checking mechanisms to ensure the data transmitted is what the source 1821 intended. Validation of the contents by the Escrow Agent is 1822 RECOMMENDED to ensure not only the file was transmitted correctly 1823 from the Registry, but also the contents are also "meaningful". 1825 12. Acknowledgments 1827 Parts of this document are based on EPP [RFC5730] and related RFCs by 1828 Scott Hollenbeck. 1830 13. Change History 1832 [[RFC Editor: Please remove this section.]] 1834 13.1. Changes from version 00 to 01 1836 1. Included DNSSEC elements as part of the basic element 1837 as defined in [RFC5910]. 1839 2. Included RGP elements as part of the basic element as 1840 defined in [RFC3915]. 1842 3. Added support for IDNs and IDN variants. 1844 4. Eliminated the element and all its subordinate 1845 objects, except . 1847 5. Renamed to and included it directly 1848 under root element. 1850 6. Renamed root element to . 1852 7. Added element under element. 1854 8. Added element under element. 1856 9. Reversed the order of the and elements. 1858 10. Removed minOccurs="0". 1860 11. Added element under root element. 1862 12. Added element under element. 1864 13. Removed element from element. 1866 14. Populated the "Security Considerations" section. 1868 15. Populated the "Internationalization Considerations" section. 1870 16. Populated the "Extension Example" section. 1872 17. Added element under element. 1874 18. Added element under element. 1876 19. Added element under root element. 1878 20. Fixed some typographical errors and omissions. 1880 14. References 1882 14.1. Normative References 1884 [ISO-3166-1] 1885 International Organization for Standardization, "Codes for 1886 the representation of names of countries and their 1887 subdivisions -- Part 1: Country codes", ISO Standard 3166, 1888 November 2006. 1890 [ITU-E164] 1891 International Telecommunication Union, "The international 1892 public telecommunication numbering plan", ITU-T 1893 Recommendation E.164, February 2005. 1895 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1896 Requirement Levels", BCP 14, RFC 2119, March 1997. 1898 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1899 Internet: Timestamps", RFC 3339, July 2002. 1901 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 1902 the Extensible Provisioning Protocol (EPP)", RFC 3915, 1903 September 2004. 1905 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1906 STD 69, RFC 5730, August 2009. 1908 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1909 Domain Name Mapping", STD 69, RFC 5731, August 2009. 1911 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1912 Host Mapping", STD 69, RFC 5732, August 2009. 1914 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1915 Contact Mapping", STD 69, RFC 5733, August 2009. 1917 [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) 1918 Security Extensions Mapping for the Extensible 1919 Provisioning Protocol (EPP)", RFC 5910, May 2010. 1921 14.2. Informative References 1923 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1924 September 1981. 1926 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1927 January 2004. 1929 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1930 Architecture", RFC 4291, February 2006. 1932 Authors' Addresses 1934 Francisco Arias 1935 Internet Corporation for Assigned Names and Numbers 1936 4676 Admiralty Way, Suite 330 1937 Marina del Rey 90292 1938 United States of America 1940 Phone: +1.310.823.9358 1941 Email: francisco.arias@icann.org 1943 Shoji Noguchi 1944 Japan Registry Services Co., Ltd. 1945 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 1946 Chiyoda-ku, Tokyo 101-0065 1947 Japan 1949 Phone: +81.3.5215.8451 1950 Email: noguchi@jprs.co.jp