IETF LDAPEXT Working Group March 17, 1999 Minutes recorded by Mark Wahl . 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. ==