Re: WG Last Call: draft-ietf-ldapext-ldapv3-dupent-03.txt

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Some comments...

How does this control behave in the face of subtypes of the
provided AttributeDescriptions?

It should be an error to specify "cn;binary,cn".  I don't
think ";binary" actually makes sense in this context as
this mechanism does not specify how the attribute is to
be transferred (this should be clearly stated).  I would
recommend stating that clients SHOULD NOT specify options
which indicate transfer encoding.

RFC 2019 edits.  There are a number of lowercase should, must,
may's in the document.  I suggest that the author review each
of these and, where appropriate, use the uppercase varient.

The document is missing a "Security Considerations" section.
This must be included.  In particular, I would suggest detailing
DoS attacks using this control... just imagine specifying all
the schema related attributes on a subschema subentry search...
(this is hinted at in section 7).

4.1:
   An AttributeDescription should only occur once in the list.  If an
   AttributeDescription is included in the DuplicateEntryRequest
   multiple times, the server should return an unwillingToPerform error
   in the DuplicateEntryResponse.

I believe that unwillingToPerform should not be used to indicate
this error.  I suggest protocolError.

4.2:
DuplicateEntryResponse ::= SEQUENCE {
          result   ENUMERATED { ... }

Is this list of possible result codes a restriction?  If so,
is a MUST, SHOULD, or MAY?  I suggest other codes be allowed
as appropriate.  Also wherever a resultCode is returned,
optional human readable text should be provided as well.

   operations error    (1),  -- server internal failure
             ^ typo

Also, note my past and future comments regarding operationsError
v. other.  I believe other is more appropriate for internal
failures and operationsError is more appropriate for request
sequencing errors.  This, of course, is an rfc2251bis/errcodes
issue (which we should address separately).

   attributeType   AttributeDescription OPTIONAL

I believe it inappropriate for this control to return this
information.  This feature should be part of a more general
disclose error information control.

Examples:

I suggest using a base DN and domains reserved for examples,
such as "dc=example,dc=net" and example.com.  I would also
avoid using trademarked names in the examples (though I
do chuckle at Elmer's e-mail address).