Subject: [regext] AD Review: draft-ietf-regext-bundling-registration

From: Adam Roach <[email-masked]>
Date: Fri, 1 Mar 2019 16:17:10 -0600

This is my Area Director review for 
draft-ietf-regext-bundling-registration. I
have a handful of comments on the document's comments, but none are of the
nature that preclude going into IETF last call, which should begin shortly.
Please treat my comments below the same as as IETF last call comments.

Thanks to everyone who worked on this specification.

---------------------------------------------------------------------------

General: This document is grammatically incorrect or awkward in many 
places in
a way that detracts from its readability. I believe it would benefit from an
editorial pass by a skilled editor. I call out specific issues in section 1
below; however, in the interest of primarily reviewing the technical content
of this document, I have not indicated them for other sections.

---------------------------------------------------------------------------

§1:

 >  Bundled domain names are those which share the same TLD but whose
 >  second level labels are variants, or those which has identical second

Nit: "...those which have..."

 >  TLDs.  For example, Public Interest Registry, request to implement
 >  technical bundling of second level domains for .NGO and .ONG.

Nit: "For example, the Public Interest Registry has requested 
implementation of
bundling of second-level domains for..."

 >  First one is strict bundling, which requires all
 >  bundled names to share many same attributes

Nit: "The first one... share many of the same..."

 >  Second
 >  one is partial bundling

Nit: "The second one..."

 >  Third one is relax bundling, which has not specific
 >  requirements to the domain registration.  This document mainly focus
 >  on strict bundling names registration.

Nit: "The third one... has no specific... mainly focuses..."

 >  In order to meet above requirements of the strict bundled names
 >  registration

Nit: "...bundled name registration..."

 >  names.This document is specified using the Extensible Markup Language

Nit: "...names. This..."

 >  This document uses lots of the concepts of the IDN, so a thorough

Nit: "...uses lots of IDN concepts, so..."

---------------------------------------------------------------------------

§2:

 >  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].

Please use the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§2:

 >  "b-dn-1.0" in this document is used as an abbreviation for
 >  urn:ietf:params:xml:ns:epp:b-dn-1.0.

I don't see this abbreviation used anywhere in the document. I do see 
the use of
the "<b-dn:..." prefix in a number of places. Should this refer to 
"b-dn" rather
than "b-dn-1.0"?

---------------------------------------------------------------------------

§2:

 >  white space in examples are provided only to illustrate element
 >  relationships and are not a REQUIRED feature of this specification.

This is inconsistent with the RFC 2119 meaning of "REQUIRED." Please replace
"REQUIRED" with "required".

---------------------------------------------------------------------------

§5:

 >  o When performing a domain Create, either BDN or RDN will be
 >  accepted.  If the domain name is available, both BDN and RDN will be
 >  registered.

This seems to go against the definition of "RDN" given earlier: "Registered
Domain Name (RDN), represents the valid domain name that users submitted for
registration by the first time."  My understanding is that "Create" is the
process of registering a name for the first time, and so the name given 
will be
the RDN, by the definition of RDN.

Is my understanding correct?

---------------------------------------------------------------------------

§6.1:

 >  For example: <b-dn:rdn uLabel="U+5B9E""U+4F8B".example> xn--
 >  fsq270a.example</b-dn:rdn>

I presume that this would literally be:

   <b-dn:rdn uLabel="实例.example"> xn--fsq270a.example</b-dn:rdn>

...and that the use of the "U+...." format is to deal with the current
restrictions on the RFC format, correct? If so, the handling of 
quotation marks
in the preceding example is very confusing: XML requires attributes to be
fully enclosed in quotation marks, and the current example leaves ".example"
outside of them.

Consider using the XML escaping mechanism in these examples instead:

   <b-dn:rdn uLabel="&#x5B9E;&#x4F8B;.example"> 
xn--fsq270a.example</b-dn:rdn>

Alternately, if you want to use the format described in Section 2, this 
would
look like:

   <b-dn:rdn uLabel="U+5B9EU+4F8B.example"> xn--fsq270a.example</b-dn:rdn>

I would, however, advise using a different convention than this, as it is
somewhat difficult to read.

This same comment applies to other examples of the "uLabel" attribute as 
well.

---------------------------------------------------------------------------

§7.2.1:

 >  The <extension> element SHOULD contain a child
 >  <b-dn:create> element that identifies the bundle namespace and the
 >  location of the bundle name schema.

This description appears to be somewhat incomplete; the example shows it 
also
containing a <b-dn:rdn> element. Please either expand the text to 
include the
purpose and meaning of the <b-dn:rdn> element in this context; or, if it 
should
not be in the example, remove it from the example.

---------------------------------------------------------------------------

§8:

 >     <element name="infData" type="b-dn:trnDataType"/>
 >     <element name="delData" type="b-dn:trnDataType"/>
 >     <element name="creData" type="b-dn:trnDataType"/>
 >     <element name="renData" type="b-dn:trnDataType"/>
 >     <element name="trnData" type="b-dn:trnDataType"/>
 >     <element name="upData" type="b-dn:trnDataType"/>
 >
 >     <complexType name="trnDataType">
 >       <sequence>
 >             <element name="bundle" type="b-dn:bundleType" />
 >       </sequence>
 >     </complexType>

Although there's nothing syntactically wrong with it, the use of 
"trnDataType"
(implying "<transfer>" operations) for all six operations is a bit 
confusing.
Consider renaming something like "bundleDateType".

/a

---

From: "Jiankang Yao" <[email-masked]>
Date: Fri, 15 Mar 2019 09:37:08 +0800

< From: Adam Roach
< Date: 2019-03-02 06:17
< To: draft-ietf-regext-bundling-registration.all
< CC: Registration Protocols Extensions
< Subject: AD Review: draft-ietf-regext-bundling-registration
< This is my Area Director review for 
< draft-ietf-regext-bundling-registration. I
< have a handful of comments on the document's comments, but none are of the
< nature that preclude going into IETF last call, which should begin shortly.
< Please treat my comments below the same as as IETF last call comments.
< Thanks to everyone who worked on this specification.
< ---------------------------------------------------------------------------

Thanks a lot to AD's kind and detail review.

< General: This document is grammatically incorrect or awkward in many 
< places in
< a way that detracts from its readability. I believe it would benefit from an
< editorial pass by a skilled editor. I call out specific issues in section 1
< below; however, in the interest of primarily reviewing the technical content
< of this document, I have not indicated them for other sections.
< ---------------------------------------------------------------------------
< §1:
< Bundled domain names are those which share the same TLD but whose
 <second level labels are variants, or those which has identical second
< Nit: "...those which have..."
< TLDs. For example, Public Interest Registry, request to implement
< technical bundling of second level domains for .NGO and .ONG.
< Nit: "For example, the Public Interest Registry has requested 
< implementation of
< bundling of second-level domains for..."
 <First one is strict bundling, which requires all
< bundled names to share many same attributes
< Nit: "The first one... share many of the same..."
< Second
< one is partial bundling
< Nit: "The second one..."
< Third one is relax bundling, which has not specific
< requirements to the domain registration. This document mainly focus
< on strict bundling names registration.
< Nit: "The third one... has no specific... mainly focuses..."
< In order to meet above requirements of the strict bundled names
< registration
< Nit: "...bundled name registration..."
< names.This document is specified using the Extensible Markup Language
< Nit: "...names. This..."
< This document uses lots of the concepts of the IDN, so a thorough
< Nit: "...uses lots of IDN concepts, so..."
< ---------------------------------------------------------------------------

Thanks. We will update it in the new version. We will have a more detailed review. 
The native English speaker/editor will help to review it.

< §2:
 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].
< Please use the boilerplate from RFC 8174.
< ---------------------------------------------------------------------------

ok, we will update it.

< §2:
 "b-dn-1.0" in this document is used as an abbreviation for
 urn:ietf:params:xml:ns:epp:b-dn-1.0.
< I don't see this abbreviation used anywhere in the document. I do see 
< the use of
< the "<b-dn:..." prefix in a number of places. Should this refer to 
< "b-dn" rather
< than "b-dn-1.0"?
< ---------------------------------------------------------------------------

Thanks for catching it.  We will remove the version -1.0, and use b-dn.

< §2:
<  white space in examples are provided only to illustrate element
<  relationships and are not a REQUIRED feature of this specification.
< This is inconsistent with the RFC 2119 meaning of "REQUIRED." Please replace
< "REQUIRED" with "required".
< ---------------------------------------------------------------------------

ok, we will update it.

< §5:
<  o When performing a domain Create, either BDN or RDN will be
<  accepted. If the domain name is available, both BDN and RDN will be
<  registered.
< This seems to go against the definition of "RDN" given earlier: "Registered
< Domain Name (RDN), represents the valid domain name that users submitted for
< registration by the first time." My understanding is that "Create" is the
< process of registering a name for the first time, and so the name given 
< will be
< the RDN, by the definition of RDN.
< Is my understanding correct?
< ---------------------------------------------------------------------------

Yes, your understanding is correct. We will clarify the text.

< §6.1:
 < For example: <b-dn:rdn uLabel="U+5B9E""U+4F8B".example> xn--
<  fsq270a.example</b-dn:rdn>
< I presume that this would literally be:
< <b-dn:rdn uLabel="实例.example"> xn--fsq270a.example</b-dn:rdn>
< ...and that the use of the "U+...." format is to deal with the current
< restrictions on the RFC format, correct? If so, the handling of 
< quotation marks
< in the preceding example is very confusing: XML requires attributes to be
< fully enclosed in quotation marks, and the current example leaves ".example"
< outside of them.
< Consider using the XML escaping mechanism in these examples instead:
< <b-dn:rdn uLabel="&#x5B9E;&#x4F8B;.example"> 
< xn--fsq270a.example</b-dn:rdn>
< Alternately, if you want to use the format described in Section 2, this 
< would
< look like:
< <b-dn:rdn uLabel="U+5B9EU+4F8B.example"> xn--fsq270a.example</b-dn:rdn>
< I would, however, advise using a different convention than this, as it is
< somewhat difficult to read.
< This same comment applies to other examples of the "uLabel" attribute as 
< well.
< ---------------------------------------------------------------------------

Thanks.
We will see whether use <b-dn:rdn uLabel="U+5B9EU+4F8B.example">   or  <b-dn:rdn uLabel="实例.example"> .
either way has advantage and disadvantage. 

< §7.2.1:
< The <extension> element SHOULD contain a child
 <b-dn:create> element that identifies the bundle namespace and the
 location of the bundle name schema.
< This description appears to be somewhat incomplete; the example shows it 
< also
< containing a <b-dn:rdn> element. Please either expand the text to 
< include the
< purpose and meaning of the <b-dn:rdn> element in this context; or, if it 
< should
< not be in the example, remove it from the example.
< ---------------------------------------------------------------------------

Ok, thanks. We will update it.

< §8:
< <element name="infData" type="b-dn:trnDataType"/>
< <element name="delData" type="b-dn:trnDataType"/>
< <element name="creData" type="b-dn:trnDataType"/>
< <element name="renData" type="b-dn:trnDataType"/>
< <element name="trnData" type="b-dn:trnDataType"/>
< <element name="upData" type="b-dn:trnDataType"/>
< >
< <complexType name="trnDataType">
< <sequence>
< <element name="bundle" type="b-dn:bundleType" />
< </sequence>
< </complexType>
< Although there's nothing syntactically wrong with it, the use of 
< "trnDataType"
< (implying "<transfer>" operations) for all six operations is a bit 
< confusing.
< Consider renaming something like "bundleDateType".
<

Good suggestion. We will consider to use   "bundleDateType".

Jiankang Yao

< /a