RE: WG Charter Proposal v2

["Chris Apple" <capple@xxxxxxxxxxxxxxxxxx>]

Comments embedded below.

Chris.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@xxxxxxxxxxxx] 
Sent: Thursday, March 27, 2003 5:12 PM
To: capple@xxxxxxxxxxxxxxxxxx
Cc: ietf-ldup@xxxxxxx; John Strassner
Subject: Re: WG Charter Proposal v2


In reading the proposed WG description, I found a discussion
of this WG "was originally chartered" to deliver but I couldn't
any statement as what the WG "is chartered" to delivered,

CWA> There is language there which treats this topic as implicit.
     I have included some additional text below to make the connection
     between the original WG direction and the new WG direction more
     explicit. This additional text is incorporated into the WG
     description as included by you in the posting to which I am
     replying now.

nor could I find any statement of what work is considered
beyond the scope of the WG.

CWA> If you have suggestions for how to phrase what work is
     out of scope for LDUP in a sentence or two, I'm certainly
     open to considering its inclusion. Otherwise, without a
     "second" from a few other WG members, I will have to treat
     this comment as an isolated one and one that doesn't
     represent consensus.

I note as well that this charter doesn't detail all the new
work discussed in "Proposal 1" which WG consensus was declared
for.

http://www.imc.org/ietf-ldup/mail-archive/msg01630.html (Proposals 1 & 2)
http://www.imc.org/ietf-ldup/mail-archive/msg01655.html (Consensus
declaration)

There seems to be major discontinuities between this
charter proposal and "Proposal 1".


CWA> I do not agree with the observation you have made
     above.

     First, proposal 1 does not require new work.
     Proposal 1 keeps existing, planned work and changes
     the originally intended publication track from
     standards to a combination of experimental and
     informational documents.

     Second, proposal 1 does mention that X.500 BAC
     will be referenced; this also doesn't qualify
     as new work as it was the intention of the LDUP WG
     to reference ACM work produced by another WG. Because
     this other WG didn't produce such a standard,
     proposal 1 simply changes the reference source to
     a document that does exist. This does not constitute
     new work.

     Third, while the details of the recommendations made
     by the design team are not reflected verbatim in the
     revised WG description, there are no discontinuities
     between what we intend to do as a WG (as reflected
     in mailing list and WG meeting discussions), proposal 1,
     or the revised WG description. The only significant
     distinguishing factor between these expressions of
     our intent is the level of specificity observable in
     each.

     The only aspect of proposal 1 which is not explicitly
     reflected in some way in the revised WG charter
     description is that we plan to reference X.500 BAC
     and in which documents this reference will be made.
     I believe that including this level of specificity in
     a WG description for a charter would be a mistake because
     there are several documents in which we could reference
     X.500 BAC. Evaluating each requires that the WG consider
     a contextual reference in an actual document. And there
     is more than one way of referencing X.500 BAC (directly
     or indirectly - as in an I-D that explains how to use it
     in the context of LDAPv3). We do not know which ways will
     be appropriate without evaluating them and therefore this
     should not be specified in a WG charter.

     Now, I would think it perfectly reasonable of you to propose
     alternate language to include or to replace existing language
     if you believe such language clarifies the charter. Please
     post any such contributions with specific language additions
     and replacements on or before the deadline for comments.

     The WG Charter Revision review period will continue per
     the original posting on this thread and as corrected
     in the follow up posting I made to the original.

     

Kurt  


At 03:46 AM 3/20/2003, Chris Apple wrote:

>Description of Working Group:
>
>As LDAPv3 becomes more widely deployed, replication of data
>across servers running different implementations becomes an
>important part of providing a distributed directory service.
>However, the LDAPv3 community, to date, has focused on
>standardizing the client-server access protocol. This group
>was originally chartered to standardize master-slave and
>multi-master LDAPv3 replication as defined below:
>
>o Multi-Master Replication - A replication model where
>  entries can be written and updated on any of several
>  replica copies, without requiring communication with
>  other masters before the write or update is performed. 
>
>o Master-Slave, or Single-Master Replication - A replication
>  model that assumes only one server, the master, allows
>  write access to the replicated data. Note that
>  Master-Slave replication can be considered a proper
>  subset of multi-master replication. 
>


<New text to clarify per Kurt's first comment above>

Recently, the WG established consensus on a change of
direction to pursue publication of a standards track
protocol for LDAPv3 client synchronization, an experimental
LDAPv3 replication protocol, and supporting informational
documents. Thus the new work program is largely the same
as the original work program with one notable exception,
the LDAPv3 replication protocol is intended to be an
experimental rather than a standards track protocol.

>The WG's approach was to first develop a set of requirements
>for LDAPv3 directory replication and write an applicability
>statement defining scenarios on which replication requirements
>are based. An engineering team was formed consisting of different
>vendors and the co-chairs in order to harmonize the existing
>approaches into a single standard approach. All of these have
>been accomplished during the pre-working group stage. It should
>be noted, however, that replication using heterogeneous servers
>is dependent on resolving access control issues, which were
>the domain of other working groups. Because the responsible
>WG failed to achieve consensus on a standard access control
>model for LDAPv3, the LDUP WG formed a design team to explore
>the issue of how to address the lack of such a model
>in the context of LDAPv3 replication. This design team made
>recommendations to the working group. The working group
>considered these recommendations and consensus was
>established on addressing these recommendations in
>the context of revising other working group deliverables
>rather than adding new deliverables specific to access
>control for replication. Largely because of the lack of
>a standard access control model for LDAPv3, the working
>group also established consensus on pursuing an experimental
>or informational publication path for a majority of working
>group documents formerly intended to become proposed standards.
>
>The new replication architecture supports all forms of
>replication mentioned above. Seven areas of working group
>focus have been identified through LDUP Engineering Team
>discussions, each leading to one or more documents to be
>published: 
>
>o LDAPv3 Replication Architecture 
>
>   This documents a general-purpose LDAPv3 replication
>   architecture, defines key components of this architecture,
>   describes how these key components functionally behave,
>   and describes how these components interact with each
>   other when in various modes of operation 
>
>o LDAPv3 Replication Information Model 
>
>   Defines the schema and semantics of information used to
>   operate, administer, maintain, and provision replication
>   between LDAPv3 servers. Specifically, this document will
>   contain common schema specifications intended to
>   facilitate interoperable implementations with respect to: 
>
>      + replication agreements 
>
>      + consistency models 
>
>      + replication topologies 
>
>      + managing deleted objects and their states 
>
>      + administration and management 
>
>o LDAPv3 Replication Information Transport Protocol 
>
>   LDAPv3 extended operation and control specifications
>   required to allow LDAPv3 to be used as the transport
>   protocol for information being replicated 
>
>o LDAPv3 Mandatory Replica Management 
>
>   Specifications required to allow administration,
>   maintenance, and provisioning of replicas and
>   replication agreements. These specifications may
>   take the form of definitions for LDAPv3 extended
>   operations, controls, and/or new schema elements. 
>
>o LDAPv3 Update Reconciliation Procedures 
>
>   Procedures for detection and resolution of conflicts
>   between the state of multiple replicas that contain
>   information from the same unit of replication. 
>
>o LDAPv3 Profiles 
>
>   Including the LDAPv3 Replication Architecture,
>   Information Model, Protocol Extensions, and Update
>   Reconciliation Procedures for: 
>
>        + LDAPv3 Replication General Usage
>
>        + LDAPv3 Single-Master Directory Replication 
>
>      + LDAPv3 Multi-Master Directory Replication 
>
>o LDAPv3 Client Update 
>
>   A protocol that enables an LDAP client to
>   synchronize with the content of a directory
>   information tree (DIT) stored by an LDAP server
>   and to be notified about the changes to that
>   content. 
>
>The work being done in the LDUP WG should be coordinated
>to the closest extent possible with similar work being done
>in the ITU. This is necessary both because LDAP depends
>on X.500 and because it makes sense from an operational
>perspective. 
>
>Goals and Milestones:
>
>Done    Submit I-D on LDAPv3 Directory Replication Requirements.  
>Done    Submit I-D on LDAPv3 Replication Information Model  
>Done    Submit I-D on LDAPv3 Update Reconciliation Procedures.  
>Done    Revise I-D on LDAPv3 Directory Replication Requirements.  
>Done    Revise I-D on LDAPv3 Replication Architecture.  
>Done    Revise I-D on LDAPv3 Replication Information Model.  
>Done    Submit I-D on LDAPv3 Replication Information Transport Protocol.  
>Done    Revise I-D on LDAPv3 Replication Architecture.  
>Done    LDAPv3 Directory Replication Requirements I-D goes to WG Last Call
>as Informational.  
>Done    Submit I-D on LDAPv3 Mandatory Replica Management.
>Done      Submit I-D on LDAPv3 Replication General Usage Profile.
>Done      LDAPv3 Client Update Protocol I-D goes to WG Last Call as
Proposed
>Standard.
>Done    Revise LDAPv3 Client Update Protocol I-D.
>
>APR 03  Revise LDAPv3 Replication Information Model I-D.
>APR 03  Revise LDAPv3 Client Update Protocol I-D.
>
>MAY 03  Revise LDAPv3 Update Reconciliation Procedures I-D.
>MAY 03  Revise LDAPv3 Replication Architecture I-D.
>MAY 03  Revise LDAPv3 Replication Information Transport Protocol I-D.
>MAY 03  Revise LDAPv3 Mandatory Replica Management I-D.
>MAY 03  LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed
>Standard.  
>
>JUN 03  Revise LDAPv3 Replication General Usage Profile I-D.
>JUN 03  Submit I-D on LDAPv3 Single-Master Directory Replication Profile.
>JUN 03  Submit I-D on LDAPv3 Multi-Master Directory Replication Profile.
>JUN 03  LDAPv3 Replication Information Model I-D goes to WG Last Call as
>Informational.
>JUN 03  LDAPv3 Replication Architecture I-D goes to WG Last Call as
>Informational.
>
>JUL 03  Revise LDAPv3 Single-Master Directory Replication Profile I-D.
>JUL 03  Revise LDAPv3 Multi-Master Directory Replication Profile I-D.
>JUL 03  Revise LDAPv3 Update Reconciliation Procedures I-D.
>JUL 03  Revise LDAPv3 Replication Information Transport Protocol I-D.
>JUL 03  Revise LDAPv3 Mandatory Replica Management I-D.
>JUL 03  Evaluate Deliverables Status
>
>AUG 03  LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call as
>Experimental.
>AUG 03  LDAPv3 Replication Information Transport Protocol I-D goes to WG
>Last Call as Experimental.
>AUG 03  LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as
>Experimental.
>
>SEP 03  LDAPv3 Replication General Usage Profile I-D goes to WG Last Call
as
>Informational.
>SEP 03  LDAPv3 Single-Master Directory Replication Profile I-D goes to WG
>Last Call as Informational.
>SEP 03  LDAPv3 Multi-Master Directory Replication Profile I-D goes to WG
>Last Call as Informational.
>
>Chris Apple - Principal Architect
>
>DSI Consulting, Inc.
>
>mailto:capple@xxxxxxxxxxxxxxxxxx
>
>http://www.dsi-consulting.com