draft-yao-regext-bundling-registration has been brought to the ISE for
publication as an Informational RFC in the Independent Submissions
Stream.
Previously, this work advanced through the EPPEXT and then the
REGEXT working group as draft-ietf-regext-bundling-registration.
That document passed working group last call, AD review, and IETF
last call before being assessed by the IESG. The IESG ballot shows
one Discuss (about the intended status of the document, and
whether it should be presented as a proprietary solution).
More notably, it appears that the IESG determined that the WG and IETF
last calls amounted to "consensus by silence," and that the IETF had no
reason to care about advancing the document. Barry Leibe, the
responsible AD at the time, was convinced by the arguments and suggested
to the authors that they try the Independent Stream.
The document was reviewed for the ISE by Yoshiro Yoneya who has
experience of registry management through his work at Japan Registry
Services. His review is shown below, as is the ISE's review. all
comments have been addressed satisfactorily.
John Klensin also sent significant comments and suggested text to the
authors who made changes accordingly.
The question of whether this document is of broad enough interest to the
wider community (or just to the registries that implement it) is to
some extent answered in the Introduction by the text:
This extension is especially useful for registries of practicing
Chinese domain name registration. This method is also useful for
other language domain names that have similar issues with Chinese
domain names.
The final document makes it clear that this is a proprietary
specification both in the Abstract...
This is a non-standard proprietary extension.
...and in the Introduction...
This document describes a non-standard proprietary extension.
Note that there is IPR disclosed against the original document at
https://datatracker.ietf.org/ipr/2479/ when the document was in
the EPPEXT working group.
A final point of note is that this document asks for IANA action that
is from registries that use the "Specification Required" allocation
policy. That means that review by a DE is required. The original
REGEXT document had already progressed through DE review and so we
expect that a further review is just a formality.
** Yoshiro Yoneya review **
Page 3: 1st paragraph
In this paragraph, the term 'V-label' and 'V-tld' are introduced.
V-label is said that 'shared the same TLD' but 'V-tld' is not.
It should be explicitly explained that V-tld must be managed by the same entity.
Page 3: last paragraph
Although original intention of bundling is for Chinese Domain Names,
it will be useful adding notes that this method is applicable for other
language domain names that have variants.
Page 4: 2. Terminology, 2nd paragraph
"LABEL.Variants" and "Variants.LABEL" notation is differ from Page3,
"LABEL.V-tld" and "V-label.TLD". Notation of technical term have to be
consistend in whole document.
The last sentence, "..., those TLDs should be controlled by the same registry"
will be more clear "..., those TLDs must be managed by the same entity".
Page 5: 3. Definitions
I don't see clear distinction between "Terminology" section and
"Definitions" section. Those can be mereged into one section.
Page 5: 4. Overview, 3rd paragraph
Before the last sentence, there should be explanation that there are
"allocatable" bundled names and "blocked" bundled names.
Both bundled names are in one package, but some objects such as name
server association and domain status are not synchronized (registrants
can't modify any object of blocked bundled names).
I believe this is very important concept of bundled names, but it is not
addressed in this document.
This document seems assuming any bundled names are all allocatable bundled names.
Informative reference to LGR (RFC 7940) and ICANN Root/SLD LGR works
will be very helpful.
Page 6: 2nd paragraph
The 3rd point, "o When performing a domain Create, either of the bundle
names will be accepted. If the domain name is available, both BDN and
RDN will be registered." is contradictional.
The label (domain name) used for domain create it is always RDN.
Apparantly from its definition, BDN is delivarable of RDN.
Page 8: Example <check> response:
As its nature of variants, BDNs for a RDN could be tens of thousands or more.
This fact means that the response of <check> for BDNs will be huge size.
Therefore, there must be some mechanisms to eliminate huge response,
such as indicating numbers of BDNs and temporal download URI for all of BDNs.
Otherwise, this could be DoS mechanism for both registries and registrars.
Page 9: Example <info> response for an authorized client:
As mentioned above, BDNs have "allocatable" or "blocked" attribute also.
Those must be included in the response.
Response size issue commented at <check> command is issue here also.
Page 11: 7.2.1. EPP <create> Command
I can't understand meaning for <b-dn:create> extension.
Is it for specifying uLabel? If so, why A-Label in <domain:name> is insufficient?
Clarification of <b-dn:create> extention meaning is very much appreciated.
Page 12: Example <create> response:
Please refer comments for <check> command above (for Page 8).
Page 13: 7.2.2. EPP <delete> Command
Please refer comments for <check> command above (for Page 8).
Page 14: 7.2.3. EPP <renew> Command
Please refer comments for <check> command above (for Page 8).
Page 16: Example <transfer> response:
Please refer comments for <check> command above (for Page 8).
Page 17: Example <update> response:
Please refer comments for <check> command above (for Page 8).
Page 21: 1st paragraph
I assume this paragraph is going to say "zone file for RDN and BDNs
can be different even though served by the same name server."
If this document mandates domain objects of RDN/BDNs (except for
"blocked" BDNs) are bundled and being the same (synchronized),
DS/DNSKEY records have to be the same as well.
And if it is correct, this paragraph should say "Because RDN/BDNs share
the same DS/DNSKEY information, signing keys for those zones must be
the same, therefore, the bundled domain names share fate if there is a
key compromise."
** ISE review **
==Question==
Is there an issue to consider about interop between implementations that
do and do not support the extensions in this document. This would
happen either if a client that supports this document sends a request to
a server that does not support this document (I think that is safe from
my understanding of this draft), or if a client that does not support
this document receives a response from a server that does support it (I
think this is more of a risk, but I suspect that RFC 5731 may cover
this.
It could be nice to add a few lines of text just to reassure people that
there are no issues.
==Rewrite==
The IANA section could usefully indicate the name of the registry so
IANA can easily determine what action to take. Also, I think it will
make things easier to follow it you break section 9 into subsections.
So...
OLD
9. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688]. IANA is
requested to assignment the following two URIs.
Registration request for the IDN namespace:
o URI: urn:ietf:params:xml:ns:epp:b-dn
o Registrant Contact: See the "Author's Address" section of this
document.
o XML: None. Namespace URI does not represent an XML specification.
Registration request for the IDN XML schema:
o URI: urn:ietf:params:xml:schema:epp:b-dn
o Registrant Contact: See the "Author's Address" section of this
document.
o XML: See the "Formal Syntax" section of this document.
The EPP extension described in this document should be registered by
IANA in the "Extensions for the Extensible Provisioning Protocol
(EPP)" registry described in [RFC7451]. The details of the
registration are as follows:
o Name of Extension: "Domain Name Mapping Extension for Strict
Bundling Registration"
o Document status: Informational
o Reference: This document
o Registrant Name and Email Address: See the "Author's Address"
section of this document.
o Top-Level Domains (TLDs): Any
o IPR Disclosure: https://datatracker.ietf.org/ipr/
o Status: Active
o Notes: None
NEW
9. IANA Considerations
9.1. XML Namespace and XML Schema
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688].
9.1.1. IDN Namespace
IANA is requested to make an assignment from the IETF XML Registry
"ns" registry as follows for the IDN namespace with this document
as the reference:
o URI: urn:ietf:params:xml:ns:epp:b-dn
o Registrant Contact: See the "Author's Address" section of this
document.
o XML: None. Namespace URI does not represent an XML specification.
9.1.2. IDN XML Schema
IANA is requested to make an assignment from the IETF XML Registry
"schema" registry as follows for the IDN XML schema with this
document as the reference:
o URI: urn:ietf:params:xml:schema:epp:b-dn
o Registrant Contact: See the "Author's Address" section of this
document.
o XML: See the "Formal Syntax" section of this document.
9.2. EPP Extension
The EPP extension described in this document should be registered by
IANA in the "Extensions for the Extensible Provisioning Protocol
(EPP)" registry described in [RFC7451]. The details of the
registration are as follows:
o Name of Extension: "Domain Name Mapping Extension for Strict
Bundling Registration"
o Document status: Informational
o Reference: This document
o Registrant Name and Email Address: See the "Author's Address"
section of this document.
o Top-Level Domains (TLDs): Any
o IPR Disclosure: https://datatracker.ietf.org/ipr/
o Status: Active
o Notes: None
END
==Nits==
1.
s/In RFC4290/In RFC4290 [RFC4290]/
s/according the domain/according to the domain/
s/the same TLD/the same Top Level Domain (TLD)/
s/For an example, Public/For example, the Public/
s/label(LABEL)/label (LABEL)/
s/names to share many same/names to share many of the same/
s/transferring of any/transferring any/
s/bundling names registration/bundling name registration/
s/variant IDNs should/variant Internationalized Domain Name (IDNs) should/
2.
s/according the domain/according to the domain/
OLD
The Registered Domain Name(RDN) and Bundled Domain Name(BDN) are used
in this document.
NEW
The terms Registered Domain Name (RDN) and Bundled Domain Name (BDN)
are used in this document.
END
OLD
In the current practice, BDN's number will
usually be kept to one according to the registration policy set by
the registry.
NEW
In current practice, the number of BDNs is
usually be kept to one according to the registration policy set by
the registry.
END
3.
OLD
that property of all other domain objects in the bundle
package will be updated at the same time.
NEW
that property will be updated at the same time for all other domain
objects in the bundle package.
END
4.
s/some parameter or attributes/some parameters or attributes/
Second bullet list. Can you format the bullets with:
- all text indented and aligned
- a blank line between bullets
4.
In the second bullet list, you have EPP commands in different cases
for example, domain transfer and domain Create. For clarity, I think
these might usefully always be capitalised as Domain Transfer and Domain
Create. Note, however, that 5731 uses "EPP <create>" or simply
"<create>". You probably want to mirror that way of doing things since
it is consistent with later on in the document.
6.1.2
s/changed,see/changed, see/
6.2.1
s/When an <create> command/When a <create> command/
s/if an <create> command/if a <create> command/
8.
s/use of UTF-8 is recommend./use of UTF-8 is recommended./
s/the elements, element/the elements, and element/
10.
s/more than 15 years/more than 15 years experience/