ldapbis WG minutes from IETF 51

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

Find below the draft meeting minutes from the ldapbis WG meeting at IETF
51 in London.

As usual (my apologies again) these were completed only at the submission
deadline for the IETF proceedings, so the version below is the version
that will be in the proceedings.  However, please review and provide me
with any corrections; if there are any I'll issue a revised version to the
WG list.

 - RL "Bob"

---


DRAFT ldapbis meeting minutes
51st IETF, London, August 9, 2001
Kurt Zeilenga and RL "Bob" Morgan, co-chairs
RL "Bob" Morgan and Roger Harrison, minutes-takers


Kurt called the meeting to order at 9AM.  Following agenda-bashing,
the first item was document status.

 * The LDAPv3 Technical Specification,
     draft-ietf-ldapbis-ldapv3-ts-00.txt
   is awaiting progress from the Area Directors.

 * The DN, Filter, and URL documents,
     draft-ietf-ldapbis-dn-06.txt
     draft-ietf-ldapbis-filter-01.txt
     draft-ietf-ldapbis-url-01.txt
   are finished, but are awaiting implementation reports before they
   can progress further.

 * The IANA Considerations document
     draft-ietf-ldapbis-iana-03.txt
   is ready for working group last call.

 * The proposed Overview/Data-Model document has not been written, and
   does not currently have an author.  We will proceed on the
   assumption that it will not happen.

 * The four other main documents:
     draft-ietf-ldapbis-protocol-02.txt
     draft-ietf-ldapbis-user-schema-00.txt
     draft-ietf-ldapbis-syntaxes-00.txt
     draft-ietf-ldapbis-authmeth-01.txt
   are still being worked on.

Other documents on which this group has dependencies are being
tracked.  A document to advance SASL to Draft standard status has been
submitted, and a SASL WG has been proposed but not yet started.  The
TLS WG is considering a document to move TLS to Draft standard, but
this is still a few months from completion.  Question:  are we also
dependent on ABNF moving to Draft standard?  Kurt:  It is likely that
this will happen by the time we need it; we can always fall back to
RFC 822.

Jim Sermersheim talked about issues with the protocol document.  The
-02 revision includes items agreed to at the last IETF, including:

  subschemaSubentry is single-valued in the root DSE;
  criticality=TRUE not permitted on unbind, adandon requests;
  differences between "unauthenticated" and "anonymous" removed
    and the four states defined;
  removed use of ExtendedResponse as interim search result
    since there were no implementations.

About 30 other items are listed in the doc as "pending"; most are
trivial.  Jim will propose language to the list on "equally capable"
referrals.  The attribute options vs subtypes issue remains
unresolved.  An engineering team, consisting of Steven Legg, Skip Sloan,
Kathy Dally, Tim Hahn, and Jim Sermersheim will consider the issues
and make a proposal to the group within 2 months.  Jim and Roger
Harrison will work to make sure all authentication-related text is
moved into the authentication/security document.  Jim will figure out
how to incorporate the result-codes document material into the
protocol document.  The data model document will probably not happen
so this material will remain in the protocol document.  This implies
continued reliance on X.501 for defining these concepts.  Jim hopes to
have the next revision within 2 months.

Roger Harrison talked about issues with the authentication/security
document.  This has been reorganized based on inclusion of material
from RFCs 2829 and 2830, and the Bind-related material from the
protocol document.  A text version of the STARTTLS state-transition
diagram has been prepared, and will be included if possible.  It was
noted that it would be normative, so must be correct.  Roger noted
that "LDAP association" isn't well-defined in RFC 2830.  Bob Morgan
commented that it was intended to distinguish the LDAP-level
connection from the TLS-level connection; this will be clarified.  The
meaning of "secure authentication function" in RFC 2829 was also
questioned.  There was discussion on the requirement for a client to
discard/confirm server capabilities after TLS is started; do we really
expect clients to do this?  Answer:  Yes.  About 20 other issues are
listed in the current draft; comments on these are solicited on the
list.

Kathy Dally talked about issues with the the syntaxes draft.  Equality
matching rules were added to several attributes.  Kurt said this
amounts to adding new features and so should be removed.  Tim Hahn
said these rules were left out due to oversight, and that their
existence was implied, so they should be added.  Kurt pointed out that
a compliant implementation now might not implement them.  This will be
discussed more on the list.  Kathy asked whether encoding should be
specified in this document or in the protocol document.  Steven Legg
said that because the encoding of various string syntaxes in LDAP is
ad hoc, it makes more sense to do the definition of the encoding with
the syntax definition; Kathy will use this approach.  A question was
raised about documenting ";binary".  Kurt commented that this applies
generally to ASN.1, so it should go in the protocol doc; further, the
effect of ";binary" may not be what's desired, eg a cert may be sent
as BER, rather than DER, thus destroying it.  There was further
discussion on this point, leading to the observation that perhaps a
warning should be given to always use DER for security objects.  More
discussion is needed on the list.

Kathy reported that she added a requirement that servers MUST
implement syntaxes for supported attribute types.  Kurt said this may
be an issue:  should the same statement be made for matching rules?
Maqrk Wahl said that an X.500 server can support an attribute without
knowing its syntax; so this probably shouldn't be a MUST.  Regarding
syntaxes and rules that are desirable but were left out of RFC 2252,
Kurt has proposed to add them as extensions, and has written an I-D on
this topic; so they will not be in the core spec.  Steven noted that
case-ignore is a matching rule, not a syntax.  Kathy added a NAME
option to the BNF for syntax descriptions but it will be removed.

Open issues with the syntax document were discussed.  Should OID
assignments be moved to an Annex?  This could be left to IANA
considerations.  Those without interoperable implementations can be
deleted.  Helmut Volpers asked about attribute values vs. assertion
values on operations like compare, delete, etc. where the attribute
value is different from the assertion value; he will propose a
clarification to the editor.  Should the text say "subschema entry" or
"subschema auxiliary object class"?  Kurt suggests "subschema entry
(or subentry)" in each use.  Kathy thought this would need more
clarification.  The security considerations section probably needs
expansion; Kathy would like some assistance with this.  Kathy also
suggested adopting Kurt's proposal about white space.  Steven Legg
would like the [option] element removed from the BNF from objectClass
definitions so that it would be "attribute type" rather than
"attribute description".  This needs to be taken to list since at
least one implementation currently uses this for certificates.

Kathy continued with a discussion of the user schema document.
Referring only to 2nd edition of X.500, as proposed, means no
certificate matching rule, is that OK?  It is, cert schema will be in
the cert schema doc, so it should be removed from this document.
David Chadwick noted that the certificate schema is a work item in the
PKIX WG, but that PMI content will have to be separated out.  Various
other items were clarified in the document.  Various open issues were
discussed.  Should all syntaxes and rules be moved to the syntax
document?  Yes.  Kathy estimated that a new revision would be out in
two months.

Kurt discussed the IANA considerations document.  The question was put
whether this should be published now, or wait for the rest of the
ldapbis documents to finish?  The consensus was to publish now, as
there are no dependencies and any modifications can be made at the
time all the other docs are published.  So a WG last call will be
initiated soon.

Kurt led a discussion of the interoperability report.  Workers are
still needed on this.  Chris Harding of the Open Group has
volunteered, and already has test suites in place.  LDAP Plugfest data
can be used as well.  Question:  do the report preparers have to
verify the interoperability?  No, the implementors merely claim it.
Question:  does widespread reliance on original UMich code base mean
fewer "independent implementations"?  This has to be considered on a
feature-by-feature basis, but implementors should document their code
source for this reason.  We will start with filter features, then do
DN and URL.  These should start to happen in the next month or two.

Kurt led the final discussion on updating milestones in the WG
charter.  The overview/data-model item will be dropped.  STARTTLS will
be removed as a separate item.  Digest-MD5 will remain on until the
SASL WG starts up.  The data on the implementation report I-D will be
changed to December 2001, with March 2002 as the date for all final
drafts.

The meeting adjourned at 11:30 AM.