Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names
RFC 4514

[Ballot discuss]
[I note this ldapbis set depends on completion on  protocol and iana documents,
and I've reviewed those drafts to understand these].

comment for future - protocol document needs a specific section on how
access control is done and to what extent it must be implemented.

Discuss on ldapbis-dn - please expand the privacy guidance; Suggestion. 
OLD (in its entirety):
  Most countries have privacy laws regarding the publication of
  information about people.
NEW:
  A number of attributes of DNs contain information which may
  be viewed as sensitive (e.g. location information and phone numbers),
  and in many countries may also be subject to privacy law.
  The use of access control of disclosure and other security measures
  SHOULD be considered, as described in the security considerations
  in draft-ietf-ldapbis-proto-xx.

[Ballot comment]
Reviewed by Scott Brim, Gen-ART

His review:

This draft might be ready for Proposed Standard but I have a couple
discussion questions.  I definitely suggest bringing up the first one.

(1) It says

  1.2. Relationship to X.501

    This document includes material, with and without adaptation, from
    [X.501].  The material in this document takes precedence over that
    in [X.501].

Has ITU-T been informed? :-p  That is, under what conditions or in what
contexts does this override X.501, and what does ITU-T have to say about
that?  I have trouble believing the statement is accurate as it stands.


(2) Statements like:

  Servers SHALL restrict modifications of this attribute to prevent
  superclasses of remaining 'objectClass' values from being deleted.

might be better down in Section 5.1 (server-specific data requirements)
or 7.1 (server (implementation) guidelines).  Where they occur I suggest
changing them so they look a lot less procedural -- this draft is about
informational models after all -- for example "this attribute cannot be
changed except administratively".

[Ballot discuss]
Minor terminology/political issue, identified by Scott Brim:

The document says:

  1.2. Relationship to X.501

    This document includes material, with and without adaptation, from
    [X.501].  The material in this document takes precedence over that
    in [X.501].

I think this can be read as "we are changing X.501", which we of course are not.

Suggested alternate text:

    This document describes LDAP, which is a protocol that is somewhat like
    the X.500 protocol described in X.501. To describe this protocol, it uses
    material from [X.501], but when this document and [X.501] differ, it is
    this document that describes LDAP.

[Ballot discuss]
Section 2 of draft-ietf-ldapbis-dn says:
  >
  > If the AttributeType is defined to have a short name and that short
  > name is known to be registered [REGISTRY][BCP64bis] as identifying
  > the AttributeType, that short name, a , is used.
  >
  I do not have a problem with this approach, but there needs
  to be an IANA consideration associated with this registry.  That
  seems to be in section A.4 of draft-ietf-ldapbis-bcp64-04.txt, but
  that document is still being worked on by the working group.

  Section 3 of draft-ietf-ldapbis-dn says:
  >
  > Implementations MAY recognize other DN string representations
  > (such as that described in RFC 1779).
  >
  All of the X.500 attribute types listed in the table of RFC 1779
  MUST be supported in this document.  This reference adds confusion.

[Ballot comment]
Please add "This document obsoletes RFC 2253." to the end of the
  Abstract of draft-ietf-ldapbis-dn.

  Please add "This document obsoletes RFC 2254." to the end of the
  Abstract of draft-ietf-ldapbis-filter.  Also, the reference should
  be removed from the Abstract.  The last sentence might read:
  >
  > This document defines a human-readable string representation of
  > LDAP search filters that is appropriate for use in LDAP URLs and
  > other applications.
  >
  This wording avoids the need to wait for [LDAPURL] to be assigned
  an RFC number.

  Please add "This document obsoletes RFC 2251, RFC 2252, and
  RFC 2256." to the end of the Abstract of draft-ietf-ldapbis-models.

[Ballot discuss]
Section 2 of draft-ietf-ldapbis-dn says:
  >
  > If the AttributeType is defined to have a short name and that short
  > name is known to be registered [REGISTRY][BCP64bis] as identifying
  > the AttributeType, that short name, a , is used.
  >
  I do not have a problem with this approach, but an IANA there needs
  to be an IANA consideration associated with this registry.  That
  seems to be in section A.4 of draft-ietf-ldapbis-bcp64-04.txt, but
  that document is still being worked on by the working group.

  Section 3 of draft-ietf-ldapbis-dn says:
  >
  > Implementations MAY recognize other DN string representations
  > (such as that described in RFC 1779).
  >
  All of the X.500 attribute types listed in the table of RFC 1779
  MUST be supported in this document.  This reference adds confusion.