2.1.6 LDAP (v3) Revision (ldapbis)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional LDAPBIS Web Page

Last Modified: 2004-09-22

Chair(s):

Kurt Zeilenga <kurt@openLDAP.org>
RL Bob Morgan <rlmorgan@washington.edu>

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

Applications Area Advisor:

Ted Hardie <hardie@qualcomm.com>

Mailing Lists:

General Discussion: ietf-ldapbis@openldap.org
To Subscribe: ietf-ldapbis-request@openldap.org
In Body: (un)subscribe
Archive: http://www.openldap.org/lists/ietf-ldapbis/

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 RFCs
2251-2256, 2829-2831.

The group will deliver a document detailing IANA considerations
for LDAP suitable for consideration as a Best Current Practice.

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:
- "LDAPv4"

- All LDAP Extensions (LDAPext) excepting StartTLS.

- LDAP Replication (LDUP)- LDAP non-"core" Schema

- Connection-less LDAP (LDAPext)

Goals and Milestones:

Done  Submit LDAP Applicability Statement I-D
Done  Submit LDAP Overview / Data Model I-D
Done  Submit LDAP Protocol I-D
Done  Submit LDAP Attribute Syntaxes I-D
Done  Submit LDAP DN I-D
Done  Submit LDAP Filter I-D
Done  Submit LDAP URL I-D
Done  Submit LDAP User Schema I-D
Done  Submit LDAP Authentication Methods I-D
Done  Submit LDAP Start TLS I-D
Done  Submit LDAP Applicability Statement I-D to the IESG for consideration as Proposed Standard
Done  Submit IANA Considerations for LDAP I-D to IESG for consideration as BCP
Sep 03  Deliver revised LDAP
Sep 03  Deliver revised BCP 64 I-D to IESG for consideration to the IESG as a BCP
Oct 03  ubmit Interoperability Report I-D
Apr 04  Deliver Interoperability Report to IESG with recommendation that revised LDAP

Internet-Drafts:

  • draft-ietf-ldapbis-dn-15.txt
  • draft-ietf-ldapbis-protocol-27.txt
  • draft-ietf-ldapbis-filter-08.txt
  • draft-ietf-ldapbis-authmeth-13.txt
  • draft-ietf-ldapbis-url-07.txt
  • draft-ietf-ldapbis-user-schema-08.txt
  • draft-ietf-ldapbis-syntaxes-09.txt
  • draft-ietf-ldapbis-roadmap-06.txt
  • draft-ietf-ldapbis-models-12.txt
  • draft-ietf-ldapbis-strprep-04.txt
  • draft-ietf-ldapbis-bcp64-04.txt

    Request For Comments:

    RFCStatusTitle
    RFC3377 PS Lightweight Directory Access Protocol (v3):Technical Specification
    RFC3383 BCP Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)

    Current Meeting Report

    LDAP Revision WG (LDAPBIS)

    TUESDAY, November 9 at 1300-1400
    ================================

    CHAIRS:
    RL "Bob" Morgan <rlmorgan@washington.edu>
    Kurt Zeilenga <kurt@OpenLDAP.org>

    Minutes:

    These minutes were compiled by Kurt from Jabber session notes taken by Ludo.

    The chair called the meeting to order shortly after 1300.

    The chair provided a WG status summary.

    Multiple WG documents have or soon will be progressed to the IESG for consideration, including draft-ietf-ldapbis-models, -dn, -url, and -filter. The latter two require minor revision before progression, to be done immediately after the meeting.

    There is one known outstanding issue with -syntax, uniqueMemberMatch. As this rule is owned by the ITU-T, guidance (or at least, "no objection") is desirable. As ITU-T has not responded to informal requests, will try formal channels. Chairs note that the Editor has been asked to proposal a technical solution to this problem. This solution will be presented to the WG and ITU-T consideration.

    There are no known issues with -user-schema. Will likely be progressed to the IESG soon.

    There are a number of issues requiring further work with
    -protocol and -authmeth.

    There are no issues with -roadmap, but it will be LC'ed last.

    The chairs indicated their intent to drive WG to deliver on existing charter items quickly. There appeared to be generally support this could be done, and should be done.

    Roger presented a summary of changes (since last meeting) to the authmeth I-D (see presentation). There are five open issues.
    1) TLS mail thread
    2) TLS vs External mail thread
    3) Rework for new terminology
    4) Return explicit result code for Bind with no name or password
    5) Rename unauthenticated mechanism
    Regarding the issue 4, Jim noted that issue had already been discussed and we should leave the semantics undefined. The WG appears to support this approach.
    Regarding the issue 5, Kurt noted that aside from there being no good alternative and that renaming was technically unnecessary. Issue 3 was discussed separately (see below). The other issues were not discussed in any depth. Roger estimated he would need 2-3 weeks to produce the next revision, but needed feedback on the current release. Chair suggested waiting for consensus on terminology to producing next revision. Chair noted intent to proceed with WGLC after giving WG two weeks to consider next revision.

    Kurt presented a terminology proposal (see mailing list archives) for the LDAP session and layers within that session. The basic proposal included definitions for "LDAP session", "LDAP stream" (replacing "LDAP Exchange"), "SASL layer", "TLS layer" and "connection". Roger noted that the proposal would allow the term "LDAP association" to be dropped from authmeth I-D. Ted noted that, unless explicitly defined, "LDAP stream" might be viewed oddly by some. Jim suggested replacing "LDAP stream" with "LDAP PDU layer" or "LDAP message layer". The WG appeared to favor the latter. The modified proposal appeared to be supported by consensus. Will be taken to list for further discussion and consideration.

    Jim presented a summary of changes (since last meeting) to the protocol I-D (see presentation). Remaining issues include:
    - Extensibility of ASN1: defer to extensibility mechanisms defined in ASN1. (don't want to add own semantic).
    - Update with recommended connection terminology
    - Removing some imperatives: referral following (removing MUSTs instructing clients how to consume fields)
    - Commonize adherence to data model text.
    - Result code for invalidated association. Need text to suggest Notice of Disconnection ? Need to prescribe specific error ?
    - Undo some changes to strongAuthRequired in regards to Notice of Disconnection.
    While the WG rehashed some of the list discussions, the general sediment as to how these issues should be resolved appears consistent with that on the list. The Editor is to prepare a revision addressing these issues and that revision will likely be then be progressed to the IESG.

    The chairs briefly went over next steps. They are: protocol progressed by end of November, authmeth WGLC in December, then Roadmap in January.

    There were no open mic discussions.

    The session was concluded shortly before 1400.

    Slides

    Authmeth Outstanding Issues
    LDAP: The Protocol