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

From: Mark Wahl <[email-masked]>
Date: Wed, 14 Jun 2000 12:04:38 -0500

The purpose of this message is to initiate an LDAPEXT
working group last call on the "LDAP Control for a 
Duplicate Entry Representation of Search Results" Internet
Draft.

WHAT DOCUMENT?

The document in last call is:

   draft-ietf-ldapext-dupent-03.txt

WHAT IS A LAST CALL FOR?

The purpose of the working group last call is to ensure
that the working group has reached consensus on the
document, believes that all the known outstanding issues
have been addressed, and is ready to put the document
forward for proposed standard status.

During the last call, any comments on the documents are
collected and discussed on the mailing list.

HOW LONG DOES IT LAST?

The last call starts today and will last approximately two
weeks. It will end on Friday, June 30, 2000.

WHAT'S THE NEXT STEP?

After the last call completes, there are three possible
outcomes:

1) No changes are required and we request our ADs to put
forward the document to the IESG for proposed standard
status.

2) Minor changes agreed to on the list are required, and
the document is revised. We then ask our ADs to put
forward the revised document to the IESG for proposed
standard status.

3) Major issues are raised and no consensus is reached on
the list. In this case, we slink back and discuss things
until consensus is reached, at which time another working
group last call will be issued.

Assuming we achieve outcome 1) or 2), and that the ADs
agree with our assessment, the next stop for the document
is with the IESG. The IESG reads it and may approve the
documents (with or without changes), or send the document
back to the working group to have major issues addressed.

If the first outcome happens, the document is put forward
for a two-week last call to the entire IETF, and after
successful completion the document is published as RFCs
with proposed standard status.

If the second outcome happens, we go back and address
the issues, putting the document forward again when we
believe they're ready.

WHAT SHOULD I DO?

You should read the document, making sure that 1) there
are no problems or deficiencies or outstanding issues that
need to be resolved; and 2) that there are no typos,
formatting problems, grammatical errors, etc.

Any substantive problems you find, you should send to the
list. Any minor problems (typos, etc.) you may send to the
list or just to the authors. If, for some reason, you have
comments you don't want to send to the entire list, you may
send them to me.

Read, enjoy, and send your comments in!

Mark Wahl, Directory Architect, Service Provider/Infrastructure
Sun Microsystems, Inc. iPlanet Alliance

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 14 Jun 2000 11:14:31 -0700

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 14 Jun 2000 11:44:34 -0700

Additionally, I believe it might be generally useful for
clients to be able to distinguished duplicated entries
from non-duplicated entries returned by a search with
this control.  I suggest that a control be returned
in each LDAPMessage which contains a duplicated entry.

In particular, this would be useful where the server was
able to return duplicate entries for a subset of the
requested entries and the control was marked non-critical.

For example, user requests duplicate entries for the
attribute description "givenName,sn".  The server
has disallows duplicating entries where multiple
listed attributed contain multiple values.  That is,
it will generate duplicates for a given entry
if only givenName has duplicates and only if sn
has duplicates, but not if both givenName and sn
have duplicates.  This would be avoid generating
NxM entries for the N values of givenname and
the M values of sn.

There are likely other cases where the control was
provided only to a subset of the entries returned.

Oh, and another implementation note, servers which
chain requests should avoid passing this control to
other servers by splitting chained results itself.