Re: IETF ldapbis WG Last Call: draft-ietf-ldapbis-user-schema-05.txt

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

I have directed the editor to prepare a revision addressing
outstanding technical issues as previously summarized with
excepted noted below.  Once published, I will ask the WG to
confirm that the changes made adequately address these issues.
Presently, I do not think another WG Last Call will be necessary
as I believe I believe we have WG (good to rough) consensus
on how to resolve outstanding issues, however I will defer
this decision until after the editor has made the changes and
the WG has had an opportunity to consider those changes.

While waiting for the editor to make these changes, I suggest we
turn our energy to reviewing the [Protocol] and [AuthMeth] I-Ds.

-- Kurt, LDAPbis co-chair

At 11:41 AM 5/26/2003, Kurt D. Zeilenga wrote:
>This message serves to summarize issues to be addressed
>before this I-D is progressed.  For each issue, I have suggested
>a course of action which I believe to be consistent with WG
>consensus.  If you don't believe the this course of action
>is appropriate, please comment within the next couple of days.
>Otherwise, the chairs will declare these issues resolved and
>direct the editor to revise the document accordingly.
>
>KurtZ raised concerns regarding the ommission of an 'uid' attribute
>type specification.  He made a proposal to add it.  No one opposed
>this proposal, implement it.
>
>MarkH raised concerns regarding suggested upper limits.
>StevenL proposed that all suggested upper limits be removed
>to avoid confusion.  No one opposed this proposal, implement it.
>
>KurtZ raised concerns regarding internationalization of textual
>user passwords.  Kurt proposed that it be recommended that applications
>prepare textural passwords by first transcoding them to Unicode,
>apply SASLprep, and then encoding them as UTF-8.  Hallvard offered
>some word smithing which was found acceptable.  No one opposed this
>proposal, implement it.
>
>NorbertK raised concerns regarding alternative names used for
>in some implementations which do not appear in the attribute
>type's formal description and suggested they be added.  Objections
>to the proposal were raised.  The proposal is rejected.
>
>KurtZ provided a laundry list of issues.  For brevity, I will
>only summarize technical issues.  There were no opposing comments
>to any of his proposals.
>
>KurtZ noted that most attribute types are discussed in single
>value terms though are declared as multiple values.  Kurt
>proposed that the editor reword each description to reflect
>their multi-valued-ness.  Clarify.
>
>KurtZ noted that the description of 'dc' is needs further
>clarification.  Clarify as noted.
>
>KurtZ noted 'destinationIndicator' specification does not
>include a statement of how the attribute type is used.  Clarify.
>
>KurtZ noted the description of 'givenName' is inconsistent
>with that provided in X.520.  Clarify.
>
>KurtZ proposed that the 'domain' object class should not have
>been added to the specification.  Remove.
>
>KurtZ raised a security consideration regarding session hijacking.
>Add consideration.

MichaelS and HallvardF noted that this was misplaced (belongs in
[Protocol] and/or [AuthMeth]).  The editor should not added
this consideration.

HallvardF noted the statement
   It is required that strong authentication be performed in order to 
   modify directory entries using LDAP.
is also misplaced (also belongs in [Protocol] and/or [AuthMeth]).
The editor should remove this statement.

MichaelS raised an issue with multi-valued userPasswords.  Kurt
suggested considerations be stated.  The editor should add
appropriate considerations.