Subject: Consolidation of several counts thread

From: John Strassner <[email-masked]>
Date: Sun, 25 Feb 2001 08:05:33 -0800

LDUPers,

this is the fourth memo, summarizing the thread: RE: Consolidation of 
several counts thread. Note that there were a lot of subjects covered in 
this thread. Only those subjects that directly pertain to the requirements 
I-D will be discussed here. Other subjects having merit will be discussed 
later.

This memo is written as a summarization by the WG Co-Chair of declaring 
consensus on discussed items and requesting changes to be made to the 
current (-06) version of the requirements I-D prior to it being reissued 
for WG Last Call.

Issue 1: if we start singling out particular types of information that can 
or can not be replicated, where do we stop?

We've had two different attempts to characterize this issue. One was the 
(in)famous active vs. passive data, and the other was Kurt explicitly 
listing several types of attributes with MUST, SHOULD, and MAY support 
levels. This implies that some members of the WG are trying to define this 
in more detail. However, I would like to see more detail in what we are 
recommending. The active vs. passive definition fails due to the lack of 
familiarity with the precise meanings of the terms. Similarly, listing some 
but not all attributes to be replicated just raises questions about what to 
do with the attributes that aren't specified.

Action: Kurt to work with the authors to either build a matrix of ALL 
attributes and whether they should be replicated or not, or the authors 
convince Kurt that he's wrong ;-) and this doesn't need to be satisfied. 
Result to be posted to the WG list.

Issue 2: stop using the term passive data to describe what can be replicated

I'm going to make the decision to stop this discussion. I don't see this 
discussion being resolved, and Jerry brought up the point that most 
implementations will have operational attributes modified for even the 
passive data. Proponents and opponents have still not reached a common 
ground, and there are many unanswered questions from each side.

regards,
John Strassner
Co-Chair, LDUP WG

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 25 Feb 2001 18:40:00 -0800

At 08:05 AM 2/25/01 -0800, John Strassner wrote:
>Issue 1: if we start singling out particular types of information that can or can not be replicated, where do we stop?
>
>We've had two different attempts to characterize this issue. One was the (in)famous active vs. passive data, and the other was Kurt explicitly listing several types of attributes with MUST, SHOULD, and MAY support levels. This implies that some members of the WG are trying to define this in more detail. However, I would like to see more detail in what we are recommending. The active vs. passive definition fails due to the lack of familiarity with the precise meanings of the terms. Similarly, listing some but not all attributes to be replicated just raises questions about what to do with the attributes that aren't specified.
>
>Action: Kurt to work with the authors to either build a matrix of ALL attributes and whether they should be replicated or not, or the authors convince Kurt that he's wrong ;-) and this doesn't need to be satisfied. Result to be posted to the WG list.

Instead of a matrix, I suggest:

  LDUP MUST be capable to replicate all userApplication
  attribute types.  LDUP MUST be capable to replicate all
  directoryOperation and distributedOperation attribute
  types defined in the LDAP "core" specification (RFC 2251-2255,
  2829-2830).  LDUP SHOULD provide general guidelines for
  replication of directoryOperation and distributedOperation
  attribute types defined as LDAP extensions.  LDUP
  SHALL NOT support replication of dsaOperation attribute
  types as such attributes are DSA-specific.

I note that certain operational attributes, such as
subschemaSubentry, may require special attention.  I note
there are existing requirements in this area.

In addition,
  LDUP MUST be capable of replicating attribute subtypes.
  LDUP MUST be capable of replicating attribute description
  options (including ";binary" and Language Tags).

---

From: "Ryan Moats" <[email-masked]>
Date: Mon, 26 Feb 2001 08:49:15 -0600

I'm certainly in favor of somthing shorter than a matrix.  I still
have to parse what Kurt is saying below to make sure I agree with
it, but I like that approach better than a matrix.

Ryan

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Kurt D. Zeilenga
Sent: Sunday, February 25, 2001 8:40 PM
To: John Strassner
Cc: [email-masked]
Subject: Re: Consolidation of several counts thread

In addition,

---

From: John Strassner <[email-masked]>
Date: Tue, 27 Feb 2001 01:50:50 -0800

My only problem with not having a matrix is that it begs the question, what 
about attributes that are not specifically covered? Plus, it still makes me 
uncomfortable that we are in effect saying that some attributes are more 
equal than others with respect to replication. Maybe we could call this 
LDUP-1984. ;-)

If you **really** want to do it this way, fine. But as a compromise, please 
consider adding a short justification as to WHY each attribute is being 
included as a MUST, SHOULD, or MAY (or NOT, as appropriate). And please 
consider changing the approach to instead say that all attributes MAY be 
replicated with the following exceptions.

regards,
John