[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: IETF ldapbis WG Last Call: draft-ietf-ldapbis-iana-04.txt
Having finished my first pass of draft-ietf-ldapbis-iana-04.txt, I have
a couple of editorial suggestions (to clean up punctuation and grammar)
and two technical issues.
===Editorial points===
-In section 3.5, shouldn't the sentence
Keywords associated with integers in the range 0-1023 SHALL NOT start
with "e-" or "x- the range 1024-8191 SHALL start with "e-".
be #"
Keywords associated with integers in the range 0-1023 SHALL NOT start
with "e-" or "x-". Further, the range 1024-8191 SHALL start with "e-"
only.
-In section 3.7, the sentence
For historical purposes, the current list of registered names SHOULD be
remain available.
should read
For historical purposes, the current list of registered names SHOULD
remain available.
-In section 4, the sentence
The requester is viewed is the owner of values registered under Expert
Review.
should read
The requester is viewed as the owner of values registered under Expert
Review.
-Also in section 4, the sentence
The requester is viewed is the owner of values registered under First
Come First Served.
should read
The requester is viewed as the owner of values registered under First
Come First Served.
===Technical issues===
1. Several searches on the ldapbis mailing archives failed to show any
discussion on the limits on protocol descriptors and option strings.
I for one am uncomfortable with applying such limits without more discussion.
Rather, once the requester has met the "SHOULD" consideration, I don't
think IANA should be given the right to arbitrarily refuse a request just
because of length. I propose striking the sentences
"IANA MAY refuse to register any descriptor over 48 characters in length."
and
"IANA MAY refuse to register any option over 16 characters in length."
2. In section 5.3, there a reference to a change control request.
It is not clear from the rest of the document what the process is for
the change control request triggering a specification update or IESG
asserting ownership. I think this needs to be addressed to provide some
guidance to requesters (both for initial requests and subsequent requests).
Ryan Moats