IETF LDAPEXT Working Group
March 17, 1999
Minutes recorded by Mark Wahl <M.Wahl@innosoft.com>.
1. Summary of completed documents and charter items (Mark Wahl)
HTTP Digest is moving to Proposed Standard. There have been some changes to
DIGEST-MD5 based on late-last-call comments from members of the working group,
so an updated draft will be sent out that resolves them.
The C API will be reissued before another Last Call. There are currently two
proposals for a Java API for LDAP. The authors are meeting later in the week
with a goal for producing a single document.
The referral document is being split into two. The 'named reference' portion
should be available within about a week, the 'mesh interconnection' will be
available later.
There was concensus that the signed operations document should go to
Experimental.
Mark Wahl will be getting comments on the merger of the persistent and
triggered search documents, and there should be a combined document within a
month.
The Virtual List view and Server-side sorting drafts will be going to Proposed
Standard.
2. Charter review discussion
The Working Group has made progress on quite a few of the items on its charter.
Mandatory-to-implement authentication method is done. Access control and
referrals are in progress. There is a presentation on drafts written
concerning server discovery later in the meeting.
2.1 Connectionless LDAP
No drafts have yet been written updating RFC 1798. There is some
interest in working on this, in particular adding support for referrals.
(Note that while CLDAP is not intended as a replacement for DNS, it could be
used in future resource discovery protocols being discussed elsewhere in the
IETF.)
Mark Wahl, Pat Connely and Roland Hedberg are interested in working on this
and should have a draft by the next IETF, so there is concensus that it should
be kept on the charter.
2.2 Families of Entries
The X.500 committee is working on a proposal for families of entries, and
David Chadwick gave an overview of its approaches at the last IETF meeting.
There was interest at that time in using families of entries in LDAP directory
servers.
The rough concensus of the group appeared to indicate that the IETF should
follow, and where possible participate, in the ISO development, and that it
should not be added to the charter of the LDAPEXT working group at this time.
A new working group could be formed later in the IETF following completion of
the ISO work to evaluate this for LDAP, or a specification could be published
as Informational.
2.3 Transactions
Earlier in the life of the LDAPEXT working group there were discussions on the
use transactions in LDAP. These are primarily intended not in the 'database'
sense with the ASID properties, but just as a way of grouping DIT modification
operations as a unit.
There was a short discussion on the scope of the problem. There have not been
many different deployments so far; Hitachi had implemented a specification but
it did not use distributed transactions. Also, the plans in the LDUP working
group for replication would increase availability of the directory
information, but would not permit full transaction semantics to necessarily be
provided, and might not allow synchronization guarantees to be maintained.
Transactions are not on the LDAPEXT charter at present.
2.4 Other proposed additions to charter
There are two other drafts - a 'complex' search specification for sending
Java bytecodes to an LDAP server, and a proxy auth. document. Neither were
discussed at this meeting.
The Area Director Patrik Falstrom noted that a Working Group cannot close
down until there are no Internet Drafts outstanding in the ID-archive.
Therefore, a document should not be submitted with a name of
draft-ietf-ldapext-... unless it is already on the charter of LDAPEXT.
The LDAPEXT working group does not need to persist indefinitely: once the
group is shut down, the mailing list can still remain active to discuss
future proposed extensions.
3. Access Control (Ellen Stokes)
Slides concerning draft-ietf-ldapext-acl-model-02.txt
Changes to Model Draft (02)
* Section on bind / credentials
- push from client to server
- control that rides with ldap_bind()
- server behavior for processing specifyCredentials control
* 2 well-defined subject DNs
- public (public access for all users)
- this ( self - user whose name matches entry being accessed)
* Proposed LDIF
The Model Today
* Defines what ACI flows on the wire
* Defines protocol extensions (controls & extended operations)
- updateAccessControl
- getEffectiveRights
- listSubjectRights
- specifyCredentials
* Defines LDIF for ACI
The Problem
* Defining LDIF for ACI approaches on defining a data format / schema
* Defining an acceptable subset of all ACI defined for today's directory
servers is hard
* Do reasonable definitions for previous 2 bullets such that
interoperability, portability, and replication are possible, but reaching
concensus is potentially problematic
The Proposed Modified Model
* Define an acceptable subset of LDIF for ACI such that it can be used as
input for ldap_add/delete/modify protocol flows
- Server responsible for mapping such LDIF ACI to server's own
implementation
- updateAccessControl extended operation & control no longer needed
- Aids in application portability, interoperability, and management
* Remaining proposed extended operations & controls enhance management of ACI
Work Plan
* Enhance LDIF
- Need contributor(s)
* Review the protocol extensions & LDIF
* Issue new draft in mid-April
* Resolve issues on list for last call before Oslo meeting
Concerns were expressed that a subset of a server's policy will not be
insecure if that policy cannot be replicated. This can in part be addressed
by servers' advertising their supported policy mechanisms: a server should then
not attempt to replicate data to another whose policy mechanism is different
if the data is protected by policy information that could not be expressed in
the form described by this model.
Several volunteers formed an engineering committee to revise the LDIF
specifications.
4. Service Location (Eric Guttman)
There are several areas in which the design goals for Service Location
Protocol (SLPv2) have led to alignment to LDAPv3. Directory Agents may
be backed by LDAP servers: attributes and search filters are broadly compatible
with LDAPv3 concepts, and SLP scopes could be mapped into distinguished names.
Service Templates are schema definitions which specify the attributes which
model particular services.
The document draft-ietf-svrloc-ldap-scheme-01.txt is a service template that
describes how LDAP servers can be advertised by SLP. The LDAPEXT working
group should review this document from SVRLOC to ensure that it is complete.
The document draft-ietf-svrloc-template-conversion-03.txt describes how to
convert SVRLOC service templates into LDAP schemas. This document is based
on SLPv1, so needs to be updated. It highlights a few differences between
the two schema models, such as the use of keywords - zero-valued attributes in
LDAP. It may be desirable to have SLP templates be a subset of LDAP schemas,
and have LDAP schemas be designed to be compatible with SLP.
5. Tree Delete Control (Michael Armijo)
Michael would like to have this document (draft-armijo-ldap-treedelete-00.txt)
moved forward as a Proposed Standard. The Area Directors need it to be
reviewed by the LDAPEXT working group. Please in the next few weeks send
comments to the author or to the mailing list.
6. Duplicate Entry Result Control (Jim Sermersheim)
There are two immediate applications of this control. One is to allow paging
of an entry with an attribute of a large number of values (e.g. a group with
many members): one PDU is returned for each value. The other
is to specify an alternative behavior for sorting on a multi-valued attribute:
one PDU is returned at each value's location in the sort order. A revised
draft should go into last call and plan to move forward as a Proposed Standard.
Ed Reed will send implementation experiences to the mailing list.
==