[Ballot comment]
Clearing my Discuss:

The issue concerned the use of the word "owner" for
the registry objects, particularly the IESG owning them.
Kurt pointed out there is much precedent, including some
words in RFC 2434, and in many IANA registry labels themselves
(though not all).  I think there is still some consideration
to be made of this, for instance, the IESG point, but I
can agree that this document does not have to be the place.
I'll send a comment for rfc2434bis and I suggest that
this be raised by the IANA RFP parties (the registry objects,
change control versus ownership terms for IETF).

I've changed my position to No-Obj

[Ballot comment]
Thoughts I have for personal followup of my issue about the
term "owner" (especially IESG owning) even though it has
precedent:  I'll make a comment on the rfc2434bis and I'll
comment towards the discussions on future IANA service.
I'm pretty sure we need to clarify this issue.

But this document need not solve the problem, so I've
turned my position to a no-objection, with thanks to
Kurt for explaining the whole context to me.

[Ballot comment]
Thoughts I have for personal followup of my issue about the
term "owner" (especially IESG owning) even though it has
precedent:  I'll make a comment on the rfc2434bis and I'll
comment towards the discussions on future IANA service.
I'm pretty sure we need to clarify this issue.

But this document need not solve the problem, so I've
turned my position to a no-objection, with thanks to
Curt for explaining the whole context to me.

[Ballot discuss]
Since bcp64 is the last remaining document in the 20-document ldapbis dependency graph, and this issue was also in the existing BCP 64 without the Internet falling down around us, I'll clear my discuss without requiring any change.

[Ballot discuss]
[This issue remains in -06]
It seems misleading to describe a keyword as
  "a case-insensitive string of UTF-8 [RFC3629] encoded 
  Unicode [Unicode] restricted to the <keystring> production.".
The <keystring> production restricts strings to a subset of
US-ASCII, so UTF-8 need not enter into things.

Adding (or appropriately referring to) the productions from RFC 3629 might be appropriate, if I'm guessing the intent properly perhaps the following makes sense:

  keychar    = ALPHA / DIGIT / HYPHEN / UTF8-hichar
  UTF8-hichar = UTF8-2 / UTF8-3 / UTF8-4
; either "import" UTF8-2, UTF8-3 and UTF8-4" from RFC 3629
; or simply replicate them
  UTF8-2      = %xC2-DF UTF8-tail
  UTF8-3      = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
                %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
  UTF8-4      = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) /
                %xF4 %x80-8F 2( UTF8-tail )
  UTF8-tail  = %x80-BF

(This error exists in RFC 3383 too, but it would be nice to fix)

[Ballot discuss]
"The requester is viewed as the owner of values registered under
  Expert Review."

  "For registrations...owned by the IESG"

This terminology of ownership of registrations is problematic in our world of
IPR.  Please substitutue "has change control"?  This also helps with the fact that the
requester in the case of the Expert Review situations may be representing another
standards body.
------

Procedural request:  the AD should tell IESG/IANA who the Expert Reviewer is, and who
the Secondary is (and IANA should tell us, if they're incumbent, whether they're
performing well).

[Ballot discuss]
"The requester is viewed as the owner of values registered under
  Expert Review."

  "For registrations...owned by the IESG"

This terminology of ownership of registrations is problematic in our world of
IPR.  Please substitutue "has change control"?  This also helps with the fact that the
requester in the case of the Expert Review situations may be representing another
standards body.
------

Procedural request:  the AD should tell IESG/IANA who the Expert Reviewer is, and who
the Secondary is (and IANA should tell us, if they're incumbent, whether they're
performing well).

[Ballot discuss]
one but last para of sect 3.1 states:

  Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by
  IANA <http://www.iana.org/cgi-bin/enterprise.pl>.  Practices for IANA
  assignment of Internet Private Enterprise Numbers is detailed in STD
  16 [RFC1155].

But this is (no longer true. In fact RFC2578 has the definitions
as is also indicated on the IANA web page.

last para of sect 3.1 states:
  To avoid interoperability problems between early implementations of a
  "work in progress" and implementations of the published specification
  (e.g., the RFC), experimental OIDs SHOULD be used in "works in
  progress" and early implementations.  OIDs under the Internet
  Experimental OID arc (1.3.6.1.3.x) may be used for this purpose.
  Practices for IANA assignment of these Internet Experimental numbers
  is detailed in STD 16 [RFC1155].

Again I believe it is RFC2578 (sect 4) that defines the "exprimental"
branch in the OID tree. IANA has a (?) on their pages, that porbably needs
updating too
While

IANA Comments:
Upon approval of this document the IANA will create 4 new registries for  LDAP Syntax, Search Scope, Filter Choice, ModifyRequest operation, and authzId prefixes.  These new registries will be found at the following:
http://www.iana.org/assignments/ldap-parameters

[Ballot discuss]
It seems misleading to describe a keyword as
  "a case-insensitive string of UTF-8 [RFC3629] encoded 
  Unicode [Unicode] restricted to the <keystring> production.".
The <keystring> production restricts strings to a subset of
US-ASCII, so UTF-8 need not enter into things.

Adding (or appropriately referring to) the productions from RFC 3629 might be appropriate, if I'm guessing the intent properly perhaps the following makes sense:

  keychar    = ALPHA / DIGIT / HYPHEN / UTF8-hichar
  UTF8-hichar = UTF8-2 / UTF8-3 / UTF8-4
; either "import" UTF8-2, UTF8-3 and UTF8-4" from RFC 3629
; or simply replicate them
  UTF8-2      = %xC2-DF UTF8-tail
  UTF8-3      = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
                %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
  UTF8-4      = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) /
                %xF4 %x80-8F 2( UTF8-tail )
  UTF8-tail  = %x80-BF

(This error exists in RFC 3383 too, but it would be nice to fix)

[Ballot comment]
From Gen-ART review by Joel Halpern:

Question: Based on the issues that have been raised about reviews recently,
should this document be more specific as to what kinds of issues the expert
reviewer is to look for in each kind of item to be reviewed, and why?  (I
am not arguing with the WGs choice of mechanism, just trying to head off
trouble that can be foreseen.)

[BC - I think that would be asking too much]

Question: Is the last sentence of the second paragraph of 3.4 intended to
call for expert review of all descriptors, or only of descriptors
referencing different object identifiers from an already registered
descriptor with the same name?  While I find this verbiage awkward in the
other places it is used, this particular usage is less clear than the others.

[BC - a small clarification would help]

Editorial: In section 3, the word "expecting" is almost certainly "excepting".

[Ballot comment]
Some small editorial things.  Section 3:

"IANA may reject obviously bogus registrations described." appears to be a sentence fragment.

"Other LDAP values, expecting those in private-use name spaces, SHOULD be registered." "expecting"?  Maybe "except"?

"or otherwise recongize unregistered" s/recongize/recognize/