[Date Prev][Date Next] [Chronological] [Thread] [Top]
Draft Minutes from LDAPEXT working group

To: ietf-ldapext@netscape.com
Subject: Draft Minutes from LDAPEXT working group
From: Mark Wahl <M.Wahl@INNOSOFT.COM>
Date: Mon, 29 Nov 1999 10:56:21 -0600
Cc: minutes@ietf.org
Resent-date: Mon, 29 Nov 1999 08:57:17 -0800 (PST)
Resent-from: ietf-ldapext@netscape.com
Resent-message-id: <"DSaNV.A.QCH.bBrQ4"@glacier>
Resent-sender: ietf-ldapext-request@netscape.com
Minutes of LDAPEXT 
Taken by Mark Wahl <M.Wahl@innosoft.com>
November 10, 1999

1. Status of Completed Items

LDAP Extension for TLS, Recommended Authentication Methods, DIGEST-MD5 have 
completed Working Group last call and are in the hands of the IESG.

Server-Side Sorting Control, which was waiting on Simple Paged, is now in 
IETF-wide last call and is expected to become a Proposed Standard RFC.

Jeff Hodges has unresolved comments on Access Control requirements which he
will send to the document authors and WG chairs.

2. Items soon to enter WG last call

The virtual list view and Duplicate Entries drafts have been waiting on 
Sorting.  Now that sorting is gone into IETF-wide last call, the WG chairs
will issue WG last call on these drafts soon after the meeting.  They are
expected to become Proposed Standard RFCs.

3. C API

The latest draft -04 which is in last call has small editorial changes and 
bug fixes.  

There has been some discussion on the list about the security considerations 
section, for handling credentials and identities with server referrals, that
will be addressed during last call.

There is agreement to improve error reporting for functions which do not take
an LDAP* as an argument.  The authors of the C API and Kurt Zeilenga will 
have an engineering discussion to arrive at a suitable approach.  

Behavior in multithreaded environments is covered by a separate draft which
is not part of this last call.

4. Java API

There were no comments on the Java API.

5. ACL model

As Ellen Stokes was not present, discussion was deferred to the list. 

Paul Leach and Jeff Hodges have comments which they will provide to the 
authors.

Since there has been significant discussion on the list, a new draft is 
expected soon from the authors.

6. Server Location

The draft-ietf-ldapext-locate-00.txt describes how SRV records are to be 
used to discover LDAP servers.  Paul Leach to investigate whether there are
any IANA considerations.  Mark Smith requested a reference added to RFC 
2052 or its successor for the algorithm clients should use to choose the 
correct server.

There were no other significant issues raised on the taxonomy or discovering
servers through DNS.

We will plan to issue last calls on these drafts soon, with the intention 
that draft-ietf-ldapext-ldap-taxonomy-00.txt will become Informational and
draft-ietf-ldapext-locate-00.txt will become a Proposed Standard RFC.

7. Referrals

A work item is the definition of how to manage references between LDAP 
servers.  An earlier draft had specified both the 'simple' behavior, where
there is both hierarchical name subordination and knowledge of all the 
subordinates, names, as well as a more complex behavior to handle potentially
overlapping or unknown naming contexts.  The former was broken out into 
draft-ietf-ldapext-namedref-00.txt, the latter does not exist in an IETF
draft at present.  There is a competing proposal for the former which also 
covers several inter-X.500-server knowledge cases.  David Chadwick was not 
present and so the technical issues were not discussed.  The authors are 
requested to ensure that by the next meeting we have a single base document
on the simple referral behavior that is suitable for last call to become a 
Proposed Standard.

8. CLDAP 

There is not yet a draft on CLDAP, although there are several people interested
in writing and implementing it.  The authors are requested to discuss and 
have a draft before the next meeting.  If not, this item might be dropped 
from the charter.

9. Persistent / triggered search

No change in their text since last meeting, so not discussed.

10. LDAP error codes

draft-just-ldapv3-rescodes-00.txt  gathers information from X.511 and presents
a glossary, table and operational guidance for handling of the error codes in 
2251.  It does not cover error codes defined by extensions. The authors 
consider adding flow charts to a subsequent revision.  There were several 
requests however to ensure that flow charts were illustrative examples and not 
prescriptive, so as to not over-constrain server impementation.

The editor of the core LDAPv3 protocol intends to add this text to the next 
revision of 2251.  A discussion of what status this document as an RFC would 
have if until that time: If the information changes or updates X.511 or RFC 
2251, or if 2251 is underspecified such that this is necessary to implement
it, it should be a Proposed Standard which updates 2251, otherwise it should
be Informational.  The WG chairs, ADs and document authors will discuss this
when the draft is ready for last call.

   LDAPv3 Result Codes: Definitions and Appropriate Use
   LDAPExt Working Group
   IETF - November 1999

   New draft
   edited by Kristianne Leclair (Entrust), Jim Sermersheim (Novell), Mark 
   Smith (Netscape), Mike Just (Entrust)
   Available at IETF web site
   draft-just-ldapv3-rescodes-00.txt
   Posted to LDAPExt mailing list on Oct 27

   Draft purpose
   RFC 2251 unclear
   refers to X.511, but who does?
   Gather information into a single source
   Intent is to aid 
   directory developers as to what error to return
   application developers as to what error to expect

   Draft contents
   Glossary
   classification of result codes
   definition for each result code
   Operational guidance
   what result to return in case of error
   Table
   matching each operation and their applicable errors

   Next version
   Add a Table of Contents
   Incorporate comments from group
   Add flow charts
   possibly replacing or complementing Section 4

   How to progress?
   Obtain comments
   Does draft accomplish what it intended to accomplish?
   Long-term?
   Incorporate in next version of RFC 2251
   Short-term
   Standards track in LDAPExt
   Last call after March meeting

11. Dereferencing Match

draft-moats-ldap-dereference-match-01.txt is an extensible matching rule which 
allows indirection through DN-valued attributes during filter evaluation.  
Its side effects are that the internal state of a filter tree changes from 
being a tri-state value to entries, and that it is not known whether it could 
be efficently implemented in a distributed directory.  There are several 
other issues, including whether the service could be provided with a 
combination of families of entries feature and alias objects, whether it 
should be specified as a matching rule, search control or extended operation, 
and how it interacts with weakly consistent replication.  

There appeared to be consensus that this work was interesting but not yet ready
to be a work item or Proposed Standard.  The authors and implementors will
prepare an Experiment and produce an Experimental RFC, so that experience
may be gained with its use.

   Slide 1:
   draft-moats-ldap-dereference-match-01.txt
   
   Ryan Moats (AT&T), Jerry Maziarski (AT&T), John Strassner (Cisco)
   
   Slide 2:
   Extended Matching Rule that allows dereferencing of DN pointers in server
   Simplifies client complexity and round trip time
   Standards Track
   
   Slide 3: Dereferencing Match - Example 1
   find phone number and building of all managers of any building
   (sub, manager:<oid>:=(objectClass=person), (phoneNumber, building))
   filter to find phone number of managers of building 12
   (base, manager:<oid>:=(building=12), phoneNumber)
   
   Slide 4: Dereferencing Match - Example 2
   Find policy rules for outbound traffic for routers with IP Address
   192.128.170.x:
   (sub, (policyRulesAuxContainedSet:<oid>:=&(ipAddress=
   ?192.128.170.*?)(qosPolicyRules:<oid>:(QosPolicyDirection=2))), ??)
   
   Slide 5: Dereferencing Match - Side Effects
   Filter generates separate objects rather than boolean that applies to
   current object of search
   Filter rules complex: what is legal?
   Legal combination
   &(objectclass=fancyconnectiontype)((targetDN:<oid>:=(&(objectClass=dmtfActiv
   eConnection)(trafficType=2))))
   Illegal combination
   |(foo=bar)(foo=barshelf)(&(objectclass=fancyconnectiontype)((targetDN:<oid>:
   =(&(objectClass=dmtfActiveConnection)(trafficType=2)))))
   
   Slide 6: Implementation?
   Chadwick: use aliases in families of entries in place of multi-valued
   pointer attributes
   Pro: Servers already have alias dereferencing
   Con: Acceptance of families of entries (that include aliases)
   
   Slide 7: Net Steps?
   >From mailing-list:
   - Need correct syntax OID for matching rule
   - Need more discussion (and an example) of how referrals are handled
   	query rewriting using LDAP URLs
   -Clarify impact of server side limits
   -Add more clarity in the security considerations
   
   Is extended matching the correct approach?
   	Would a control be better?
   
   Add to WG charter?


12. Extended Partial Response

draft-rharrison-ldap-extpartresp-00.txt specifies an approach of how an 
extended request can return multiple response PDUs, similar to how a search 
request returns multiple entries and references followed by a final result.

There are several potential applications of this concept.  One would be 
operation status notification, although this could be done with SNMP, 
unsoliticed notifications or server-specific operation status subentries.

The editor of the core LDAPv3 protocol will take this concept into account
for the reissue of 2251.

13. Password Policy

Jim Sermersheim presented draft-behera-ldap-password-policy-00.txt, which 
describes a password policy object and password information.  A planned 
revision will remove the modify and compare mechanisms, and remove references
to the 'userpassword' attribute.  (A separate draft is in preparation for 
the password hash encoding indications.)  Issues under consideration include
how to specify  the linkage between policy entries and the entries governed
by this policy, how to operate under weakly consistent replication, and how
to support multi-valued password attributes.

   LDAP Password Policy
   draft-behera-ldap-password-policy-00.txt
   
   Password Policy Overview
   Used to administer password related policy
   	pwdPolicy object class
   		Used to create policy for users. Hold info like:
   			Intruder detection policy
   			Password expiration policy
   			Password modification policy
   
   Overview (cont.)
   pwdInfoObject object class
   	Holds password information about a specific entry:
   		Intruder detect resets
   		expiration info
   		modification info
   
   Changes being made to the draft
   Remove modify/compare mechanisms and references to userPassword
   Incorporate other feedback from the WG list
   	fix return codes
   	address V2 concerns
   	provide clarifications
   	...
   
   Issues being resolved
   Define the association between pwdPolicy and pwdPolicyObject
   	A one to many relationship between policy and entries
   	Grouping could be done by:
   		structural relationship (subentry - subtree)
   		group inclusion
   		reverse group inclusion
   Work out algorithm/efficiency problems
   
   Placement and Category
   Is this an LDAP-EXT WG item?
   Should this be a standards track document?

14. LDAP subentries

draft-ietf-ldup-subentry-01.txt describes a subset of X.500 subentries which
could be useful for holding DIT policy information, such as subschema or 
password rules.  This is in the LDUP working group as it is being used
for replication agreement modelling.  When LDUP is ready with this draft, a
coordinated last call will be done between LDUP and LDAPEXT for it to become
a Proposed Standard.


Mark Wahl, Directory Product Architect
Innosoft International, Inc.
Prev by Date: re: Just in Time for the Christmas Rush
Next by Date: IPv6 addressed in LDAP C-API
Index(es):
- Chronological
- Thread