[Date Prev][Date Next]
minutes from ldapbis WG meeting at IETF 59, 2004-03-02
I sent these minutes to firstname.lastname@example.org earlier today for inclusion
in the official proceedings. They're still accepting updates, though, so
if there are any fixes to be made please let me (and/or the list) know.
- RL "Bob"
IETF ldapbis WG meeting notes
IETF 59, Seoul, South Korea
submitted by: RL "Bob" Morgan
also thanks to Alexey Melnikov for Jabber scribing
The meeting was called to order at 1545 by the chairs, Kurt Zeilenga and
RL "Bob" Morgan.
The first agenda item was WG status. Kurt noted that only two documents
are still being worked on. The protocol document
(draft-ietf-ldapbis-protocol-22.txt) is very close to being done. Its
editor, Jim Sermersheim, will submit one more revision, and a last call
will be done. The authmeth document (draft-ietf-ldapbis-authmeth-10.txt)
still needs review and revision.
Jim Sermersheim talked about items regarding the protocol document. A
number of items have had discussion on the WG list. The issue about
"attributes with no equality matching rule" should be handled by an update
to the draft-ietf-ldapbis-models document.
There was discussion about the "server-enforced control criticality" issue
raised by Hallvard Furuseth, which has seen lots of list discussion: what
does a server do if a client sends a control with its criticality flag set
differently than specified in the control's definition? Hallvard has said
(on the list) that the server should return an error. It was asked
whether this is useful in real operations or only in debugging. Hallvard
will be requested to supply a real-life use case. It was noted that if
Hallvard's suggestion is adopted some existing servers will have to change
their behavior; whereas there are no known implementations that work in
the way Hallvard is suggesting.
Jim said that another remaining change is that some text is still planned
to move from the protocol doc to the authmeth doc. A last-callable
version of -protocol- can be published as soon as the criticality issue is
Jim went on to talk about the authmeth document, for Roger Harrison who
couldn't attend. Outstanding items include: clarifying that password
considerations apply only to plaintext passwords being sent in the clear;
moving language about mandatory-to-implement features to its own section;
and removing the statement that anonymous authentication is typical when
not updating. Another item is about STARTTLS sequencing: the logical
requirement is that clients have to wait for all operations to finish
before sending STARTTLS, but some clients are known not to. The current
spec has language saying what might happen in this case, but the proposal
is to clarify the situation by saying simply that clients MUST wait.
Another clarification is proposed regarding choice of SASL mechanisms
(section 8.5). New language would say that client and server must confirm
that negotiated security level meets their requirements before proceeding
to use the connection.
Roger is working on a new version, and should publish soon. Kurt
emphasized that the document needs good review from the WG before it can
be taken to last call, so please review!
In other issues: Kurt proposes that the LDAP handling of missing equality
matching rules conform to the X.501 approach. This is a change from
current LDAPv3 spec, but appears to be what is done by known
implementations. It was asked whether the models document needs another
last call, and noted that some other already-through-last-call documents
have had minor tweaks to them. There will be an all-documents last call
before they are sent to IESG in any case.
Kurt also asked whether matching rules that are in RFC 3698 should be
added to the syntaxes document. These are in X.520, and have been in
use. JimS asked whether any of these will be mandatory to implement. In
response it was asked whether the current doc says that any syntaxes are
mandatory; this will be looked at.
Lastly milestones were discussed. The intent is to finish the protocol
document in March, the authmeth document in April, and to finish the
roadmap and final last call for all in May, and submit the package to the
IESG. Then an interop report could be prepared for 6 months following
approval of the documents as RFCs.
The meeting was adjourned at 1635.