RE: Revised WG Charter Proposal

Same response on the other comment.

The language present in the milestones
section of the charter is the language
that the WG has been directed to use.

So I don't plan to re-word the last milestone
unless directed to do so by our ADs or the
IESG.

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:[email protected]> 
(V) +1 610 425 2860


-----Original Message-----
From: Christopher Apple 
Sent: Thursday, November 08, 2001 10:17 AM
To: 'Kurt D. Zeilenga'
Cc: '[email protected]'; John Strassner (E-mail)
Subject: RE: Revised WG Charter Proposal


The use of the "REVISE" and "WG Last Call" milestones is consistent
with feedback we have received from the IESG/our ADs in the past.

I don't plan to try changing that now. If the IESG or our ADs
want to see milestones expressed in a different way, they will
change them accordingly prior to charter approval.

Chris Apple
Program Manager - Integration Services
United Messaging Inc.
<http://www.unitedmessaging.com>
<mailto:[email protected]> 
(V) +1 610 425 2860


-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email protected]]
Sent: Thursday, November 08, 2001 12:25 AM
To: Christopher Apple
Cc: '[email protected]'; John Strassner (E-mail)
Subject: Re: Revised WG Charter Proposal


I suggest striking all the "REVISE" milestones... and
replacing all "WG Last Call" milestones with "Recommend
to the IESG for consideration as a ...".   From past
experience, each document has multiple WG Last Calls...
it's successfully completely the WG Last Call and
progressing the I-D that counts.

And I suggest the last milestone be:
        Revise charter or conclude
as "Re-evaluate Charter and Milestones" doesn't sound like
much of a commitment to successfully conclude.

At 12:30 PM 2001-11-05, Christopher Apple wrote:
>Based on input from document editors and a little editing from me,
>please review the following. The open review period of this begins
>today, Monday, November 5, 2001 and will last for 7 days.
>
>The review period therefore ends on Monday, November 12, 2001.
>
>Silence equals consent. This will be sent to the ADs for review
>subject to incorporation of comments sent, discussed, and
>vetted on the WG mailing list shortly after November 12, 2001.
>
>LDAP Duplication/Replication/Update Protocols (ldup) 
>
>Last Modified: 05-Nov-01 
>
>Chair(s):
>
>Chris Apple <[email protected]>
>John Strassner <[email protected]>
>
>Applications Area Director(s): 
>
>Ned Freed <[email protected]>
>Patrik Faltstrom <[email protected]>
>
>Applications Area Advisor: 
>
>Patrik Faltstrom <[email protected]>
>
>Mailing Lists:
> 
>General Discussion:[email protected] 
>To Subscribe: [email protected] 
>In Body: subscribe 
>Archive: http://www.imc.org/ietf-ldup/ 
>
>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. Therefore, this group will 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. 
>
>The WG's approach is 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 are the domain of other
>working groups. Should these issues not be resolved outside of
>the LDUP WG in a timely manner relative to the WG's needs, the
>WG will be re-chartered subject to Applications AD/IESG approval
>to include the minimum required work.
>
>The new replication architecture support 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 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 Replication Usage Profile 
>
>   Including the LDAPv3 Replication Architecture, Information Model,
>   Protocol Extensions, and Update Reconciliation Procedures for: 
>
>      + LDAPv3 Master-Slave 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 Internet-Draft 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 Architecture. 
>
>Done    Revise I-D on LDAPv3 Replication Information Model. 
>
>Done    Submit I-D on LDAPv3 Replication Information Transport
Protocol.
>
>
>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 General LDUP Usage Profile.
>
>Done    Submit I-D on LDAPv3 Operations Framing.
>
>Oct 01  I-D on LDAPv3 Extended Operations for Framing goes to WG Last
>Call as Proposed Standard.
>
>Nov 01  Submit I-D on LDAPv3 Replication Information Transport
Protocol.
>
>
>Nov 01  Revise I-D on General LDUP Usage Profile.
>
>Nov 01  Revise I-D on LDAPv3 Mandatory Replica Management.
>
>Dec 01  LDAPv3 Client Update Protocol I-D goes to WG Last Call as
>Proposed Standard. 
>
>Feb 02  LDAPv3 Replication Architecture I-D goes to WG Last Call as
>Informational. 
>
>Mar 02  LDAPv3 Update Reconciliation Procedures I-D goes to WG Last
Call
>as Proposed Standard.
>
>Mar 02  LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as
>Proposed Standard. 
>
>Mar 02  LDAPv3 Replication Information Model I-D goes to WG Last Call
as
>Proposed Standard.
>
>Mar 02  LDAPv3 Replication Information Transport Protocol I-D goes to
WG
>Last Call as Proposed Standard.
>
>Mar 02  Re-evaluate Charter and Milestones.
>
>Chris Apple
>Program Manager - Integration Services
>United Messaging Inc.
><http://www.unitedmessaging.com>
><mailto:[email protected]> 
>(V) +1 610 425 2860
>

BEGIN:VCARD
VERSION:2.1
N:Apple;Christopher
FN:Christopher Apple (E-mail)
ORG:UMI
TITLE:Program Manager
TEL;WORK;VOICE:(610) 425-2860
TEL;HOME;VOICE:(215) 873-0850
TEL;CELL;VOICE:(610) 585-4241
TEL;WORK;FAX:(610) 425-6501
ADR;WORK:;;1161 McDermott Drive;West Chester;Pa.;19380;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:1161 McDermott Drive=0D=0AWest Chester, Pa. 19380=0D=0AUnited States of Amer=
ica
EMAIL;PREF;INTERNET:[email protected]
REV:20010925T181636Z
END:VCARD