--- 1/draft-ietf-regext-bundling-registration-05.txt 2018-10-11 03:13:44.844947021 -0700 +++ 2/draft-ietf-regext-bundling-registration-06.txt 2018-10-11 03:13:44.892948159 -0700 @@ -1,24 +1,24 @@ Internet Engineering Task Force N. Kong Internet-Draft Consultant Intended status: Informational J. Yao, Ed. -Expires: March 3, 2019 L. Zhou +Expires: April 14, 2019 L. Zhou CNNIC W. Tan Cloud Registry J. Xie - August 30, 2018 + October 11, 2018 Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration - draft-ietf-regext-bundling-registration-05 + draft-ietf-regext-bundling-registration-06 Abstract This document describes an extension of Extensible Provisioning Protocol (EPP) domain name mapping for the provisioning and management of strict bundling registration of domain names. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of bundled domain names. @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 3, 2019. + This Internet-Draft will expire on April 14, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -79,41 +79,42 @@ 7. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 7 7.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 7 7.1.1. EPP Command . . . . . . . . . . . . . . . . . 7 7.1.2. EPP Command . . . . . . . . . . . . . . . . . 8 7.1.3. EPP Query Command . . . . . . . . . . . . 10 7.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 10 7.2.1. EPP Command . . . . . . . . . . . . . . . . 11 7.2.2. EPP Command . . . . . . . . . . . . . . . . 12 7.2.3. EPP Command . . . . . . . . . . . . . . . . . 13 7.2.4. EPP Command . . . . . . . . . . . . . . . 14 - 7.2.5. EPP Command . . . . . . . . . . . . . . . . 14 - 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 - 9. Internationalization Considerations . . . . . . . . . . . . . 16 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 - 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 - 14. Change History . . . . . . . . . . . . . . . . . . . . . . . 18 - 14.1. draft-kong-epp-bundle-mapping: Version 00 . . . . . . . 18 - 14.2. draft-kong-epp-bundle-mapping: Version 01 . . . . . . . 18 - 14.3. draft-kong-epp-bundle-mapping: Version 02 . . . . . . . 18 - 14.4. draft-ietf-regext-bundle-mapping: Version 00 . . . . . . 18 - 14.5. draft-ietf-regext-bundle-mapping: Version 01 . . . . . . 18 - 14.6. draft-ietf-regext-bundle-mapping: Version 02 . . . . . . 18 - 14.7. draft-ietf-regext-bundle-mapping: Version 03 . . . . . . 18 - 14.8. draft-ietf-regext-bundle-mapping: Version 04 . . . . . . 18 - 14.9. draft-ietf-regext-bundle-mapping: Version 05 . . . . . . 19 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 15.1. Normative References . . . . . . . . . . . . . . . . . . 19 - 15.2. Informative References . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 + 7.2.5. EPP Command . . . . . . . . . . . . . . . . 15 + 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9. Internationalization Considerations . . . . . . . . . . . . . 18 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 + 14. Change History . . . . . . . . . . . . . . . . . . . . . . . 20 + 14.1. draft-kong-epp-bundle-mapping: Version 00 . . . . . . . 20 + 14.2. draft-kong-epp-bundle-mapping: Version 01 . . . . . . . 20 + 14.3. draft-kong-epp-bundle-mapping: Version 02 . . . . . . . 20 + 14.4. draft-ietf-regext-bundle-mapping: Version 00 . . . . . . 20 + 14.5. draft-ietf-regext-bundle-mapping: Version 01 . . . . . . 20 + 14.6. draft-ietf-regext-bundle-mapping: Version 02 . . . . . . 21 + 14.7. draft-ietf-regext-bundle-mapping: Version 03 . . . . . . 21 + 14.8. draft-ietf-regext-bundle-mapping: Version 04 . . . . . . 21 + 14.9. draft-ietf-regext-bundle-mapping: Version 05 . . . . . . 21 + 14.10. draft-ietf-regext-bundle-mapping: Version 06 . . . . . . 21 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 15.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 15.2. Informative References . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Bundled domain names are those which share the same TLD but whose second level labels are variants, or those which has identical second level labels for which certain parameters are shared in different TLDs. For example, Public Interest Registry, request to implement technical bundling of second level domains for .NGO and .ONG. So we have two kinds of bundled domain names. First one is in the form of "V-label.TLD" in which the second level labels (V-label) are variants @@ -164,23 +165,24 @@ understanding of the IDNs for Application (IDNA, described in [RFC5890], [RFC5891], and [RFC5892]) and a thorough understanding of variant approach discussed in [RFC4290] are both required. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. - uLable is defined in [RFC 5890]. uLabel is expressed in this document - as a number of characters with the format of U+XXXX where XXXX is a - UNICODE point. + uLabel in this document is used to express U-label of the + internationalized domain name into series of characters where non- + ASCII characters will be represented with the format of U+XXXX where + XXXX is a UNICODE point. U-Label is defined in [RFC5890]. "b-dn-1.0" in this document is used as an abbreviation for urn:ietf:params:xml:ns:epp:b-dn-1.0. In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in examples are provided only to illustrate element relationships and are not a REQUIRED feature of this specification. XML is case sensitive. Unless stated otherwise, XML specifications @@ -591,42 +593,143 @@ An EPP error response MUST be returned if a command cannot be processed for any reason. 7.2.3. EPP Command This extension does not add any element to the EPP command described in the EPP domain name mapping [RFC5731]. However, when either RDN or BDN is sent for renew, response SHOULD contain both RDN and BDN information. When the command has been processed - successfully, the EPP element MUST contain child elements - as described in the EPP domain mapping [RFC5731]. This EPP - element SHOULD contain the which contains - element. + successfully, the EPP element SHOULD be contained in the + resoponse if the domain object has data associated with bundled + names. This EPP element SHOULD contain the + which contains element. + + Example Response for an authorized client: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: xn--fsq270a.example + S: 2012-04-03T22:00:00.0Z + S: + S: + S: + S: + S: + S: xn--fsq270a.example + S: xn--fsqz41a.example + S: + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: 7.2.4. EPP Command This extension does not add any element to the EPP command - described in the EPP domain name mapping [RFC5731]. When the command - has been processed successfully, the EPP element MUST - contain child elements as described in the EPP domain mapping - [RFC5731]. This EPP element SHOULD contain the + described in the EPP domain name mapping [RFC5731]. However, + additional elements are defined for the response in the + EPP object mapping. When the command has been processed + successfully, the EPP element SHOULD be contained in the + resoponse if the domain object has data associated with bundled + names. This EPP element SHOULD contain the which contains element. + Example Response for an authorized client: + + S: + S: + S: + S: + S: Command completed successfully; action pending + S: + S: + S: + S: xn--fsq270a.example + S: pending + S: ClientX + S: 2011-04-03T22:00:00.0Z + S: ClientY + S: 2011-04-08T22:00:00.0Z + S: 2012-04-03T22:00:00.0Z + S: + S: + S: + S: + S: + S: xn--fsq270a.example + S: xn--fsqz41a.example + S: + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + 7.2.5. EPP Command This extension does not add any element to the EPP command - described in the EPP domain name mapping [RFC5731]. When the command - has been processed successfully, the EPP element MUST - contain child elements as described in the EPP domain mapping - [RFC5731]. This EPP element SHOULD contain the - which contains element. + described in the EPP domain name mapping [RFC5731]. However, + additional elements are defined for the response in the EPP + object mapping. When the command has been processed successfully, + the EPP element SHOULD be contained in the resoponse if + the domain object has data associated with bundled names. This EPP + element SHOULD contain the which contains + element. + + Example Response for an authorized client: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: + S: xn--fsq270a.example + S: xn--fsqz41a.example + S: + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: 8. Formal Syntax An EPP object name mapping extension for bundled names is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The BEGIN and END tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes. @@ -754,24 +856,29 @@ o URI: urn:ietf:params:xml:schema:epp:b-dn-1.0 o Registrant Contact: See the "Author's Address" section of this document. o XML: See the "Formal Syntax" section of this document. 11. Security Considerations - The object mapping extension described in this document does not - provide any other security services or introduce any additional - considerations beyond those described by [RFC5730] or those caused by - the protocol layers used by EPP. + Some registries and registrars have more than 15 years of the bundled + registration of domain names (especially Chinese domain names). They + have not found some significant security issues. One principle that + the registry and registrar should let the registrants know is that + bundled registered domain names will be created, transfered, updated, + and deleted together as a group. The registrants for bundled domain + names should remember this principle when doing some operations to + these domain names. [RFC5730] also introduces some security + consideration. 12. Implementation Status Note to RFC Editor: Please remove this section before publication. o The Chinese Domain Name Consortium(CDNC) including CNNIC, TWNIC, HKIRC, MONIC, SGNIC and more have followed the principles defined in this document for many years. o CNNIC and TELEINFO have implemented this extension in their EPP @@ -783,23 +890,21 @@ example, the NGO registrant is also registering and purchasing the corresponding name in the .ong TLD (and vice-versa for registrations in .ong). o Patrick Mevzek has released a new version of Net::DRI, an EPP client (Perl library, free software) implementing this extension. 13. Acknowledgements The authors especially thank the authors of [RFC5730] and [RFC5731] - and the following ones of CNNIC: Weiping Yang, Chao Qi. This draft - extends the draft draft-kong-epp-idn-variants-mapping to support both - forms of bundled names: V-label.TLD and LABEL.V-tld. + and the following ones of CNNIC: Weiping Yang, Chao Qi. Useful comments were made by John Klensin, Scott Hollenbeck, Patrick Mevzek and Edward Lewis. 14. Change History RFC Editor: Please remove this section. 14.1. draft-kong-epp-bundle-mapping: Version 00 @@ -839,20 +944,26 @@ 14.8. draft-ietf-regext-bundle-mapping: Version 04 o Update the implementation section. o Refine the text. 14.9. draft-ietf-regext-bundle-mapping: Version 05 o Scope the XML namespaces to include 'epp'. +14.10. draft-ietf-regext-bundle-mapping: Version 06 + + o add some examples for the transfer, update and renew command + + o add some text to security consideration + 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,