NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 01-Dec-00
Kurt Zeilenga <kurt@openLDAP.org>
RL Morgan <email@example.com>
Applications Area Director(s):
Ned Freed <firstname.lastname@example.org>
Patrik Faltstrom <email@example.com>
Applications Area Advisor:
Patrik Faltstrom <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: (un)subscribe
Description of Working Group:
The LDAPv3 "core" specification is RFC 2251-2256 and 2829-2831. The purpose of this working group is to shepherd these RFCs through the Internet Standard process.
The group will deliver revised LDAPv3 specifications suitable for consideration as a Draft Standard. This work will be based upon RFC 2251-2256,2829-2831.
The group will deliver an applicability statement defining LDAPv3. This work will be based upon draft-hodges-ldapv3-as-00.txt.
The following areas are out of scope:
- All LDAP Extensions (LDAPext) excepting StartTLS.
- LDAP Replication (LDUP)
- LDAP non-"core" Schema
- Connection-less LDAP (LDAPext)
Goals and Milestones:
Submit LDAP Applicability Statement I-D
Submit LDAP Revised Specification I-Ds
Submit LDAP Applicability Statement I-D to the IESG for consideration as Proposed Standard
Submit Implementation Report as I-D
Submit LDAP Revised Specification I-Ds and Implementation Report to the IESG for consideration as Draft Standard
No Current Internet-Drafts
No Request For Comments
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.
RFC 2256 Revision