Talked to Kurt about the IANA section; probably derived from BCP issue
(which does not recommend a table format, even for large values).  Next step
is to talk to Jim Semmershein about follow-up, then Kurt will help review
Security section

IANA Review Comments: We understand there to be 67 LDAP Descriptor registrations for the ldap-parameters registry.  We are double-checking with an LDAP-type expert to verify what the assignments would actually be.  It is possible that the SYNTAX is the same as the number assignment.  We are confirming this.
In RFC3383, section 3.3, it says x- and e- descriptors have separate registration procedures and for all "other descriptors require Expert Review to be registered".  If we understand this correctly, there should be an expert review.  Has this been completed yet?

[Ballot discuss]
The IANA considerations section says "we would like the IANA to register on Standards Action the following:" but Standards Action means standards-track according to 2434 and this is Informational.  If the registry is actually Standards Action, then these registrations aren't allowed; if the registry allows them, then this is confusing.

There are 67 subsections in the IANA considerations section, each requesting the registration of an OID.  It seems that the only one that needs to be *assigned* is the one referred to as IANA-ASSIGNED-OID, and the rest just need to be inserted into the registry?

For myself, I can't find the registry that they're asking for assignments in so I can't compare with other LDAP assignments to see if this is normal.  Michelle probably needs to look at this more closely.

[Ballot comment]
Reviewed by Spencer Dawkins, Gen-ART

His review:

I'm way out of my depth here, but certainly don't see anything that
disqualifies this draft for Informational RFC...

[Ballot comment]
In section 2, the document says:
  :
  : The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  : "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  : document are to be interpreted as described in RFC 2119..[Novell Em1]
  :
  s/..[Novell Em1]/[RFC2119]./

[Ballot discuss]
In section 8, the document says:
  :
  : ... With UDDIv3, publishers can digitally
  : sign entries enabling registry clients to validate the integrity of
  : UDDI entries read from the UDDIv3 registry by verifying the digital
  : signature.
  :
  First, a reference seems highly desirable.  Second, how is the signer
  identified?  The client needs to know how to determine whether the
  signer is appropriate.  To make this determination, the identity of
  the signer needs to be mapped to the LDAP entry in a deterministic
  fashion.

[Ballot discuss]
I think that the Security Considerations section for a document like this should be similar to what is done for MIBs.  That is, it should identify items of particular sensitivity (for both read and write access), and should (if appropriate) recommend specific security mechanisms to counter the threats.

[Ballot comment]
Section 2: the reference to RFC 2119 is broken ("RFC 2119..[Novell Em1]").

I think section 9 could be clearer about where the IANA-assigned base OID should be coming from, but I'll let Michelle decide if that should be a discuss or not.

A comment from Chris Ridd at Isode:

They have created lots of new attributes, but most of them use
DirectoryString syntax.

A lot of these are inappropriate and/or just wrong. For example
uddiv3EntityModificationTime contains some kind of timestamp, but is a
DirectoryString and not a GeneralizedTime. (So a value of "today" would be
valid. So would other Unicode values.)

The uddiUUID attribute appears to be for holding a UUID, which is a 16-byte
long octet string and *not* a DirectoryString. There's an I-D describing
UUIDs in the directory which perhaps the authors ought to read.

LDAP directorate review, from Kurt; detailed comments sent to
authors.

General comment: I would like to see this document include more
examples.  I find it very hard to review particular uses of LDAP
syntax, matching rules, and other elements as currently written.  I
suspect I've only touched on problems here.  Hopefully my comments
offer enough food for thought for the Authors to not only address
specific issues I've raised, but address issues which are likely
lurking.