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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/