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