Subject: Re: Subentries decision - internet draft withdrawn

From: "Ed Reed" <[email-masked]>
Date: Tue, 30 Oct 2001 09:17:25 -0700

Tim - I went away from the meeting expecting that we would
pull what we needed into the LDUP infomod document from the
LDAP Subentries document.

However, Kurt has now published a short and sweet id
documenting adaption of the X.500 subentry to LDAP
(see http://search.ietf.org/internet-drafts/draft-zeilenga-ldap-subentry-00.txt)
and I now think we should go ahead and reference that draft,
instead.

What we'd do is

1) encourage Kurt to revise the draft to make it "Standards Track"
instead of "Informational", so we can refer to it;
2) Follow David Chadwick's suggestion that we define the
replicationAgreementSubentry class as a subclass of the X.500
subentry, and define a structure rule for it that allows containment
of the replicationAgreementSubentry class entries by replicaSubentry class
entries.  That way we don't "break" the subentry definition,
and the X.500 community can consider using the same technique to
allow for name subordination (ie, containment) of subentries in the future.
3) discourage use of the specificationFilter in the SubtreeSpecification,
4) encourage a simple use of the base and ChopSpecification in the
SubtreeSpecification

Items 3 and 4 represent my bias, towards defining simple replicationAreas
of non-overlaping partitions of an Administration Area.  I'd appreciate
hearing from the list whether such simplification is worth while, or not.
One argument is that people will use them, because they're there, and
so for interoperability sake, everyone should be required to fully
support them.  It's a compelling argument.

Comments?
Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 716 624 2402 (new!)
http://www.Reed-Matthews.COM

>>> "Timothy Hahn" <[email-masked]> 08/13/01 11:15AM >>>
Ed,

Thanks for the summary.

Was the concensus that we not use subentries at ALL with respect to the 
information model - i.e. just use "regular entries" for this information? 
This seems very easy to do at the expense of these entries "showing up" in 
the directory when they otherwise might not be expected.  Of course, 
access controls and/or search filters would probably keep them from 
showing up in most cases anyway.

I'll get to work on re-aligning the LDUP information model draft.

Regards,
Tim Hahn

Internet: [email-masked] 
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

"Ed Reed" <[email-masked]>
08/13/2001 10:04 AM

        To:     <[email-masked]>, <[email-masked]>
        cc: 
        Subject:        Subentries decision - internet draft withdrawn

Hello, all -

At the IETF in London the working group chairs of the LDUP and (late) 
LDUPEXT working groups considered the issues raised surrounding the LDAP 
Subentries draft I've been working on.  Their decision, as related to me, 
was to ask that the LDUP information model be revised so that object 
classes defined there for ReplicaSubentry and ReplicaAgreementSubentry no 
longer are treated as subentries, and that the work on the LDAP Subentries 
as a standards track document be ended.

So, the draft is hereby withdrawn from work group consideration.

The basis of the decision was that since the Access Control editors have 
decided not to use LDAP Subentries in their document, and since they were 
the only other charter-item document in the works that might have 
referenced the document, there appears to be insufficient interest in 
generalizing a variant from the X.500 version  of Subentries to be worth 
continuing in the working group.  There is a strongly felt (and forcefully 
expressed) feeling among several folks in the working group that there is 
no reason to "dummy down" the X.500 Subentry specification.  So we won't.

Thank you all for your patience in this matter...

Ed

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 31 Oct 2001 06:21:20 -0800

>instead of "Informational", so we can refer to it;

no problem.

>entries.

no problem.

>3) discourage use of the specificationFilter in the SubtreeSpecification,

I note that specificationFilter seems to a useful in supporting
sparse replication.

Kurt