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

["Jim Sermersheim" <JIMSE@novell.com>]

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 6/14/00 12:14:53 PM >>>

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

If an attribute is specified, only that attribute is considered for returning duplicate entries, subtypes of that attribute are not considered. I'll add text to make this clear.

>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.

hmm. The Server Side Sorting control doesn't go into this level of detail either. What happens with that control in this case? I agree that it doesn't make sense in the Duplicate Entries draft. Though I don't think we need to go to these depths of detail, I'll add something along these lines nonetheless.

>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.

Thanks, in reviewing I also found a few should's that should be MUSTs.

>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).

Yes, I'll add.

>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.

I agree. I lifted this verbatim from the Server Side Sorting draft which still has this wording. I'll fix for the dupent draft.

>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.  

Again, I lifted the way I did this from the sorting draft. What's nice about this list is that it gives more specific meanings to the errors listed. I will do something to make it allowable to send any LDAP result code (tho some make absolutely no sense), and simply list the ones that have specific meanings in the draft.

>Also wherever a resultCode is returned,
>optional human readable text should be provided as well.

Fine, I'll add that capability.

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

Thanks.

>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).

yes

>   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.

I don't think it's inappropriate, especially where it's optional. Again I lifted this from the SSS control. I wonder why these complaints weren't lodged against it as well? If you feel strongly, I'll remove it and state that the server MAY include this information in the errorMessage (which I will also add as I stated above).

>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).

sigh. Fine.

Jim