< 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="实例.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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
