Re: Subentries decision - internet draft withdrawn
"Ed Reed" <[email protected]>
| Newsgroups | gmane.ietf.ldup |
|---|---|
| Message-ID | <[email protected]> |
<eer> comments </eer> ================= Ed Reed Reed-Matthews, Inc. +1 716 624 2402 (new!) http://www.Reed-Matthews.COM >>> "Kurt D. Zeilenga" <[email protected]> 10/31/01 09:21AM >>> At 08:17 AM 2001-10-30, Ed Reed wrote: >1) encourage Kurt to revise the draft to make it "Standards Track" >instead of "Informational", so we can refer to it; no problem. <eer> thanks </eer> >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. no problem. <eer> thanks </eer> >3) discourage use of the specificationFilter in the SubtreeSpecification, I note that specificationFilter seems to a useful in supporting sparse replication. <eer> Yeah, I know. But that's what I"m afraid of right now, because I'm having trouble visualizing how the administration tool (built on Microsoft's Console or Novell's ConsoleOne or NetScape's Directory Manager) will represent the sparse replication, and worse yet, the overlap, if any, of two different replicaSubentry specifications of the same replicationArea when they choose different subsets of entries, or possibly overlapping subsets of entries. I know there are uses of such things, but it seems to me that the 80-20 rule would dictate that 80% of the time such sparse replication won't be needed, or wanted, and support for the other 20% will, while possible, more difficult to manage correctly. If we don't discourage its use, then it will have to be supported by everyone, whether they can create a management tool to make sense of it by administrators, or not. I confess, this is an area of my own bias. I can certainly be persuaded to just let it go and see what the market creates. But I've felt that I owed the community that would listen this one last appeal for simplicity of required implementation. Nuff said. </eer> Kurt