RE: submission: draft-ietf-ldup-infomod-08.txt

"Chris Apple" <[email protected]> Wed, 22 Oct 2003 10:49:00 -0400
Newsgroups gmane.ietf.ldup
Organization DSI-Consulting, Inc.
Message-ID <001e01c398ab$a94fe180$65d68640@D7ST2111>
John and I are sorting through how to cycle/stage the last calls for
various documents.

Thanks for getting the document revised in time for the meeting.

Chris Apple - Principal Architect

DSI Consulting, Inc.

mailto:[email protected]

http://www.dsi-consulting.com

-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Ryan Moats
Sent: Wednesday, October 22, 2003 9:21 AM
To: [email protected]; [email protected]
Subject: submission: draft-ietf-ldup-infomod-08.txt


To the I-D editor:

Attached is draft-ietf-ldup-infomod-08.txt for the repository.

To LDUP:

Attached is draft-ietf-ldup-infomod-08.txt, ready for last call.  As 
such, we've extracted the
document changes section and place it here for reference.

John and Chris, please schedule a last call when you can.

Ryan Moats (for the authors)

===================Recent document changes
 

Changes in this version (-08)
 

-       Explicitly change replicaAgreement to not be a subentry.
-       Explicitly allow multiple replicaSubentries per replicaContext
-       Added replicaDN to examples.
-       Remove discussion of "Primary" replica.
-       Clarify information that must be present in all replicas 
(replicaSubentries) and what replicaAgreements and associated 
information must be present in a
replica.
 

Changes made to previous versions
 

-       Fixed OID values to have correct prefix: 2.16.840.1.113719.1.142
-       Fixed formatting to avoid strange single quote characters in 
text formatted file
-       Changed name of attrs1 and attrs2 to attrReplicationGroup1 and 
attrReplicationGroup2
-       Made obsolete timeScheduledSubentry and eventScheduledSubentry
-       Re-based replicaSubEntry and other object classes on subentry 
schema from draft-zeilenga-ldap-subentry-00.txt
-       Clarified that root DSE attribute replicaSubentries should be 
automatically updated on both add and delete of these entries
-       Made obsolete replicaSubEntry and replicaAgreementSubentry 
object classes
-       Defined replacement object classes replicaSubEntry2 and 
replicaAgreementSubentry2
-       Defined replicaEventSchedule and replicaTimeSchedule object 
classes and
associated attributes
-       Defined attributes that must appear in the server's root DSE 
entry as part of the LDUP information model
-       Many editorial fixes
-       Clarified the notion that the updateVector is a replicated 
attribute and thus, itself, has CSN information for its attribute values
-       Introduced the notion that replicaAgreementSubentry entries 
represent constraints to what is, by default, "immediate" replication 
session initiation
-       LDAP Schedule Subentry definition is defined.
-       LDAP Access Point removed in favor of just using the DN of the 
server holding the replica (so a new syntax isn't required).
-       LDAP Change Sequence Number syntax eliminated in favor of just 
calling it a CaseIgnoreString, so new comparison rules aren't required.
-       Deleted ldapSearchFilter definition from here.  Sparse replicas 
is deferred. Might sparse be supported for single-master configurations 
(read-only, of course).
-       Fractional are okay in multi-master configurations, but again, 
only on read-only replicas.
-       Changed the naming convention upper-lower case usage to look 
less weird.-       Consistency discussion
-       Schema document must clearly indicate that clients can and 
should inspect the replica subentries to understand the 
single-master/multi-master nature of
the naming context to which they're talking.
-       The paradigm change, to distributed data, needs to be 
exhaustively discussed in the profile documents.  How old applications 
which assume single-master
behave or misbehave in a multi-master environment is critical to make 
clear.  Draw examples from SMP pre-emptive programming practices, from 
DNS vs. host file models, etc.