First version was published as an ldup working group document on 15 August 1999 with agreement of both the LDAPEXT and LDUP working group chairs that the document would be subject to a joint working group last call, but would be "worked" in the LDUP working group, due to LDAPEXT wg work load.
1) David Chadwick commented, on 25 Oct 1999 that the two attributes, "cn" and "subtreeSpec", serve different purposes. In particular, that because the LDAPSubentry definition is a subset of the X.500 subentries, "cn" used to name the subentry and "subtreeSpec" used to refine the scope of the subentry to possibly include fewer than all entries than the full subtree in which it's defined.
Response: True. That is the intent of defining the LDAPSubentry - to make explicit that the scope is as though an empy subtreeSpec is defined for the LDAPSubentry. Arguably, we could say that LDAP will use the X.501 subentry definition, but then implementations would all have to "grok" the subtreeSpec attribute syntax and semantics, and the goal of creating the LDAPSubentry is to eliminate that requirement.
2) Kurt Zeilenga commented on 18 Nov 1999 that he didn't want to be required to name LDAPSubentries with cn, but wanted to be able to use other naming attributes instead that wouldn't introduce conflicts with non-subentries named with "cn". He suggested making LDAPSubentry be an abstract class with no naming attribute defined, and then subclassing another class that used "cn" as its naming attribute.
Response: Naming rules are funny things in LDAP...following more discussion, Kurt suggested on 25 April 2000 that we make "cn" MUST, but state that naming with attributes other than CN is allowed. Agreed.
3) Steven Legg, on 30 March 2000 asked that we not leave naming up to developers, but clearly define what's to be expected.
Response: Each application developer that defines a use of the LDAPsubentry class with a derived class (by which alternative naming attributes could be added - I presume that alternative naming attributes may NOT be added via adding Auxilliary classes) will be so defining the semantics of the new class (including the naming rules for the new class) that applications will need to know those semantics to make sense of the new subentry type, anyway. Browsers and applications will need to either know the semantics of the new class, or be schema aware enough to read and interpret naming rules that apply to the new class. The definition sets the expectation that "cn" will be used, but that other attributes MAY be used instead or as well (subject to the naming rules defined for the new class). My heart's with Steven, but I'm trying to accomodate Kurt, too. Came down on Kurt's side on this one.
4) David Chadwick on 15 March 2000 opined that if, in the future, LDAP wants to limit the portion of a naming context to which a subentry applies, we can simply re-invent subtreeSpecification at that time.
Response - agreed, or even simply use the X.500 definition of subentry, if that will work for the application (ie, if the application doesn't need subentries to contain other subentries in a tree of subentries, and if X.500's family of entries won't work to reproduce the LDAPSubentry containment rules allowing subentries to contain other subentries).
5) Kurt Zeilenga on 3 July 2000 opined that LDAPSubentry should be abandoned in favor of just doing X.500 subentries, including subtreeSpecification, and be visible on the basis of a control. He made these suggestions so they'd be more useful within LDAP and for the Access Control Model, in particular.
Response: After considerable discussion, we agreed on the list to use a control to make LDAPSubentries visible instead of the search filter mechanism, because the filter mechanism adds significant logic predicate complexity to developers whose applications already use complex search filters. The filter makes things simple and more importantly provides equivalent functionality to the X.500 subentries visibility mechanism.
With regard to "just doing X.500", Mark Smith wrote on 7 July 2000 that "The X.500 subtree specifier is rich and therefore fairly complex to implement. That doesn't mean we shouldn't adopt it, but id does mean we should consider the impact." Kurt replied that we also need to consider the impact of making changes, possibly incompatible ones, to X.500 elements, like making them hierarchical instead of flat, and limiting their utility by dropping the subtreeSpecification.
The author (me, Ed Reed) replied to Kurt's proposal to "just do X.500" with the following reasons for omitting the subtree specifier:
a) it introduces what seems to be a lot of complexity to determining
which entries a subentry would refer to,
b) it introduces what seems to be a lot of complexity to determining
which subentries apply to a particular entry,
c) it introduces what seems to be a lot of complex thinking for
administrators who want to understand how to tell their system
to do something, and to understand what their system is trying
to do
d) the author (me) has not been exposed to many (any) real-world
problems solved by the subtree specifier which are not or can
not be as well handled in some other fashion.
6) There followed a discussion between Alan Lloyd, Albert Langer, Rob Byrne and Ron Ramsay about the relative merits of using subentries to hold access control information, particularly in distributed environments.
7) Last Call attempted on 14 July 2000, but Kurt immediately objected...to inadequate clarity of scoping specification and semantics, and to continued use of search filter to control visibility.
Response: following additional remarks by others about semantics and administrative models, a section describing the X.501 administrative model and a proposed LDAP subset using LDAPsubentries was added. Additional language was added to try to pin down the semantics relating to containment/structure rules governing LDAPsubentries and their scope. The search filter visibility mechanism was eliminated in favor of a control.
8) Once the decision was made to use a control, the question of what kind of control was discussed: one corresponding to the subentries bit of the ServiceControls argument in X.511, or one corresponding to the whole ServiceControls argument (including the subentries bit).
Response: concensus of the group appears to support the simpler control - representing just the subentries bit of the ServiceControl argument. It's simpler and doesn't introduce a lot of unresolved design issues that having the whole ServiceControls argument would create.
9) Compatibility issues for clients using RFC2215 to read LDAP subschema subentries (via search filter instead of a control) was raised, and Kurt offered to address them in LDAPbis.
Response: Kurt to address in LDAPbis.
10) A discussion ensued over the behavior of the LDAPSubentriesControl to searches with scope of base entries (not an issue for X.500, since X.500 has READ as well as SEARCH).
Respons: visibility was specified to be implicitly TRUE when a base entry search or a subtree search is made where the base of the search is an LDAPSubentry. So, even if the control is absent, if you base a search on an LDAPSubEntry it's obvious that you DO want the LDAPSubentry, so pretend the control is present even if it's not.
11) On 4 November 2000 I recounted the discussion from the working group about administrative areas and subentries. Issues raised in the discussion had to do with problems of partitioning administrative areas, dealing with various inheritance models of policy across multiple partitions of an administrative area, and so on.
Response: Following that discussion, and the one at the spring IETF, I published a "light weight" administrative model designed as a subset of the X.500 model for comments, and then added them to the latest (-08.txt) draft.
12) On 6 Nov 2000 Rick Huber submitted several editorial corrections to the draft -04.txt, which were incorporated into later drafts. Ditto the -06 draft.
13) In the -07.txt draft published 1 March 2001 I removed the whole discussion of inheritance and the inheritableLdapSubentry object class specification and its attributes from the text. At bar boff convened to discuss the issue, we found that no "down-tree" inheritance replication mechanism was needed if servers hold sparse/fractional replicas of superior administrative areas that have LDAPsubentries relevant to the replication areas they hold. A separate internet draft, due to expire shortly, was written to describe that scheme.
14) The -08.txt draft published 6 April 2001 includes the candidate administration model originally circulated for comment on 22 March 2001. There have been two comments - one saying "it looks reasonable at first glance", and the other opposing the adoption of an administration model subsetted from X.500 without careful analysis and consideration. The comment in opposition also expressed the desire to see both LDAPEXT and LDUP involved in the decision, which both are (this being an output of both working groups and subject to last call in both groups).
Response: The need for subentries to be understood within the context of an administrative model seems to be generally agreed to across the working group participants who have commented. The need to understand how administrative areas will work in a multi-master environment, and how policy is projected from an administrative point through a subtree needs to be understood. I've chosen in the model to leave some of the thornier issues of how administrative areas span specific administration areas, and in particular replication areas until more work is done on LDAP distributed operations. I'm generally in agreement that the X.500 model of Directory Specific Entries, distributed chaining operations, and even the use of subtreeSpecifications (for defining sparse and fractional replicas) probably do make sense - but that they need to be adapted to deal with the kind of multi-master, loosely consistent replication provided by LDUP. I think the administrative model subset I've !
proposed keeps us moving in the right direction - towards accreting more and more of X.500 into LDAP - without forcing us to lunge all the way into the pool at once.
So - I'd like more comments on the administrative model. Does it work for ACI as LDAPEXT is defining it? Other applications than just LDUP? I think it DOES work for LDUP (ie, managing replication areas).
With that, said, I'd like to ask the working group chairs of LDAPEXT and LDUP to jointly or severally issue last call on draft-ietf-ldup-subentry-08.txt.
Regards,
Ed Reed
=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COM