Subject: LDAP subentry schema request for last call

From: "Ed Reed" <[email-masked]>
Date: Thu, 13 Jul 2000 09:55:49 -0600

After reviewing the recent comments on LDAPsubentry (and posting my reply), and reviewing where the March 9 version of the doc (as posted on the LDUP wg web site) stands with regard to MUST/MAY (cn) and naming, I think the document, as published, should go forward for last call.

With regard to naming, the doc says LDAPsubentry MAY be named by cn, which is where I think the concensus of the list now resides.

With regard to MUST/MAY {cn} as an attribute, the document now says MAY, and leaves the class as a STRUCTURAL class.  Of course, that means that a naming rule will need to use CN as it's naming attribute if no other attributes are defined on the class, which pretty much turns it into a MUST in those cases, but when other classes are derived from LDAPsubentry other attributes may also be defined, and then cn need not be used as a naming attribute.  I think we could also make it be MUST {cn} and require cns to be populated, even if they're not being used to name the LDAPsubentry, and I'll be happy to make that change after last call if needed.  I just don't see the need to bother, now.

With regard to making LDAPsubentry fully compatible with the X.500 subentry, it's been pointed out that people wanting to use the X.500 subentry should feel free to do so - it's incorporated by reference in the base LDAP definitions.  The purpose of this proposal is to define a subset of the X.500 functionality (and extend the structural rules by allowing nesting of LDAPsubentries) for use by certain LDAP applications which find the subset functionality a useful simplification.

So - Please, put out the last call for the draft as posted on the LDUP WG IETF Charter page, document draft-ietf-ldup-subentry-02.txt, dated 9 March 2000.

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COM

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 14 Jul 2000 09:12:39 -0700

Even if you dismiss my suggestion to align with X.500 subentry,
the LDAPentry I-D still needs work and, IMO, not ready for last call.

1) Given that LDAPsubentry is NOT X.500 subentry, the I-D must
explicit in defining it's semantics.  As defined, it is not
clear which X.500 subentry semantics apply or which ones don't.
The reader cannot assume X.500 semantics apply unless the
document explicitly states they do apply.

It is not clear of how LDAPsubentries are scoped.  It is not
clear whether or not X.500 placement (at administrative points)
restrictions apply to LDAPsubentries (the I-D uses a MAY).

It is not clear what container restrictions, if any, are
applicable. Can they be contained by the root DSE? 
other non-entry DSEs?  Can a LDAPsubentry contain a
non-LDAPsubentry?  Are there restrictions upon sub-classing
with other 'special' object classes (such as 'alias' and 'referral')?

2) I believe the specification of (objectclass=LDAPsubentry)
filter component is inadequate and that a control should be used
instead.  If a filter component is used, the specification
should state the semantics of filter component when it is
part of an Undefined or FALSE filter component or not
evaluated due to filter evaluation short circuiting.  I think
further overloading the search filter is a really bad idea.
But beyond that, a search filter component is limited to only
search operation operations and the visibility control may be
needed with other operations (such as modify, see below).

I proposed use of a control instead of a filter component.
We have operational experience with similar controls
(ManageDSAit) working well and experience with overloaded
search filter components not working well (previous matched
values I-D).  I believe a control would facilitate
implementation of LDAP-DAP gateways.

But beyond this, a control is usable with any operation.  I
would suspect that visibility control would be needed with
other operations such as modify and/or extended operations.
In particular, note that in X.500 collective attributes
(which an LDAP server may support) are not normally modifiable
unless the subentries control is present.  X.511, 11.3.2:

  The [modify] operation may be used to modify collective attributes only if the
 service control subentries is TRUE and if the object is the subentry actually
  holding the collective attribute(s) to be modified.

(careful readers might note this sentence conflicts conflicts
with 7.5(f), but that's another matter)

At 09:55 AM 7/13/00 -0600, Ed Reed wrote:
>With regard to making LDAPsubentry fully compatible with the X.500 subentry, it's been pointed out that people wanting to use the X.500 subentry should feel free to do so - it's incorporated by reference in the base LDAP definitions.

Yes.  So there must be an overwhelming reason why a replacement is
needed.  I don't think the complexity of the subtree specifier is
an overwhelming reason.  It would be similar just to grant vendors
some freedom to implement portions of the specifier (as previously
suggested by another member).

>The purpose of this proposal is to define a subset of the X.500 functionality (and extend the structural rules by allowing nesting of LDAPsubentries) for use by certain LDAP applications which find the subset functionality a useful simplification.

I believe the removal of the subtree specifier will require the
introduction of replacement scoping mechanisms/placement restrictions
with complexity similar to that of the subtree specifier.  And if
you allow LDAPsubentries to be placed anywhere in the directory,
locating the applicable LDAPsubentry becomes quite complex (for
both clients and servers).

On an editorial note, Section 2:
  ... RFC 2119 [RFC2119]. The sections below reiterate these definitions
  and include some additional ones. 

The need for alternative and/or additional ones should be eliminated.
This is an IESG nit: http://www.ietf.org/ID-nits.html