DRAFT IETF 50 ldapbis meeting minutes

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

Below are draft meeting minutes for the ldapbis WG session at IETF 50 in
Minneapolis last month.  Once again I've waited until the last minute, so
the minutes below will likely be those that go into the official IETF
archives, unless you get changes to me immediately.  Please do look them
over in any case and submit corrections to me, and if needed I'll
republish them to the list.

 - RL "Bob"

---


DRAFT ldapbis meeting notes
50th IETF, Minneapolis, March 21, 2001
Kurt Zeilenga and RL "Bob" Morgan, co-chairs


Kurt called the meeting to order at 9 AM, then reviewed the status of
the work.

 * Six documents have been submitted for review.
 * One (attribute syntax) will have a change of editor.
 * The security documents will be reorganized.
 * The implementation report needs a fresh start.
 * The Digest-MD5 document should be handled by a new SASL working
   group which is starting up.
 * draft-ietf-ldapbis-ldapv3-ts-00.txt is in IETF Last Call.

Kurt noted that overall, good progress has been made but we need to
keep up the pace.

Q:  Are there known issues with Digest-MD5?
Kurt:  Some have been raised regarding security layers.  The document
should be able to move to Draft Standard.

Jim Sermersheim led a discussion of outstanding issues with the
Protocol document.

Section 4.1.11 on Referral says that "All the URLs MUST be equally
capable of being used to progress the operation".  What does the
server have to ensure that all URLs are "equally capable"?  Must the
server check to make sure all referred to servers are up, accessible,
etc?  Mark Wahl proposed a definition of "equally capable": if a
client picks one of the referrals at random, the client would receive
the same information as if it picked any other of the referrals.
Several people noted that "equally" implied more knowledge at the
server than is necessary, so simply "capable" might be better
wording.  "Capable" in the data-model sense means "has the necessary
data".  Kurt asked whether this is necessary for interoperability;
perhaps the text should be about how to choose good referrals.  This
issue will be taken to the list.

Section 4.1.2 says that when a server doesn't recognize a critical
control, it "MUST ... return the resultCode
unavailableCriticalExtension".  But the unbind and abandon operations
don't have responses.  Should these operations not be performed?  Can
these operations have critical controls?  Kurt proposed that the doc
clarify what servers should do:  ignore the abandon operation, but
perform the unbind.  Mark Smith said the doc should note that
well-behaved clients SHOULD NOT use critical controls on these
operations; many agreed.

The current language in section 4.5.1 regarding use of "subordinates"
with "derefInSearching" is consistent with X.511 but may be
confusing.  The name should be "derefSubordinatesInSearching" to be
precise.  It was agreed that clarification is needed.  It may be
appropriate to submit a defect report to X.500.

The terms "anonymous" and "unauthenticated" are apparently used as
synonyms; is there a distinction between them?  The issue appears to
be about interpretation of the simple bind when either the name or
password field is empty.  It was noted that use of name without
password is common so this should be supported.  There was dispute
about whether such a connection is "anonymous" or not.  Bob Morgan
noted that this has to be considered in the context of the access
control factors discussion in 2829.  A four-entry table was presented.
There was agreement that the doc should use one term, not two, and
that terms should probably be "anonymous".  The information from the
four-position table should be included.

Section 4.1.5 deals with attribute options and subtypes.  There is a
need for clarification of these concepts.  Are some options, like
";binary", not subtypes?  After much discussion there appeared to be
consensus that there are two types of options, subtypes and
non-subtypes.  Skip Slone noted that the X.500 "contexts" concept
probably applies here.  Do multiple options form a subtype hierarchy?
For example, is cn;a;b subservient to both cn;a, cn;b, and cn or is it
just subservient to cn?  Kurt claimed that language tags depend on the
former interpretation.  It was suggested that language tags might have
to change to avoid this.  An engineering team was to be convened to
consider the issues in more detail.  This issue might be substantive
enough to recycle the specification as a Proposed Standard, but we
don't know yet.

Language in section 3.4 on subschemaSubentry should be reworded to
indicate that it is a single-valued attribute pointing to the schema
entry for the Root DSE.  There was discussion of the poor state of
schema discovery in today's clients.  Ed Reed noted that LDUP has a
concrete requirement for schema discovery prior to replication; but
that subschema administration needs to be done some other way.  Mark
Wahl proposed removing subschemaSubentry from the RootDSE text in the
protocol document and leave this problem to future work (eg the
proposed ELSE WG) on schema evolution and administration.

Roger Harrison discussed work on the security documents.  He proposed
to combine material from RFC 2829 and 2830 with the bind-related text
from the protocol document into a comprehensive security document.
There was agreement on this approach.  There was discussion of
"tutorial" material from 2829 and whether it was better in the main
text of the document or an appendix; opinions varied.  Jeff Hodges
suggested including the security state-transition diagram (in text
form) that was developed alongside 2830.  Roger also suggested adding
boilerplate text to the beginning of each ldapbis document tying the
set of documents together.

Kurt discussed issues with the DN document.  One issue is defining
when name strings and when OIDs can be used as AttributeType, in
section 2.3.  Kurt proposed a "liberal in what you accept,
conservative in what you send" principle; this would imply limiting
use of name strings to those types listed in that document.  Mark
Smith noted that some servers just store what's given to them; how can
they be "conservative"?  Kathy Dally suggested that deployers should
be free to use name strings if they agree to do so.  Following other
discussion, it was suggested that another engineering team be convened
for this issue.

In another DN issue, Kurt proposed removing all syntaxes that not
specified in the attribute syntax document.  Kathy argued that this is
a profile of X.500 syntaxes and they should be defined so people can
base new syntaxes on them, and that we should be able to clarify
without adding new material to the standard.  Mark Wahl noted that one
syntax was an error and should be removed; others should have been
documented in another LDAP RFC that never happened; he suggested
removing them.  Harald Alvestrand noted that DHCP had similar issues
about a standard referring to non-standard items; he recommended
removing them also.

Mark Smith led discussion of issues with the filter and URL documents.
The filter ABNF needs updating to use AssertionValue instead of
LDAPString for SubstringFilter, conforming to the protocol change.
Following this it should be ready for Last Call.  It was noted that
documents can proceed through WG and IETF Last Call prior to adding
boilerplate text that will happen when all docs are finished.  ABNF
cleanups were also done for the URL document.  Mark proposed, and
there was consensus, that extensions dealing with TLS or SASL or
userinfo@host:port or various search parameters were out of scope
since they would be new work.  This document also appears to be ready
for Last Call following a little cleanup.

Kurt noted that the Implementation Report still must be done.
Document authors are encouraged to scan their documents for features
for which no implementations exist, for likely removal.

Q:  What happened to the glossary/dictionary document?
Mark Wahl:  It timed out; this material will be included in data model
document.

The meeting adjourned at 11:30.