Kurt,
there are many different WGs that use "REVISE" as well as many different
WGs that use "WG Last Call". Furthermore, this wording is consistent with
current practice.
I do agree with your suggested change to the last milestone.
regards,
John
-----Original Message-----
From: owner-ietf-ldup@xxxxxxxxxxxx
[mailto:owner-ietf-ldup@xxxxxxxxxxxx]On Behalf Of Kurt D. Zeilenga
Sent: Wednesday, November 07, 2001 10:25 PM
To: Christopher Apple
Cc: 'ietf-ldup@xxxxxxx'; 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 <christopher.apple@xxxxxxxxxxxxxxxxxxx>
>John Strassner <john.strassner@xxxxxxxxxxxxxx>
>
>Applications Area Director(s):
>
>Ned Freed <ned.freed@xxxxxxxxxxx>
>Patrik Faltstrom <paf@xxxxxxxxx>
>
>Applications Area Advisor:
>
>Patrik Faltstrom <paf@xxxxxxxxx>
>
>Mailing Lists:
>
>General Discussion:ietf-ldup@xxxxxxx
>To Subscribe: ietf-ldup-request@xxxxxxx
>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:christopher.apple@xxxxxxxxxxxxxxxxxxx>
>(V) +1 610 425 2860
>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature