Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes
draft-zeilenga-ldap-opattrs-05

Thomas:

Note: this note contains question/issues on both of two documents:

  o Feature Discovery in LDAP (Proposed)

  o LDAPv3: All Operational Attributes (Proposed)


In:
  o Feature Discovery in LDAP (Proposed)



would be nice if document gave examples of the kind of features that
would be discoverable using the technique described in this
document. Is this really needed or a good thing? I.e., it smells to me
(not that I know much about LDAP) as a way of discoverying/advertising
support for extremely fine-grained features. Is this good for
interoperability?

Is there a registry for these features? If not, isn't this bad for
interoperability? I.e, how do I know which features I'm looking for?
Or, is this in fact just for vendor-specific things where the client
knows what its asking for and the (same vendor) server knows the same,
and neither cares about stuff supported by other vendors?

  o LDAPv3: All Operational Attributes (Proposed)


  Servers supporting this feature SHOULD publish the Object Identifier
  1.3.6.1.4.1.4203.1.5.1 as a value of supportedFeatures [FEATURES]
  attribute in the root DSE.

Same general question as above. Where is this OID registered? I gather
it doesn't need to be. I.e, the OID is just being used as a
globally-unique identifier. That's OK, for those cases where a
document says "this OID means XXX" (as in this specific case). Seems
less good if arbitrary features can be assigned OIDs and there is no
way to figure out what OID corresponds to what feature.

4.  Security Considerations

  This document provides a mechanism which clients may use to discover
  operational attributes.

Pretty content free.

  Those relying on security by obscurity SHOULD
  implement appropriate access controls to restricts access to
  operational attributes per local policy.

Is this all that needs to be said here?

Editorial nits follow.

  The Lightweight Directory Access Protocol (LDAP) supports a mechanism
  for requesting the return of all user attributes but does not all
  operational attributes.  This document describes an LDAP extension

sentence doesn't parse.

  attributes.  The mechanism is designed for use with existing general
  purpose LDAP clients (including web browsers which support LDAP URLs)
  and existing LDAP API.

s/and/and the/ ? 
 
  controls or other restrictions.  Clients implementors should also note

s/Clients/Client/

  operational attributes using existing LDAP clients.  In particular,
  the mechanism is designed to be compatible with existing general
  purpose LDAP clients includes web browsers which support LDAP URLs
  [RFC2255].

doesn't parse

State Changes to Discuss fix received                              from New Version Needed (WG/Author)                    by paf