LDAPEXT Minutes 31-July-2000  1-3pm   Chair: Mark Wahl

Recorded by Mark Smith <[email protected]>

1:05pm Start

- Discussion of agenda
       Kurt Z.: add grouping at the end?
       Mark W.: may come up under charter review

- Other groups and BOFS (Mark Wahl and everyone)
       LDUP (Tuesday)
       LDAPbis (Wed afternoon)
       LDAP Grouped Operations (dinner BOF: 5:30pm near palms)
       SP-DNA intro. session (7:30pm in N. meeting room 2)
       SP-DNA working groups (8:00pm)
       Evolving LDAP Schema Entries (ELSE - not scheduled)
       VPIM 2nd meeting - LDAP schema (Thu afternoon)

- New RFCs: startTLS, LDAP auth. methods, Digest/MD5

- Pending RFCs: server side sorting and VLV

- Duplicate entries - Jim S. (1 transparency)
       last call comments handled:
               added option for server to selectively apply the dupent ctrl
               a control is now returned with each searchResultEntry
               allow any LDAPv3 result code to be returned in result ctrl
               updated examples, etc.
       outstanding issues:
               attribute subtypes ignored (goes against X.500 + LDAPv3)
               what if returned attr. list does not include dup ctrl attr?
       next step: revise and issue another last call

- Java API (Jim S.)
       last call comments handled:
               main/sync. and async. drafts combined into one document
               changes to schema abstraction classes
       next step: issue another last call.  Mark W. to issue last call.
       Kurt Z.: still some outstanding LDAPv2 & charset issues to work on.

- Server discovery
       Taxonomy doc. is waiting on its dependencies (last call completed OK)
       Locating servers through DNS (Michael Armijo) - last call comments
               fully qualified domain names syntax and text
               conversion of domain names into DNs
               security considerations additions (DNS spoofing)
               next step: review and reissue last call

- LDAP access control - Ellen Stokes (3 electronic slides)
       Engineering subteam has made good progress over the past 3-4 months
               Trying to take the good things from X.500
               BNF and ASN.1 clean up
               strength of authentication added (SASL issues remain)
               management (access control for ldapaci)
               subEntries: need to add scoping?
               text added on alias derefering and referrals
               version of ldapaci: punting (define a new attr later if needed)
               security considerations, examples, etc. updated
       Other work to be done:
               discloseOnError to be moved to a permission ala X.500
               browse/read/search clarifications needed
               rename to possibly be removed in favor of other permissions
               scoping: divide into two attributes (David Chadwick)
               implicit vs. explicity deny "conflicts"
               support filters in the aci?  leaning is towards "no"
               subentry issues
               specificity of permissions
       Jim S.: meetings or mailing list to resolve open issues?
       Ellen: get together after this meeting to schedule more face-2-face time
       ?: replicated area issues not addressed (replication of acis)
       Ellen: that is an oversight
       Mark W.: time table for new draft
       Ellen: by end of August if progress can be made; then issue last call

- Referrals and knowledge references - Roland Hedberg (elec. slides)
       plan: split into 2 documents
               a) superior & subordinate plus general schema, etc.
               b) other kinds of references
       Bruce Greenblatt (?): what is a superior reference?
       Roland: open issue to be resolved
       Kurt Z.: global superior (doc a) vs. immediate superior (doc b)
       Open issues:
               replication related issues
               manageDSAIT control definition ("unhide" knowledge info
                       vs. see only knowledge info.)
       ???: Do we need NSSR?
       Roland: 2 places something similar to NSSR is useful:
               a) efficient support for one level searches (spot shadowing)
               b) master info. below a country node plus org. specific info.
       Mark W.: can we publish document a) (immediate subordinates)
               by end of August?
       Roland: yes, hopefully.

- CLDAP - Leif J. (transparencies)
       motivation: simple, fast anonymous reads
       Open issues:
               No updates (hard to do over UDP)
               No new security mechanisms (rely on ipsec and friends)
               Retry scheme using same LDAP msgid to be specified
       Bruce G. ?: Active Directory does this today.  How does this align?
       Leif: Unknown, but it is still early in the CLDAPv3 specification process.
       Mark W.: there are at least 3 LDAPv2 CLDAP implementations
       Mark W.: wants updates, SASL, etc.

- Subentries - Ed Reed (elect. slides)
       Presentation of resolved issues:
               cn is a "may" although it will typically be the naming attribute
               auxiliary objectclass
       Scoping: Ed assumed it would be derived from the definition of the administrative areas and naming contexts, i.e., this is like an X.501 subentry that does not have a subtreeSpecifier
       But: inheritance across naming contexts, etc. is a tricky area
               Some implementations (e.g., Novell) "cache" inherited rights across naming context boundaries
       Input so far:  need scoping for access control
               make it clear, regardless
       Mark W.: make the default clear and allow subclasses to override the definition
       Ellen Stokes: access control spec. currently assumes ldapaci applies from its location down the tree until another ldapaci is encountered (or to the leaves if no additional ldapaci's)
       Ed: where can these subEntries be defined?  Intent was to limit the locations to a few "well known" areas
       David Chadwick: administrative areas and naming contexts need to be treated separately -- be more flexible.  Say that subEntries always reside within AA boundaries, i.e., drop naming contexts from the ldapSubEntry specification.
       XXX: Agree with David.  Note that naming contexts are within one server but AAs can span servers.
       Ed: But we don't have a way to denote the AAs in LDAP.  Define an auxiliary class to hold an attribute for this.
       Mark W.: adopt the one from X.500 (the attribute's value is an OID).
       XXX: Does this discussion belong in the ELSE BOF?
       Mark W.: ELSE is focused on user schema, not admin./operational schema
       David C.: Need operational attr. within each entry to locate the nearest AA.  Could also have a list in the rootDSE of AAs.
       Ed: Also need a way to decorate ldapSubEntries.
       Helmut Volpers: operational attribute vs. aux class
       Ed: I find aux. classes more elegant
       David C.: Not needed.  AAs are implicitly defined.
       Kurt Z.: Subentries within subentries.  What does each entry apply to?
       Ed: Intent was that all subentries that are together are one set.
       Mark W.: Could express how nesting is handled (in a specification for a particular flavor of subentry).
       David C.: This would disallow one subentry to hold two kinds of info., e.g. replication and access control
       Mark W.: Typically they would be separate anyway.
       Next step: Ed to initiate discussion on the list.
       Robert Byrne: Should demonstrate how many applications really need scoping vs. those that do not.  If there are many applications, we should address it in a common way but if not we can leave it up to each application.
       Ed: Trying to avoid copy/paste of subtreeSpecifier from X.500.  People can use that today if they like (MUST X.500 in RFC 2251)
       Kurt Z.: Why do we need this if we have X.500 subentries already?
       Ed: Doesn't allow nesting of replication subentries.
       Mark W.: Doesn't allow for other naming attributes.
       Ed: Will need to clarify this point.

Charter Review (Mark Wahl led discussion; elect. slides)
       Probably need one or two more IETF meetings to wrap up current work
       Other work to be done
               Simple extensions
               Complex extensions (requirements needed)
                       LCUP
                       operation grouping
                       families of entries
                       schema issues
               Schema specification issues (some specs. are circa 1991)
               LDAPv3 bug fixes (how to move to DS)
               Documents LDAP depends on, e.g., SASL.
       Patrik F.: area directors want two working groups
               a) core protocol group to focus on MUSTs (attend the BOF)
               b) optional extensions as a separate group
       Patrik F.: What else is needed to take LDAPv3 to DS?
       Next steps: attend the LDAPbis BOF
                       rechartering discussion w/ADs and so on.

Non Work Item - Matched values only - David Chadwick (elec. slides)
       Simplified approach specified; new I-D released in July.
       Next steps: new draft followed by last call
               remove complex examples (no longer interesting)
               add/keep 3 useful examples
               take into account recent comments
       Open issue: some people say this work is not needed.
       Mark W.: the matched values filter is not the same as search filter
       David: Yes, it is simpler.   Just the basic filter items.  Subset.
       Helmut Volpers: So I can't use the same filter in both places?
       David: Yes, the use of the filter is different.

Non Work Item - Password extended op - Kurt Z.
       Submitted to area directors

Non Work Item - Auth Password - Kurt Z.
       Still some open issues; to be discussed on the list.

Non Work Item - Password Policy - Jim S.
       Almost ready for last call
       Will reissue with replication related fix.

Non Work Item - Reply Signatures (no one to represent this)

Non Work Item - LDAP Grouping discussion
       Mark W.: motivation comes from LDUP (grouping of repl. updates)
               Also, various transaction drafts.
               Also, bulk update (LBURP)
               Beginning and ending (framing) is useful.  But semantics are challenging to specify.  ACID?  A stream of operations?
               Kurt Z. draft specified semantics using an OID.
               Many people working on this at the same time.  We need 3 things:
                       - a requirements document
                       - framing
                       - semantics of grouping (several documents?)
       Roger Harrison: Mark's comments stand: this is generally useful.
       Kurt Z.: Need to get on the same sheet of music, but there are some semantic differences.  Should have an engineering team meeting.
       Mark W.: 5:30pm today!
       XXX: Multiple groups on the same connection at the same time.
       Mark W.: Yes, if control is used.
       XXX: Not going to use the word "transactions?"
       Mark W.: ACID is not needed for everthing.  Let's do the core work and let the struggles continue where there are hard issues)
       Rick Huber: Replication is a useful property of directories.  Make sure we take that into account.
       Kurt Z.: Single master only?
       Rick: Disagree.
       XXX: There is somewhat of an analagous situation in the SCSI world:  linking of commands (e.g., sequence plus link flag)
       Mark W.: One interesting thing is that operations need not be performed in the order sent by the client.

Send slides and presos. to Mark W.

2:50pm Break.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.