draft ldapbis meeting minutes, IETF 49 San Diego

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

Below are draft meeting minutes for the meeting in San Diego last month.
I humbly apologize for the delay in getting these out.  Unfortunately the
deadline for getting these to the IETF secretariat for publishing in the
official proceedings is imminent, so the notes below are the ones that
will be published.  Please do submit any corrections to me or to the list,
and I'll get any needed revisions out to the list.

 - RL "Bob"

---


DRAFT ldapbis WG meeting notes
San Diego, December 11 2000
Kurt Zeilenga and RL "Bob" Morgan, co-chairs

Kurt opened the meeting and noted that this was the first meeting of
ldapbis as a Working Group.  The WG charter has been approved by the
IESG and is available on the IETF web site,
http://www.ietf.org/html.charters/ldapbis-charter.html.

Kurt proposed an engineering approach to revising the documents.
Smaller documents will be revised as needed and advanced to last call
as soon as possible.  These are: DN representation (2253), filter
representation (2254), URL format (2255).  The other documents consist
of larger issues which may need to be recombined into new documents.
The proposed groupings of issues are: (1) Data Model and Protocol
Model, and (2) Schema.  Two engineering teams will be put together,
one for each area, to consider how to reorganize the existing RFCs to
make the information more readable, organized, etc.  The teams are to
report their proposals to the WG as a whole.

Teams are based on authors of strawman revised RFCs.  Data/Protocol:
Mark Wahl, Mark Smith, Roger Harrison, Jim Sermersheim, Jeff Hodges.
Schema: Kathy Dally, Mark Hinckley.

Kurt asked for feedback on this approach.

Keith Richardson asked: will some of the drafts be heavily revised and
require passing through proposed standard again?

Kurt replied: It might become necessary, but we don't know if it will
be now.  All we know now is that we want to go to draft standard and
if we can, we will.  If the accumulation of changes is sufficient to
require "recycling" docs, then we will do so.  The charter of our WG
is to get to draft standard, and we don't want to take
changes/enhancements to protocol that will stop us from our charter.

Kurt noted that an implementation report is required for the protocol
to advance to Draft Standard.  A lot of surveying will be required for
an appropriate implementation report due to the size of LDAP.  A
volunteer is needed to do the implementation report and to help keep
track of the information/issues that go into it.  Contact the chairs if
you would like to volunteer.

Jeff Hodges spoke about draft-hodges-ldapbis-ldapv3-ts-00.txt.
Feedback was received from Patrick Faltstrom and from Kurt Zeilenga.
He expects to ship a new version in the next 1-2 weeks and it needs to
go to proposed standard before we can rework the entire batch of
documents.  This version will be available to the WG for comment for a
couple of weeks, then (pending comment) go to WG last call.  There was
discussion clarifying the role of the doc: to list all the documents
comprising "LDAPv3" and remove the IESG note about update security.

Kurt noted that 2831 is not part of LDAPv3 but it needs to go to draft
standard.  The tech-spec document will not include it.  Because
there's no explicit owner, we're doing it in this WG for now.  We'll
look for a different/better owner in the future.

Q: Will the tech-spec document live beyond this review period?  Will
it get updated as the core I-Ds evolve?  Kurt: It will get updated
with the other documents.  The Technical Specification will need to
change.  Jeff: It could stay a separate document or get merged into a
bigger document.

The strawman revisions of 2251-56 and 2829-31 were then reviewed.

Jim Sermersheim spoke on draft-sermersheim-ldapbis-rfc2251-00.txt.
Appendix B lists all changes from 2251.  A concern was expressed about
some claimed instances of changing MAY to MUST as breaking
interoperability and conformance.  Mark Wahl noted that the only
reason to make this kind of change is if it is required to ensure
interoperability.  Kurt noted this must be done with special care.
Jim said exhaustive review of MAYs and MUSTs remains to be done.  Mark
and Kurt requested that changes be proposed before being made, and
that an explanation be given for each change.  Jim noted that To-Do
items are listed in Appendix C.  The main items for this doc are: to
split the protocol from the data model, and to integrate the results
code draft (draft-just-ldapv3-rescodes-02.txt, now expired) into it.
Jim said that for contentious issues, he would try to reach consensus
2 or 3 at a time, but that he is counting on feedback.

Mark Hinckley spoke on draft-hinckley-ldapv3-attr-syntax-00.txt, a
revision of 2252.  He has received comments on the BNF.  He added a
section 10 on issues that need to be addressed.  He noted that the
syntax description table does not describe all 56 syntaxes.  Mark Wahl
commented that we will drop the ones that have no interoperable
implementations.  Ryan Moats commented that we must explicitly
document all remaining syntaxes.  Kurt noted:, the doc now says "We
act in accordance with X.500;" one approach is to cite specific
locations for definition in X.500 as a normative reference.  Ryan
said:  From an implementation point of view, the ABNF needs to be in
one place for each major set of stuff: syntaxes, matching rules, etc.
Kurt noted that making clarifying changes to X.500 is not in scope for
this work.  Mark noted that we need to expend matching rules to be
complete.

Mark Wahl spoke on data definitions (draft-wahl-ldapv3-defns-00.txt).
In the LDAP data model, some elements of X.500 are left out, and some
new elements are added.  LDAP also uses some terms differently.  An
LDAP attribute's BER encoding is different from X.500.  Definitions
and cross-reference of all terms is needed, which is the intent of
this document.  The intent is to clarify the existing data model.
Mark will reissue the document with a smaller number of terms.  Mark
thinks it is a candidate for being a "core" document in the revised
LDAP set, but if not he will pursue it as an individual submission.

Kurt spoke on revisions to RFC 2253.  The reference to "a published
table of attribute types" whose name strings are used must be
clarified.  Kurt asked what we can do to make sure that all
implementations recognize a common set of short names for attribute
types (e.g. cn for commonName).  Ryan noted that this raises the
thorny question of a name registry.  Kurt noted that there is an IANA
registry of type names but this approach is not clear going forward.
Section 4 on relationship with RFC 1779 and LDAPv2 also has created
confusion, but whether it goes away completely with the removal of
references to v2 is unclear.  This issue will be discussed on the list.

Kurt spoke on revisions to RFC 2254.  Mark Smith is reported to have
said that no changes are needed.  No one present had any issues with
it.

Regarding RFC 2295, Kurt mentioned that a "*" should be added to the
BNF (it was inadvertently left out).  No other changes are known or
were suggested.

Kathy Dally spoke on draft-dally-ldapbis-rfc2256-00.txt.  Some
elements need more description.  References to RFC 1778 must be
removed.  She suggested that schema be split into: elements necessary
for the directory to operate; and "user" schema.  Kathy noted that
some elements (teletexTerminalNumber) have been declared obsolete by
revisions of X.500.  It was noted that this raises the question of
whether so marking an attribute is acceptable in LDAP, and which
revision of X.500 LDAP is (and should) be based on.  There was
discussion of the IESG security note and whether there were implied
security issues with 2256 (probably not).  Mark Wahl noted that the
Quipu reference was an acknowledgement that perhaps should remain.
Kurt noted that we need an explicit acknowledgement policy for ldapbis
work.

Roger Harrison spoke on draft-rharrison-ldapbis-rfc2829-00.txt.  He
suggested that restatements of protocol features from other documents
be removed.  He suggested that the language about the use of simple
password authentication is not clear, and discussion confirmed this.
He suggested that the use of security terminology be made consistent
with RFC 2828 ("Internet Security Glossary").  He agreed to add a
change log to future revisions.

Jeff Hodges spoke on revisions to RFC 2830.  There are no glaring
issues.  Kurt noted that there is now some operational experience and
some cases (eg TLS alerts) need clarification.

Kurt noted that ldapbis is trying to move RFC 2831 (SASL DIGEST-MD5)
forward to Draft Standard in the absence of some other venue for
this.  We may need to appeal to the Security Area for help.

Mark Wahl suggested some additional tasks.  Protocol encoding examples
should be produced, hopefully comprehensive.  We need to establish a
clear definition and set of tests for determining whether
interoperability of a feature exists.  One question is testing vs
revising:  on which document is the testing and implementation report
based?  Mark noted that any protocol changes need to be based on
documented interoperability problems, hence testing must proceed
soon.

Kurt led discussion of other issues.  It was noted that a summary of
major changes to the set of documents would be useful to have.  We
must clarify which revision of X.500 is being used; with the goal of
using the same revision throughout.  It was noted that version 2 of
X.500 ("1993") is now out of copyright and is freely available.
Documents will not be published as "draft-ietf-ldapbis-..." until
engineering teams report back on revised structure.

The meeting adjourned on time.