draft ldapbis meeting notes, IETF 57, Vienna

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

Draft notes below, please send me any corrections.

 - RL "Bob"

---


DRAFT ldapbis meeting notes
IETF 57, Vienna, Austria
2003-07-15
submitted by:  RL "Bob" Morgan

The co-chairs, Kurt Zeilenga and RL 'Bob' Morgan, called the meeting to
order at 14:15.

Kurt noted that the WG charter has been updated to reflect current plans,
which call for all remaining documents to go through WG Last Call in
July/August, and (assuming consensus) for revised documents to be
submitted to the IESG by September.  It is expected that the WG will not
need to meet at IETF in Minneapolis.

Jim Sermersheim spoke about the protocol document.  The "attribute
descriptor length" issue has received much discussion on the WG list, and
was discussed at length at this meeting.

Ted Hardie, the WG's Area Director, spoke for ("channeled") Chris Apple,
saying that the issue is that designers of LDAP-based applications and
schema need interoperable LDAP implementations to support them, and need
to know what limits they can design to.

Kurt responded that there are two separable issues.  One, the one that
started the email thread, is that an implementation was observed to
truncate short names; this is just a bad implementation, it may be useful
to clarify the doc to make it clear this isn't permitted.  The other is
that LDAP can be used in many contexts, so not all features are required
or appropriate for all contexts.  Applicability statements are the IETF
documents that say which features are required for particular
applications.

Rick Huber observed that the problem is a protocol interoperability
problem, hence should be addressed by the protocol spec.  John Strassner
observed that lots of schema designers are writing schema with long
attribute descriptors (names), and are depending on implementations
supporting this.  Kurt observed that other requirements like matching
rules will lead to a need for application-specific AS.

Ted said applicability statements would be fine, and suggested a "basic"
one on which variations can be based.

Leif Johansson asked if implementation-specific limits need to be
discoverable?  Ted said that would follow but isn't necessary.

Rick observed that requiring an application statement per app is a lot of
work for app developers.  Kurt said it might be feasible to define a
"general-purpose" LDAP AS, but might be hard to get consensus.

Ted said it seems byzantine to have protocol limits defined separately
from the protocol.  Kurt responded that it seems inappropriate to clutter
a general-purpose protocol spec with considerations of only one
application scenario.

It was observed that this discussion needs to move back to the mailing
list.

Jim requested that people look at the protocols and models documents
together for potential overlaps or gaps.  He also encouraged a review of
the use of MUST/SHOULD/MAY in the docs.

Kurt said that since it now appears that our documents will have to be
again at Proposed Standard level, interoperability reports can wait until
after this, when we prepare to go to Draft Standard.

Vithalprasad Gaitonde presented for Roger Harrison regarding the authmeth
document.  Draft -06 was produced.  It lists various fixes since the
previous version in its appendix.  Some issues were discussed.

Is password protection needed regardless of the use of authzid?

Is the SASL PLAIN method prohibited in LDAP?  No, just "not typically
used".

In the TLS server name check function, should the use of the CN RDN in the
Subject DN to hold the server DNS hostname be documented?  RL "Bob"
observed that other app-TLS specs have not done this, even though the
method is commonly used, because it is such a clumsy mechanism.

Must the SASL EXTERNAL operation immediately follow completion of
STARTTLS?  No, the first operation after STARTTLS should be another check
of server capabilities.  The TLS-complete-but-not-bound state may not be
in the authentication state diagram.

Use of derived DNS names OK in the TLS server name check function?  RL
"Bob" said that this would be a change from the current RFC, but is
consistent with the original intent.

It was observed that the description of DIGEST authentication in the
authmeth doc is too detailed, and may conflict with other specs, so it was
suggested to modify it to reduce this.

Kurt wrapped up the session by noting that once all documents have been
through Last Call, there will be a Last Call on the Roadmap document and
one more pass over the whole document set for consistency.

The session concluded at 15:15.