From owner-ietf-ldup@mail.imc.org Thu Mar 1 15:42:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22155 for ; Thu, 1 Mar 2001 15:42:29 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id MAA19577 for ietf-ldup-bks; Thu, 1 Mar 2001 12:14:19 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA19567 for ; Thu, 1 Mar 2001 12:14:17 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA01422 for ; Thu, 1 Mar 2001 12:14:07 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id ABA03233; Thu, 1 Mar 2001 12:13:47 -0800 (PST) Message-Id: <4.3.2.7.2.20010301121243.034da5d8@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Mar 2001 12:13:43 -0800 To: ietf-ldup@imc.org From: John Strassner Subject: NEW meeting time just posted Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi LDUPers, seems that we've been moved to Monday evening (NOT my idea, so no flames please). Here's our slot and what we conflict with: 1930-2200 Evening Sessions APP ldup LDAP Duplication/Replication/Update Protocols WG GEN ipo IP over Optical WG INT idn Internationalized Domain Name WG OPS aaa Authentication, Authorization and Accounting WG OPS rmonmib Remote Network Monitoring WG RTG manet Mobile Ad-hoc Networks WG SEC ipsp IP Security Policy WG TSV tsvwg Transport Area WG regards, John From owner-ietf-ldup@mail.imc.org Thu Mar 1 15:49:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22402 for ; Thu, 1 Mar 2001 15:49:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA13290 for ietf-ldup-bks; Thu, 1 Mar 2001 10:44:45 -0800 (PST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA13281 for ; Thu, 1 Mar 2001 10:44:42 -0800 (PST) Received: from qsun.mt.att.com ([135.16.30.2]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f21IhO114514; Thu, 1 Mar 2001 13:43:24 -0500 (EST) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id NAA29135; Thu, 1 Mar 2001 13:43:22 -0500 Date: Thu, 1 Mar 2001 13:43:22 -0500 Message-Id: <200103011843.NAA29135@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: ietf-ldup@imc.org, internet-drafts@ietf.org Subject: New LDUP requirements draft Cc: rmoats@coreon.com, rweiser@digsigtrust.com, stokes@austin.ibm.com Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I-D editor: Please publish the attached I-D as draft-ietf-ldup-replica-req-07. LDUP: Thanks for all the comments. The authors have sat down and gone through John's action items (as well as other requests) and compiled a list of changes, along with the -07 draft. The following is John's issue list (rearranged with origin part # and internal issues lists) and our actions. >Part I Sub-issue 2: text describing objectives (in Section 3), clarity of text >Some people wondered if the text was clear enough in pointing out that LDUP >was providing "...interoperability between directories rather than between >their representations". I think that, in order to move on, it would be >helpful to have a brief sentence or two added to the draft that clarifies >this point. > >Action: add clarification that when LDUP is used to replicate information >that is interpreted by a directory server in ways that are not standardized >by LDAP, the results are unpredictable. > >Part III >First, Kurt recommends that "...the requirement I-D needs to state that >"application-level interoperability" will not be guaranteed by the >protocol, but may be resolvable by applicability statements (profiles). In >the end, "application interoperability" requires that all replicas >implement the same features in the same manner and this, IMO, is beyond the >scope of LDUP". > >Action: this seems very reasonable. Authors, please work with Kurt and >incorporate an addition to this effect in the requirements I-D. > >Part V, Issue 2: interoperability > >Kurt pointed out that interoperability may also be limited by servers that >implement semantics that implement optional features which LDAP defines >(such as subtypes). > >Action: this is a good point, please add this to the requirements I-D -We have rewritten the interoperability paragraph at the end of section three to address all of the above issues, as we see them as related. The current paragraph is worded to address the fact that interoperability is more than just the application level. >Part I Sub-issue 4: locking >Locking is not germane to the requirements draft. It is up to the >architecture and other drafts, as required, to address locking. However, >several people have suggested that if developers attempt to create their >own locking or other similar control mechanisms, the requirements draft >should state that they do so at their own peril when operating against >directories supporting LDUP. I agree. > >Action: a brief explanatory note pointing this out should be added to the >requirements I-D. -A quorum of the authors of both the requirement and profile I-Ds feel that this is incorrect. Discussion of locking is aimed at the application developer, not at replication, and so should be properly included in the profile I-D. The profile I-D authors are willing to add this to the profile I-D >Part I Sub-issue 6: noting unsuitability of LDUP for environments with >"high rate of change" >While everyone agrees with this, no one could come up with a reasonable >definition of "high rate of change". However, there is consensus that this >should not be specified in the requirements draft, but rather in other >drafts (architecture and profile are obvious candidates). A suggestion was >to change in section B.5.5 from "They are changing the data at the same >time" to "They are changing the data before previous changes have replicated". > >Action: change in section B.5.5 from "They are changing the data at the >same time" to "They are changing the data before previous changes have >replicated". -So changed >Part I Sub-issue 7: removal of P6 (atomicity information) >We've had one argument and one reply which said "yes it does" without >technical justification. The request centered around replicating and >converging state, and defined atomicity in an application-specific sense. >While I don't believe that the requirements draft was concerned with >application-specific atomicity information, I do think that this needs a >response, and likely better definition of what, specifically, propagating >atomicity information means. > >Action: This requirement needs to be explained and justified in the I-D. >The I-D should answer the question of whether it is propagating end-state >or propagating a set of operations required to replicate that end-state, >and WHY it is doing so. -We feel that discussion of propagating end state vs. changes is about implementation. Rather, P6 (now P7 due to other changes) has been rewritten to explicitly require propagation of atomicity of LDAP operations as defined in RFC 2251. We feel it is now self justifying. >Part II Issue: >Kurt is objecting to the introduction of LDUP-specific terminology. He's >worried that many terms defined in the requirements I-D redefine many >existing LDAP/X.500 >terms, and wants to see existing LDAP/X.500 terminology used wherever >possible. > >However, the problem is that Kurt has not identified the specific terms >that he is objecting to. > >Actions: > 1. Kurt, please delineate the terms that you feel are being redefined. > 2. Authors, please respond, indicating how the I-D will change. > 3. The WG will evaluate the response. -As a result of issues Kurt has raised, we have replaced naming context with "replication base entry". However, we disagree that "area of replication" here is different from X.525 replicated area and have indicated this in the definition of "area of replication" -We have deprecated "updateable replicas" where used. >Second, Kurt notes that the I-D's Security Considerations section says that >specific issues are being addressed in RFC 2820 (and the work in progress) >when this is clearly not the case. > >Action: Authors, please work with Kurt and fix this. -We have clarified the last sentence of the security section to explicitly note the ACL work ongoing in LDAPEXT. >Part IV >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. -Kurt proposed some text in a separate piece of email and after review and some rearrangement, the text is acceptable to the authors as requirements G9, G10, G11. With these requirements, we have removed the partial example list in the last paragraph of section 3 as discussion of that paragraph on the mailing list has not led to working group consensus. >Part V > >Issue 1: models and atomicity > >There was disagreement in how to describe this. Kurt thought that the extra >functionality that was provided by Model 1 wasn't adequately expressed. But >the authors didn't like his wording changes because they thought that model >2 would be able to support atomicity, at least in some limited cases like >single-master.g > >Action: I didn't see any other support from the WG, but this does seem >reasonable. Therefore, could Kurt please get with the authors and agree to >mutually acceptable wording? -We have added a statement that model 1 may ease support of atomicity in multi-master systems Additional changes -We have reworded M3 to correspond to Steven Legg's comments. -Section A.10 has been modified to be self consistent. -We have replaced "replica-ring" with "replica-group" to not imply any topology. -Additional changes per previous email to the list (http://www.imc.org/ietf-ldup/mail-archive/msg00884.html and http://www.imc.org/ietf-ldup/mail-archive/msg00881.html) are included in this version. -As a result of some of the above changes, the "P" requirements were renumbered. Having made technical changes to the requirements, we request that (without additional changes) another WG last call be declared on 3/26. Ryan, Russ, Rick, Ellen --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Internet-Draft Ellen J. Stokes LDAP Duplication/Replication/Update Tivoli Systems Protocols WG Russel F. Weiser Intended Category: Informational Digital Signature Trust Expires: September 2001 Ryan D. Moats Coreon, Inc. Richard V. Huber AT&T Laboratories March 2001 LDAPv3 Replication Requirements draft-ietf-ldup-replica-req-07.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt. The list of Internet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. Stokes, et al Expires September 2001 [Page 1] Internet-Draft LDAPv3 Replication Requirements March 2001 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Stokes, et al Expires February 2001 [Page 2] Internet-Draft LDAPv3 Replication Requirements March 2001 Table of Contents 1 Introduction.......................................................4 2 Terminology........................................................4 3 The Models.........................................................7 4 Requirements.......................................................8 4.1 General.........................................................8 4.2 Model...........................................................9 4.3 Protocol.......................................................10 4.4 Schema.........................................................11 4.5 Single Master..................................................11 4.6 Multi-Master...................................................11 4.7 Administration and Management..................................12 4.8 Security.......................................................13 5 Security Considerations...........................................13 6 Acknowledgements..................................................13 7 References........................................................13 A.APPENDIX A - Usage Scenarios......................................15 A.1.Extranet Example...............................................15 A.2.Consolidation Example..........................................15 A.3.Replication Heterogeneous Deployment Example...................15 A.4.Shared Name Space Example......................................16 A.5.Supplier Initiated Replication.................................16 A.6.Consumer Initiated Replication.................................16 A.7.Prioritized attribute replication..............................17 A.8.Bandwidth issues...............................................17 A.9.Interoperable Administration and Management....................17 A.10.Enterprise Directory Replication Mesh.........................18 A.11.Failure of the Master in a Master-Slave Replicated Directory..18 A.12.Failure of a Directory Holding Critical Service Information...19 B.APPENDIX B - Rationale............................................19 B.1.Meta-Data Implications.........................................19 B.2.Order of Transfer for Replicating Data.........................19 B.3.Schema Mismatches and Replication..............................20 B.4.Detecting and Repairing Inconsistencies Among Replicas.........21 B.5.Some Test Cases for Conflict Resolution in Multi-Master Replication........................................................22 B.6.Data Privacy During Replication................................26 B.7.Failover in Single-Master Systems..............................26 B.8.Including Operational Attributes in Atomic Operations..........27 Authors' Addresses..................................................28 Full Copyright Statement............................................28 Stokes, et al Expires February 2001 [Page 3] Internet-Draft LDAPv3 Replication Requirements March 2001 1 Introduction Distributing directory information throughout the network provides a two-fold benefit: (1) it increases the reliability of the directory through fault tolerance, and (2) it brings the directory content closer to the clients using the data. LDAP's success as an access protocol for directory information is driving the need to distribute LDAP directory content within the enterprise and Internet. Currently, LDAP does not define a replication mechanism, and mentions LDAP shadow servers (see [RFC2251]) in passing. A standard mechanism for directory replication in a multi-vendor environment is critical to the continued success of LDAP in the market place. This document sets out the requirements for replication between multiple LDAP servers. While RFC 2251 and RFC 2252 [RFC2252] set forth the standards for communication between LDAP clients and servers there are additional requirements for server-to-server communication. Some of these are covered here. This document first introduces the terminology to be used, then presents the different replication models being considered. Requirements follow, along with security considerations. The reasoning that leads to the requirements is presented in the Appendices. This was done to provide a clean separation of the requirements from their justification. 2 Terminology The following terms are used in this document: Area of replication - A whole or portion of a Directory Information Tree (DIT) that makes up a distinct unit of data to be replicated. An area of replication is defined by a replication base entry and includes all or some of the depending entries contained therein on a single server. It divides directory data into partitions whose propagation behavior may be independently configured from other partitions. Areas of replication may overlap or be nested. Also known as a "replicated area" in X.525 [X.525]. Atomic operation - A set of changes to directory data which the LDAP standards guarantee will be treated as a unit; all changes will be made or all the changes will fail. Atomicity Information - Information about atomic operations passed as part of replication. Stokes, et al Expires February 2001 [Page 4] Internet-Draft LDAPv3 Replication Requirements March 2001 Conflict - A situation that arises when changes are made to the same directory data on different directory servers before replication can synchronize the data on the servers. When the servers do synchronize, they have inconsistent data - a conflict. Conflict resolution - Deterministic procedures used to resolve change information conflicts that may arise during replication. Critical OID - Attributes or object classes defined in the replication agreement as being critical to the operation of the system. Changes affecting critical OIDs cause immediate initiation of a replica cycle. An example of a critical OID might be a password or certificate. Fractional replication - The capability to filter a subset of attributes for replication. Incremental Update - An update that contains only those attributes or entries that have changed. Master Replica - A replica that may be directly updated via LDAP operations. In a Master-Slave Replication system, the Master Replica is the only directly updateable replica in the replica-group. Master-Slave, or Single Master Replication - A replication model that assumes only one server, the master, allows LDAP write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. Meta-Data - Data collected by the replication system that describes the status/state of replication. Multi-Master Replication - A replication model where entries can be written and updated on any of several master replica copies without requiring communication with other master replicas before the write or update is performed. Replication base entryOne-way Replication - The process of synchronization in a single direction where the authoritative source information is provided to a replica. Partial Replication - Partial Replication is Fractional Replication, Sparse Replication, or both. Propagation Behavior - The behavior of the synchronization process between a consumer and a supplier. Stokes, et al Expires February 2001 [Page 5] Internet-Draft LDAPv3 Replication Requirements March 2001 Replica - An instance of an area of replication on a server.replication base entry Replica-Group - The servers that hold instances of a particular area of replication. A server may be part of several replica-groups. Replica (or Replication) Cycle - The interval during which update information is exchanged between two or more replicas. It begins during an attempt to push data to, or pull data from, another replica or set of replicas, and ends when the data has successfully been exchanged or an error is encountered. Replication - The process of synchronizing data distributed across directory servers and rectifying update conflicts. Replication Agreement - A collection of information describing the parameters of replication between two or more servers in a replica- group. Replication Base Entry - The distinguished name of the root vertex of a replicated area. Replication Initiation Conflict - A Replication Initiation Conflict is a situation where two sources want to update the same replica at the same time. Replication Session - A session set up between two servers in a replica-group to pass update information as part of a replica cycle. Slave (or Read-Only) Replica - A replica that cannot be directly updated via LDAP requests. Changes may only be made via replication from a master replica. Read-only replicas may occur in both single- and multi-master systems. Sparse Replication - The capability to filter some subset of entries (other than a complete collection) of a replication base entry for replication. Topology - The shape of the directed graph describing the relationships between replicas. Two-way Replication - The process of synchronization where change information flows bi-directionally between two replicas. Update Propagation - Protocol-based process by which directory replicas are reconciled. Stokes, et al Expires February 2001 [Page 6] Internet-Draft LDAPv3 Replication Requirements March 2001 3 The Models The objective is to provide an interoperable, LDAP v3 directory synchronization protocol that is simple, efficient and flexible; supporting both multi-master and master-slave replication. The protocol must meet the needs of both the Internet and enterprise environments. There are five data consistency models. Model 1: Transactional Consistency -- Environments that exhibit all four of the ACID properties (Atomicity, Concurrency, Independence, Durability) [ACID]. Model 2: Eventual (or Transient) Consistency -- Environments where definite knowledge of the topology is provided through predetermined replication agreements. Examples include X.500 Directories (the X.500 model is single-master only) [X.501, X.525], Bayou [XEROX], and NDS (Novell Directory Services) [NDS]. In this model, every update propagates to every replica that it can reach via a path of stepwise eventual connectivity. Model 3: Limited Effort Eventual (or Probabilistic) Consistency -- Environments that provide a statistical probability of convergence with knowledge of topology. An example is the Xerox Clearinghouse [XEROX]. This model is similar to "Eventual Consistency", except where replicas may purge updates. Purging drops propagation changes when some replica time boundary is exceeded, thus leaving some changes replicated to only a portion of the topology. Transactional consistency is not preserved, though some weaker constraints on consistency are available. Model 4: Loosest Consistency -- Environments where information is provided from an opportunistic or simple cache until stale. Complete knowledge of topology may not be shared among all replicas. Model 5: Ad hoc -- A copy of a data store where no follow up checks are made for the accuracy/freshness of the data. Consistency models 1, 2 and 3 involve the use of prearranged replication agreements among servers. While model 1 may simplify support for atomicity in multi-master systems, the added complexity of the distributed 2-phase commit required for Model 1 is significant; therefor, model 1 will not be considered at this time. Models 4 and 5 involve unregistered replicas that "pull" updates from another directory server without that server's knowledge. These models violate a directory's security policies. Stokes, et al Expires February 2001 [Page 7] Internet-Draft LDAPv3 Replication Requirements March 2001 Models 2 and 3 illustrate two replication scenarios that must be handled: policy configuration through security management parameters (model 2), and hosting relatively static data and address information as in white-pages applications (model 3). Therefore, replication requirements are presented for models 2 and 3. Interoperability among directories using LDUP replication may be limited for implementations that add semantics beyond those specified by the LDAP core documents (RFC 2251-2256, 2829, 2830). 4 Requirements 4.1 General G1. LDAP Replication MUST support models 2 (Eventual Consistency) and 3 (Limited Effort Eventual Consistency) above. G2. LDAP Replication SHOULD NOT preclude support for model 1 (Transactional Consistency) in the future. G3. LDAP replication SHOULD have minimal impact on both the system and network performance. G4. The LDAP Replication Standard SHOULD NOT limit the replication transaction rate. G5. The LDAP replication standard SHOULD NOT limit the size of an area of replication or a replica. G6. Meta-data collected by the LDAP replication mechanism MUST NOT grow without bound. G7. All policy and state data pertaining to replication MUST be accessible via LDAP. G8. The LDAP replication standard SHOULD NOT preclude support of Transactional Consistency (model 1). G9. LDAP replication MUST be capable of replicating the following: - all userApplication attribute types - all directoryOperation and distributedOperation attribute types defined in the LDAP "core" specifications (RFC 2251- 2256, 2829-2830) - attribute subtypes Stokes, et al Expires February 2001 [Page 8] Internet-Draft LDAPv3 Replication Requirements March 2001 - attribute description options (e.g. ";binary" and Language Tags) G10. LDAP replication SHOULD support replication of directoryOperation and distributedOperation attribute types defined in standards track LDAP extensions. Future standards track specifications MUST include a "Replication Considerations" section which indicates how and whether the new feature operates in a replicated environment. G11. LDAP replication MUST NOT support replication of dsaOperation attribute types as such attributes are DSA-specific. 4.2 Model M1. The model MUST support the following triggers for initiation of a replica cycle: a) A configurable set of scheduled times b) Periodically, with a configurable period between replica cycles c) A configurable maximum amount of time between replica cycles d) A configurable number of accumulated changes e) Change in the value of a critical OID f) As the result of an automatic rescheduling after a replication initiation conflict g) A manual request for immediate replication With the exception of manual request, the specific trigger(s) and related parameters for a given server MUST be identified in a well- known place defined by the standard, e.g. the Replication Agreement(s). M2. The replication model MUST support both master-slave and multi- master relationships. M3. An attribute in an entry must eventually converge to the same set of values in every replica holding that entry. M4. LDAP replication MUST encompass schema definitions, attribute names and values, access control information, knowledge information, and name space information. M5. LDAP replication MUST NOT require all copies of the replicated information to be complete copies of the replicated object. The model MUST support Partial Replicas. M6. The determination of which OIDs are critical MUST be configurable in the replication agreement. Stokes, et al Expires February 2001 [Page 9] Internet-Draft LDAPv3 Replication Requirements March 2001 M7. The parameters of the replication process among the members of the replica-group, including access parameters, necessary authentication credentials, and assurances of confidentiality (encryption) MUST be defined in a standard location (e.g. the replication agreements). M8. The replication agreements SHOULD accommodate multiple servers receiving the same area of replication under a single predefined agreement. M9. LDAP replication MUST provide scalability to both enterprise and Internet environments, e.g. an LDAP server must be able to provide replication services to replicas within an enterprise as well as across the Internet. M10. While different directory implementations can support different/extended schema, schema mismatches between two replicating servers MUST be handled. One way of handling such mismatches might be to raise an error condition. M11. There MUST be a facility that can update, or totally refresh, a replica-group from a standard data format, such as LDIF format [RFC2849]. 4.3 Protocol P1. The replication protocol MUST provide for recovery and rescheduling of a replication session due to replication initiation conflicts (e.g. consumer busy replicating with other servers) and or loss of connection (e.g. supplier cannot reach a replica). P2. LDUP replication SHOULD NOT send an update to a consumer if the consumer has previously acknowledged that update. P3. An update received by a consumer more than once MUST NOT produce a different outcome than if the update were received only once. P4. The LDAP replication protocol MUST allow for full update to facilitate replica initialization and reset loading utilizing a standardized format such as LDIF [RFC2849] format. P5. Incremental replication MUST be allowed. P6. The replication protocol MUST allow either a master or slave replica to initiate the replication process. P7. The protocol MUST preserve atomicity of LDAP operations as defined in RFC2251 [RFC2251]. Stokes, et al Expires February 2001 [Page 10] Internet-Draft LDAPv3 Replication Requirements March 2001 P8. The protocol MUST support a mechanism to report schema mismatches between replicas discovered during a replication session. 4.4 Schema SC1. A standard way to determine what replicas are held on a server MUST be defined. SC2. A standard schema for representing replication agreements MUST be defined. SC3. The semantics associated with modifying the attributes of replication agreements MUST be defined. SC4. A standard method for determining the location of replication agreements MUST be defined. SC5. A standard schema for publishing state information about a given replica MUST be defined. SC6. A standard method for determining the location of replica state information MUST be defined. SC7. It MUST be possible for appropriately authorized administrators, regardless of their network location, to access replication agreements in the DIT. SC8. Replication agreements of all servers containing replicated information MUST be accessible via LDAP. SC9. An entry MUST be uniquely identifiable throughout its lifetime. 4.5 Single Master SM1. A Single Master system SHOULD provide a fast method of promoting a slave replica to become the master replica. SM2. The master replica in a Single Master system SHOULD send all changes to read-only replicas in the order in which the master applied them. 4.6 Multi-Master MM1. The replication protocol SHOULD NOT saturate the network with redundant or unnecessary entry replication. Stokes, et al Expires February 2001 [Page 11] Internet-Draft LDAPv3 Replication Requirements March 2001 MM2. The initiator MUST be allowed to determine whether it will become a consumer or supplier during the synchronization startup process. MM3. During a replica cycle, it MUST be possible for the two servers to switch between the consumer and supplier roles. MM4. When multiple master replicas want to start a replica cycle with the same replica at the same time, the model MUST have an automatic and deterministic mechanism for resolving or avoiding replication initiation conflict. MM5. Multi-master replication MUST NOT lose information during replication. If conflict resolution would result in the loss of directory information, the replication process MUST store that information, notify the administrator of the nature of the conflict and the information that was lost, and provide a mechanism for possible override by the administrator. MM6. Multi-master replication MUST support convergence of the values of attributes and entries. Convergence may result in an event as described in MM5. MM7. Multi-master conflict resolution MUST NOT depend on the in-order arrival of changes at a replica to assure eventual convergence. 4.7 Administration and Management AM1. Replication agreements MUST allow the initiation of a replica cycle to be administratively postponed to a more convenient period. AM2. Each copy of a replica MUST maintain audit history information of which servers it has replicated with and which servers have replicated with it. AM3. Access to replication agreements, topologies, and policy attributes MUST be provided through LDAP. AM4. The capability to check the differences between two replicas for the same information SHOULD be provided. AM5. A mechanism to fix differences between replicas without triggering new replica cycles SHOULD be provided. AM6. The sequence of updates to access control information (ACI)_and the data controlled by that ACI MUST be maintained by replication. Stokes, et al Expires February 2001 [Page 12] Internet-Draft LDAPv3 Replication Requirements March 2001 AM7. It MUST be possible to add a 'blank' replica to a replica-group, and force a full update from (one of) the Master(s), for the purpose of adding a new directory server to the system. AM8. Vendors SHOULD provide tools to audit schema compatibility within a potential replica-group. 4.8 Security S1. During initiation of a replication session, authentication and verification of authorization of both the replica and the source directory MUST be allowed before any data is transferred. S2. The transport for LDAP synchronization MUST permit assurance of the integrity and privacy of all data transferred. S3. To promote interoperability, there MUST be a mandatory-to- implement data privacy mechanism. S4. The transport for administrative access MUST permit assurance of the integrity and privacy of all data transferred. 5 Security Considerations This document includes security requirements (listed in section 4.8 above) for the replication model and protocol. As noted in Section 3, security may be impacted when replicating among servers that implement non-standard extensions to basic LDAP semantics. Access control is one common case which affects security; work to address this issue is going on in LDAPEXT as documented in RFC 2820 [RFC2820]. 6 Acknowledgements This document is based on input from IETF members interested in LDUP Replication. 7 References [ACID] T. Haerder, A. Reuter, "Principles of Transaction-Oriented Database Recovery", Computing Surveys, Vol. 15, No. 4 (December 1983), pp. 287-317. [NDS] Novell, "NDS Technical Overview", 104-000223-001, http://developer.novell.com/ndk/doc/docui/index.htm#../ndslib/dsov_enu/ data/h6tvg4z7.htm, September, 2000. Stokes, et al Expires February 2001 [Page 13] Internet-Draft LDAPv3 Replication Requirements March 2001 [RFC2119] S. Bradner, "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory Access Protocol", RFC 2251, December 1997. [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [RFC2253] S. Kille, M. Wahl, and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [RFC2254] T. Howes, "The String Representation of LDAP Search Filters", RFC 2254, December 1997. [RFC2255] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December 1997. [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. [RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access Control Requirements for LDAP", RFC 2820, May 2000. [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. "Authentication Methods for LDAP", RFC 2829, May 2000. [RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000. [RFC2849] Gordon Good, "The LDAP Data Interchange Format (LDIF)", RFC 2849, June 2000. [X.501] ITU-T Recommendation X.501 (1993), | ISO/IEC 9594-2: 1993, Information Technology - Open Systems Interconnection - The Directory: Models. [X.525] ITU-T Recommendation X.525 (1997), | ISO/IEC 9594-9: 1997, Information Technology - Open Systems Interconnection - The Directory: Replication. [XEROX] Hauser, C. "Managing update conflicts in Bayou, a weakly connected replicated storage system". Palo Alto, CA: Xerox PARC, Computer Science Laboratory; 1995 August; CSL-95-4. [CSL-95-04] Stokes, et al Expires February 2001 [Page 14] Internet-Draft LDAPv3 Replication Requirements March 2001 A. APPENDIX A - Usage Scenarios The following directory deployment examples are intended to validate our replication requirements. A heterogeneous set of directory implementations is assumed for all the cases below. This material is intended as background; no requirements are presented in this Appendix. A.1. Extranet Example A company has a trading partner with whom it wishes to share directory information. This information may be as simple as a corporate telephone directory, or as complex as an extranet workflow application. For performance reasons, the company wishes to place a replica of its directory within the Partner Company, rather than exposing its directory beyond its firewall. The requirements that follow from this scenario are: . One-way replication, single mastered. . Authentication of clients. . Common access control and access control identification. . Secure transmission of updates. . Selective attribute replication (Fractional Replication), so that only partial entries can be replicated. A.2. Consolidation Example Company A acquires company B. Each company has an existing directory. During the transition period, as the organizations are merged, both directory services must coexist. Company A may wish to attach company B's directory to its own. The requirements that follow from this scenario are: . Multi-Master replication. . Common access control model. Access control model identification. . Secure transmission of updates. . Replication between DITs with potentially differing schema. A.3. Replication Heterogeneous Deployment Example An organization may choose to deploy directory implementations from multiple vendors, to enjoy the distinguishing benefits of each. Stokes, et al Expires February 2001 [Page 15] Internet-Draft LDAPv3 Replication Requirements March 2001 In this case, multi-master replication is required to ensure that the multiple replicas of the DIT are synchronized. Some vendors may provide directory clients, which are tied to their own directory service. The requirements that follow from this scenario are: . Multi-Master replication . Common access control model and Access control model identification. . Secure transmission of updates. . Replication among DITs with potentially differing schemas. A.4. Shared Name Space Example Two organizations may choose to cooperate on some venture and need a shared name space to manage their operation. Both organizations will require administrative rights over the shared name space. The requirements that follow from this scenario are: . Multi-Master replication. . Common access control model and Access control model identification. . Secure transmission of updates. A.5. Supplier Initiated Replication This is a single master environment that maintains a number of replicas of the DIT by pushing changes based on a defined schedule. The requirements that follow from this scenario are: . Single-master environment. . Supplier-initiated replication. . Secure transmission of updates. A.6. Consumer Initiated Replication Again a single mastered replication topology, but the slave replica initiates the replication exchange rather than the master. An example of this is a replica that resides on a laptop computer that may run disconnected for a period of time. The requirements that follow from this scenario are: . Single-master environment. . Consumer initiated replication. . Open scheduling (anytime). Stokes, et al Expires February 2001 [Page 16] Internet-Draft LDAPv3 Replication Requirements March 2001 A.7. Prioritized attribute replication The password attribute can provide an example of the requirement for prioritized attribute replication. A user is working in Utah and the administrator resides in California. The user has forgotten his password. So the user calls or emails the administrator to request a new password. The administrator provides the updated password (a change). Under normal conditions, the directory replicates to a number of different locations overnight. But corporate security policy states that passwords are critical and the new value must be available immediately (e.g. shortly) after any change. Replication needs to occur immediately for critical attributes/entries. The requirements that follow from this scenario are: . Incremental replication of changes. . Immediate replication on change of certain attributes. . Replicate based on time/attribute semantics. A.8. Bandwidth issues The replication of Server (A) R/W replica (a) in Kathmandu is handled via a dial up phone link to Paris where server (B) R/W replica of (a) resides. Server (C) R/W replica of (a) is connected by a T1 connection to server (B). Each connection has a different performance characteristic. The requirements that follow from this scenario are: . Minimize repetitive updates when replicating from multiple replication paths. . Incremental replication of changes. . Provide replication cycles to delay and/or retry when connections cannot be reached. . Allowances for consumer initiated or supplier initiated replication. A.9. Interoperable Administration and Management The administrator with administrative authority of the corporate directory which is replicated by numerous geographically dispersed LDAP servers from different vendors notices that the replication process is not completing correctly as the change log is continuing to grow and/or error message informs him. The administrator uses his $19.95 RepCo LDAP directory replication diagnostics tools to look at Root DSE replica knowledge on server 17 and determines that server 42 made by Stokes, et al Expires February 2001 [Page 17] Internet-Draft LDAPv3 Replication Requirements March 2001 LDAP'RUS Inc. is not replicating properly due to an Object conflict. Using his Repco Remote repair tools he connects to server 42 and resolves the conflict on the remote server. The requirements that follow from this scenario are: . Provides replication audit history. . Provisions for managing conflict resolution. . Provide LDAP access to predetermined agreements, topology and policy attributes. . Provide operations for comparing replica's content for validity. . Provide LDAP access to status and audit information. A.10. Enterprise Directory Replication Mesh A Corporation builds a mesh of directory servers within the enterprise utilizing LDAP servers from various vendors. Five servers are holding the same area of replication. The predetermined replication agreement(s) for the enterprise mesh are under a single management, and the security domain allows a single predetermined replication agreement to manage the 5 servers' replication. The requirements that follow from this scenario are: . One predefined replication agreement that manages a single area of replication that is held on numerous servers. . Common support of replication management knowledge across vendor implementation. . Rescheduling and continuation of a replication cycle when one server in a replica-group is busy and/or unavailable. A.11. Failure of the Master in a Master-Slave Replicated Directory A company has a corporate directory that is used by the corporate email system. The directory is held on a mesh of servers from several vendors. A corporate relocation results in the closing of the location where the master copy of the directory is located. Employee information (such as mailbox locations and employee certificate information) must be kept up to date or mail cannot be delivered. The requirements that follow from this scenario are: . An existing slave replica must be "promote-able" to become the new master. . The "promotion" must be done without significant downtime, since updates to the directory will continue. Stokes, et al Expires February 2001 [Page 18] Internet-Draft LDAPv3 Replication Requirements March 2001 A.12. Failure of a Directory Holding Critical Service Information An ISP uses a policy management system that uses a directory as the policy data repository. The directory is replicated in several different sites on different vendors' products to avoid single points of failure. It is imperative that the directory be available and be updateable even if one site is disconnected from the network. Changes to the data must be traceable, and it must be possible to determine how changes made from different sites interacted. The requirements that follow from this scenario are: . Multi-master replication . Ability to reschedule replication sessions . Support for manual review and override of replication conflict resolution B. APPENDIX B - Rationale This Appendix gives some of the background behind the requirements. It is included to help the protocol designers understand the thinking behind some of the requirements and to present some of the issues that should be considered during design. With the exception of section B.8, which contains a suggested requirement for the update to RFC 2251, this Appendix does not state any formal requirements. B.1. Meta-Data Implications Requirement G4 states that meta-data must not grow without bound. This implies that meta-data must, at some point, be purged from the system. This, in turn, raises concerns about stability. Purging meta-data before all replicas have been updated may lead to incomplete replication of change information and inconsistencies among replicas. Therefore, care must be taken setting up the rules for purging meta- data from the system while still ensuring that meta-data will not grow forever. B.2. Order of Transfer for Replicating Data Situations may arise where it would be beneficial to replicate data out-of-order (e.g. send data to consumer replicas in a different order than it was processed at the supplier replica). One such case might occur if a large bulk load was done on the master server in a single- master environment and then a single change to a critical OID (a password change, for example) was then made. Rather than wait for all the bulk data to be sent to the replicas, the password change might be moved to the head of the queue and be sent before all the bulk data was Stokes, et al Expires February 2001 [Page 19] Internet-Draft LDAPv3 Replication Requirements March 2001 transferred. Other cases where this might be considered are schema changes or changes to critical policy data stored in the directory. While there are practical benefits to allowing out-of-order transfer, there are some negative consequences as well. Once out-of-order transfers are permitted, all receiving replicas must be prepared to deal with data and schema conflicts that might arise. As an example, assume that schema changes are critical and must be moved to the front of the replication queue. Now assume that a schema change deletes an attribute for some object class. It is possible that some of the operations ahead of the schema change in the queue are operations to delete values of the soon-to-be-deleted attribute so that the schema change can be done with no problems. If the schema change moves to the head of the queue, the consumer servers might have to delete an attribute that still has values, and then receive requests to delete the values of an attribute that is no longer defined. In the multi-master case, similar situations can arise when simultaneous changes are made to different replicas. Thus, multi- master systems must have conflict resolution algorithms in place to handle such situations. But in the single-master case conflict resolution is not needed unless the master is allowed to send data out- of-order. This is the reasoning behind requirement SM2, which recommends that data always be sent in order in single-master replication. Note that even with this restriction, the concept of a critical OID is still useful in single-master replication. An example of its utility can be found in section A.7. B.3. Schema Mismatches and Replication Multi-vendor environments are the primary area of interest for LDAP replication standards. Some attention must thus be paid to the issue of schema mismatches, since they can easily arise when vendors deliver slightly different base schema with their directory products. Even when both products meet the requirements of the standards [RFC2252], the vendors may have included additional attributes or object classes with their products. When two different vendor's products attempt to replicate, these additions can cause schema mismatches. Another potential cause of schema mismatches is discussed in section A.3. There are only a few possible responses when a mismatch is discovered. . Raise an error condition and ignore the data. This should always be allowed and is the basis for requirement P8 and the comment on M10. Stokes, et al Expires February 2001 [Page 20] Internet-Draft LDAPv3 Replication Requirements March 2001 . Map/convert the data to the form required by the consuming replica. A system may choose this course; requirement M10 is intended to allow this option. The extent of the conversion is up to the implementation; in the extreme it could support use of the replication protocol in meta-directories. . Quietly ignore (do not store on the consumer replica and do not raise an error condition) any data that does not conform to the schema at the consumer. Requirement M10 is intended to exclude the last option. Requirement AM8 suggests that vendors should provide tools to help discover schema mismatches when replication is being set up. But schema will change after the initial setup, so the replication system must be prepared to handle unexpected mismatches. Normal IETF practice in protocol implementation suggests that one be strict in what one sends and be flexible in what one receives. The parallel in this case is that a supplier should be prepared to receive an error notification for any schema mismatch, but a consumer may choose to do a conversion instead. The other option that can be considered in this situation is the use of fractional replication. If replication is set up so only the common attributes are replicated, mismatches can be avoided. One additional consideration here is replication of the schema itself. M4 requires that it be possible to replicate schema. If a consumer replica is doing conversion, extreme care should be taken if schema elements are replicated since some attributes are intended to have different definitions on different replicas. For fractional replication, the protocol designers and implementors should give careful consideration to the way they handle schema replication. Some options for schema replication include: . All schema elements are replicated. . Schema elements are replicated only if they are used by attributes that are being replicated. . Schema are manually configured on the servers involved in fractional replication; schema elements are not replicated via the protocol. B.4. Detecting and Repairing Inconsistencies Among Replicas Despite the best efforts of designers, implementors, and operators, inconsistencies will occasionally crop up among replicas in production directories. Tools will be needed to detect and to correct these inconsistencies. Stokes, et al Expires February 2001 [Page 21] Internet-Draft LDAPv3 Replication Requirements March 2001 A special client may accomplish detection through periodic comparisons of replicas. This client would typically read two replicas of the same replication base entry and compare the answers, possibly by BINDing to each of the two replicas to be compared and reading them both. In cases where the directory automatically reroutes some requests (e.g. chaining), mechanisms to force access to a particular replica should be supplied. Alternatively, the server could support a special request to handle this situation. A client would invoke an operation at some server. It would cause that server to extract the contents from some other server it has a replication agreement with and report the differences back to the client as the result If an inconsistency is found, it needs to be repaired. To determine the appropriate repair, the administrator will need access to the replication history to figure out how the inconsistency occurred and what the correct repair should be. When a repair is made, it should be restricted to the replica that needs to be fixed; the repair should not cause new replication events to be started. This may require special tools to change the local data store without triggering replication. Requirements AM2, AM4, and AM5 address these needs. B.5. Some Test Cases for Conflict Resolution in Multi-Master Replication Use of multi-master replication inevitably leads to the possibility that incompatible changes will be made simultaneously on different servers. In such cases, conflict resolution algorithms must be applied. As a guiding principle, conflict resolution should avoid surprising the user. One way to do this is to adopt the principle that, to the extent possible, conflict resolution should mimic the situation that would happen if there were a single server where all the requests were handled. While this is a useful guideline, there are some situations where it is impossible to implement. Some of these cases are examined in this section. In particular, there are some cases where data will be "lost" in multi-master replication that would not be lost in a single-server configuration. Stokes, et al Expires February 2001 [Page 22] Internet-Draft LDAPv3 Replication Requirements March 2001 In the examples below, assume that there are three replicas, A, B, and C. All three replicas are updateable. Changes are made to replicas A and B before replication allows either replica to see the change made on the other. In discussion of the multi-master cases, we assume that the change to A takes precedence using whatever rules are in force for conflict resolution. B.5.1. Create-Create A user creates a new entry with distinguished name DN on A. At the same time, a different user adds an entry with the same distinguished name on B. In the single-server case, one of the create operations would have occurred before the other, and the second request would have failed. In the multi-master case, each create was successful on its originating server. The problem is not detected until replication takes place. When a replication request to create a DN that already exists arrives at one of the servers, conflict resolution is invoked. (Note that the two requests can be distinguished even though they have the same DN because every entry has some sort of unique identifier per requirement SC9.) As noted above, in these discussions we assume that the change from replica A has priority based on the conflict resolution algorithm. Whichever change arrives first, requirement MM6 says that the values from replica A must be those in place on all replicas at the end of the replication cycle. Requirement MM5 states that the system cannot quietly ignore the values from replica B. The values from replica B might be logged with some notice to the administrators, or they might be added to the DIT with a machine generated DN (again with notice to the administrators). If they are stored with a machine generated DN, the same DN must be used on all servers in the replica-group (otherwise requirement M3 would be violated). Note that in the case where the entry in question is a container, storage with a machine generated DN provides a place where descendent entries may be stored if any descendents were generated before the replication cycle was completed. In any case, some mechanism must be provided to allow the administrator to reverse the conflict resolution algorithm and force the values originally created on B into place on all replicas if desired. B.5.2. Rename-Rename Stokes, et al Expires February 2001 [Page 23] Internet-Draft LDAPv3 Replication Requirements March 2001 On replica A, an entry with distinguished name DN1 is renamed to DN. At the same time on replica B, an entry with distinguished name DN2 is renamed to DN. In the single-server case, one rename operation would occur before the other and the second would fail since the target name already exists. In the multi-master case, each rename was successful on its originating server. Assuming that the change on A has priority in the conflict resolution sense, DN will be left with the values from DN1 in all replicas and DN1 will no longer exist in any replica. The question is what happens to DN2 and its original values. Requirement MM5 states that these values must be stored somewhere. They might be logged, they might be left in the DIT as the values of DN2, or they might be left in the DIT as the values of some machine generated DN. Leaving them as the values of DN2 is attractive since it is the same as the single-server case, but if a new DN2 has already been created before the replica cycle finishes, there are some very complex cases to resolve. Any of the solutions described in this paragraph would be consistent with requirement MM5. B.5.3. Locking Based on Atomicity of ModifyRequest There is an entry with distinguished name DN that contains attributes X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is processed which includes modifications to change that value of X from 1 to 0 and to set the value of Y to "USER1". At the same time, replica B processes a ModifyRequest which includes modifications to change the value of X from 1 to 0 and to set the value of Y to "USER2" and the value of Z to 42. The application in this case is using X as a lock and is depending on the atomic nature of ModifyRequests to provide mutual exclusion for lock access. In the single-server case, the two operations would have occurred sequentially. Since a ModifyRequest is atomic, the entire first operation would succeed. The second ModifyRequest would fail, since the value of X would be 0 when it was attempted, and the modification changing X from 1 to 0 would thus fail. The atomicity rule would cause all other modifications in the ModifyRequest to fail as well. In the multi-master case, it is inevitable that at least some of the changes will be reversed despite the use of the lock. Assuming the changes from A have priority per the conflict resolution algorithm, the value of X should be 0 and the value of Y should be "USER1" The interesting question is the value of Z at the end of the replication cycle. If it is 42, the atomicity constraint on the change from B has been violated. But for it to revert to its previous value, grouping Stokes, et al Expires February 2001 [Page 24] Internet-Draft LDAPv3 Replication Requirements March 2001 information must be retained and it is not clear when that information can be safely discarded. Thus, requirement G6 may be violated. B.5.4. General Principles With multi-master replication there are a number of cases where a user or application will complete a sequence of operations with a server but those actions are later "undone" because someone else completed a conflicting set of operations at another server. To some extent, this can happen in any multi-user system. If a user changes the value of an attribute and later reads it back, intervening operations by another user may have changed the value. In the multi- master case, the problem is worsened, since techniques used to resolve the problem in the single-server case won't work as shown in the examples above. The major question here is one of intended use. In LDAP standards work, it has long been said that replication provides "loose consistency" among replicas. At several IETF meetings and on the mailing list, usage examples from finance where locking is required have been declared poor uses for LDAP. Requirement G1 is consistent with this history. But if loose consistency is the goal, the locking example above is an inappropriate use of LDAP, at least in a replicated environment. B.5.5. Avoiding the Problem The examples above discuss some of the most difficult problems that can arise in multi-master replication. While they can be dealt with, dealing with them is difficult and can lead to situations that are quite confusing to the application and to users. The common characteristics of the examples are: . Several directory users/applications are changing the same data. . They are changing the data before previous changes have replicated. . They are using different directory servers to make these changes. . They are changing data that are parts of a distinguished name or they are using ModifyRequest to both read and write a given attribute value in a single atomic request. If any one of these conditions is reversed, the types of problems described above will not occur. There are many useful applications of multi-master directories where at least one of the above conditions Stokes, et al Expires February 2001 [Page 25] Internet-Draft LDAPv3 Replication Requirements March 2001 does not occur. For cases where all four do occur, application designers should be aware of the possible consequences. B.6. Data Privacy During Replication Directories will frequently hold proprietary information. Policy information, name and address information, and customer lists can be quite proprietary and are likely to be stored in directories. Such data must be protected during replication. In some cases, the network environment (e.g. a private network) may provide sufficient privacy for the application. In other cases, the data in the directory may be public and not require protection. For these reasons data privacy was not made a requirement for all replication sessions. But there are a substantial number of applications that will need data privacy, so there is a requirement (S2) that the protocol allow for data privacy in those cases where it is needed. This leaves the question of what privacy mechanism(s) to use. While this is ultimately a design/implementation decision, replication across different vendors' directory products is an important goal of the LDAP replication work at the IETF. If different vendors choose to support different data privacy mechanisms, the advantages of a standard replication protocol would be lost. Thus there is a requirement (S3) for a mandatory-to-implement data privacy mechanism. B.7. Failover in Single-Master Systems In a single-master system, all modifications must originate at the master. The master is therefore a single point of failure for modifications. This can cause concern when high availability is a requirement for the directory system. One way to reduce the problem is to provide a failover process that converts a slave replica to master when the original master fails. The time required to execute the failover process then becomes a major factor in availability of the system as a whole. Factors that designers and implementors should consider when working on failover include: . If the master replica contains control information or meta-data that is not part of the slave replica(s), this information will have to be inserted into the slave that is being "promoted" to master as part of the failover process. Since the old master is presumably unavailable at this point, it may be difficult to obtain this data. For example, if the master holds the status Stokes, et al Expires February 2001 [Page 26] Internet-Draft LDAPv3 Replication Requirements March 2001 information of all replicas, but each slave replica only holds its own status information, failover would require that the new master get the status of all existing replicas, presumably from those replicas. Similar issues could arise for replication agreements if the master is the only system that holds a complete set. . If data privacy mechanisms (e.g. encryption) are in use during replication, the new master would need to have the necessary key information to talk to all of the slave replicas. . It is not only the new master that needs to be reconfigured. The slaves also need to have their configurations updated so they know where updates should come from and where they should refer modifications. . The failover mechanism should be able to handle a situation where the old master is "broken" but not "dead". The slave replicas should ignore updates from the old master after failover is initiated. . The old master will eventually be repaired and returned to the replica-group. It might join the group as a slave and pick up the changes it has "missed" from the new master, or there might be some mechanism to bring it into sync with the new master and then let it take over as master. Some resynchronization mechanism will be needed. . Availability would be maximized if the whole failover process could be automated (e.g. failover is initiated by an external system when it determines that the original master is not functioning properly). B.8. Including Operational Attributes in Atomic Operations LDAPv3 [RFC2251] declares that some operations are atomic (e.g. all of the modifications in a single ModifyRequest). It also defines several operational attributes that store information about when changes are made to the directory (createTimestamp, etc.) and which ID was responsible for a given change (modifiersName, etc.). Currently, there is no statement in RFC2251 requiring that changes to these operational attributes be atomic with the changes to the data. It is RECOMMENDED that this requirement be added during the revision of RFC2251. In the interim, replication SHOULD treat these operations as though such a requirement were in place. Stokes, et al Expires February 2001 [Page 27] Internet-Draft LDAPv3 Replication Requirements March 2001 Authors' Addresses Russel F. Weiser Digital Signature Trust Co. 1095 East 2100 South Suite #201 Salt Lake City, Utah 84106 USA E-mail: rweiser@digsigtrust.com Telephone: +1 801 246 4323 Fax: +1 801 246 4361 Ellen J. Stokes Tivoli Systems 6300 Bridgepoint Parkway Austin, Texas 78731 USA E-mail: estokes@tivoli.com Telephone: +1 512 436 9098 Fax: +1 512 436 1199 Ryan D. Moats Coreon, Inc. 15621 Drexel Circle Omaha, NE 68135 USA E-Mail: rmoats@coreon.net Telephone: +1 402 894 9456 Richard V. Huber Room C3-3B30 AT&T Laboratories 200 Laurel Avenue South Middletown, NJ 07748 USA E-Mail: rvh@att.com Telephone: +1 732 420 2632 Fax: +1 732 368 1690 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, Stokes, et al Expires February 2001 [Page 28] Internet-Draft LDAPv3 Replication Requirements March 2001 provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Stokes, et al Expires February 2001 [Page 29] From owner-ietf-ldup@mail.imc.org Thu Mar 1 19:39:13 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29762 for ; Thu, 1 Mar 2001 19:39:12 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id PAA01562 for ietf-ldup-bks; Thu, 1 Mar 2001 15:43:42 -0800 (PST) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA01551 for ; Thu, 1 Mar 2001 15:43:38 -0800 (PST) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f21Nh1w31344 for ; Thu, 1 Mar 2001 16:43:01 -0700 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Thu, 01 Mar 2001 15:53:27 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 01 Mar 2001 15:53:20 -0700 From: "Ed Reed" To: Cc: , , , , , Subject: draft-ietf-ldup-subentry-07.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_E9B240F7.DCBDD149" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=_E9B240F7.DCBDD149 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please publish this updated internet draft. Abstract: This document describes two object classes called ldapSubEntry and = inheritableLDAPSubEntry, and a control, ldapSubentriesControl (to control = the visibility of entries of type ldapSubEntry) which MUST be used by = directory servers claiming support for the features of this document to = indicate operations and management related entries in the directory, = called LDAP Subentries. Scope rules are defined for LDAP Subentries. =20 To the work groups: Per discussions in San Diego and on the list, I've removed the provision = for a search-filter visibility mechanism. Per discussions on the list, mechanisms to facilitate propagation of = inherited information from servers holding superior administrative areas = to servers holding (only) subordinate replication areas is NOT addressed = here, but rather are discussed in a private internet draft submission = draft-reed-ldup-inheritance-00.txt. I've been careful NOT to make this = internet draft dependent (via reference) to the private draft on inheritanc= e. Other than that I've cleaned up language, capitalizations, and have = strengthened the admonition against deeply nested subentries. One remaining question for the list - as written (in the abstract, above) = support for inheritableLDAPSubEntry is MUST, along with support for the = ldapSubentry class and its visibility control. Should the inheritable = class be MAY? Should it even be removed to its own draft? If the answer = is "it should be a MUST", then I think this draft is ready for last call. Thank you. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM --=_E9B240F7.DCBDD149 Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldup-subentry-07.txt" Content-Transfer-Encoding: base64 DQoKCgoKCiBJTlRFUk5FVC1EUkFGVCANCiBkcmFmdC1pZXRmLWxkdXAtc3ViZW50cnktMDcudHh0 IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RWQgUmVlZCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJlZWQt TWF0dGhld3MsIEluYy4gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBNYXJjaCAxLCAyMDAxIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgIExEQVAg U3ViZW50cnkgU2NoZW1hIA0KCgogMSAgU3RhdHVzIG9mIHRoaXMgTWVtbyANCgogVGhpcyBkb2N1 bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCANCiBjb25mb3JtYW5jZSB3 aXRoIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4gDQogIA0KIEludGVy bmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IA0KIEVuZ2lu ZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyANCiBn cm91cHMuIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5n IA0KIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICANCiAgDQogSW50ZXJuZXQtRHJhZnRz IGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiANCiBzaXggbW9udGhz IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSANCiBvdGhlciBk b2N1bWVudHMgYXQgYW55IHRpbWUuIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIA0KIEludGVy bmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIA0K IHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIiAgDQogIA0KIFRoZSBsaXN0IG9mIGN1cnJlbnQg SW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCiBodHRwOi8vd3d3LmlldGYub3Jn L2lldGYvMWlkLWFic3RyYWN0cy50eHQuICANCiAgDQogVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJh ZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSANCiBhY2Nlc3NlZCBhdCBodHRwOi8vd3d3Lmll dGYub3JnL3NoYWRvdy5odG1sLiANCiAgDQogVGhpcyBJbnRlcm5ldC1EcmFmdCBleHBpcmVzIG9u IFNlcHRlbWJlciAxLCAyMDAxLiANCgoKIDIgIEFic3RyYWN0IC8gRGVzY3JpcHRpb24gDQoKIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIHR3byBvYmplY3QgY2xhc3NlcyBjYWxsZWQgDQogbGRhcFN1 YkVudHJ5IGFuZCBpbmhlcml0YWJsZUxEQVBTdWJFbnRyeSwgYW5kIGEgY29udHJvbCwgDQogbGRh cFN1YmVudHJpZXNDb250cm9sICh0byBjb250cm9sIHRoZSB2aXNpYmlsaXR5IG9mIGVudHJpZXMg DQogb2YgdHlwZSBsZGFwU3ViRW50cnkpIHdoaWNoIE1VU1QgYmUgdXNlZCBieSBkaXJlY3Rvcnkg DQogc2VydmVycyBjbGFpbWluZyBzdXBwb3J0IGZvciB0aGUgZmVhdHVyZXMgb2YgdGhpcyBkb2N1 bWVudCANCiB0byBpbmRpY2F0ZSBvcGVyYXRpb25zIGFuZCBtYW5hZ2VtZW50IHJlbGF0ZWQgZW50 cmllcyBpbiANCiB0aGUgZGlyZWN0b3J5LCBjYWxsZWQgTERBUCBTdWJlbnRyaWVzLiAgU2NvcGUg cnVsZXMgYXJlIA0KIGRlZmluZWQgZm9yIExEQVAgU3ViZW50cmllcy4gICANCgogVGhlIGtleSB3 b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsIA0KICJTSEFMTCBO T1QiLCAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgDQogYW5k ICAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIA0K CgogUmVlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgMV0gDQogICAgICAgICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAxLCAy MDAxIAwNCgoKIElOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg MSBNYXJjaCAyMDAxIA0KICAgICAgICAgICAgICAgICAgICAgTERBUCBTdWJlbnRyeSBTY2hlbWEg DQoKIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uIFRoZSBzZWN0aW9ucyBiZWxvdyByZWl0ZXJhdGUg dGhlc2UgDQogZGVmaW5pdGlvbnMgYW5kIGluY2x1ZGUgc29tZSBhZGRpdGlvbmFsIG9uZXMuIA0K CgoKIDMgIFRhYmxlIG9mIENvbnRlbnRzIA0KCiAxICBTdGF0dXMgb2YgdGhpcyBNZW1vICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMSANCiAyICBBYnN0cmFjdCAvIERl c2NyaXB0aW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMSANCiAzICBU YWJsZSBvZiBDb250ZW50cyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgMiANCiA0ICBPYmplY3QgQ2xhc3MgRGVmaW5pdGlvbnMgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgMiANCiA0LjEgIGxkYXBTdWJFbnRyeSBDbGFzcyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIgDQogNC4xLjEgICAgIFNjb3BlIFJ1bGVzICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAzIA0KIDQuMiAgSW5oZXJp dGFibGVMREFQU3ViZW50cnkgQ2xhc3MgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNCAN CiA0LjIuMSAgICAgSWxsdXN0cmF0aW9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDUgDQogNSAgQXR0cmlidXRlIERlZmluaXRpb25zICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDYgDQogNS4xICBpbmhlcml0YWJsZSBBdHRyaWJ1dGUgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA2IA0KIDUuMiAgYmxvY2tJbmhlcml0 YW5jZSBBdHRyaWJ1dGUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNiANCiA2ICBW aXNpYmlsaXR5IENvbnRyb2xzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgNyANCiA2LjEgIGxkYXBTdWJlbnRyaWVzQ29udHJvbCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDcgDQogNi4xLjEgICAgIExEQVAgU2VhcmNoIHdpdGggc2NvcGUgb3Ro ZXIgdGhhbiBiYXNlT2JqZWN0ICAgICAgICAgICA3IA0KIDYuMS4yICAgICBMREFQIFNlYXJjaCB3 aXRoIHNjb3BlIG9mIGJhc2VPYmplY3QgICAgICAgICAgICAgICAgICAgNyANCiA2LjEuMyAgICAg T3RoZXIgTERBUCBvcGVyYXRpb25zICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDgg DQogNi4xLjQgICAgIENvcnJlc3BvbmRlbmNlIHRvIFguNTAwIFtYLjUxMV0gICAgICAgICAgICAg ICAgICAgICAgICA4IA0KIDcgIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA4IA0KIDggIFJlZmVyZW5jZXMgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA5IA0KIDkgIENvcHlyaWdodCBOb3Rp Y2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA5IA0KIDEwIEFj a25vd2xlZGdlbWVudHMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAxMCANCiAxMSBBdXRob3IncyBBZGRyZXNzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgMTEgDQogIA0KCgogNCAgT2JqZWN0IENsYXNzIERlZmluaXRpb25zIA0K CgogNC4xIGxkYXBTdWJFbnRyeSBDbGFzcyANCgogKCAyLjE2Ljg0MC4xLjExMzcxOS4yLjE0Mi42 LjEuMSBOQU1FICdsZGFwU3ViRW50cnknICANCiAgICBERVNDICdMREFQIFN1YmVudHJ5IGNsYXNz LCB2ZXJzaW9uIDEnICANCiAgICAgIFNVUCB0b3AgU1RSVUNUVVJBTCAgDQogICAgICBNQVkgKCBj biApICkgIA0KCiBUaGUgY2xhc3MgbGRhcFN1YkVudHJ5IGlzIGludGVuZGVkIHRvIGJlIHVzZWQg YXMgYSBzdXBlci0gDQogY2xhc3Mgd2hlbiBkZWZpbmluZyBvdGhlciBzdHJ1Y3R1cmFsIGNsYXNz ZXMgdG8gYmUgdXNlZCANCiBhcyBMREFQIFN1YmVudHJpZXMsIGFuZCBhcyB0aGUgc3RydWN0dXJh bCBjbGFzcyB0byB3aGljaCANCiBBdXhpbGlhcnkgY2xhc3NlcyBtYXkgYmUgYWRkZWQgZm9yIGFw cGxpY2F0aW9uIHNwZWNpZmljIA0KIHN1YmVudHJ5IGluZm9ybWF0aW9uLiAgV2hlcmUgcG9zc2li bGUsIHRoZSB1c2Ugb2YgQXV4aWxpYXJ5IA0KIGNsYXNzZXMgdG8gZXh0ZW5kIExEQVAgU3ViZW50 cmllcyBpcyBzdHJvbmdseSBwcmVmZXJyZWQuIA0KCiBSZWVkICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyXSANCiAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDEsIDIwMDEgDQogIAwNCgoKIElOVEVSTkVULURSQUZUICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgMSBNYXJjaCAyMDAxIA0KICAgICAgICAgICAgICAgICAg ICAgTERBUCBTdWJlbnRyeSBTY2hlbWEgDQoKICANCiBUaGUgcHJlc2VuY2Ugb2YgbGRhcFN1YkVu dHJ5IGluIHRoZSBsaXN0IG9mIHN1cGVyLWNsYXNzZXMgDQogb2YgYW4gZW50cnkgaW4gdGhlIGRp cmVjdG9yeSBtYWtlcyB0aGF0IGVudHJ5IGFuIExEQVAgDQogU3ViZW50cnkuICBPYmplY3QgY2xh c3NlcyBkZXJpdmVkIGZyb20gbGRhcFN1YkVudHJ5IGFyZSANCiB0aGVtc2VsdmVzIGNvbnNpZGVy ZWQgbGRhcFN1YkVudHJ5IGNsYXNzZXMsIGZvciB0aGUgcHVycG9zZSANCiBvZiB0aGlzIGRpc2N1 c3Npb24uIA0KCiBMREFQIFN1YmVudHJpZXMgTUFZIGJlIG5hbWVkIGJ5IHRoZWlyIGNvbW1vbk5h bWUgYXR0cmlidXRlIA0KIFtSRkMyMjUxXS4gIE90aGVyIG5hbWluZyBhdHRyaWJ1dGVzIGFyZSBh bHNvIHBlcm1pdHRlZC4gDQoKIExEQVAgU3ViZW50cmllcyBNQVkgYmUgY29udGFpbmVycywgdW5s aWtlIHRoZWlyIFtYLjUwMV0gDQogY291bnRlcnBhcnRzLiANCgogTERBUCBTdWJlbnRyaWVzIE1B WSBiZSBjb250YWluZWQgYnksIGFuZCB3aWxsIHVzdWFsbHkgYmUgDQogbG9jYXRlZCBpbiB0aGUg ZGlyZWN0b3J5IGluZm9ybWF0aW9uIHRyZWUgaW1tZWRpYXRlbHkgDQogc3Vib3JkaW5hdGUgdG8s IGFkbWluaXN0cmF0aXZlIHBvaW50cy4gIEZ1cnRoZXIgKHVubGlrZSANCiBYLjUwMCBzdWJlbnRy aWVzKSwgTERBUCBTdWJlbnRyaWVzIE1BWSBiZSBjb250YWluZWQgYnkgDQogb3RoZXIgTERBUCBT dWJlbnRyaWVzICh0aGUgd2F5IG9yZ2FuaXphdGlvbmFsIHVuaXRzIG1heSBiZSANCiBjb250YWlu ZWQgYnkgb3RoZXIgb3JnYW5pemF0aW9uYWwgdW5pdHMpLiAgRGVlcCBuZXN0aW5nIG9mIA0KIExE QVAgU3ViZW50cmllcyBhcmUgZGlzY291cmFnZWQsIGJ1dCBub3QgcHJvaGliaXRlZC4gIA0KIERl dmVsb3BlcnMgYXJlIHdhcm5lZCB0aGF0IGRlZXAgbmVzdGluZyBvZiBMREFQIFN1YmVudHJpZXMg DQogbWF5IG5vdCBiZSBzdXBwb3J0ZWQgYnkgYWxsIChvciBpbmRlZWQsIGJ5IGFueSkgTERBUCBz ZXJ2ZXIgDQogaW1wbGVtZW50YXRpb25zLiANCgoKIDQuMS4xU2NvcGUgUnVsZXMgDQoKIFRoZSBk ZWZhdWx0IHNjb3BlIG9mIGFuIExEQVAgU3ViZW50cnkgaXMgbGltaXRlZCB0byB0aGUgDQogYWRt aW5pc3RyYXRpdmUgYXJlYSBpbiB3aGljaCBpdCBpcyBkZWZpbmVkLiAgU3BlY2lmaWNhbGx5LCAN CiB0aGUgc3VidHJlZSBvZiB0aGUgZGlyZWN0b3J5IG5hbWVzcGFjZSBiYXNlZCBhdCB0aGUgDQog YWRtaW5pc3RyYXRpdmUgcG9pbnQgbW9zdCBpbW1lZGlhdGVseSBzdXBlcmlvciB0byB0aGUgTERB UCANCiBTdWJlbnRyeSwgZG93biB0byBidXQgbm90IGluY2x1ZGluZyBhbnkgc3Vib3JkaW5hdGUg DQogYWRtaW5pc3RyYXRpdmUgcG9pbnRzIG9yIGFyZWFzLiAgUG9saWN5IGRlZmluZWQgaW4gYW4g TERBUCANCiBTdWJlbnRyeSBpcyBub3QgaW5oZXJpdGFibGUsIHVubGVzcyBzdWNoIGluaGVyaXRh bmNlIGlzIA0KIGV4cGxpY2l0bHkgZGVmaW5lZCAoc2VlIHRoZSBvYmplY3QgY2xhc3MgZGVmaW5p dGlvbiBmb3IgDQogSW5oZXJpdGFibGVMREFQU3ViRW50cnksIGJlbG93LCBmb3Igc3VjaCBhbiBl eGFtcGxlKS4gDQoKIElmIGFuIExEQVAgU3ViZW50cnkgaXMgc3Vib3JkaW5hdGUgdG8gYW5vdGhl ciBMREFQIA0KIFN1YmVudHJ5LCBpdCB0YWtlcyB0aGUgc2FtZSBkZWZhdWx0IHNjb3BlIGFzIHRo ZSBwYXJlbnQgDQogTERBUCBTdWJlbnRyeS4gDQoKIEFwcGxpY2F0aW9ucyBNQVkgZGVmaW5lIGFs dGVybmF0aXZlIHNjb3BlIHNlbWFudGljcyBmb3IgDQogY2xhc3NlcyB0aGV5IGRlZmluZSB3aGlj aCBhcmUgZGVyaXZlZCBmcm9tIHRoZSBsZGFwU3ViRW50cnkgDQogY2xhc3MuIFRoaXMgbWVhbnMg dGhhdCBhbiBhcHBsaWNhdGlvbiBjYW4gZGVyaXZlIGEgbmV3IA0KIGNsYXNzIGZyb20gdGhlIGxk YXBTdWJFbnRyeSBjbGFzcyBhbmQgYWRkIGFuIGF0dHJpYnV0ZSwgDQogbGlrZSBzdWJ0cmVlU3Bl Y2lmaWNhdGlvbiBbWC41MDFdIG9yIGluaGVyaXRhbmNlIGNvbnRyb2xzIA0KIChzZWUgYmVsb3cp LCB0byBkZWZpbmUgYSBuZXcgc2NvcGUgcnVsZSBmb3IgdGhhdCANCiBhcHBsaWNhdGlvbiB0byB1 c2UuIA0KCiBSZWVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBbUGFnZSAzXSANCiAgICAgICAgICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDEsIDIwMDEg DQogIAwNCgoKIElOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg MSBNYXJjaCAyMDAxIA0KICAgICAgICAgICAgICAgICAgICAgTERBUCBTdWJlbnRyeSBTY2hlbWEg DQoKIEFwcGxpY2F0aW9ucyBNVVNUIE5PVCBkZWZpbmUgYWx0ZXJuYXRpdmUgc2NvcGUgcnVsZXMg Zm9yIA0KIGF1eGlsaWFyeSBjbGFzc2VzIHVzZWQgdG8gZGVjb3JhdGUgZW50cmllcyBvZiB0aGUg DQogbGRhcFN1YkVudHJ5IGNsYXNzLiAgVGhpcyByZXN0cmljdGlvbiBpcyByZXF1aXJlZCB0byBh dm9pZCANCiBoYXZpbmcgY29uZmxpY3Rpbmcgb3IgY29udHJhZGljdG9yeSBzY29wZSBkZWZpbml0 aW9ucyANCiBhcHBsaWVkIGJ5IGRpZmZlcmVudCBhcHBsaWNhdGlvbnMgdG8gdGhlIHNhbWUgTERB UCANCiBTdWJlbnRyeS4gDQoKCiA0LjIgSW5oZXJpdGFibGVMREFQU3ViRW50cnkgQ2xhc3MgDQoK ICggMS4zLjYuMS40LjEuNzYyOC41LjYuMS4xIE5BTUUgJ2luaGVyaXRhYmxlTERBUFN1YkVudHJ5 JyAgDQogICAgREVTQyAnSW5oZXJpdGFibGUgTERBUCBTdWJlbnRyeSBjbGFzcywgdmVyc2lvbiAx JyAgDQogICAgU1VQIGxkYXBTdWJFbnRyeSBTVFJVQ1RVUkFMICANCiAgICBNVVNUICggaW5oZXJp dGFibGUgKSAgDQogICAgTUFZICAoIGJsb2NrSW5oZXJpdGFuY2UgKSANCgogVGhlIEluaGVyaXRh YmxlTERBUFN1YmVudHJ5IGNsYXNzIGlzIGRlcml2ZWQgZnJvbSB0aGUgDQogbGRhcFN1YkVudHJ5 IGNsYXNzIGFuZCBwcm92aWRlcyBtb2RpZmllZCBzY29wZSBzZW1hbnRpY3MgdG8gDQogcGVybWl0 IGFuZCBjb250cm9sIGluaGVyaXRhbmNlIGZyb20gb25lIGFkbWluaXN0cmF0aXZlIGFyZWEgDQog dG8gb25lIG9yIG1vcmUgc3Vib3JkaW5hdGUgYWRtaW5pc3RyYXRpdmUgYXJlYXMuIA0KCiBJZiB0 aGUgJ2luaGVyaXRhYmxlJyBhdHRyaWJ1dGUgaXMgVFJVRSAoMSksIHRoZW4gdGhlIHBvbGljeSAN CiBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhlIEluaGVyaXRhYmxlTERBUFN1YkVudHJ5IGlz IA0KIGludGVuZGVkIHRvIGFwcGx5IHRvIGFueSAoYW5kIGFsbCkgc3Vib3JkaW5hdGUgDQogYWRt aW5pc3RyYXRpdmUgYXJlYXMuICBTdWJvcmRpbmF0ZSBhZG1pbmlzdHJhdGl2ZSBhcmVhcyANCiBN VVNUIGluY2x1ZGUgSW5oZXJpdGFibGUgTERBUCBTdWJlbnRyaWVzIGZyb20gdGhlaXIgDQogaW1t ZWRpYXRlbHkgc3VwZXJpb3IgYWRtaW5pc3RyYXRpdmUgYXJlYSAodW5sZXNzIGJsb2NrZWQsIA0K IHNlZSBiZWxvdykuICBUaGUgbWVhbnMgb2Ygc3VjaCBpbmNsdXNpb24gKHRoYXQgaXMsIHdoZXRo ZXIgDQogdmlhIHJlcGxpY2F0aW9uLCBjYWNoaW5nLCBvciBleHBsaWNpdGx5IHdhbGtpbmcgdGhl IHRyZWUgdG8gDQogbG9jYXRlIGFuZCAiaW5jbHVkZSIgdGhlbSwgYXJlIGxlZnQgdG8gdGhlIGFw cGxpY2F0aW9uIHRoYXQgDQogY29uc3VtZXMgdGhlIGluaGVyaXRhYmxlIHBvbGljeSBpbmZvcm1h dGlvbiBjb250YWluZWQgb24gDQogdGhlIGluaGVyaXRhYmxlTERBUFN1YkVudHJ5LiANCgogSWYg dGhlICdpbmhlcml0YWJsZScgYXR0cmlidXRlIGlzIEZBTFNFICgwKSwgdGhlIHBvbGljeSBpcyAN CiBOT1QgaW5oZXJpdGFibGUsIGFuZCBzdWJvcmRpbmF0ZSBhZG1pbmlzdHJhdGl2ZSBhcmVhcyBN VVNUIA0KIHRyZWF0IHRoZSBhc3NvY2lhdGVkIHBvbGljeSBpbmZvcm1hdGlvbiBhcyBVTkRFRklO RUQgKHRoYXQgDQogaXMsIGFic2VudCkgdW5sZXNzIGV4cGxpY2l0bHkgZGVmaW5lZCB3aXRoaW4g dGhlaXIgb3duIA0KIGFkbWluaXN0cmF0aXZlIGFyZWEuIA0KCiBJZiBhIHN1Ym9yZGluYXRlIGFk bWluaXN0cmF0aXZlIGFyZWEgZGVmaW5lcyBhbiBJbmhlcml0YWJsZSANCiBMREFQIFN1YmVudHJ5 IGZvciBhbiBhcHBsaWNhdGlvbiB3aXRoIHRoZSBzYW1lIG5hbWUgYXMgb25lIA0KIGRlZmluZWQg aW4gYSBzdXBlcmlvciBhZG1pbmlzdHJhdGl2ZSBhcmVhLCBhbmQgaWYgdGhlIA0KIHN1Ym9yZGlu YXRlknMgSW5oZXJpdGFibGUgTERBUCBTdWJlbnRyeSBoYXMgdGhlIGF0dHJpYnV0ZSANCiAnYmxv Y2tJbmhlcml0YW5jZScgd2l0aCB0aGUgdmFsdWUgVFJVRSwgdGhlbiBpbmhlcml0YW5jZSBpcyAN CiBibG9ja2VkIGZyb20gdGhlIHN1cGVyaW9yIGFkbWluaXN0cmF0aXZlIGFyZWEgdG8gdGhhdCAN CiBzdWJvcmRpbmF0ZSBhZG1pbmlzdHJhdGl2ZSBhcmVhLCBhbmQgdGhlIGVmZmVjdCBpcyB0aGUg c2FtZSANCiBhcyBpZiB0aGUgc3VwZXJpb3IgSW5oZXJpdGFibGUgTERBUCBTdWJlbnRyeSBjb250 YWluZWQgdGhlIA0KICdpbmhlcml0YWJsZScgYXR0cmlidXRlIHNldCB0byBGQUxTRS4gDQoKIFJl ZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDRd IA0KICAgICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMSwgMjAwMSANCiAgDA0KCgog SU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxIE1hcmNoIDIw MDEgDQogICAgICAgICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSANCgogVGhlIHZh bHVlIG9mIHRoZSAnYmxvY2tJbmhlcml0YW5jZScgYXR0cmlidXRlIGluIGEgc3VwZXJpb3IgDQog YWRtaW5pc3RyYXRpdmUgYXJlYSBJbmhlcml0YWJsZSBMREFQIFN1YmVudHJ5IGlzIGlycmVsZXZh bnQgDQogdG8gYSBzdWJvcmRpbmF0ZSBhZG1pbmlzdHJhdGl2ZSBhcmVhIGZvciB0aGlzIG9iamVj dCBjbGFzcy4gICANCgogTm8gbWVjaGFuaXNtIGlzIGRlZmluZWQgKGF0IHRoaXMgdGltZSkgdG8g c2lnbmFsIHRvIA0KIHN1Ym9yZGluYXRlIGFkbWluaXN0cmF0aXZlIGFyZWFzIHRoYXQgdGhleSBt YXkgbm90IGJsb2NrIA0KIGluaGVyaXRhYmxlIHBvbGljeSBmcm9tIHN1cGVyaW9yIGFkbWluaXN0 cmF0aXZlIGFyZWFzLiANCgoKIDQuMi4xSWxsdXN0cmF0aW9uIA0KCiBBbiBpbGx1c3RyYXRpb24g bWF5IGhlbHAgY2xhcmlmeSB0aGUgdXNlIG9mIHRoZSBjbGFzcyBhbmQgDQogdGhlc2UgYXR0cmli dXRlcy4gDQoKIFN1cHBvc2UgdGhlIGFkbWluaXN0cmF0aXZlIGFyZWEgYmFzZWQgYXQgJ2RjPWNv bScgaGFzIGFuIA0KIEluaGVyaXRhYmxlIExEQVAgU3ViZW50cnkgZm9yIGFuIGFwcGxpY2F0aW9u IGRlZmluZWQgd2l0aCANCiB0aGUgJ2luaGVyaXRhYmxlJyBhdHRyaWJ1dGUgc2V0IHRvIFRSVUUu ICBTdWJvcmRpbmF0ZSANCiBhZG1pbmlzdHJhdGl2ZSBhcmVhcywgZm9yIGluc3RhbmNlICdkYz13 aWRnZXQsIGRjPWNvbScgDQogbWlnaHQgb3IgbWlnaHQgbm90IHdhbnQgdG8gYWNjZXB0IHRoZSBp bmhlcml0ZWQgcG9saWN5IGZyb20gDQogdGhlICdkYz1jb20nIGFkbWluaXN0cmF0aXZlIGFyZWEu IA0KCiBJZiB0aGUgYWRtaW5pc3RyYXRvciBvZiB0aGUgJ2RjPXdpZGdldCwgZGM9Y29tJyANCiBh ZG1pbmlzdHJhdGl2ZSBhcmVhIGNyZWF0ZXMgYW4gSW5oZXJpdGFibGUgTERBUCBTdWJlbnRyeSAN CiAoc2F5LCAnY249ZXhhbXBsZSwgZGM9d2lkZ2V0LCBkYz1jb20nKSB3aXRoIHRoZSBzYW1lIA0K IHJlbGF0aXZlIGRpc3Rpbmd1aXNoZWQgbmFtZSBhcyB1c2VkIGluIHRoZSAnZGM9Y29tJyANCiBh ZG1pbmlzdHJhdGl2ZSBhcmVhICh0aGF0IGlzLCAnY249ZXhhbXBsZSwgZGM9Y29tJykgc2V0dGlu ZyANCiB0aGUgJ2Jsb2NrSW5oZXJpdGFuY2UnIGF0dHJpYnV0ZSBzZXQgdG8gVFJVRSwgdGhlbiB0 aGUgDQogaW5oZXJpdGFuY2Ugb2YgdGhlIHBvbGljeSBkZWZpbmVkIChvbiAnY249ZXhhbXBsZSwg ZGM9Y29tJykgDQogaXMgZWZmZWN0aXZlbHkgYmxvY2tlZCBmcm9tIGFmZmVjdGluZyB0aGUgJ2Rj PXdpZGdldCwgDQogZGM9Y29tJyBhZG1pbmlzdHJhdGl2ZSBhcmVhLiAgV2WSbGwgY2FsbCB0aGlz IGEgYmxvY2tpbmcgDQogc3ViZW50cnkgZm9yIG91ciBkaXNjdXNzaW9uIGhlcmUuIA0KCiBJZiB0 aGUgYWRtaW5pc3RyYXRvciBvZiB0aGUgJ2RjPXdpZGdldCwgZGM9Y29tJyANCiBhZG1pbmlzdHJh dGl2ZSBhcmVhIGNyZWF0ZXMgYSBibG9ja2luZyBzdWJlbnRyeSAoYXMgYWJvdmUpIA0KIHdpdGgg c29tZSBsb2NhbGx5IGRlZmluZWQgcG9saWN5IGluZm9ybWF0aW9uLCB0aGF0IHBvbGljeSANCiBp bmZvcm1hdGlvbiBlZmZlY3RpdmVseSByZXBsYWNlcyB0aGUgcG9saWN5IGluZm9ybWF0aW9uIA0K IGRlZmluZWQgYnkgdGhlIHN1cGVyaW9yIGFkbWluaXN0cmF0aXZlIGFyZWEuICBXZZJsbCBjYWxs IA0KIHRoaXMgYW4gb3Zlci1yaWRpbmcgc3ViZW50cnkgZm9yIG91ciBkaXNjdXNzaW9uIGhlcmUu IA0KCiBBbiBvdmVyLXJpZGluZyBzdWJlbnRyeSBNQVkgaXRzZWxmIGJlIGluaGVyaXRhYmxlLCBp biB3aGljaCANCiBjYXNlIHRoZSAnaW5oZXJpdGFibGUnIGF0dHJpYnV0ZSBvbiB0aGUgbG9jYWxs eSBkZWZpbmVkIA0KIEluaGVyaXRhYmxlIExEQVAgU3ViZW50cnkgTUFZIGJlIHNldCB0byBUUlVF IG9yIEZBTFNFLCBhdCANCiB0aGUgZGlzY3JldGlvbiBvZiB0aGUgbG9jYWwgYWRtaW5pc3RyYXRp dmUgYXV0aG9yaXR5LCB3aXRoIA0KIGFwcHJvcHJpYXRlIGltcGxpY2F0aW9ucyBmb3IgaW5oZXJp dGFuY2Ugb2YgdGhlIG5ldywgDQogbG9jYWxseSBkZWZpbmVkIHBvbGljeSwgb24gYW55IG90aGVy IHN1Ym9yZGluYXRlIA0KIGFkbWluaXN0cmF0aXZlIGFyZWFzLiAgSW4gdGhpcyB3YXksIHRoZSAn ZGM9d2lkZ2V0LCBkYz1jb20nIA0KIGFkbWluaXN0cmF0b3IgY2FuIHNldCBpbmhlcml0YWJsZSBw b2xpY3kgZm9yIG9yZ2FuaXphdGlvbmFsIA0KIHVuaXRzIChsaWtlICdvdT1lbmcsIGRjPXdpZGdl dCwgZGM9Y29tJykgZm9yIGFuIGFwcGxpY2F0aW9uIA0KCiBSZWVkICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA1XSANCiAgICAgICAgICAgICAgICAg IEV4cGlyZXMgU2VwdGVtYmVyIDEsIDIwMDEgDQogIAwNCgoKIElOVEVSTkVULURSQUZUICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgMSBNYXJjaCAyMDAxIA0KICAgICAgICAgICAgICAg ICAgICAgTERBUCBTdWJlbnRyeSBTY2hlbWEgDQoKIHdoaWxlIG92ZXItcmlkaW5nIGluaGVyaXRh YmxlIHBvbGljeSBmcm9tIHRoZSBzdXBlcmlvciANCiAnZGM9Y29tJyBhZG1pbmlzdHJhdGl2ZSBh cmVhLiANCgoKCiA1ICBBdHRyaWJ1dGUgRGVmaW5pdGlvbnMgDQoKCiA1LjEgaW5oZXJpdGFibGUg QXR0cmlidXRlIA0KCiAoIDEuMy42LjEuNC4xLjc2MjguNS40LjEgTkFNRSAnaW5oZXJpdGFibGUn IA0KICAgIFNZTlRBWCBCT09MRUFOIA0KICAgIFNJTkdMRS1WQUxVRSBOTy1VU0VSLU1PRElGSUNB VElPTiBVU0FHRSBkU0FPcGVyYXRpb24gKSANCgogVXNlZCB0byBzaWduYWwgd2hldGhlciBhbiBp bmhlcml0YWJsZUxEQVBTdWJFbnRyeSBpcyANCiBpbnRlbmRlZCB0byBiZSBpbmhlcml0ZWQgYnkg c3Vib3JkaW5hdGUgYWRtaW5pc3RyYXRpdmUgDQogYXJlYXMsIG9yIG5vdC4gIFRSVUUgaW5kaWNh dGVzIHRoYXQgdGhlIHN1YmVudHJ5IGFuZCB0aGUgDQogcG9saWN5IGl0IGNvbnRhaW5zIGlzIGlu aGVyaXRhYmxlLiAgIA0KCiBGQUxTRSBpbmRpY2F0ZXMgdGhhdCBpbmZvcm1hdGlvbiBmcm9tIHRo ZSANCiBpbmhlcml0YWJsZUxEQVBTdWJFbnRyeSBpcyBub3QgdG8gYmUgaW5oZXJpdGVkIGJ5IA0K IHN1Ym9yZGluYXRlIGFkbWluaXN0cmF0aXZlIGFyZWFzLiANCgoKIDUuMiBibG9ja0luaGVyaXRh bmNlIEF0dHJpYnV0ZSANCgogKCAxLjMuNi4xLjQuMS43NjI4LjUuNC4yIE5BTUUgJ2Jsb2NrSW5o ZXJpdGFuY2UnIA0KICAgIFNZTlRBWCBCT09MRUFOIA0KICAgIFNJTkdMRS1WQUxVRSBOTy1VU0VS LU1PRElGSUNBVElPTiBVU0FHRSBkU0FPcGVyYXRpb24gKSANCgogVXNlZCBieSBhZG1pbmlzdHJh dG9ycyBvZiBzdWJvcmRpbmF0ZSBhZG1pbmlzdHJhdGl2ZSBhcmVhcyANCiB0byBvdmVyLXJpZGUs IG9yIGJsb2NrLCB0aGUgaW5oZXJpdGFuY2Ugb2YgDQogaW5oZXJpdGFibGVMREFQU3ViRW50cnkg cG9saWN5IGZyb20gc3VwZXJpb3IgYWRtaW5pc3RyYXRpdmUgDQogYXJlYXMuICAgDQoKIEEgdmFs dWUgb2YgVFJVRSBpbmRpY2F0ZXMgdGhhdCBpbmhlcml0YW5jZSBpcyB0byBiZSANCiBibG9ja2Vk LiAgIA0KCiBBIHZhbHVlIG9mIEZBTFNFIGlzIGltcGxpZXMgdGhhdCBpbmhlcml0YW5jZSBpcyBu b3QgdG8gYmUgDQogYmxvY2tlZCwgYnV0IHNwZWNpZmljIHNlbWFudGljIGludGVycHJldGF0aW9u IGlzIGxlZnQgdG8gDQogYXBwbGljYXRpb25zICh3aG8gbWF5IHNwZWNpZnkgYW55IG9mIGEgdmFy aWV0eSBvZiBwb2xpY3kgDQogYWdncmVnYXRpb24gbWVjaGFuaXNtcyB0byBkZWZpbmUgaG93IGlu aGVyaXRlZCBwb2xpY3kgaXMgdG8gDQogYmUgbWl4ZWQgd2l0aCBsb2NhbGx5IGRlZmluZWQgcG9s aWN5LCB3aGljaCBtZWNoYW5pc21zIGFyZSANCiBleHBsaWNpdGx5IG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoaXMgc3BlY2lmaWNhdGlvbikuIA0KCgoKCgogUmVlZCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0gDQogICAgICAgICAgICAgICAgICBF eHBpcmVzIFNlcHRlbWJlciAxLCAyMDAxIA0KICAMDQoKCiBJTlRFUk5FVC1EUkFGVCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDEgTWFyY2ggMjAwMSANCiAgICAgICAgICAgICAgICAg ICAgIExEQVAgU3ViZW50cnkgU2NoZW1hIA0KCiA2ICBWaXNpYmlsaXR5IENvbnRyb2xzIA0KCgog Ni4xIGxkYXBTdWJlbnRyaWVzQ29udHJvbCANCgogVGhpcyBjb250cm9sIGlzIGluY2x1ZGVkIGlu IHRoZSBzZWFyY2hSZXF1ZXN0IG1lc3NhZ2UgYXMgDQogcGFydCBvZiB0aGUgY29udHJvbHMgZmll bGQgb2YgdGhlIExEQVBNZXNzYWdlLCBhcyBkZWZpbmVkIA0KIGluIFNlY3Rpb24gNC4xLjEyIG9m IFtSRkMyMjUxXS4gDQoKIFRoZSBjb250cm9sVHlwZSBpcyBzZXQgdG8gIjEuMy42LjEuNC4xLjc2 MjguNS4xMDEuMSIuIFRoZSANCiBjcml0aWNhbGl0eSBNQVkgYmUgc2V0IHRvIGVpdGhlciBUUlVF IG9yIEZBTFNFLiAgVGhlIA0KIGNvbnRyb2xWYWx1ZSBpcyBhYnNlbnQuICAgDQoKIFRoZXJlIGlz IG5vIGNvcnJlc3BvbmRpbmcgcmVzcG9uc2UgY29udHJvbCBkZWZpbmVkLiANCgogTERBUCBzZXJ2 ZXJzIHRoYXQgc3VwcG9ydCB0aGlzIGNvbnRyb2wgTVVTVCB0cmVhdCBMREFQIA0KIFN1YmVudHJp ZXMgYXMgIm9wZXJhdGlvbmFsIG9iamVjdHMiIGluIG11Y2ggdGhlIHNhbWUgd2F5IA0KIHRoYXQg Im9wZXJhdGlvbmFsIGF0dHJpYnV0ZXMiIGFyZSBub3QgcmV0dXJuZWQgaW4gc2VhcmNoIA0KIHJl c3VsdHMgYW5kIFtYLjUxMV0gcmVhZCBvcGVyYXRpb25zIHdoZW4gb25seSB1c2VyIA0KIGF0dHJp YnV0ZXMgYXJlIHJlcXVlc3RlZC4gIA0KCiBFbnRyaWVzIHdoaWNoIGFyZSBub3QgTERBUCBTdWJl bnRyaWVzIG1heSBzdGlsbCBiZSANCiByZWZlcmVuY2VkIGluIHRoZSBiYXNlIG9iamVjdCBvZiBz ZWFyY2ggb3BlcmF0aW9ucyB3aGVyZSANCiB0aGUgbGRhcFN1YmVudHJpZXNDb250cm9sIGlzIHBy ZXNlbnQgaW4gdGhlIHJlcXVlc3QuICAgDQoKCiA2LjEuMUxEQVAgU2VhcmNoIHdpdGggc2NvcGUg b3RoZXIgdGhhbiBiYXNlT2JqZWN0IA0KCiBUaGUgbGRhcFN1YmVudHJpZXNDb250cm9sIGlzIGRl ZmluZWQgZm9yIExEQVAgdG8gc2lnbmFsIHRvIA0KIExEQVAgU2VhcmNoIG9wZXJhdGlvbnMgdGhh dCBPTkxZIExEQVAgU3ViZW50cmllcyBhcmUgdG8gYmUgDQogaW5jbHVkZWQgaW4gdGhlIHJldHVy biBzZXQgb2YgZW50cmllcyBmb3IgdGhlIFNlYXJjaCwgDQogcHJvdmlkZWQgb3RoZXIgU2VhcmNo IGNyaXRlcmlhIChzdWNoIGFzIHNjb3BlIGFuZCBmaWx0ZXIpIA0KIGFyZSBzYXRpc2ZpZWQuICBX aGVuIGxkYXBTdWJlbnRyaWVzQ29udHJvbCBpcyBOT1QgaW5jbHVkZWQgDQogaW4gYSBTZWFyY2gg cmVxdWVzdCBvbiBhIHNlcnZlciB0aGF0IHN1cHBvcnRzIHRoZSBjb250cm9sLCANCiBMREFQIFN1 YmVudHJpZXMgTVVTVCBiZSBvbWl0dGVkIGZyb20gdGhlIHJldHVybiBzZXQgKHdpdGggDQogdGhl IHNpbmdsZSBleGNlcHRpb24gZGVzY3JpYmVkIGluIFNlYXJjaCBGaWx0ZXIgVmlzaWJpbGl0eSwg DQogYmVsb3cpLiANCgoKIDYuMS4yTERBUCBTZWFyY2ggd2l0aCBzY29wZSBvZiBiYXNlT2JqZWN0 IA0KCiBGb3IgU2VhcmNoIG9wZXJhdGlvbnMgd2l0aCBhIHNjb3BlIHZhbHVlIG9mIGJhc2VPYmpl Y3QsIHRoZSANCiBwcmVzZW5jZSBvciBhYnNlbmNlIG9mIHRoZSBsZGFwU3ViZW50cmllc0NvbnRy b2wgTVVTVCBiZSANCiBpZ25vcmVkLiAgU3BlY2lmaWNhbGx5LCBiYXNlT2JqZWN0IHNlYXJjaGVz IGFwcGxpZWQgdG8gDQogbGRhcFN1YkVudHJ5IGVudHJpZXMgTVVTVCBiZSBldmFsdWF0ZWQgYnkg U2VhcmNoIGFzIGlmIHRoZSANCiBsZGFwU3ViZW50cmllc0NvbnRyb2wgaXMgcHJlc2VudCwgZXZl biBpZiBpdCBpcyBhYnNlbnQuICANCgoKCiBSZWVkICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBbUGFnZSA3XSANCiAgICAgICAgICAgICAgICAgIEV4cGlyZXMg U2VwdGVtYmVyIDEsIDIwMDEgDQogIAwNCgoKIElOVEVSTkVULURSQUZUICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMSBNYXJjaCAyMDAxIA0KICAgICAgICAgICAgICAgICAgICAgTERB UCBTdWJlbnRyeSBTY2hlbWEgDQoKIFRoaXMgcHJvdmlzaW9uIGlzIGludGVuZGVkIHRvIHByZXNl cnZlIHRoZSBiZWhhdmlvciBvZiANCiBbWC41MTFdIFJlYWQgb3BlcmF0aW9ucywgd2hpY2ggYXJl IG5vdCBhZmZlY3RlZCBieSB0aGUgDQogW1guNTExXSBzdWJlbnRyaWVzIGNvbnRyb2wgKHNlZSBD b3JyZXNwb25kZW5jZSB0byBYLjUwMCwgDQogYmVsb3cpLCBhbmQgYmVjYXVzZSBpdCB3b3VsZCBz ZWVtIHNpbGx5IHRvIGJlaGF2ZSANCiBvdGhlcndpc2UuIA0KCgogNi4xLjNPdGhlciBMREFQIG9w ZXJhdGlvbnMgDQoKIFRoZSBsZGFwU3ViZW50cmllc0NvbnRyb2wgaXMgbm90IGRlZmluZWQgZm9y IGFueSBMREFQIA0KIG9wZXJhdGlvbiBvdGhlciB0aGFuIFNlYXJjaC4gIEhvd2V2ZXIsIGFuIExE QVB2MyBFeHRlbnNpb24gDQogTUFZIGRlZmluZSBhIHVzZSBvZiB0aGlzIGNvbnRyb2wgd2l0aCB0 aGF0IGV4dGVuc2lvbiBhcyANCiBsb25nIGFzIHN1Y2ggdXNlIGlzIGNvbnNpc3RlbnQgd2l0aCB0 aGlzIHNwZWNpZmljYXRpb24uIA0KCgogNi4xLjRDb3JyZXNwb25kZW5jZSB0byBYLjUwMCBbWC41 MTFdIA0KCiBJbiBbWC41MTFdIGEgU2VydmljZUNvbnRyb2wgb3B0aW9uIGlzIHVzZWQgdG8gZ292 ZXJuIHRoZSANCiB2aXNpYmlsaXR5IG9mIFtYLjUwMV0gc3ViZW50cmllcy4gIFRoZSBzdWJlbnRy eSANCiBTZXJ2aWNlQ29udHJvbCBvcHRpb24gaXMgYSBzcGVjaWZpYyBiaXQgb2YgYSBiaXRzdHJp bmcgDQogdGhhdCwgd2hlbiBzZXQgdG8gVFJVRSBpbiB0aGUgY29tbW9uIGFyZ3VtZW50cyBvZiBh biBYLjUwMCANCiBTZWFyY2ggb3IgTGlzdCBvcGVyYXRpb24sIGluZGljYXRlcyB0aGF0IHRoZSBv cGVyYXRpb24gaXMgDQogdG8gYWNjZXNzIE9OTFkgdGhlIHN1YmVudHJpZXMgZm91bmQgaW4gdGhl IGNvbnRleHQgb2YgdGhlIA0KIGxpc3Qgb3Igc2VhcmNoLiAgSW4gZmFjdCwgbm9ybWFsIGVudHJp ZXMgYXJlIGV4cGxpY2l0bHkgTk9UIA0KIHJldHVybmVkIGluIHRoZSByZXN1bHQgb2YgYSBsaXN0 IG9yIHNlYXJjaCBvcGVyYXRpb24gd2hlbiANCiB0aGUgWC41MDAgc3ViZW50cmllcyBTZXJ2aWNl Q29udHJvbCBpcyBzZXQuICAgDQoKIEVudHJpZXMgd2hpY2ggYXJlIG5vdCBzdWJlbnRyaWVzIG1h eSBzdGlsbCBiZSByZWZlcmVuY2VkIGluIA0KIHRoZSBiYXNlIG9iamVjdCBvZiBsaXN0IGFuZCBz ZWFyY2ggb3BlcmF0aW9ucyB3aGVyZSB0aGUgDQogc3ViZW50cmllcyBjb250cm9sIGlzIHNldC4g ICANCgogVGhlIFtYLjUxMV0gc3ViZW50cmllcyBTZXJ2aWNlQ29udHJvbCBoYXMgbm8gbWVhbmlu ZyBmb3IgDQogb3BlcmF0aW9ucyBvdGhlciB0aGFuIFNlYXJjaCBhbmQgTGlzdCAoaS5lLiwgUmVh ZCwgTW9kaWZ5LCANCiBEZWxldGUsIGV0Yy4pLiANCgogSW4gW1guNTAxXSwgdGhlIHNjb3BlIG9m IGEgc3ViZW50cnkgaXMgYSBzdWJ0cmVlIG9yIHN1YnRyZWUgDQogcmVmaW5lbWVudC4gIFRoZSBs ZGFwU3ViRW50cnkgY2xhc3MgZGVmaW5lZCBpbiB0aGlzIA0KIGRvY3VtZW50IHByb3ZpZGVzIG5v IG1lY2hhbmlzbSB0byBkZWZpbmUgYSBzdWJ0cmVlIA0KIHJlZmluZW1lbnQuICANCgoKCiA3ICBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyANCgogTERBUCBTdWJlbnRyaWVzIHdpbGwgZnJlcXVlbnRs eSBiZSB1c2VkIHRvIGhvbGQgZGF0YSB3aGljaCANCiByZWZsZWN0cyBlaXRoZXIgdGhlIGFjdHVh bCBvciBpbnRlbmRlZCBiZWhhdmlvciBvZiB0aGUgDQogZGlyZWN0b3J5IHNlcnZpY2UuICBBcyBz dWNoLCBwZXJtaXNzaW9uIHRvIHJlYWQgc3VjaCANCiBlbnRyaWVzIE1BWSBuZWVkIHRvIGJlIHJl c3RyaWN0ZWQgdG8gYXV0aG9yaXplZCB1c2Vycy4gIA0KCiBSZWVkICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA4XSANCiAgICAgICAgICAgICAgICAg IEV4cGlyZXMgU2VwdGVtYmVyIDEsIDIwMDEgDQogIAwNCgoKIElOVEVSTkVULURSQUZUICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgMSBNYXJjaCAyMDAxIA0KICAgICAgICAgICAgICAg ICAgICAgTERBUCBTdWJlbnRyeSBTY2hlbWEgDQoKIE1vcmUgaW1wb3J0YW50bHksIElGIGEgZGly ZWN0b3J5IHNlcnZpY2UgdHJlYXRzIHRoZSANCiBpbmZvcm1hdGlvbiBpbiBhbiBMREFQIFN1YmVu dHJ5IGFzIHRoZSBhdXRob3JpdGF0aXZlIHNvdXJjZSANCiBvZiBwb2xpY3kgdG8gYmUgdXNlZCB0 byBjb250cm9sIHRoZSBiZWhhdmlvciBvZiB0aGUgDQogZGlyZWN0b3J5LCB0aGVuIHBlcm1pc3Np b24gdG8gY3JlYXRlLCBtb2RpZnksIG9yIGRlbGV0ZSANCiBzdWNoIGVudHJpZXMgTVVTVCBiZSBj YXJlZnVsbHkgcmVzdHJpY3RlZCB0byBhdXRob3JpemVkIA0KIGFkbWluaXN0cmF0b3JzLiANCgog VGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSBwb2xpY3kgaW5oZXJpdGFuY2UgbW9kZWwgdGhh dCANCiBhbGxvd3Mgc3Vib3JkaW5hdGUgYWRtaW5pc3RyYXRvcnMgdG8gb3Zlci1yaWRlIHBvbGlj eSANCiBkZWZpbmVkIGJ5IGFkbWluaXN0cmF0b3JzIG9mIGFkbWluaXN0cmF0aXZlIGFyZWFzIHN1 cGVyaW9yIA0KIHRvIHRoZSBsb2NhbCBhZG1pbmlzdHJhdGl2ZSBhcmVhLiAgTm8gbWVjaGFuaXNt IGlzIGRlZmluZWQgDQogaGVyZSB0byBrZWVwIGxvY2FsIGFkbWluaXN0cmF0b3JzIGZyb20gb3Zl ci1yaWRpbmcgc3VjaCANCiBpbmhlcml0ZWQgcG9saWN5LiAgSW1wbGVtZW50YXRpb25zIHRoYXQg aW50ZW5kIHRvIHByb3ZpZGUgDQogc3VjaCBjb250cm9sIG92ZXIgdGhlIGFjdGlvbnMgb2Ygc3Vi b3JkaW5hdGUgYWRtaW5pc3RyYXRvcnMgDQogd2lsbCByZXF1aXJlIGFkZGl0aW9uYWwgc2VtYW50 aWNzIChhbmQgcG9zc2libHkgc3ludGF4KS4gDQoKCgogOCAgUmVmZXJlbmNlcyANCgogW1JGQzIx MTldIFMuIEJyYWRuZXIsICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIA0KIEluZGljYXRl IFJlcXVpcmVtZW50IExldmVscyIsIFJGQyAyMTE5LCBNYXJjaCAxOTk3IA0KCiBbUkZDMjI1MV0g Uy4gS2lsbGUsIE0uIFdhaGwsIGFuZCBULiBIb3dlcywgIkxpZ2h0d2VpZ2h0IA0KIERpcmVjdG9y eSBBY2Nlc3MgUHJvdG9jb2wgKHYzKSIsIFJGQyAyMjUxLCBEZWNlbWJlciAxOTk3IA0KCiBbWC41 MDFdIElUVS1UIFJlYy4gWC41MDEsICJUaGUgRGlyZWN0b3J5OiBNb2RlbHMiLCAxOTkzIGFuZCAN CiBzdWJzZXF1ZW50IHZlcnNpb25zIA0KCiBbWC41MTFdIElUVS1UIFJlYy4gWC41MDEsICJUaGUg RGlyZWN0b3J5OiBBYnN0cmFjdCBTZXJ2aWNlIA0KIERlZmluaXRpb24iLCAxOTkzIGFuZCBzdWJz ZXF1ZW50IHZlcnNpb25zIA0KCiAgDQoKCgogOSAgQ29weXJpZ2h0IE5vdGljZSANCgogQ29weXJp Z2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMCkuIEFsbCBSaWdodHMgDQogUmVzZXJ2 ZWQuICANCiAgDQogVGhpcyBkb2N1bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBj b3BpZWQgYW5kIA0KIGZ1cm5pc2hlZCB0byBvdGhlcnMsIGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRo YXQgY29tbWVudCBvbiANCiBvciBvdGhlcndpc2UgZXhwbGFpbiBpdCBvciBhc3Npc3QgaW4gaXRz IGltcGxlbWVudGF0aW9uIG1heSANCiBiZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQgYW5k IGRpc3RyaWJ1dGVkLCBpbiB3aG9sZSBvciANCiBpbiBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9u IG9mIGFueSBraW5kLCBwcm92aWRlZCB0aGF0IHRoZSANCiBhYm92ZSBjb3B5cmlnaHQgbm90aWNl IGFuZCB0aGlzIHBhcmFncmFwaCBhcmUgaW5jbHVkZWQgb24gDQogYWxsIHN1Y2ggY29waWVzIGFu ZCBkZXJpdmF0aXZlIHdvcmtzLiBIb3dldmVyLCB0aGlzIA0KCiBSZWVkICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA5XSANCiAgICAgICAgICAgICAg ICAgIEV4cGlyZXMgU2VwdGVtYmVyIDEsIDIwMDEgDQogIAwNCgoKIElOVEVSTkVULURSQUZUICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMSBNYXJjaCAyMDAxIA0KICAgICAgICAgICAg ICAgICAgICAgTERBUCBTdWJlbnRyeSBTY2hlbWEgDQoKIGRvY3VtZW50IGl0c2VsZiBtYXkgbm90 IGJlIG1vZGlmaWVkIGluIGFueSB3YXksIHN1Y2ggYXMgYnkgDQogcmVtb3ZpbmcgdGhlIGNvcHly aWdodCBub3RpY2Ugb3IgcmVmZXJlbmNlcyB0byB0aGUgSW50ZXJuZXQgDQogU29jaWV0eSBvciBv dGhlciBJbnRlcm5ldCBvcmdhbml6YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIA0KIGZvciB0aGUg cHVycG9zZSBvZiBkZXZlbG9waW5nIEludGVybmV0IHN0YW5kYXJkcyBpbiB3aGljaCANCiBjYXNl IHRoZSBwcm9jZWR1cmVzIGZvciBjb3B5cmlnaHRzIGRlZmluZWQgaW4gdGhlIEludGVybmV0IA0K IFN0YW5kYXJkcyBwcm9jZXNzIG11c3QgYmUgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIA0K IHRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFuIEVuZ2xpc2guIA0KICANCiBU aGUgbGltaXRlZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIA0K IHdpbGwgbm90IGJlIHJldm9rZWQgYnkgdGhlIEludGVybmV0IFNvY2lldHkgb3IgaXRzIA0KIHN1 Y2Nlc3NvcnMgb3IgYXNzaWducy4gDQogIA0KIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaGVyZWluIGlzIA0KIHByb3ZpZGVkIG9uIGFuICJBUyBJUyIgYmFzaXMg YW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCANCiBUSEUgSU5URVJORVQgRU5HSU5FRVJJTkcg VEFTSyBGT1JDRSBESVNDTEFJTVMgQUxMIA0KIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElF RCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCANCiBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUg VVNFIE9GIFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCANCiBOT1QgSU5GUklOR0UgQU5ZIFJJ R0hUUyBPUiBBTlkgSU1QTElFRCBXQVJSQU5USUVTIE9GIA0KIE1FUkNIQU5UQUJJTElUWSBPUiBG SVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4iIA0KCgogMTAgQWNrbm93bGVkZ2VtZW50 cyANCgogVGhlIHV0aWxpdHkgb2Ygc3ViRW50cnkgb2JqZWN0IGNsYXNzIHdhcyBvcmlnaW5hbGx5 IA0KIHN1Z2dlc3RlZCBhcyBhIG1lYW5zIHRvIHN0b3JlIFJlcGxpY2EgYW5kIFJlcGxpY2F0aW9u IA0KIEFncmVlbWVudCBpbmZvcm1hdGlvbiB3aXRoIGEgdGhlIGx1Y2lkIGV4cGxhbmF0aW9uIGJ5 IE1hcmsgDQogV2FobCwgKHRoZW4gb2YgSW5ub3NvZnQpLCBvZiBob3cgdGhleSBjb3VsZCBiZSB1 c2VkIGFuZCANCiBleHRlbmRlZC4gDQogIA0KIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJl Z2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgDQogb2YgYW55IGludGVsbGVjdHVhbCBwcm9w ZXJ0eSBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSANCiBjbGFpbWVkIHRvIHBlcnRhaW4g dG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgDQogdGVjaG5vbG9neSBkZXNjcmli ZWQgaW4gdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIA0KIHdoaWNoIGFueSBsaWNlbnNl IHVuZGVyIHN1Y2ggcmlnaHRzIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSANCiBhdmFpbGFibGU7IG5l aXRoZXIgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMgbWFkZSBhbnkgDQogZWZmb3J0IHRv IGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gSW5mb3JtYXRpb24gb24gdGhlIA0KIElFVEYncyBw cm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gc3RhbmRhcmRzLXRyYWNrIA0KIGFu ZCBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0aW9uIGNhbiBiZSBmb3VuZCBpbiBCQ1AtMTEu IA0KIENvcGllcyBvZiBjbGFpbXMgb2YgcmlnaHRzIG1hZGUgYXZhaWxhYmxlIGZvciBwdWJsaWNh dGlvbiANCiBhbmQgYW55IGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFi bGUsIG9yIHRoZSANCiByZXN1bHQgb2YgYW4gYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVy YWwgbGljZW5zZSBvciANCiBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mIHN1Y2ggcHJvcHJpZXRh cnkgcmlnaHRzIGJ5IA0KIGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzIHNwZWNpZmljYXRp b24gY2FuIGJlIG9idGFpbmVkIA0KIGZyb20gdGhlIElFVEYgU2VjcmV0YXJpYXQuIA0KICANCiBU aGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyANCiBh dHRlbnRpb24gYW55IGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywg DQogb3Igb3RoZXIgcHJvcHJpZXRhcnkgcmlnaHRzIHdoaWNoIG1heSBjb3ZlciB0ZWNobm9sb2d5 IHRoYXQgDQoKIFJlZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgW1BhZ2UgMTBdIA0KICAgICAgICAgICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMSwgMjAw MSANCiAgDA0KCgogSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAxIE1hcmNoIDIwMDEgDQogICAgICAgICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVt YSANCgogbWF5IGJlIHJlcXVpcmVkIHRvIHByYWN0aWNlIHRoaXMgc3RhbmRhcmQuIFBsZWFzZSBh ZGRyZXNzIA0KIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBFeGVjdXRpdmUgRGlyZWN0b3Iu IA0KCgogMTEgQXV0aG9yJ3MgQWRkcmVzcyANCgogICAgICBFZHdhcmRzIEUuIFJlZWQgDQogICAg ICBSZWVkLU1hdHRoZXdzLCBJbmMuIA0KICAgICAgMTA2NCBFIDE0MCBOb3J0aCANCiAgICAgIExp bmRvbiwgVVQgIDg0MDQyIA0KICAgICAgVVNBIA0KICAgICAgRS1tYWlsOiBlZXJAb25jYWxsZGJh LmNvbSAgDQogICAgICAgDQogICAgICBMRFVQIE1haWxpbmcgTGlzdDogaWV0Zi1sZHVwQGltYy5v cmcgIA0KICAgICAgTERBUEVYVCBNYWlsaW5nIExpc3Q6IGlldGYtbGRhcGV4dEBuZXRzY2FwZS5j b20gDQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKIFJlZWQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTFdIA0KICAgICAgICAgICAg ICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMSwgMjAwMSANCiAgDA== --=_E9B240F7.DCBDD149-- From owner-ietf-ldup@mail.imc.org Thu Mar 1 22:25:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03708 for ; Thu, 1 Mar 2001 22:25:09 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id TAA09749 for ietf-ldup-bks; Thu, 1 Mar 2001 19:01:04 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA09745 for ; Thu, 1 Mar 2001 19:01:03 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id TAA12070; Thu, 1 Mar 2001 19:00:41 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id ABC07011; Thu, 1 Mar 2001 19:00:35 -0800 (PST) Message-Id: <4.3.2.7.2.20010301145038.00b8b5e8@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Mar 2001 19:00:30 -0800 To: From: John Strassner Subject: Re: Clear explicit recommendation for corrective action Cc: In-Reply-To: <003101c0a1ee$5094eec0$6628a8c0@nowhere.com> References: <4.3.2.7.2.20010219100603.00b4bab0@mira-sjcm-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Albert, As WG Co-Chair, I have four things to say to you: first, concerning your arguing over the following statement: > >An applicability statement should clearly indicate > >that multi-master is unsuitable in any situation with a high rate of > >concurrent changes to the same entries. the problem with this statement is that this is a requirements document, and "high rate" is not quantified. We developed a consensus in the mail list on the wording change, and the requirements authors implemented that wording change. Some additional detail may show up in subsequent documents, but the point is that, for the requirements document, this issue is closed. If you still disagree, I'm happy to discuss this with you in private, or you can appeal to our ADs. Second, I thought you had agreed to stop making derisive, inflammatory remarks. Your text below is both: >[Albert] >The problem I see is that John believes the WG has reached a conclusion >when he forms an opinion, or even when he is merely "confused", that >everyone has agreed when he has changed his mind, and that no one could >come up with a reasonable answer to a question that has not been asked. PLEASE STOP MAKING SUCH COMMENTS. The mail list is for technical discussions only, not for expressing insults. Third, I note that you write: >Unlike normal WG technical business I do not believe this problem can >best be resolved through email discussions and I am not calling for such >a discussion now. It is better suited to face to face meetings. It might be nice if you practice what you preach and actually show up to a meeting to argue your point. Finally, concerning your "corrective action" diatribe, a WG Co-Chair has the power to declare consensus, especially to keep the working group going. This also includes stopping discussions when something has already been decided, which I have tried to get you to do. Patrik has even sent a mail to you pointing this out. Please read RFC 2418, and please stop this type of communication on the wg list. Please instead keep to technical issues, and try not to express frustration, emotion, etc. in your comments. John Strassner WG Co-Chair, LDUP WG From owner-ietf-ldup@mail.imc.org Thu Mar 1 22:39:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04934 for ; Thu, 1 Mar 2001 22:39:48 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id TAA10037 for ietf-ldup-bks; Thu, 1 Mar 2001 19:15:56 -0800 (PST) Received: from ps2.walltech.com (ps2.walltech.com [207.5.77.1]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA10033 for ; Thu, 1 Mar 2001 19:15:55 -0800 (PST) Received: from dtasi1.directory-applications.com (dsl081-050-175-sea1.dsl-isp.net [64.81.50.175]) by ps2.walltech.com (8.11.1/8.11.1/walltech-2.14) with ESMTP id f223FuV14550; Thu, 1 Mar 2001 19:15:56 -0800 (PST) Message-Id: <5.0.2.1.2.20010301190738.00a8a7e0@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 01 Mar 2001 19:15:19 -0800 To: John Strassner From: Bruce Greenblatt Subject: Re: Clear explicit recommendation for corrective action Cc: In-Reply-To: <4.3.2.7.2.20010301145038.00b8b5e8@mira-sjcm-1.cisco.com> References: <003101c0a1ee$5094eec0$6628a8c0@nowhere.com> <4.3.2.7.2.20010219100603.00b4bab0@mira-sjcm-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 07:00 PM 3/1/2001 -0800, John Strassner wrote: Second, I thought you had agreed to stop making derisive, inflammatory remarks. Your text below is both: >>[Albert] >>The problem I see is that John believes the WG has reached a conclusion >>when he forms an opinion, or even when he is merely "confused", that >>everyone has agreed when he has changed his mind, and that no one could >>come up with a reasonable answer to a question that has not been asked. > >PLEASE STOP MAKING SUCH COMMENTS. The mail list is for technical >discussions only, not for expressing insults. I mostly just lurk on the LDUP list, but I've been involved with standards development for about 12 years now in a wide variety of organizations (CCITT, ISO, Open Group, XAPIA, EMA, IETF, etc.). It's been a while since I've seen anything like this. (I think that I'll make the meeting in Utah, buy me a root beer then, and I'll tell you about it). I have to agree very strongly with John! Make your technical arguments here. If people don't agree with you, that's their loss. If you think that people don't understand what you're saying, don't indicated that they are stupid or "confused". Write up a draft of your own and submit it as a personal submission. I'll go back to lurking now... Bruce ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com See my new Book on Internet Directories: http://www.phptr.com/ptrbooks/ptr_0139744525.html From owner-ietf-ldup@mail.imc.org Thu Mar 1 23:05:31 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05371 for ; Thu, 1 Mar 2001 23:05:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id SAA08822 for ietf-ldup-bks; Thu, 1 Mar 2001 18:17:38 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA08818 for ; Thu, 1 Mar 2001 18:17:35 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA25281; Thu, 1 Mar 2001 18:17:23 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id ABC06304; Thu, 1 Mar 2001 18:16:50 -0800 (PST) Message-Id: <4.3.2.7.2.20010301175716.00b7d848@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Mar 2001 18:16:45 -0800 To: rvh@qsun.mt.att.com (Richard V Huber) From: John Strassner Subject: Re: New LDUP requirements draft Cc: ietf-ldup@imc.org, rmoats@coreon.com, rweiser@digsigtrust.com, stokes@austin.ibm.com In-Reply-To: <200103011843.NAA29135@qsun.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Rick, and other authors of the requirements draft, thanks for addressing these issues, and working hard to get this update in before the deadline. Since this is a long note in response to a set of action items that I gave you, I'm bringing up a couple of points where you took an alternate action, to which I am responding as WG Co-Chair: > >Part I Sub-issue 4: locking >... > >Action: a brief explanatory note pointing this out should be added to the > >requirements I-D. > >-A quorum of the authors of both the requirement and profile I-Ds feel >that this is incorrect. Discussion of locking is aimed at the application >developer, not at replication, and so should be properly included in >the profile I-D. The profile I-D authors are willing to add this to the >profile I-D As WG Co-Chair, this action is fine, as it meets the spirit of my action item. > >Part I Sub-issue 7: removal of P6 (atomicity information) >... > >Action: This requirement needs to be explained and justified in the I-D. > >The I-D should answer the question of whether it is propagating end-state > >or propagating a set of operations required to replicate that end-state, > >and WHY it is doing so. > >-We feel that discussion of propagating end state vs. changes is about >implementation. Rather, P6 (now P7 due to other changes) has been >rewritten to explicitly require propagation of atomicity of LDAP >operations as defined in RFC 2251. We feel it is now self justifying. As WG Co-Chair, this action meets my action item. > >Kurt is objecting to the introduction of LDUP-specific terminology. > >... > > 1. Kurt, please delineate the terms that you feel are being redefined. > > 2. Authors, please respond, indicating how the I-D will change. > > 3. The WG will evaluate the response. > >-As a result of issues Kurt has raised, we have replaced naming context with >"replication base entry". However, we disagree that "area of replication" >here is different from X.525 replicated area and have indicated this in >the definition of "area of replication" > >-We have deprecated "updateable replicas" where used. As WG Co-Chair, this meets items 1 and 2 above. Item 3 will be met by the WG responding to the new draft. > >Part IV > >Issue 1: if we start singling out particular types of information that can > >or can not be replicated, where do we stop? >... > >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. > >-Kurt proposed some text in a separate piece of email and after review >and some rearrangement, the text is acceptable to the authors as >requirements G9, G10, G11. With these requirements, we have removed >the partial example list in the last paragraph of section 3 as >discussion of that paragraph on the mailing list has not led to working >group consensus. As WG Co-Chair, this action meets the requirements of my action item. It is now up to the WG to accept this new text. > >Part V > > > >Issue 1: models and atomicity >... > >Action: I didn't see any other support from the WG, but this does seem > >reasonable. Therefore, could Kurt please get with the authors and agree to > >mutually acceptable wording? > >-We have added a statement that model 1 may ease support of atomicity in >multi-master systems As WG Co-Chair, this action meets my action item. regards, John Strassner, Co-Chair, LDUP WG At 01:43 PM 3/1/2001 -0500, Richard V Huber wrote: >I-D editor: > >Please publish the attached I-D as draft-ietf-ldup-replica-req-07. > >LDUP: > >Thanks for all the comments. The authors have sat down and gone through >John's action items (as well as other requests) and compiled a list >of changes, along with the -07 draft. The following is John's issue list >(rearranged with origin part # and internal issues lists) and our actions. > > >Part I Sub-issue 2: text describing objectives (in Section 3), clarity > of text > >Some people wondered if the text was clear enough in pointing out that LDUP > >was providing "...interoperability between directories rather than between > >their representations". I think that, in order to move on, it would be > >helpful to have a brief sentence or two added to the draft that clarifies > >this point. > > > >Action: add clarification that when LDUP is used to replicate information > >that is interpreted by a directory server in ways that are not >standardized > >by LDAP, the results are unpredictable. > > > >Part III > >First, Kurt recommends that "...the requirement I-D needs to state that > >"application-level interoperability" will not be guaranteed by the > >protocol, but may be resolvable by applicability statements (profiles). In > >the end, "application interoperability" requires that all replicas > >implement the same features in the same manner and this, IMO, is beyond the > >scope of LDUP". > > > >Action: this seems very reasonable. Authors, please work with Kurt and > >incorporate an addition to this effect in the requirements I-D. > > > >Part V, Issue 2: interoperability > > > >Kurt pointed out that interoperability may also be limited by servers that > >implement semantics that implement optional features which LDAP defines > >(such as subtypes). > > > >Action: this is a good point, please add this to the requirements I-D > >-We have rewritten the interoperability paragraph at the end of section >three to address all of the above issues, as we see them as related. >The current paragraph is worded to address the fact that interoperability >is more than just the application level. > > >Part I Sub-issue 4: locking > >Locking is not germane to the requirements draft. It is up to the > >architecture and other drafts, as required, to address locking. However, > >several people have suggested that if developers attempt to create their > >own locking or other similar control mechanisms, the requirements draft > >should state that they do so at their own peril when operating against > >directories supporting LDUP. I agree. > > > >Action: a brief explanatory note pointing this out should be added to the > >requirements I-D. > >-A quorum of the authors of both the requirement and profile I-Ds feel >that this is incorrect. Discussion of locking is aimed at the application >developer, not at replication, and so should be properly included in >the profile I-D. The profile I-D authors are willing to add this to the >profile I-D > > >Part I Sub-issue 6: noting unsuitability of LDUP for environments with > >"high rate of change" > >While everyone agrees with this, no one could come up with a reasonable > >definition of "high rate of change". However, there is consensus that this > >should not be specified in the requirements draft, but rather in other > >drafts (architecture and profile are obvious candidates). A suggestion was > >to change in section B.5.5 from "They are changing the data at the same > >time" to "They are changing the data before previous changes have > replicated". > > > >Action: change in section B.5.5 from "They are changing the data at the > >same time" to "They are changing the data before previous changes have > >replicated". > >-So changed > > >Part I Sub-issue 7: removal of P6 (atomicity information) > >We've had one argument and one reply which said "yes it does" without > >technical justification. The request centered around replicating and > >converging state, and defined atomicity in an application-specific sense. > >While I don't believe that the requirements draft was concerned with > >application-specific atomicity information, I do think that this needs a > >response, and likely better definition of what, specifically, propagating > >atomicity information means. > > > >Action: This requirement needs to be explained and justified in the I-D. > >The I-D should answer the question of whether it is propagating end-state > >or propagating a set of operations required to replicate that end-state, > >and WHY it is doing so. > >-We feel that discussion of propagating end state vs. changes is about >implementation. Rather, P6 (now P7 due to other changes) has been >rewritten to explicitly require propagation of atomicity of LDAP >operations as defined in RFC 2251. We feel it is now self justifying. > > >Part II Issue: > >Kurt is objecting to the introduction of LDUP-specific terminology. He's > >worried that many terms defined in the requirements I-D redefine many > >existing LDAP/X.500 > >terms, and wants to see existing LDAP/X.500 terminology used wherever > >possible. > > > >However, the problem is that Kurt has not identified the specific terms > >that he is objecting to. > > > >Actions: > > 1. Kurt, please delineate the terms that you feel are being redefined. > > 2. Authors, please respond, indicating how the I-D will change. > > 3. The WG will evaluate the response. > >-As a result of issues Kurt has raised, we have replaced naming context with >"replication base entry". However, we disagree that "area of replication" >here is different from X.525 replicated area and have indicated this in >the definition of "area of replication" > >-We have deprecated "updateable replicas" where used. As WG Co-Chair, this satisfies actions 1 and 2 above. The WG now n > >Second, Kurt notes that the I-D's Security Considerations section says that > >specific issues are being addressed in RFC 2820 (and the work in progress) > >when this is clearly not the case. > > > >Action: Authors, please work with Kurt and fix this. > >-We have clarified the last sentence of the security section to explicitly >note the ACL work ongoing in LDAPEXT. > > >Part IV > >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. > >-Kurt proposed some text in a separate piece of email and after review >and some rearrangement, the text is acceptable to the authors as >requirements G9, G10, G11. With these requirements, we have removed >the partial example list in the last paragraph of section 3 as >discussion of that paragraph on the mailing list has not led to working >group consensus. > > >Part V > > > >Issue 1: models and atomicity > > > >There was disagreement in how to describe this. Kurt thought that the extra > >functionality that was provided by Model 1 wasn't adequately expressed. But > >the authors didn't like his wording changes because they thought that model > >2 would be able to support atomicity, at least in some limited cases like > >single-master.g > > > >Action: I didn't see any other support from the WG, but this does seem > >reasonable. Therefore, could Kurt please get with the authors and agree to > >mutually acceptable wording? > >-We have added a statement that model 1 may ease support of atomicity in >multi-master systems > >Additional changes > >-We have reworded M3 to correspond to Steven Legg's comments. > >-Section A.10 has been modified to be self consistent. > >-We have replaced "replica-ring" with "replica-group" to not imply any >topology. > >-Additional changes per previous email to the list >(http://www.imc.org/ietf-ldup/mail-archive/msg00884.html and >http://www.imc.org/ietf-ldup/mail-archive/msg00881.html) are included >in this version. > >-As a result of some of the above changes, the "P" requirements were >renumbered. > >Having made technical changes to the requirements, we request that >(without additional changes) another WG last call be declared on 3/26. > >Ryan, Russ, Rick, Ellen > >--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- > > > >Internet-Draft Ellen J. Stokes >LDAP Duplication/Replication/Update Tivoli Systems >Protocols WG Russel F. Weiser >Intended Category: Informational Digital Signature Trust >Expires: September 2001 Ryan D. Moats > Coreon, Inc. > Richard V. Huber > AT&T Laboratories > March 2001 > > > > LDAPv3 Replication Requirements > draft-ietf-ldup-replica-req-07.txt > >Status of This Memo > >This document is an Internet-Draft and is in full conformance with all >provisions of Section 10 of RFC2026. > >Internet-Drafts are working documents of the Internet Engineering Task >Force (IETF), its areas, and its working groups. Note that other >groups may also distribute working documents as Internet-Drafts. > >Internet-Drafts are draft documents valid for a maximum of six months >and may be updated, replaced, or obsoleted by other documents at any >time. It is inappropriate to use Internet-Drafts as reference material >or to cite them other than as "work in progress." > >The list of current Internet-Drafts can be accessed at >http://www.ietf.org/ietf/lid-abstracts.txt. > >The list of Internet-Drafts Shadow Directories can be accessed at >http://www.ietf.org/shadow.html. > >Copyright Notice > >Copyright (C) The Internet Society (2000). All Rights Reserved. > > >Abstract > >This document discusses the fundamental requirements for replication of >data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be >a gathering place for general replication requirements needed to >provide interoperability between informational directories. > > >Stokes, et al Expires September 2001 [Page 1] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >document are to be interpreted as described in [RFC2119]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Stokes, et al Expires February 2001 [Page 2] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >Table of Contents > > >1 Introduction.......................................................4 >2 Terminology........................................................4 >3 The Models.........................................................7 >4 Requirements.......................................................8 > 4.1 General.........................................................8 > 4.2 Model...........................................................9 > 4.3 Protocol.......................................................10 > 4.4 Schema.........................................................11 > 4.5 Single Master..................................................11 > 4.6 Multi-Master...................................................11 > 4.7 Administration and Management..................................12 > 4.8 Security.......................................................13 >5 Security Considerations...........................................13 >6 Acknowledgements..................................................13 >7 References........................................................13 >A.APPENDIX A - Usage Scenarios......................................15 > A.1.Extranet Example...............................................15 > A.2.Consolidation Example..........................................15 > A.3.Replication Heterogeneous Deployment Example...................15 > A.4.Shared Name Space Example......................................16 > A.5.Supplier Initiated Replication.................................16 > A.6.Consumer Initiated Replication.................................16 > A.7.Prioritized attribute replication..............................17 > A.8.Bandwidth issues...............................................17 > A.9.Interoperable Administration and Management....................17 > A.10.Enterprise Directory Replication Mesh.........................18 > A.11.Failure of the Master in a Master-Slave Replicated Directory..18 > A.12.Failure of a Directory Holding Critical Service Information...19 >B.APPENDIX B - Rationale............................................19 > B.1.Meta-Data Implications.........................................19 > B.2.Order of Transfer for Replicating Data.........................19 > B.3.Schema Mismatches and Replication..............................20 > B.4.Detecting and Repairing Inconsistencies Among Replicas.........21 > B.5.Some Test Cases for Conflict Resolution in Multi-Master > Replication........................................................22 > B.6.Data Privacy During Replication................................26 > B.7.Failover in Single-Master Systems..............................26 > B.8.Including Operational Attributes in Atomic Operations..........27 >Authors' Addresses..................................................28 >Full Copyright Statement............................................28 > > > > > > >Stokes, et al Expires February 2001 [Page 3] >Internet-Draft LDAPv3 Replication Requirements March 2001 > > > > >1 Introduction > >Distributing directory information throughout the network provides a >two-fold benefit: (1) it increases the reliability of the directory >through fault tolerance, and (2) it brings the directory content closer >to the clients using the data. LDAP's success as an access protocol >for directory information is driving the need to distribute LDAP >directory content within the enterprise and Internet. Currently, LDAP >does not define a replication mechanism, and mentions LDAP shadow >servers (see [RFC2251]) in passing. A standard mechanism for directory >replication in a multi-vendor environment is critical to the continued >success of LDAP in the market place. > >This document sets out the requirements for replication between >multiple LDAP servers. While RFC 2251 and RFC 2252 [RFC2252] set forth >the standards for communication between LDAP clients and servers there >are additional requirements for server-to-server communication. Some >of these are covered here. > >This document first introduces the terminology to be used, then >presents the different replication models being considered. >Requirements follow, along with security considerations. The reasoning >that leads to the requirements is presented in the Appendices. This >was done to provide a clean separation of the requirements from their >justification. > >2 Terminology > >The following terms are used in this document: > >Area of replication - A whole or portion of a Directory Information >Tree (DIT) that makes up a distinct unit of data to be replicated. An >area of replication is defined by a replication base entry and includes >all or some of the depending entries contained therein on a single >server. It divides directory data into partitions whose propagation >behavior may be independently configured from other partitions. Areas >of replication may overlap or be nested. Also known as a "replicated >area" in X.525 [X.525]. > >Atomic operation - A set of changes to directory data which the LDAP >standards guarantee will be treated as a unit; all changes will be made >or all the changes will fail. > >Atomicity Information - Information about atomic operations passed as >part of replication. >Stokes, et al Expires February 2001 [Page 4] >Internet-Draft LDAPv3 Replication Requirements March 2001 > > >Conflict - A situation that arises when changes are made to the same >directory data on different directory servers before replication can >synchronize the data on the servers. When the servers do synchronize, >they have inconsistent data - a conflict. > >Conflict resolution - Deterministic procedures used to resolve change >information conflicts that may arise during replication. > >Critical OID - Attributes or object classes defined in the replication >agreement as being critical to the operation of the system. Changes >affecting critical OIDs cause immediate initiation of a replica cycle. >An example of a critical OID might be a password or certificate. > >Fractional replication - The capability to filter a subset of >attributes for replication. > >Incremental Update - An update that contains only those attributes or >entries that have changed. > >Master Replica - A replica that may be directly updated via LDAP >operations. In a Master-Slave Replication system, the Master Replica >is the only directly updateable replica in the replica-group. > >Master-Slave, or Single Master Replication - A replication model that >assumes only one server, the master, allows LDAP write access to the >replicated data. Note that Master-Slave replication can be considered >a proper subset of multi-master replication. > >Meta-Data - Data collected by the replication system that describes the >status/state of replication. > >Multi-Master Replication - A replication model where entries can be >written and updated on any of several master replica copies without >requiring communication with other master replicas before the write or >update is performed. > >Replication base entryOne-way Replication - The process of >synchronization in a single direction where the authoritative source >information is provided to a replica. > >Partial Replication - Partial Replication is Fractional Replication, >Sparse Replication, or both. > >Propagation Behavior - The behavior of the synchronization process >between a consumer and a supplier. > > > >Stokes, et al Expires February 2001 [Page 5] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >Replica - An instance of an area of replication on a server.replication >base entry > >Replica-Group - The servers that hold instances of a particular area of >replication. A server may be part of several replica-groups. > >Replica (or Replication) Cycle - The interval during which update >information is exchanged between two or more replicas. It begins >during an attempt to push data to, or pull data from, another replica >or set of replicas, and ends when the data has successfully been >exchanged or an error is encountered. > >Replication - The process of synchronizing data distributed across >directory servers and rectifying update conflicts. > >Replication Agreement - A collection of information describing the >parameters of replication between two or more servers in a replica- >group. > >Replication Base Entry - The distinguished name of the root vertex of a >replicated area. > >Replication Initiation Conflict - A Replication Initiation Conflict is >a situation where two sources want to update the same replica at the >same time. > >Replication Session - A session set up between two servers in a >replica-group to pass update information as part of a replica cycle. > >Slave (or Read-Only) Replica - A replica that cannot be directly >updated via LDAP requests. Changes may only be made via replication >from a master replica. Read-only replicas may occur in both single- >and multi-master systems. > >Sparse Replication - The capability to filter some subset of entries >(other than a complete collection) of a replication base entry for >replication. > >Topology - The shape of the directed graph describing the relationships >between replicas. > >Two-way Replication - The process of synchronization where change >information flows bi-directionally between two replicas. > >Update Propagation - Protocol-based process by which directory replicas >are reconciled. > > > >Stokes, et al Expires February 2001 [Page 6] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >3 The Models > >The objective is to provide an interoperable, LDAP v3 directory >synchronization protocol that is simple, efficient and flexible; >supporting both multi-master and master-slave replication. The >protocol must meet the needs of both the Internet and enterprise >environments. > >There are five data consistency models. > >Model 1: Transactional Consistency -- Environments that exhibit all >four of the ACID properties (Atomicity, Concurrency, Independence, >Durability) [ACID]. > >Model 2: Eventual (or Transient) Consistency -- Environments where >definite knowledge of the topology is provided through predetermined >replication agreements. Examples include X.500 Directories (the X.500 >model is single-master only) [X.501, X.525], Bayou [XEROX], and NDS >(Novell Directory Services) [NDS]. In this model, every update >propagates to every replica that it can reach via a path of stepwise >eventual connectivity. > >Model 3: Limited Effort Eventual (or Probabilistic) Consistency -- >Environments that provide a statistical probability of convergence with >knowledge of topology. An example is the Xerox Clearinghouse [XEROX]. >This model is similar to "Eventual Consistency", except where replicas >may purge updates. Purging drops propagation changes when some replica >time boundary is exceeded, thus leaving some changes replicated to only >a portion of the topology. Transactional consistency is not preserved, >though some weaker constraints on consistency are available. > >Model 4: Loosest Consistency -- Environments where information is >provided from an opportunistic or simple cache until stale. Complete >knowledge of topology may not be shared among all replicas. > >Model 5: Ad hoc -- A copy of a data store where no follow up checks are >made for the accuracy/freshness of the data. > >Consistency models 1, 2 and 3 involve the use of prearranged >replication agreements among servers. While model 1 may simplify >support for atomicity in multi-master systems, the added complexity of >the distributed 2-phase commit required for Model 1 is significant; >therefor, model 1 will not be considered at this time. Models 4 and 5 >involve unregistered replicas that "pull" updates from another >directory server without that server's knowledge. These models violate >a directory's security policies. > > > >Stokes, et al Expires February 2001 [Page 7] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >Models 2 and 3 illustrate two replication scenarios that must be >handled: policy configuration through security management parameters >(model 2), and hosting relatively static data and address information >as in white-pages applications (model 3). Therefore, replication >requirements are presented for models 2 and 3. > >Interoperability among directories using LDUP replication may be >limited for implementations that add semantics beyond those specified >by the LDAP core documents (RFC 2251-2256, 2829, 2830). > > >4 Requirements > > >4.1 General > >G1. LDAP Replication MUST support models 2 (Eventual Consistency) and >3 (Limited Effort Eventual Consistency) above. > >G2. LDAP Replication SHOULD NOT preclude support for model 1 >(Transactional Consistency) in the future. > >G3. LDAP replication SHOULD have minimal impact on both the system and >network performance. > >G4. The LDAP Replication Standard SHOULD NOT limit the replication >transaction rate. > >G5. The LDAP replication standard SHOULD NOT limit the size of an area >of replication or a replica. > >G6. Meta-data collected by the LDAP replication mechanism MUST NOT >grow without bound. > >G7. All policy and state data pertaining to replication MUST be >accessible via LDAP. > >G8. The LDAP replication standard SHOULD NOT preclude support of >Transactional Consistency (model 1). > >G9. LDAP replication MUST be capable of replicating the following: > > - all userApplication attribute types > - all directoryOperation and distributedOperation attribute > types defined in the LDAP "core" specifications (RFC 2251- > 2256, 2829-2830) > - attribute subtypes > > >Stokes, et al Expires February 2001 [Page 8] >Internet-Draft LDAPv3 Replication Requirements March 2001 > > - attribute description options (e.g. ";binary" and Language > Tags) > >G10. LDAP replication SHOULD support replication of directoryOperation >and distributedOperation attribute types defined in standards track >LDAP extensions. Future standards track specifications MUST include a >"Replication Considerations" section which indicates how and whether >the new feature operates in a replicated environment. > >G11. LDAP replication MUST NOT support replication of dsaOperation >attribute types as such attributes are DSA-specific. > > >4.2 Model > >M1. The model MUST support the following triggers for initiation of a >replica cycle: > > a) A configurable set of scheduled times > b) Periodically, with a configurable period between replica cycles > c) A configurable maximum amount of time between replica cycles > d) A configurable number of accumulated changes > e) Change in the value of a critical OID > f) As the result of an automatic rescheduling after a replication > initiation conflict > g) A manual request for immediate replication > >With the exception of manual request, the specific trigger(s) and >related parameters for a given server MUST be identified in a well- >known place defined by the standard, e.g. the Replication Agreement(s). > >M2. The replication model MUST support both master-slave and multi- >master relationships. > >M3. An attribute in an entry must eventually converge to the same set >of values in every replica holding that entry. > >M4. LDAP replication MUST encompass schema definitions, attribute >names and values, access control information, knowledge information, >and name space information. > >M5. LDAP replication MUST NOT require all copies of the replicated >information to be complete copies of the replicated object. The model >MUST support Partial Replicas. > >M6. The determination of which OIDs are critical MUST be configurable >in the replication agreement. > > >Stokes, et al Expires February 2001 [Page 9] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >M7. The parameters of the replication process among the members of the >replica-group, including access parameters, necessary authentication >credentials, and assurances of confidentiality (encryption) MUST be >defined in a standard location (e.g. the replication agreements). > >M8. The replication agreements SHOULD accommodate multiple servers >receiving the same area of replication under a single predefined >agreement. > >M9. LDAP replication MUST provide scalability to both enterprise and >Internet environments, e.g. an LDAP server must be able to provide >replication services to replicas within an enterprise as well as across >the Internet. > >M10. While different directory implementations can support >different/extended schema, schema mismatches between two replicating >servers MUST be handled. One way of handling such mismatches might be >to raise an error condition. > >M11. There MUST be a facility that can update, or totally refresh, a >replica-group from a standard data format, such as LDIF format >[RFC2849]. > >4.3 Protocol > >P1. The replication protocol MUST provide for recovery and >rescheduling of a replication session due to replication initiation >conflicts (e.g. consumer busy replicating with other servers) and or >loss of connection (e.g. supplier cannot reach a replica). > >P2. LDUP replication SHOULD NOT send an update to a consumer if the >consumer has previously acknowledged that update. > >P3. An update received by a consumer more than once MUST NOT produce >a different outcome than if the update were received only once. > >P4. The LDAP replication protocol MUST allow for full update to >facilitate replica initialization and reset loading utilizing a >standardized format such as LDIF [RFC2849] format. > >P5. Incremental replication MUST be allowed. > >P6. The replication protocol MUST allow either a master or slave >replica to initiate the replication process. > >P7. The protocol MUST preserve atomicity of LDAP operations as defined >in RFC2251 [RFC2251]. > > >Stokes, et al Expires February 2001 [Page 10] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >P8. The protocol MUST support a mechanism to report schema mismatches >between replicas discovered during a replication session. > > >4.4 Schema > >SC1. A standard way to determine what replicas are held on a server >MUST be defined. > >SC2. A standard schema for representing replication agreements MUST be >defined. > >SC3. The semantics associated with modifying the attributes of >replication agreements MUST be defined. > >SC4. A standard method for determining the location of replication >agreements MUST be defined. > >SC5. A standard schema for publishing state information about a given >replica MUST be defined. > >SC6. A standard method for determining the location of replica state >information MUST be defined. > >SC7. It MUST be possible for appropriately authorized administrators, >regardless of their network location, to access replication agreements >in the DIT. > >SC8. Replication agreements of all servers containing replicated >information MUST be accessible via LDAP. > >SC9. An entry MUST be uniquely identifiable throughout its lifetime. > >4.5 Single Master > >SM1. A Single Master system SHOULD provide a fast method of promoting >a slave replica to become the master replica. > >SM2. The master replica in a Single Master system SHOULD send all >changes to read-only replicas in the order in which the master applied >them. > > >4.6 Multi-Master > >MM1. The replication protocol SHOULD NOT saturate the network with >redundant or unnecessary entry replication. > > >Stokes, et al Expires February 2001 [Page 11] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >MM2. The initiator MUST be allowed to determine whether it will become >a consumer or supplier during the synchronization startup process. > >MM3. During a replica cycle, it MUST be possible for the two servers >to switch between the consumer and supplier roles. > >MM4. When multiple master replicas want to start a replica cycle with >the same replica at the same time, the model MUST have an automatic and >deterministic mechanism for resolving or avoiding replication >initiation conflict. > >MM5. Multi-master replication MUST NOT lose information during >replication. If conflict resolution would result in the loss of >directory information, the replication process MUST store that >information, notify the administrator of the nature of the conflict and >the information that was lost, and provide a mechanism for possible >override by the administrator. > >MM6. Multi-master replication MUST support convergence of the values >of attributes and entries. Convergence may result in an event as >described in MM5. > >MM7. Multi-master conflict resolution MUST NOT depend on the in-order >arrival of changes at a replica to assure eventual convergence. > >4.7 Administration and Management > >AM1. Replication agreements MUST allow the initiation of a replica >cycle to be administratively postponed to a more convenient period. > >AM2. Each copy of a replica MUST maintain audit history information of >which servers it has replicated with and which servers have replicated >with it. > >AM3. Access to replication agreements, topologies, and policy >attributes MUST be provided through LDAP. > >AM4. The capability to check the differences between two replicas for >the same information SHOULD be provided. > >AM5. A mechanism to fix differences between replicas without triggering >new replica cycles SHOULD be provided. > >AM6. The sequence of updates to access control information (ACI)_and >the data controlled by that ACI MUST be maintained by replication. > > > > >Stokes, et al Expires February 2001 [Page 12] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >AM7. It MUST be possible to add a 'blank' replica to a replica-group, >and force a full update from (one of) the Master(s), for the purpose of >adding a new directory server to the system. > >AM8. Vendors SHOULD provide tools to audit schema compatibility within >a potential replica-group. > > >4.8 Security > >S1. During initiation of a replication session, authentication and >verification of authorization of both the replica and the source >directory MUST be allowed before any data is transferred. > >S2. The transport for LDAP synchronization MUST permit assurance of >the integrity and privacy of all data transferred. > >S3. To promote interoperability, there MUST be a mandatory-to- >implement data privacy mechanism. > >S4. The transport for administrative access MUST permit assurance of >the integrity and privacy of all data transferred. > >5 Security Considerations > >This document includes security requirements (listed in section 4.8 >above) for the replication model and protocol. As noted in Section 3, >security may be impacted when replicating among servers that implement >non-standard extensions to basic LDAP semantics. Access control is one >common case which affects security; work to address this issue is going >on in LDAPEXT as documented in RFC 2820 [RFC2820]. > > >6 Acknowledgements > >This document is based on input from IETF members interested in LDUP >Replication. > >7 References > >[ACID] T. Haerder, A. Reuter, "Principles of Transaction-Oriented >Database Recovery", Computing Surveys, Vol. 15, No. 4 (December 1983), >pp. 287-317. > >[NDS] Novell, "NDS Technical Overview", 104-000223-001, >http://developer.novell.com/ndk/doc/docui/index.htm#../ndslib/dsov_enu/ >data/h6tvg4z7.htm, >September, 2000. >Stokes, et al Expires February 2001 [Page 13] >Internet-Draft LDAPv3 Replication Requirements March 2001 > > >[RFC2119] S. Bradner, "Key Words for Use in RFCs to Indicate >Requirement Levels", RFC 2119, March 1997. > >[RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory Access >Protocol", RFC 2251, December 1997. > >[RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight >Directory Access Protocol (v3): Attribute Syntax Definitions", RFC >2252, December 1997. > >[RFC2253] S. Kille, M. Wahl, and T. Howes, "Lightweight Directory >Access Protocol (v3): UTF-8 String Representation of Distinguished >Names", RFC 2253, December 1997. > >[RFC2254] T. Howes, "The String Representation of LDAP Search >Filters", RFC 2254, December 1997. > >[RFC2255] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, >December 1997. > >[RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use >with LDAPv3", RFC 2256, December 1997. > >[RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access Control >Requirements for LDAP", RFC 2820, May 2000. > >[RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. >"Authentication Methods for LDAP", RFC 2829, May 2000. > >[RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access >Protocol (v3): Extension for Transport Layer Security", RFC 2830, May >2000. > >[RFC2849] Gordon Good, "The LDAP Data Interchange Format (LDIF)", RFC >2849, June 2000. > >[X.501] ITU-T Recommendation X.501 (1993), | ISO/IEC 9594-2: 1993, >Information Technology - Open Systems Interconnection - The Directory: >Models. > >[X.525] ITU-T Recommendation X.525 (1997), | ISO/IEC 9594-9: 1997, >Information Technology - Open Systems Interconnection - The Directory: >Replication. > >[XEROX] Hauser, C. "Managing update conflicts in Bayou, a weakly >connected replicated storage system". Palo Alto, CA: Xerox PARC, >Computer Science Laboratory; 1995 August; CSL-95-4. [CSL-95-04] >Stokes, et al Expires February 2001 [Page 14] >Internet-Draft LDAPv3 Replication Requirements March 2001 > > > >A. APPENDIX A - Usage Scenarios > >The following directory deployment examples are intended to validate >our replication requirements. A heterogeneous set of directory >implementations is assumed for all the cases below. This material is >intended as background; no requirements are presented in this Appendix. > >A.1. Extranet Example > >A company has a trading partner with whom it wishes to share directory >information. This information may be as simple as a corporate >telephone directory, or as complex as an extranet workflow application. >For performance reasons, the company wishes to place a replica of its >directory within the Partner Company, rather than exposing its >directory beyond its firewall. > >The requirements that follow from this scenario are: >. One-way replication, single mastered. >. Authentication of clients. >. Common access control and access control identification. >. Secure transmission of updates. >. Selective attribute replication (Fractional Replication), so that > only partial entries can be replicated. > > >A.2. Consolidation Example > >Company A acquires company B. Each company has an existing directory. > >During the transition period, as the organizations are merged, both >directory services must coexist. Company A may wish to attach company >B's directory to its own. > >The requirements that follow from this scenario are: >. Multi-Master replication. >. Common access control model. Access control model identification. >. Secure transmission of updates. >. Replication between DITs with potentially differing schema. > > >A.3. Replication Heterogeneous Deployment Example > >An organization may choose to deploy directory implementations from >multiple vendors, to enjoy the distinguishing benefits of each. > >Stokes, et al Expires February 2001 [Page 15] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >In this case, multi-master replication is required to ensure that the >multiple replicas of the DIT are synchronized. Some vendors may provide >directory clients, which are tied to their own directory service. > >The requirements that follow from this scenario are: >. Multi-Master replication >. Common access control model and Access control model identification. >. Secure transmission of updates. >. Replication among DITs with potentially differing schemas. > > >A.4. Shared Name Space Example > >Two organizations may choose to cooperate on some venture and need a >shared name space to manage their operation. Both organizations will >require administrative rights over the shared name space. > >The requirements that follow from this scenario are: >. Multi-Master replication. >. Common access control model and Access control model identification. >. Secure transmission of updates. > > >A.5. Supplier Initiated Replication > >This is a single master environment that maintains a number of replicas >of the DIT by pushing changes based on a defined schedule. > >The requirements that follow from this scenario are: >. Single-master environment. >. Supplier-initiated replication. >. Secure transmission of updates. > > >A.6. Consumer Initiated Replication > >Again a single mastered replication topology, but the slave replica >initiates the replication exchange rather than the master. An example >of this is a replica that resides on a laptop computer that may run >disconnected for a period of time. > >The requirements that follow from this scenario are: >. Single-master environment. >. Consumer initiated replication. >. Open scheduling (anytime). > > >Stokes, et al Expires February 2001 [Page 16] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >A.7. Prioritized attribute replication > >The password attribute can provide an example of the requirement for >prioritized attribute replication. A user is working in Utah and the >administrator resides in California. The user has forgotten his >password. So the user calls or emails the administrator to request a >new password. The administrator provides the updated password (a >change). > >Under normal conditions, the directory replicates to a number of >different locations overnight. But corporate security policy states >that passwords are critical and the new value must be available >immediately (e.g. shortly) after any change. Replication needs to >occur immediately for critical attributes/entries. > >The requirements that follow from this scenario are: >. Incremental replication of changes. >. Immediate replication on change of certain attributes. >. Replicate based on time/attribute semantics. > > >A.8. Bandwidth issues > >The replication of Server (A) R/W replica (a) in Kathmandu is handled >via a dial up phone link to Paris where server (B) R/W replica of (a) >resides. Server (C) R/W replica of (a) is connected by a T1 connection >to server (B). Each connection has a different performance >characteristic. > >The requirements that follow from this scenario are: >. Minimize repetitive updates when replicating from multiple > replication paths. >. Incremental replication of changes. >. Provide replication cycles to delay and/or retry when connections > cannot be reached. >. Allowances for consumer initiated or supplier initiated replication. > > >A.9. Interoperable Administration and Management > >The administrator with administrative authority of the corporate >directory which is replicated by numerous geographically dispersed LDAP >servers from different vendors notices that the replication process is >not completing correctly as the change log is continuing to grow and/or >error message informs him. The administrator uses his $19.95 RepCo >LDAP directory replication diagnostics tools to look at Root DSE >replica knowledge on server 17 and determines that server 42 made by >Stokes, et al Expires February 2001 [Page 17] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >LDAP'RUS Inc. is not replicating properly due to an Object conflict. >Using his Repco Remote repair tools he connects to server 42 and >resolves the conflict on the remote server. > >The requirements that follow from this scenario are: >. Provides replication audit history. >. Provisions for managing conflict resolution. >. Provide LDAP access to predetermined agreements, topology and policy > attributes. >. Provide operations for comparing replica's content for validity. >. Provide LDAP access to status and audit information. > > >A.10. Enterprise Directory Replication Mesh > >A Corporation builds a mesh of directory servers within the enterprise >utilizing LDAP servers from various vendors. Five servers are holding >the same area of replication. The predetermined replication >agreement(s) for the enterprise mesh are under a single management, and >the security domain allows a single predetermined replication agreement >to manage the 5 servers' replication. > >The requirements that follow from this scenario are: >. One predefined replication agreement that manages a single area of > replication that is held on numerous servers. >. Common support of replication management knowledge across vendor > implementation. >. Rescheduling and continuation of a replication cycle when one server > in a replica-group is busy and/or unavailable. > > >A.11. Failure of the Master in a Master-Slave Replicated Directory > >A company has a corporate directory that is used by the corporate email >system. The directory is held on a mesh of servers from several >vendors. A corporate relocation results in the closing of the location >where the master copy of the directory is located. Employee >information (such as mailbox locations and employee certificate >information) must be kept up to date or mail cannot be delivered. > >The requirements that follow from this scenario are: >. An existing slave replica must be "promote-able" to become the new > master. >. The "promotion" must be done without significant downtime, since > updates to the directory will continue. > > >Stokes, et al Expires February 2001 [Page 18] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >A.12. Failure of a Directory Holding Critical Service Information > >An ISP uses a policy management system that uses a directory as the >policy data repository. The directory is replicated in several >different sites on different vendors' products to avoid single points >of failure. It is imperative that the directory be available and be >updateable even if one site is disconnected from the network. Changes >to the data must be traceable, and it must be possible to determine how >changes made from different sites interacted. > >The requirements that follow from this scenario are: >. Multi-master replication >. Ability to reschedule replication sessions >. Support for manual review and override of replication conflict > resolution > > >B. APPENDIX B - Rationale > >This Appendix gives some of the background behind the requirements. It >is included to help the protocol designers understand the thinking >behind some of the requirements and to present some of the issues that >should be considered during design. With the exception of section B.8, >which contains a suggested requirement for the update to RFC 2251, this >Appendix does not state any formal requirements. > >B.1. Meta-Data Implications > >Requirement G4 states that meta-data must not grow without bound. This >implies that meta-data must, at some point, be purged from the system. >This, in turn, raises concerns about stability. Purging meta-data >before all replicas have been updated may lead to incomplete >replication of change information and inconsistencies among replicas. >Therefore, care must be taken setting up the rules for purging meta- >data from the system while still ensuring that meta-data will not grow >forever. > >B.2. Order of Transfer for Replicating Data > >Situations may arise where it would be beneficial to replicate data >out-of-order (e.g. send data to consumer replicas in a different order >than it was processed at the supplier replica). One such case might >occur if a large bulk load was done on the master server in a single- >master environment and then a single change to a critical OID (a >password change, for example) was then made. Rather than wait for all >the bulk data to be sent to the replicas, the password change might be >moved to the head of the queue and be sent before all the bulk data was > >Stokes, et al Expires February 2001 [Page 19] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >transferred. Other cases where this might be considered are schema >changes or changes to critical policy data stored in the directory. > >While there are practical benefits to allowing out-of-order transfer, >there are some negative consequences as well. Once out-of-order >transfers are permitted, all receiving replicas must be prepared to >deal with data and schema conflicts that might arise. > >As an example, assume that schema changes are critical and must be >moved to the front of the replication queue. Now assume that a schema >change deletes an attribute for some object class. It is possible that >some of the operations ahead of the schema change in the queue are >operations to delete values of the soon-to-be-deleted attribute so that >the schema change can be done with no problems. If the schema change >moves to the head of the queue, the consumer servers might have to >delete an attribute that still has values, and then receive requests to >delete the values of an attribute that is no longer defined. > >In the multi-master case, similar situations can arise when >simultaneous changes are made to different replicas. Thus, multi- >master systems must have conflict resolution algorithms in place to >handle such situations. But in the single-master case conflict >resolution is not needed unless the master is allowed to send data out- >of-order. This is the reasoning behind requirement SM2, which >recommends that data always be sent in order in single-master >replication. > >Note that even with this restriction, the concept of a critical OID is >still useful in single-master replication. An example of its utility >can be found in section A.7. > >B.3. Schema Mismatches and Replication > >Multi-vendor environments are the primary area of interest for LDAP >replication standards. Some attention must thus be paid to the issue >of schema mismatches, since they can easily arise when vendors deliver >slightly different base schema with their directory products. Even >when both products meet the requirements of the standards [RFC2252], >the vendors may have included additional attributes or object classes >with their products. When two different vendor's products attempt to >replicate, these additions can cause schema mismatches. Another >potential cause of schema mismatches is discussed in section A.3. > >There are only a few possible responses when a mismatch is discovered. > >. Raise an error condition and ignore the data. This should always be > allowed and is the basis for requirement P8 and the comment on M10. > >Stokes, et al Expires February 2001 [Page 20] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >. Map/convert the data to the form required by the consuming replica. > A system may choose this course; requirement M10 is intended to allow > this option. The extent of the conversion is up to the > implementation; in the extreme it could support use of the > replication protocol in meta-directories. >. Quietly ignore (do not store on the consumer replica and do not raise > an error condition) any data that does not conform to the schema at > the consumer. > >Requirement M10 is intended to exclude the last option. > >Requirement AM8 suggests that vendors should provide tools to help >discover schema mismatches when replication is being set up. But >schema will change after the initial setup, so the replication system >must be prepared to handle unexpected mismatches. > >Normal IETF practice in protocol implementation suggests that one be >strict in what one sends and be flexible in what one receives. The >parallel in this case is that a supplier should be prepared to receive >an error notification for any schema mismatch, but a consumer may >choose to do a conversion instead. > >The other option that can be considered in this situation is the use of >fractional replication. If replication is set up so only the common >attributes are replicated, mismatches can be avoided. > >One additional consideration here is replication of the schema itself. >M4 requires that it be possible to replicate schema. If a consumer >replica is doing conversion, extreme care should be taken if schema >elements are replicated since some attributes are intended to have >different definitions on different replicas. > >For fractional replication, the protocol designers and implementors >should give careful consideration to the way they handle schema >replication. Some options for schema replication include: >. All schema elements are replicated. >. Schema elements are replicated only if they are used by attributes > that are being replicated. >. Schema are manually configured on the servers involved in fractional > replication; schema elements are not replicated via the protocol. > >B.4. Detecting and Repairing Inconsistencies Among Replicas > >Despite the best efforts of designers, implementors, and operators, >inconsistencies will occasionally crop up among replicas in production >directories. Tools will be needed to detect and to correct these >inconsistencies. > >Stokes, et al Expires February 2001 [Page 21] >Internet-Draft LDAPv3 Replication Requirements March 2001 > > >A special client may accomplish detection through periodic comparisons >of replicas. This client would typically read two replicas of the same >replication base entry and compare the answers, possibly by BINDing to >each of the two replicas to be compared and reading them both. In >cases where the directory automatically reroutes some requests (e.g. >chaining), mechanisms to force access to a particular replica should be >supplied. > >Alternatively, the server could support a special request to handle >this situation. A client would invoke an operation at some server. It >would cause that server to extract the contents from some other server >it has a replication agreement with and report the differences back to >the client as the result > >If an inconsistency is found, it needs to be repaired. To determine >the appropriate repair, the administrator will need access to the >replication history to figure out how the inconsistency occurred and >what the correct repair should be. > >When a repair is made, it should be restricted to the replica that >needs to be fixed; the repair should not cause new replication events >to be started. This may require special tools to change the local data >store without triggering replication. > >Requirements AM2, AM4, and AM5 address these needs. > >B.5. Some Test Cases for Conflict Resolution in Multi-Master >Replication > >Use of multi-master replication inevitably leads to the possibility >that incompatible changes will be made simultaneously on different >servers. In such cases, conflict resolution algorithms must be >applied. > >As a guiding principle, conflict resolution should avoid surprising the >user. One way to do this is to adopt the principle that, to the extent >possible, conflict resolution should mimic the situation that would >happen if there were a single server where all the requests were >handled. > >While this is a useful guideline, there are some situations where it is >impossible to implement. Some of these cases are examined in this >section. In particular, there are some cases where data will be "lost" >in multi-master replication that would not be lost in a single-server >configuration. > > > >Stokes, et al Expires February 2001 [Page 22] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >In the examples below, assume that there are three replicas, A, B, and >C. All three replicas are updateable. Changes are made to replicas A >and B before replication allows either replica to see the change made >on the other. In discussion of the multi-master cases, we assume that >the change to A takes precedence using whatever rules are in force for >conflict resolution. > >B.5.1. Create-Create > >A user creates a new entry with distinguished name DN on A. At the >same time, a different user adds an entry with the same distinguished >name on B. > >In the single-server case, one of the create operations would have >occurred before the other, and the second request would have failed. > >In the multi-master case, each create was successful on its originating >server. The problem is not detected until replication takes place. >When a replication request to create a DN that already exists arrives >at one of the servers, conflict resolution is invoked. (Note that the >two requests can be distinguished even though they have the same DN >because every entry has some sort of unique identifier per requirement >SC9.) > >As noted above, in these discussions we assume that the change from >replica A has priority based on the conflict resolution algorithm. >Whichever change arrives first, requirement MM6 says that the values >from replica A must be those in place on all replicas at the end of the >replication cycle. Requirement MM5 states that the system cannot >quietly ignore the values from replica B. > >The values from replica B might be logged with some notice to the >administrators, or they might be added to the DIT with a machine >generated DN (again with notice to the administrators). If they are >stored with a machine generated DN, the same DN must be used on all >servers in the replica-group (otherwise requirement M3 would be >violated). Note that in the case where the entry in question is a >container, storage with a machine generated DN provides a place where >descendent entries may be stored if any descendents were generated >before the replication cycle was completed. > >In any case, some mechanism must be provided to allow the administrator >to reverse the conflict resolution algorithm and force the values >originally created on B into place on all replicas if desired. > >B.5.2. Rename-Rename > > > >Stokes, et al Expires February 2001 [Page 23] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >On replica A, an entry with distinguished name DN1 is renamed to DN. >At the same time on replica B, an entry with distinguished name DN2 is >renamed to DN. > >In the single-server case, one rename operation would occur before the >other and the second would fail since the target name already exists. > >In the multi-master case, each rename was successful on its originating >server. Assuming that the change on A has priority in the conflict >resolution sense, DN will be left with the values from DN1 in all >replicas and DN1 will no longer exist in any replica. The question is >what happens to DN2 and its original values. > >Requirement MM5 states that these values must be stored somewhere. >They might be logged, they might be left in the DIT as the values of >DN2, or they might be left in the DIT as the values of some machine >generated DN. Leaving them as the values of DN2 is attractive since it >is the same as the single-server case, but if a new DN2 has already >been created before the replica cycle finishes, there are some very >complex cases to resolve. Any of the solutions described in this >paragraph would be consistent with requirement MM5. > >B.5.3. Locking Based on Atomicity of ModifyRequest > >There is an entry with distinguished name DN that contains attributes >X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is >processed which includes modifications to change that value of X from 1 >to 0 and to set the value of Y to "USER1". At the same time, replica B >processes a ModifyRequest which includes modifications to change the >value of X from 1 to 0 and to set the value of Y to "USER2" and the >value of Z to 42. The application in this case is using X as a lock >and is depending on the atomic nature of ModifyRequests to provide >mutual exclusion for lock access. > >In the single-server case, the two operations would have occurred >sequentially. Since a ModifyRequest is atomic, the entire first >operation would succeed. The second ModifyRequest would fail, since >the value of X would be 0 when it was attempted, and the modification >changing X from 1 to 0 would thus fail. The atomicity rule would cause >all other modifications in the ModifyRequest to fail as well. > >In the multi-master case, it is inevitable that at least some of the >changes will be reversed despite the use of the lock. Assuming the >changes from A have priority per the conflict resolution algorithm, the >value of X should be 0 and the value of Y should be "USER1" The >interesting question is the value of Z at the end of the replication >cycle. If it is 42, the atomicity constraint on the change from B has >been violated. But for it to revert to its previous value, grouping >Stokes, et al Expires February 2001 [Page 24] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >information must be retained and it is not clear when that information >can be safely discarded. Thus, requirement G6 may be violated. > > >B.5.4. General Principles > >With multi-master replication there are a number of cases where a user >or application will complete a sequence of operations with a server but >those actions are later "undone" because someone else completed a >conflicting set of operations at another server. > >To some extent, this can happen in any multi-user system. If a user >changes the value of an attribute and later reads it back, intervening >operations by another user may have changed the value. In the multi- >master case, the problem is worsened, since techniques used to resolve >the problem in the single-server case won't work as shown in the >examples above. > >The major question here is one of intended use. In LDAP standards >work, it has long been said that replication provides "loose >consistency" among replicas. At several IETF meetings and on the >mailing list, usage examples from finance where locking is required >have been declared poor uses for LDAP. Requirement G1 is consistent >with this history. But if loose consistency is the goal, the locking >example above is an inappropriate use of LDAP, at least in a replicated >environment. > >B.5.5. Avoiding the Problem > >The examples above discuss some of the most difficult problems that can >arise in multi-master replication. While they can be dealt with, >dealing with them is difficult and can lead to situations that are >quite confusing to the application and to users. > >The common characteristics of the examples are: > >. Several directory users/applications are changing the same data. >. They are changing the data before previous changes have replicated. >. They are using different directory servers to make these changes. >. They are changing data that are parts of a distinguished name or they > are using ModifyRequest to both read and write a given attribute > value in a single atomic request. > >If any one of these conditions is reversed, the types of problems >described above will not occur. There are many useful applications of >multi-master directories where at least one of the above conditions > > >Stokes, et al Expires February 2001 [Page 25] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >does not occur. For cases where all four do occur, application >designers should be aware of the possible consequences. > >B.6. Data Privacy During Replication > >Directories will frequently hold proprietary information. Policy >information, name and address information, and customer lists can be >quite proprietary and are likely to be stored in directories. Such >data must be protected during replication. > >In some cases, the network environment (e.g. a private network) may >provide sufficient privacy for the application. In other cases, the >data in the directory may be public and not require protection. For >these reasons data privacy was not made a requirement for all >replication sessions. But there are a substantial number of >applications that will need data privacy, so there is a requirement >(S2) that the protocol allow for data privacy in those cases where it >is needed. > >This leaves the question of what privacy mechanism(s) to use. While >this is ultimately a design/implementation decision, replication across >different vendors' directory products is an important goal of the LDAP >replication work at the IETF. If different vendors choose to support >different data privacy mechanisms, the advantages of a standard >replication protocol would be lost. Thus there is a requirement (S3) >for a mandatory-to-implement data privacy mechanism. > >B.7. Failover in Single-Master Systems > >In a single-master system, all modifications must originate at the >master. The master is therefore a single point of failure for >modifications. This can cause concern when high availability is a >requirement for the directory system. > >One way to reduce the problem is to provide a failover process that >converts a slave replica to master when the original master fails. The >time required to execute the failover process then becomes a major >factor in availability of the system as a whole. > >Factors that designers and implementors should consider when working on >failover include: > >. If the master replica contains control information or meta-data > that is not part of the slave replica(s), this information will > have to be inserted into the slave that is being "promoted" to > master as part of the failover process. Since the old master is > presumably unavailable at this point, it may be difficult to > obtain this data. For example, if the master holds the status >Stokes, et al Expires February 2001 [Page 26] >Internet-Draft LDAPv3 Replication Requirements March 2001 > > information of all replicas, but each slave replica only holds its > own status information, failover would require that the new master > get the status of all existing replicas, presumably from those > replicas. Similar issues could arise for replication agreements > if the master is the only system that holds a complete set. > >. If data privacy mechanisms (e.g. encryption) are in use during > replication, the new master would need to have the necessary key > information to talk to all of the slave replicas. > >. It is not only the new master that needs to be reconfigured. The > slaves also need to have their configurations updated so they know > where updates should come from and where they should refer > modifications. > >. The failover mechanism should be able to handle a situation where > the old master is "broken" but not "dead". The slave replicas > should ignore updates from the old master after failover is > initiated. > >. The old master will eventually be repaired and returned to the > replica-group. It might join the group as a slave and pick up the > changes it has "missed" from the new master, or there might be > some mechanism to bring it into sync with the new master and then > let it take over as master. Some resynchronization mechanism will > be needed. > >. Availability would be maximized if the whole failover process > could be automated (e.g. failover is initiated by an external > system when it determines that the original master is not > functioning properly). > > >B.8. Including Operational Attributes in Atomic Operations > >LDAPv3 [RFC2251] declares that some operations are atomic (e.g. all of >the modifications in a single ModifyRequest). It also defines several >operational attributes that store information about when changes are >made to the directory (createTimestamp, etc.) and which ID was >responsible for a given change (modifiersName, etc.). Currently, there >is no statement in RFC2251 requiring that changes to these operational >attributes be atomic with the changes to the data. > >It is RECOMMENDED that this requirement be added during the revision of >RFC2251. In the interim, replication SHOULD treat these operations as >though such a requirement were in place. > > > >Stokes, et al Expires February 2001 [Page 27] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >Authors' Addresses > >Russel F. Weiser >Digital Signature Trust Co. >1095 East 2100 South >Suite #201 >Salt Lake City, Utah 84106 >USA >E-mail: rweiser@digsigtrust.com >Telephone: +1 801 246 4323 >Fax: +1 801 246 4361 > >Ellen J. Stokes >Tivoli Systems >6300 Bridgepoint Parkway >Austin, Texas 78731 >USA >E-mail: estokes@tivoli.com >Telephone: +1 512 436 9098 >Fax: +1 512 436 1199 > >Ryan D. Moats >Coreon, Inc. >15621 Drexel Circle >Omaha, NE 68135 >USA >E-Mail: rmoats@coreon.net >Telephone: +1 402 894 9456 > >Richard V. Huber >Room C3-3B30 >AT&T Laboratories >200 Laurel Avenue South >Middletown, NJ 07748 >USA >E-Mail: rvh@att.com >Telephone: +1 732 420 2632 >Fax: +1 732 368 1690 > > >Full Copyright Statement > >Copyright (C) The Internet Society (2000). All Rights Reserved. > >This document and translations of it may be copied and furnished to >others, and derivative works that comment on or otherwise explain it or >assist in its implementation may be prepared, copied, published and >distributed, in whole or in part, without restriction of any kind, >Stokes, et al Expires February 2001 [Page 28] >Internet-Draft LDAPv3 Replication Requirements March 2001 > >provided that the above copyright notice and this paragraph are >included on all such copies and derivative works. However, this >document itself may not be modified in any way, such as by removing the >copyright notice or references to the Internet Society or other >Internet organizations, except as needed for the purpose of developing >Internet standards in which case the procedures for copyrights defined >in the Internet Standards process must be followed, or as required to >translate it into languages other than English. > >The limited permissions granted above are perpetual and will not be >revoked by the Internet Society or its successors or assigns. > >This document and the information contained herein is provided on an >"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING >TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT >NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL >NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR >FITNESS FOR A PARTICULAR PURPOSE. > >Acknowledgement > >Funding for the RFC Editor function is currently provided by the >Internet Society. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Stokes, et al Expires February 2001 [Page 29] From owner-ietf-ldup@mail.imc.org Fri Mar 2 21:02:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27180 for ; Fri, 2 Mar 2001 21:02:56 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id RAA25176 for ietf-ldup-bks; Fri, 2 Mar 2001 17:38:41 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA25172 for ; Fri, 2 Mar 2001 17:38:39 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA01411; Fri, 2 Mar 2001 17:38:31 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id ABC26959; Fri, 2 Mar 2001 17:38:11 -0800 (PST) Message-Id: <4.3.2.7.2.20010302170948.00b3fb60@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Mar 2001 17:38:05 -0800 To: ietf-ldup@imc.org From: John Strassner Subject: LDUP WG Agenda for the Minneapolis Meeting Cc: johns@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: LDUPers, I've received one additional request for a discussion slot, so this is what our agenda currently looks like. If anyone wants an additional slot, PLEASE let me know asap. Authors, please be prepared to present the changes made since your last submitted draft. If you haven't made any changes, then please be prepared to convince the group that your work is done and is therefore ready for last call, or that you are waiting for another draft to finish first. Note that we have some expired drafts, so as a minimum, we will need to resubmit those drafts so that we can work on them. 5 - Agenda Bashing 20 - Discussion of Changes Made to Requirements I-D draft-ietf-ldup-replica-req-07 20 - Discussion of Changes Made to Architecture Document draft-ietf-ldup-model-06.txt 15 - Discussion on URP - ready for Last Call or not? draft-ietf-ldup-urp-03.txt 10 - Discussion on the LDUP Replication Update Protocol draft-ietf-ldup-protocol-02.txt 15 - Discussion on LDUP Subentry Schema draft-ietf-ldup-subentry-07.txt 15 - Discussion of Usage Profile I-D draft-ietf-ldup-usage-profile-00.txt 10 - Discussion on LDAP Client Update Protocol draft-natkovich-ldap-lcup-02.txt 15 - Discussion of Policy Inheritance Mechanisms for LDAP draft-reed-ldup-inheritance-00.txt 10 - Discussion of other missing drafts 10 - any other business regards, John Strassner LDUP WG Co-Chair From owner-ietf-ldup@mail.imc.org Mon Mar 5 07:17:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12170 for ; Mon, 5 Mar 2001 07:17:21 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id DAA14796 for ietf-ldup-bks; Mon, 5 Mar 2001 03:45:31 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA14791 for ; Mon, 5 Mar 2001 03:45:30 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11128; Mon, 5 Mar 2001 06:45:29 -0500 (EST) Message-Id: <200103051145.GAA11128@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-replica-req-07.txt Date: Mon, 05 Mar 2001 06:45:29 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAPv3 Replication Requirements Author(s) : E. Stokes, R. Weiser, R. Moats, R. Huber Filename : draft-ietf-ldup-replica-req-07.txt Pages : 29 Date : 02-Mar-01 This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-replica-req-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-replica-req-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010302132157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-replica-req-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-replica-req-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010302132157.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Mon Mar 5 07:29:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12353 for ; Mon, 5 Mar 2001 07:29:38 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id DAA14788 for ietf-ldup-bks; Mon, 5 Mar 2001 03:45:27 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id DAA14783 for ; Mon, 5 Mar 2001 03:45:26 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11115; Mon, 5 Mar 2001 06:45:25 -0500 (EST) Message-Id: <200103051145.GAA11115@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-subentry-07.txt Date: Mon, 05 Mar 2001 06:45:25 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAP Subentry Schema Author(s) : E. Reed Filename : draft-ietf-ldup-subentry-07.txt Pages : 11 Date : 02-Mar-01 This document describes two object classes called ldapSubEntry and inheritableLDAPSubEntry, and a control, ldapSubentriesControl (to control the visibility of entries of type ldapSubEntry) which MUST be used by directory servers claiming support for the features of this document to indicate operations and management related entries in the directory, called LDAP Subentries. Scope rules are defined for LDAP Subentries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-subentry-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-subentry-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010302132149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-subentry-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-subentry-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010302132149.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Mon Mar 5 11:50:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20981 for ; Mon, 5 Mar 2001 11:50:09 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id IAA06381 for ietf-ldup-bks; Mon, 5 Mar 2001 08:02:36 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA06376 for ; Mon, 5 Mar 2001 08:02:34 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA23247; Mon, 5 Mar 2001 08:02:23 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (dhcp-128-107-131-16.cisco.com [128.107.131.16]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id ABD05110; Mon, 5 Mar 2001 08:02:00 -0800 (PST) Message-Id: <4.3.2.7.2.20010305080027.03530048@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Mar 2001 08:01:48 -0800 To: roland@catalogix.se From: John Strassner Subject: Re: IETF50 draft agenda Cc: ietf-ldapext@netscape.com, ietf-ldup@imc.org In-Reply-To: <01030514390008.09921@t20> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Roland, I'd like to see a discussion of addressing replication requirements under the ACL scope portion. tia, John At 02:39 PM 3/5/2001 +0100, Roland Hedberg wrote: >Hi! > >It is our intention at the upcomming meeting that we will deal more with >issues than with drafts. Therefore the agenda below are centered around >topics that we would like to have discussed rather than listing all the drafts >that are on our charter. > >If anyone feels strongly that I have failed to put something very important >on the list of items please send me a note. > >Unfortunately I will be of the air for a couple of days, so don't expect any >immediate reply from me if you do send something. > >-- Roland >------------------------------------- > >LDAP (v3) Extension WG (LDAPext) >Meeting on Monday March 19, 2001 1300-1500 > >Chairs: > Mark Wahl > Roland Hedberg > >Agenda: > Preliminaries - chairs - 15m > Agenda Bashing > Milestone Status > > Technical Discussions - > > extention guide: > resultCode overloading > new resultCodes > > Amendments to the ASN.1 > what can be done and what should not be attempted > > ACL scope > application defined permissions > extended operations > > Subentries > inheritance/duplication/replication > visability > > Locating servers: DC-naming > > ELSE > > Other Issues - floor - 15m > >Description: > This meeting will focus on significant outstanding > issues with WG I-Ds which have not been resolved > through list discussions. Attendees should come > prepared to discuss these issues by reviewing past > discussions (available in WG list archives) and > reading relevant WG I-Ds From owner-ietf-ldup@mail.imc.org Mon Mar 5 15:12:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01817 for ; Mon, 5 Mar 2001 15:12:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA16604 for ietf-ldup-bks; Mon, 5 Mar 2001 11:35:54 -0800 (PST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA16589 for ; Mon, 5 Mar 2001 11:35:48 -0800 (PST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA79058 for ; Mon, 5 Mar 2001 14:31:01 -0600 Received: from d04nm203.raleigh.ibm.com (d04nm203.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.11.2/NCO v4.95) with ESMTP id f25JZfC59532 for ; Mon, 5 Mar 2001 14:35:41 -0500 Importance: Normal Subject: High update rates and network delay To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John McGarvey" Date: Mon, 5 Mar 2001 14:36:38 -0500 X-MIMETrack: Serialize by Router on D04NM203/04/M/IBM(Release 5.0.6 |December 14, 2000) at 03/05/2001 02:35:40 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The current LDAP replication architecture draft states: (Section 10) " ... The Consumer must not support multiple concurrent replication sessions with more than one Supplier for the same Replication Context." I suggest that this requirement may lead to suboptimal transmission of updates. Consider the following case: servers A, B, C on one network, servers D, E, F on another, and the two networks connnected by a slow network link L. (A B C) <------- L ---------> (D E F) "Slow" may mean limited bandwidth or high latency or both. Assume all of these servers hold the same replication context and that it is writable on each of the servers. To make efficient use of the network connection, changes originating at any server should only traverse L once. One way to configure bandwidth efficient replication is as follows. - Replicas B and C supply updates to, and consume updates from, A. - Replicas A, E and F supply updates to, and consume updates from, D. (Additional backup replication agreements may be added in case A or D are down.) Given this setup, suppose we want to support high rates of update with continual replication. In conformance with the current draft, A could consume updates from B, C, and D via sequential sessions. But while A is a consumer in session with B or C, it can not receive updates over L, so the constrained resource goes unused for that period. Similarly, when D is a consumer in session with E or F, it can not receive updates over L. This is suboptimal and significantly lowers the maximum update rate that the configuration can support. I have chosen a simple example, but the more complicated the topology, the more the update rate is affected. I suggest the following alternative. For this alternative, the requirement from section 10 would have to be loosened to say " ... The Consumer must not support multiple concurrent replication sessions with more than one Supplier for the same set of updates." Here is the configuration: - Replica B supplies updates to A but only those that originate at B. It consumes updates from A that originate at A, C, D, E, or F. - Replica C supplies updates to A but only those that originate at C. It consumes updates from A that originate at A, B, D, E, or F. - Replica A supplies updates to D that originate at A, B, or C. It consumes updates from D that originate at D, E, or F. and so on. The picture looks like: B <---> A <----L----> D <---> E ^ ^ | | | | v v C F (Additional backup replication agreements may also be added for availability.) This construction is similar to the "spanning tree" created by ethernet bridges, in that an update originating at a given server reaches a destination via a single optimized path. We can permit A act as a consumer for simultaneous replication sessions from B, C, and D, because the updates transmitted within each session are disjoint. How can A request updates from D that originate on D, E, and F, but not on B or C? One way is for A to transmit only part of its update vector when it begins a session as a consumer of updates from D. It would send the part corresponding to D, E, and F, but not the part corresponding to A, B, or C. -- John McGarvey From owner-ietf-ldup@mail.imc.org Mon Mar 5 15:29:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02573 for ; Mon, 5 Mar 2001 15:29:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA17196 for ietf-ldup-bks; Mon, 5 Mar 2001 11:49:52 -0800 (PST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA17191 for ; Mon, 5 Mar 2001 11:49:51 -0800 (PST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA141542 for ; Mon, 5 Mar 2001 14:44:56 -0600 Received: from d04nm203.raleigh.ibm.com (d04nm203.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.11.2/NCO v4.95) with ESMTP id f25JnZC41426 for ; Mon, 5 Mar 2001 14:49:36 -0500 Importance: Normal Subject: URP, Replication Update Protocol, and atomic changes To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John McGarvey" Date: Mon, 5 Mar 2001 14:50:32 -0500 X-MIMETrack: Serialize by Router on D04NM203/04/M/IBM(Release 5.0.6 |December 14, 2000) at 03/05/2001 02:49:36 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Applications sometimes need to make atomic changes to an entry. One example is a simple counter, a single valued attribute that is incremented by replacing the current value with the incremented value. This works fine in a single master case. It does not work in a multimaster case using URP, because the value may be incremented, say from 4 to 5, on one of the servers and then, before that change has been propagated via replication, the counter might be incremented on a different server, also from 4 to 5. The value after replication would remain 5, but the desired result is 6. The problem of atomic changes to entries has been thoroughly discussed on the list. URP does not provide any application workaround for this problem. This is troubling. I would like to suggest a workaround for use in URP. Suppose, for any replication context, one server is defined as the master for any changes requiring atomicity. We would have to define a means to advertise the location of the master. If application needs, say, to increment a counter, it should be written make that change on the atomicity master for that replication context. If that master is unavailable, the change must not proceed. Changes not requiring atomicity -- probably the great majority of writes to the directory -- could proceed on any peer master. Of course, this approach to atomicity does not guarantee that conflicting changes do not occur concurrently on other servers, because some applications may fail to use the mechanism. But, for applications that do exploit this approach consistently, reliable counters and other data requiring atomic change could be stored in the directory. This approach could be extended to make an atomic change to a collection of entries, so as to offer simple transactional semantics without 2 phase commit: [control to begin atomic change] operation operation operation [control to end atomic change] If all of these grouped operations are on directory entries within replication contexts for which a single server is the atomicity master, that master evaluates the collection of changes, applying all or none of them. If the current server is not the atomicity master for all of the affected entries, it rejects, or possibly redirects, the group of operations. Of course, as for a single entry, conflicting changes may occur concurrently on other servers, if applications fail to use the mechanism. When changes corresponding to a group of operations are replicated, they should be applied as a unit, so that an application reading data from the directory is not returned data corresponding to an intermediate state in which some but not all entries affected by the group of operations have been updated. LDUP Replication Update Protocol currently groups changes to a single entry, so that such changes can be applied as a unit, but it does not provide a means of grouping changes to a collection of entries. Perhaps the protocol should be extended to support this kind of grouping. This suggestion would require two changes to the current LDUP drafts: (1) a means of identifying the atomicity master for a given replication context, and (2) a change to the replication update protocol to permit grouping of changes to multiple entries so that they can be treated as a unit. -- John McGarvey From owner-ietf-ldup@mail.imc.org Mon Mar 5 16:30:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05126 for ; Mon, 5 Mar 2001 16:30:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA20476 for ietf-ldup-bks; Mon, 5 Mar 2001 12:48:38 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA20471 for ; Mon, 5 Mar 2001 12:48:37 -0800 (PST) Received: from rmoats2 (wenjus3.coreon.net [216.74.131.3]) by mail.coreon.net (Mirapoint) with ESMTP id AAA04862 (AUTH rmoats); Mon, 5 Mar 2001 15:47:12 -0500 (EST) From: "Ryan Moats" To: "John McGarvey" , Subject: RE: High update rates and network delay Date: Mon, 5 Mar 2001 14:53:33 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Well first, I think that the phrase "same set of changes" needs to be defined precisely. The rest of the discussion is more germane to setting up replication agreements and implementation and so I think is independent of the wording of the requirement. Ryan -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of John McGarvey Sent: Monday, March 05, 2001 1:37 PM To: ietf-ldup@imc.org Subject: High update rates and network delay The current LDAP replication architecture draft states: (Section 10) " ... The Consumer must not support multiple concurrent replication sessions with more than one Supplier for the same Replication Context." I suggest that this requirement may lead to suboptimal transmission of updates. Consider the following case: servers A, B, C on one network, servers D, E, F on another, and the two networks connnected by a slow network link L. (A B C) <------- L ---------> (D E F) "Slow" may mean limited bandwidth or high latency or both. Assume all of these servers hold the same replication context and that it is writable on each of the servers. To make efficient use of the network connection, changes originating at any server should only traverse L once. One way to configure bandwidth efficient replication is as follows. - Replicas B and C supply updates to, and consume updates from, A. - Replicas A, E and F supply updates to, and consume updates from, D. (Additional backup replication agreements may be added in case A or D are down.) Given this setup, suppose we want to support high rates of update with continual replication. In conformance with the current draft, A could consume updates from B, C, and D via sequential sessions. But while A is a consumer in session with B or C, it can not receive updates over L, so the constrained resource goes unused for that period. Similarly, when D is a consumer in session with E or F, it can not receive updates over L. This is suboptimal and significantly lowers the maximum update rate that the configuration can support. I have chosen a simple example, but the more complicated the topology, the more the update rate is affected. I suggest the following alternative. For this alternative, the requirement from section 10 would have to be loosened to say " ... The Consumer must not support multiple concurrent replication sessions with more than one Supplier for the same set of updates." Here is the configuration: - Replica B supplies updates to A but only those that originate at B. It consumes updates from A that originate at A, C, D, E, or F. - Replica C supplies updates to A but only those that originate at C. It consumes updates from A that originate at A, B, D, E, or F. - Replica A supplies updates to D that originate at A, B, or C. It consumes updates from D that originate at D, E, or F. and so on. The picture looks like: B <---> A <----L----> D <---> E ^ ^ | | | | v v C F (Additional backup replication agreements may also be added for availability.) This construction is similar to the "spanning tree" created by ethernet bridges, in that an update originating at a given server reaches a destination via a single optimized path. We can permit A act as a consumer for simultaneous replication sessions from B, C, and D, because the updates transmitted within each session are disjoint. How can A request updates from D that originate on D, E, and F, but not on B or C? One way is for A to transmit only part of its update vector when it begins a session as a consumer of updates from D. It would send the part corresponding to D, E, and F, but not the part corresponding to A, B, or C. -- John McGarvey From owner-ietf-ldup@mail.imc.org Mon Mar 5 17:38:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08130 for ; Mon, 5 Mar 2001 17:38:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA25412 for ietf-ldup-bks; Mon, 5 Mar 2001 13:57:17 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA25408 for ; Mon, 5 Mar 2001 13:57:16 -0800 (PST) Received: from rmoats2 (wenjus3.coreon.net [216.74.131.3]) by mail.coreon.net (Mirapoint) with ESMTP id AAA05092 (AUTH rmoats); Mon, 5 Mar 2001 16:57:01 -0500 (EST) From: "Ryan Moats" To: "Ryan Moats" , "John McGarvey" , Subject: RE: High update rates and network delay Date: Mon, 5 Mar 2001 16:03:21 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Doh... My brain just turned on and I just realized that this is talking about architecture. Therefore, please disregard what I'm saying below. Ryan -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Ryan Moats Sent: Monday, March 05, 2001 2:54 PM To: John McGarvey; ietf-ldup@imc.org Subject: RE: High update rates and network delay Well first, I think that the phrase "same set of changes" needs to be defined precisely. The rest of the discussion is more germane to setting up replication agreements and implementation and so I think is independent of the wording of the requirement. Ryan -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of John McGarvey Sent: Monday, March 05, 2001 1:37 PM To: ietf-ldup@imc.org Subject: High update rates and network delay The current LDAP replication architecture draft states: (Section 10) " ... The Consumer must not support multiple concurrent replication sessions with more than one Supplier for the same Replication Context." I suggest that this requirement may lead to suboptimal transmission of updates. Consider the following case: servers A, B, C on one network, servers D, E, F on another, and the two networks connnected by a slow network link L. (A B C) <------- L ---------> (D E F) "Slow" may mean limited bandwidth or high latency or both. Assume all of these servers hold the same replication context and that it is writable on each of the servers. To make efficient use of the network connection, changes originating at any server should only traverse L once. One way to configure bandwidth efficient replication is as follows. - Replicas B and C supply updates to, and consume updates from, A. - Replicas A, E and F supply updates to, and consume updates from, D. (Additional backup replication agreements may be added in case A or D are down.) Given this setup, suppose we want to support high rates of update with continual replication. In conformance with the current draft, A could consume updates from B, C, and D via sequential sessions. But while A is a consumer in session with B or C, it can not receive updates over L, so the constrained resource goes unused for that period. Similarly, when D is a consumer in session with E or F, it can not receive updates over L. This is suboptimal and significantly lowers the maximum update rate that the configuration can support. I have chosen a simple example, but the more complicated the topology, the more the update rate is affected. I suggest the following alternative. For this alternative, the requirement from section 10 would have to be loosened to say " ... The Consumer must not support multiple concurrent replication sessions with more than one Supplier for the same set of updates." Here is the configuration: - Replica B supplies updates to A but only those that originate at B. It consumes updates from A that originate at A, C, D, E, or F. - Replica C supplies updates to A but only those that originate at C. It consumes updates from A that originate at A, B, D, E, or F. - Replica A supplies updates to D that originate at A, B, or C. It consumes updates from D that originate at D, E, or F. and so on. The picture looks like: B <---> A <----L----> D <---> E ^ ^ | | | | v v C F (Additional backup replication agreements may also be added for availability.) This construction is similar to the "spanning tree" created by ethernet bridges, in that an update originating at a given server reaches a destination via a single optimized path. We can permit A act as a consumer for simultaneous replication sessions from B, C, and D, because the updates transmitted within each session are disjoint. How can A request updates from D that originate on D, E, and F, but not on B or C? One way is for A to transmit only part of its update vector when it begins a session as a consumer of updates from D. It would send the part corresponding to D, E, and F, but not the part corresponding to A, B, or C. -- John McGarvey From owner-ietf-ldup@mail.imc.org Mon Mar 5 17:47:23 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08495 for ; Mon, 5 Mar 2001 17:47:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA25501 for ietf-ldup-bks; Mon, 5 Mar 2001 13:59:40 -0800 (PST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA25497 for ; Mon, 5 Mar 2001 13:59:34 -0800 (PST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA210458; Mon, 5 Mar 2001 16:54:55 -0600 Received: from d04nm203.raleigh.ibm.com (d04nm203.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.11.2/NCO v4.95) with ESMTP id f25LxZC27150; Mon, 5 Mar 2001 16:59:35 -0500 Importance: Normal Subject: RE: High update rates and network delay To: "Ryan Moats" Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John McGarvey" Date: Mon, 5 Mar 2001 17:00:31 -0500 X-MIMETrack: Serialize by Router on D04NM203/04/M/IBM(Release 5.0.6 |December 14, 2000) at 03/05/2001 04:59:35 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Yes, fair enough. Let me try again. How about: "The Consumer may support multiple concurrent replication sessions with more than one Supplier for the same Replication Context, but if so, the Consumer must ensure that the sets of updates received from each concurrent Supplier session are disjoint. Two sets of updates are disjoint if the corresponding sets of CSNs are also disjoint." I have suggested a particular way to ensure that the sets of updates received are indeed disjoint, which is by having the consumer send different, nonoverlapping parts of the consumer's update vector to each supplier with which it is in session. Several changes to section 10.1 of the architecture document would be necessary to allow the implementation of such an approach. -- John McGarvey "Ryan Moats" on 03/05/2001 03:53:33 PM To: John McGarvey/Raleigh/IBM@IBMUS, cc: Subject: RE: High update rates and network delay Well first, I think that the phrase "same set of changes" needs to be defined precisely. The rest of the discussion is more germane to setting up replication agreements and implementation and so I think is independent of the wording of the requirement. Ryan -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of John McGarvey Sent: Monday, March 05, 2001 1:37 PM To: ietf-ldup@imc.org Subject: High update rates and network delay The current LDAP replication architecture draft states: (Section 10) " ... The Consumer must not support multiple concurrent replication sessions with more than one Supplier for the same Replication Context." I suggest that this requirement may lead to suboptimal transmission of updates. Consider the following case: servers A, B, C on one network, servers D, E, F on another, and the two networks connnected by a slow network link L. (A B C) <------- L ---------> (D E F) "Slow" may mean limited bandwidth or high latency or both. Assume all of these servers hold the same replication context and that it is writable on each of the servers. To make efficient use of the network connection, changes originating at any server should only traverse L once. One way to configure bandwidth efficient replication is as follows. - Replicas B and C supply updates to, and consume updates from, A. - Replicas A, E and F supply updates to, and consume updates from, D. (Additional backup replication agreements may be added in case A or D are down.) Given this setup, suppose we want to support high rates of update with continual replication. In conformance with the current draft, A could consume updates from B, C, and D via sequential sessions. But while A is a consumer in session with B or C, it can not receive updates over L, so the constrained resource goes unused for that period. Similarly, when D is a consumer in session with E or F, it can not receive updates over L. This is suboptimal and significantly lowers the maximum update rate that the configuration can support. I have chosen a simple example, but the more complicated the topology, the more the update rate is affected. I suggest the following alternative. For this alternative, the requirement from section 10 would have to be loosened to say " ... The Consumer must not support multiple concurrent replication sessions with more than one Supplier for the same set of updates." Here is the configuration: - Replica B supplies updates to A but only those that originate at B. It consumes updates from A that originate at A, C, D, E, or F. - Replica C supplies updates to A but only those that originate at C. It consumes updates from A that originate at A, B, D, E, or F. - Replica A supplies updates to D that originate at A, B, or C. It consumes updates from D that originate at D, E, or F. and so on. The picture looks like: B <---> A <----L----> D <---> E ^ ^ | | | | v v C F (Additional backup replication agreements may also be added for availability.) This construction is similar to the "spanning tree" created by ethernet bridges, in that an update originating at a given server reaches a destination via a single optimized path. We can permit A act as a consumer for simultaneous replication sessions from B, C, and D, because the updates transmitted within each session are disjoint. How can A request updates from D that originate on D, E, and F, but not on B or C? One way is for A to transmit only part of its update vector when it begins a session as a consumer of updates from D. It would send the part corresponding to D, E, and F, but not the part corresponding to A, B, or C. -- John McGarvey From owner-ietf-ldup@mail.imc.org Tue Mar 6 03:52:45 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05369 for ; Tue, 6 Mar 2001 03:52:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA27487 for ietf-ldup-bks; Tue, 6 Mar 2001 00:06:50 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id AAA27478 for ; Tue, 6 Mar 2001 00:06:48 -0800 (PST) Received: (qmail 22544 invoked from network); 6 Mar 2001 08:06:15 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 6 Mar 2001 08:06:15 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'John McGarvey'" , Subject: RE: High update rates and network delay Date: Tue, 6 Mar 2001 19:10:15 +1100 Message-ID: <002601c0a614$e0db5080$6628a8c0@nowhere.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [John M] The current LDAP replication architecture draft states: (Section 10) " ... The Consumer must not support multiple concurrent replication sessions with more than one Supplier for the same Replication Context." I suggest that this requirement may lead to suboptimal transmission of updates. Consider the following case: servers A, B, C on one network, servers D, E, F on another, and the two networks connnected by a slow network link L. (A B C) <------- L ---------> (D E F) "Slow" may mean limited bandwidth or high latency or both. Assume all of these servers hold the same replication context and that it is writable on each of the servers. To make efficient use of the network connection, changes originating at any server should only traverse L once. One way to configure bandwidth efficient replication is as follows. - Replicas B and C supply updates to, and consume updates from, A. - Replicas A, E and F supply updates to, and consume updates from, D. (Additional backup replication agreements may be added in case A or D are down.) [Albert] My understanding is that above is the solution used in Active Directory, - a "bridgehead server" for each relatively slow link between "sites" that have multiple DSAs with high bandwidth connectivity. It requires quite complex calculations to optimize the choice of links while meeting other constraints to minimize the number of hops so as to minimize the diameter of the replication network and hence the overall replication delay, while taking into account the distinction between fast links within a "site" and slow links between them. These calculations can be done on a decentralized basis but are non-trivial to specify. They need to be done quite freqently and using a uniform algorithm to ensure convergence in the "sporadically connected" environment of scalable directory replication. Another approach (Novell?) could use algorithms that converge to a Hamiltonian circuit which could be simpler but maximizes the diameter of the replication network. For example the circuit for above diagram could be: A B C (L) D E F (L) A (with either orientation). Traffic could pass over the slow link L from C to D in one direction and from F to A in the other direction simultaneously (at IP network layer), despite the restriction to only 1 consumer session at a time. Trouble is that as well as maximizing the replication diameter (from A to F via 5 hops), this also needs to ensure that each site has additional links and schedules so that traffic from C to A or B does not pass across the link at all while avoiding any traffic crossing more than once. I'm inclined to agree with the architecture drafts approach of just deferring such issues until basic standards for interoperability are in place, although it seems clear that "optimal" interoperability will require full standardization of link and schedule selection algorithms (and many other aspects not yet addressed at all). It is certainly useful to discuss possible approaches now though, and there is lots of research on "gossip networks" available (also applicable to other standards track protocols such as news). [JohnM] Given this setup, suppose we want to support high rates of update with continual replication. In conformance with the current draft, A could consume updates from B, C, and D via sequential sessions. But while A is a consumer in session with B or C, it can not receive updates over L, so the constrained resource goes unused for that period. Similarly, when D is a consumer in session with E or F, it can not receive updates over L. This is suboptimal and significantly lowers the maximum update rate that the configuration can support. I have chosen a simple example, but the more complicated the topology, the more the update rate is affected. [Albert] Likewise A cannot receive updates from D at the same time it is sending updates to D, so the slow link is effectively half duplex. That alone halves the total traffic that could be pushed through it. I think that is the key point to look at for more optimal propagation. The constraint imposed by A and D being unable to use the slow link while they are consuming updates from other DSAs within their respective sites is likely to have less impact since: a) all that traffic from within a single site has to pass over the slow link (slowly ;-) b) the same traffic over the high speed links within a site can be received quickly. Therefore the total loss of use of the constrained resource due to A and D at each end of the link being unavailable while consuming intra-site updates is not likely to exceed the loss from half duplex. I'm doubtful as to whether a solution to that bigger problem is feasible as consuming updates from more than one source simultaneously can get horrendously complex for implementation even with Single Master. Also, don't forget that there can be multiple replicated areas even if the replication network between the DSAs holding them is the same. That allows for overlapping consumer sessions by just partitioning the replicated area to enable it in any situation where the performance issues really justify the extra trouble - without imposing more complex standards in situations where it isn't needed. [JohnM] I suggest the following alternative. For this alternative, the requirement from section 10 would have to be loosened to say " ... The Consumer must not support multiple concurrent replication sessions with more than one Supplier for the same set of updates." Here is the configuration: - Replica B supplies updates to A but only those that originate at B. It consumes updates from A that originate at A, C, D, E, or F. - Replica C supplies updates to A but only those that originate at C. It consumes updates from A that originate at A, B, D, E, or F. - Replica A supplies updates to D that originate at A, B, or C. It consumes updates from D that originate at D, E, or F. and so on. The picture looks like: B <---> A <----L----> D <---> E ^ ^ | | | | v v C F [Albert] I don't understand. The other alternative was: - Replicas B and C supply updates to, and consume updates from, A. - Replicas A, E and F supply updates to, and consume updates from, D. How does this picture illustrate a difference? It looks like exactly the same set of symmetric links to me. Seems to me you need a picture illustrating the selection of which updates are supplied and consumed over each link. That is hard to draw and could be hard to dynamically calculate for a robust sporadically connected replication network with multiple sites. [JohnM] (Additional backup replication agreements may also be added for availability.) This construction is similar to the "spanning tree" created by ethernet bridges, in that an update originating at a given server reaches a destination via a single optimized path. We can permit A act as a consumer for simultaneous replication sessions from B, C, and D, because the updates transmitted within each session are disjoint. How can A request updates from D that originate on D, E, and F, but not on B or C? One way is for A to transmit only part of its update vector when it begins a session as a consumer of updates from D. It would send the part corresponding to D, E, and F, but not the part corresponding to A, B, or C. -- John McGarvey [Albert] I suspect this would be too brittle, though worth exploring if you want to write up an I-D specifying how to calculate the overlayed spanning trees dynamically in a sporadically connected network and at the same allow for news about replicas (and sites) joining or leaving the network to pass across such links. Might be worth first just tackling the specification of a global algorithm that ensures each replica has a common view about who else is currently in the replication network when deciding which updates to consume and which to reject. That seems to be necessary for eventual convergence with the current architecture, as well as for your suggestion, but missing from the current draft. Also consider this requirement: AM6. The sequence of updates to access control information (ACI) and the data controlled by that ACI MUST be maintained by replication. While it might be *theoretically* possible to meet that requirement without ordered propagation of updates, the architecture and URP drafts have so far made no attempt to show how. I wouldn't like to try implementing it with more than one consumer session affecting the same replicated area. Since the scope of an ACI attribute value can be an entire subtree the most obvious (and possibly only) solution requires applying change reports from each originator in the same sequence that they were generated by that originator - for all changes, not just ACI changes. The natural way to do that is to deliver changes from each originator to each supplier in their original sequence within each replication session (although arbitrarily interleaved with changes from other originators). That requires separation of local sequence numbers from originator sequence numbers. (In order to sort out the interleaving it is necessary to add version numbers and maintain a tree of all concurrent changes, rather than pretending that unsynchronized and non-monotonic clocks can impose a total ordering on a tree that is only partially ordered, just as that is necessary for "preserving atomic operations"). So if you are going to look at how to optimize update rates and network delay I would recommend assuming that the specifications finally adopted will at least require delivery of changes from each originator in strict sequence over each replication link. That, together with update vectors and the use of a high water mark based on local sequence numbers is sufficient to ensure that no changes are passed over any link more than once, and robust eventual convergence despite DSAs crashing and being restored from backups. I suspect optimization of schedules and link selection in that context will both be easier than, and differ significantly from, any attempt to optimize in the context of propagating unordered changes. If weakening the restriction to a single consumer session is possible at all, I believe it would need to be in that context. PS If anyone is responding to last part, please change it to a separate thread such as "Delivery Sequence". I only mention it here because it is likely to also impact on how to optimize update rates and network delay, and it would be a pity if anyone working on that were to waste time based on an assumption that the current approach of unordered propagation of changes will remain. From owner-ietf-ldup@mail.imc.org Tue Mar 6 11:34:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16441 for ; Tue, 6 Mar 2001 11:34:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA15144 for ietf-ldup-bks; Tue, 6 Mar 2001 07:49:44 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id HAA15136 for ; Tue, 6 Mar 2001 07:49:42 -0800 (PST) Received: (qmail 22747 invoked from network); 6 Mar 2001 15:49:10 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 6 Mar 2001 15:49:10 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'John McGarvey'" , Subject: RE: URP, Replication Update Protocol, and atomic changes Date: Wed, 7 Mar 2001 02:53:16 +1100 Message-ID: <003701c0a655$90a160a0$6628a8c0@nowhere.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [John M] [...] This approach could be extended to make an atomic change to a collection of entries, so as to offer simple transactional semantics without 2 phase commit: [control to begin atomic change] operation operation operation [control to end atomic change] If all of these grouped operations are on directory entries within replication contexts for which a single server is the atomicity master, that master evaluates the collection of changes, applying all or none of them. If the current server is not the atomicity master for all of the affected entries, it rejects, or possibly redirects, the group of operations. Of course, as for a single entry, conflicting changes may occur concurrently on other servers, if applications fail to use the mechanism. [Albert] I've omitted your discussion of a "workaround" in view of the current requirements: P7. The protocol MUST preserve atomicity of LDAP operations as defined in RFC2251 [RFC2251]. MM5. Multi-master replication MUST NOT lose information during replication. If conflict resolution would result in the loss of directory information, the replication process MUST store that information, notify the administrator of the nature of the conflict and the information that was lost, and provide a mechanism for possible override by the administrator. They will either be accepted, rejected or modified. In my view discussion of that is needed before discussion of workarounds. I'll be happy to join in discussion of that, but meanwhile am not interested in discussion of workarounds. I am however interested in multi-master at least not impeding work on grouped operations so I would like to discuss that part of your message. The way I see it confining grouped operations to a single server ("atomicity master") doesn't solve the problem of how to avoid impeding work on grouped operations, but just avoids the issue. Calling a single master an "atomicity master" does not enable it to provide any of the benefits of fault tolerance and local changeable copies that multi-master is supposed to provide. At present grouped operations are not part of the X.500/LDAP model for reasons that have nothing to do with multi-master or lack of atomicity. X.500 and LDAP currently assume a single master environment and they require atomicity whether it is single master or not. The problem is that the directory service is intended to be globally scalable with applications referring to entries by their directory names, without having to know what server will actually respond to queries or perform updates. The directory is distributed globally among many servers holding many Naming Contexts. A referral can be given to any server without the application needing to know about what servers hold what Naming Contexts, let alone whether a server is part of a replicated area or is a single master or a slave or an "atomicity master". You can't even rely on a set of direct children of a single parent being on the same DSA, let alone an arbitrary group of entries that are not siblings. Ignore that and you are designing a not very good local substitute for a DBMS rather than part of a global directory service. Why not just use ODBC as the client server protocol instead of LDAP? You'd get ACID transactions and a full query language with selects, joins, insert, update etc - not just atomicity and queries with filter scopes restricted to simple subtrees and changes to a predefined group of entries (1 at present, some larger predefined set with grouped operatons). The point of the *limitations* of LDAP is to work in that globally scalable *distributed* environment. Anything that doesn't need that can just use a DBMS. A grouped operation can of course be restricted to work only within a single Naming Context (hence a single server for single master). This is necessary for the new parent option of modifyDN because it hasn't been shown to be globally scalable to coordinate moves between two independent servers that are designed to each just look after their own parts of a global namespace rather than be able to establish secure bilateral relations with any other DSA. (It may become feasible with widely deployed directory based Public Key certificate Infrastructure). At present it isn't even clear how LDUP proposes to deal with modifyDN operations within a Naming Context that has several replicated areas. Version 5 of the architecture is the first that actually recognized the distinction but it still hasn't linked it to handling modifyDN within a Naming Context rather than just within a replicated area (which leaves a Naming Context somewhat useless for namespace management). But whatever LDUP does to allow grouped operations to work in a replicated area (or, harder, within a Naming Context), has to be based on not impeding work done on grouped operations for *distributed* single master. Anything done for a single server environment should be standardized in LDAPEXT if it really needs LDAP at all and anything done across distributed DSAs holding different Naming Contexts likewise should be standardized in LDAPEXT. We just have to make sure that when an area is replicated instead of held by a single DSA it breaks as little as possible and impedes as little as possible in return for the benefits of doing so (fault tolerance and local changeable copies). So I don't see much point in trying to tackle the problem here. The best we can do is just avoid getting in the way. That can be done by ensuring we at least do support the current data model so that multi-master servers aren't getting in the way of attempts to extend it. At present we have a proposed requirement for doing that, but no proposed architecture or conflict resolution procedures that meet the requirement. Let's focus on how to actually implement that requirement for single entries before worrying about how to extend it to multiple entries. It just doesn't make sense to me to be simultaneously looking for a "workaround" instead of implementing atomicity at the level of entries, while in the very same message proposing to solve the harder problem of atomicity extending over multiple entries. [John M] When changes corresponding to a group of operations are replicated, they should be applied as a unit, so that an application reading data from the directory is not returned data corresponding to an intermediate state in which some but not all entries affected by the group of operations have been updated. LDUP Replication Update Protocol currently groups changes to a single entry, so that such changes can be applied as a unit, but it does not provide a means of grouping changes to a collection of entries. Perhaps the protocol should be extended to support this kind of grouping. This suggestion would require two changes to the current LDUP drafts: (1) a means of identifying the atomicity master for a given replication context, and (2) a change to the replication update protocol to permit grouping of changes to multiple entries so that they can be treated as a unit. -- John McGarvey [Albert] There's been no problem specifying a transfer protocol that will carry all parts of an operation as a unit. In fact the LDAP protocolOp syntax did exactly that without any help from LDUP. All that's needed is *not* splitting it into sub-atomic primitives by just leaving it alone. Wrapping that into a sequence of grouped operations is no harder. That's all you need "so that such changes *can* be applied as a unit". What's needed now is a multi-master architecture that *does* apply them as a unit (and doesn't lose information etc). Calling a server an "atomicity server" instead of just a plain ordinary DSA does not give it any enhanced capabilities whatsoever beyond what LDAP had before LDUP started work. A simple label "not broken" would suffice. Step 1 apply the changes to a single entry as a unit. Step 2 check what LDAPEXT is doing about applying grouped changes to multiple entries as a unit and make sure we aren't impeding it. Step 3 try to actually implement grouped changes it in a multi-master context. After 2 years we still haven't actually started work on step 1, but only started to recognize that we might have to. There are lots of ways applications can build their own grouped operations on top of a directory service that does support atomicity, without any support from the directory service. It can even be done with a directory that breaks atomicity at the entry level but at least maintains it at the attribute level. eg I have the impression that some Active Directory applicatins use a UUID to identify all changes made as a group. If a DUA following that application convention reads back the same UUID on all the changes it made, then it knows that no other DUA following the same convention interfered with those changes (provided a full replication across the replication network has occurred). Otherwise it needs to rollback those parts of the change that weren't interfered with and leave it the other DUAs to rollback their bits that they regard as having been interfered with, because they also see that their UUIDs did not stick. There are various other tricks such as hashes and child counts. Extending DSA support for them such as cleaning up if DUAs fail to do their rollbacks could be useful one day - but not until after we have simple entry level atomicity actually in place. The UUID trick doesn't work when atomicity is broken at the attribute value level, as with URP, because you just end up with the groupedUUID attribute containing UUIDs from each of the conflicting grouped operations with no way to tell which of the changes made to other attributes was made by which grouped operation. You can't even tell which DUA made the change, let alone which grouped operation by that DUA the change corresponds to, because even modifiersName doesn't work without atomicity. Let's fix it and *then* move on, not proudly label DSAs that have not been broken by LDUP as "atomicity masters". They already have a name - LDAP servers. From owner-ietf-ldup@mail.imc.org Tue Mar 6 18:37:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03424 for ; Tue, 6 Mar 2001 18:37:00 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id PAA12442 for ietf-ldup-bks; Tue, 6 Mar 2001 15:04:21 -0800 (PST) Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA12437 for ; Tue, 6 Mar 2001 15:04:20 -0800 (PST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA40510; Tue, 6 Mar 2001 17:57:52 -0600 Received: from d04nm203.raleigh.ibm.com (d04nm203.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.11.2/NCO v4.95) with ESMTP id f26N41F48230; Tue, 6 Mar 2001 18:04:02 -0500 Importance: Normal Subject: RE: High update rates and network delay To: , ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John McGarvey" Date: Tue, 6 Mar 2001 18:04:57 -0500 X-MIMETrack: Serialize by Router on D04NM203/04/M/IBM(Release 5.0.6 |December 14, 2000) at 03/06/2001 06:04:02 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Albert] Likewise A cannot receive updates from D at the same time it is sending updates to D, so the slow link is effectively half duplex. >> I do not find that restriction in the current architecture draft. The current draft says that a server can't be in concurrent session as a consumer with two or more suppliers for the same replication context. But I don't think it says that a server can't be in concurrent sessions as a consumer and as a supplier. In section 7, it says "A two way exchange requires two replication sessions; one session in each direction." [Albert] I'm inclined to agree with the architecture drafts approach of just deferring such issues until basic standards for interoperability are in place, although it seems clear that "optimal" interoperability will require full standardization of link and schedule selection algorithms (and many other aspects not yet addressed at all). >>The approach I suggested does affect basic standards for interoperability and the current drafts. I suggested that a partial update vector could be sent by the consumer to receive only those updates that originate on a subset of the writeable servers, so that update paths through the topology could be optimized. If this idea has merit, the current drafts should be changed to allow partial update vectors to be sent, which is disallowed at present. We can probably defer the task of explicitly defining algorithms for optimizing these update paths. -- John McGarvey From owner-ietf-ldup@mail.imc.org Wed Mar 7 01:32:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15489 for ; Wed, 7 Mar 2001 01:32:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id WAA24808 for ietf-ldup-bks; Tue, 6 Mar 2001 22:01:47 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id WAA24804 for ; Tue, 6 Mar 2001 22:01:45 -0800 (PST) Received: (qmail 1809 invoked from network); 7 Mar 2001 06:01:17 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 7 Mar 2001 06:01:17 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'John McGarvey'" , Cc: "'Ed Reed'" Subject: RE: High update rates and network delay Date: Wed, 7 Mar 2001 17:05:38 +1100 Message-ID: <003d01c0a6cc$a265e5a0$6628a8c0@nowhere.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ed could you please clarify my confusion on whether a replica can concurrently have a supplier and a consumer session? [Albert] Likewise A cannot receive updates from D at the same time it is sending updates to D, so the slow link is effectively half duplex. [John M] >> I do not find that restriction in the current architecture draft. The current draft says that a server can't be in concurrent session as a consumer with two or more suppliers for the same replication context. But I don't think it says that a server can't be in concurrent sessions as a consumer and as a supplier. In section 7, it says "A two way exchange requires two replication sessions; one session in each direction." [Albert] Whoops! I can't find it in the architecture draft either. For some unknown reason I read "two replication sessions; one session in each direction" as implying that one would follow the other. But there is clearly no such implication - it reads at least as well for overlapping concurrent sessions. I'll have to take a closer look as I don't think I understand how the Update Vector that gets updated at the end of a session works in this situation, or why there is no special provision for two way sessions in the replication protocol. I've always assumed there was a deliberate simplification here that avoids some complexities when supplying updates at the same time as recieving them - ie at any given moment any given replica is either acting as a supplier for multiple consumers, or a consumer from 1 supplier, but never both. Doesn't seem to be what it actually says though. Anyway, the assumptions on which a large part of my response to you were based look pretty shaky. Sorry about that ;-) [Albert] I'm inclined to agree with the architecture drafts approach of just deferring such issues until basic standards for interoperability are in place, although it seems clear that "optimal" interoperability will require full standardization of link and schedule selection algorithms (and many other aspects not yet addressed at all). [John M] >>The approach I suggested does affect basic standards for interoperability and the current drafts. I suggested that a partial update vector could be sent by the consumer to receive only those updates that originate on a subset of the writeable servers, so that update paths through the topology could be optimized. If this idea has merit, the current drafts should be changed to allow partial update vectors to be sent, which is disallowed at present. We can probably defer the task of explicitly defining algorithms for optimizing these update paths. -- John McGarvey [Albert] I think we might be at cross purposes here. Certainly if we are going to do it now, the architecture draft would have to be amended to remove the restriction. But in addition it would have to specify what partial update vectors can be sent. You would need to write some text on that at the same time as proposing removal of the restriction (with more detailed text to go in the actual standards). The specification would have to at least guarantee eventual convergence, and therefore could not just "permit" implementations to do whatever they like as regards partial update vectors. Algorithms for *optimizing* the update paths could be deferred, perhaps with related information model changes for coordinating the choice of common algorithms. But at least a minimal algorithm that just guarantees eventual convergence using a partial update vector instead of a complete update vector would be necessary. My other suggestion is that if you are writing an I-D on that, a good start would be to just demonstrate that it works with new replicas joining and leaving the replication network, given that it is arbitrarily and sporadically connected with arbitrary and dynamically changing schedules and replication agreements - starting with a demonstration of that for the case of a full update vector. (I'm not even sure how that works with full update vectors at the moment ;-) My comment about "deferring" was not intended to suggest that your proposal (*with* some specification ;-) could be deferred until after architecture was finalized, if we are going to do something like that in version 1. I meant I was agreeing with what I assumed to be the authors intention of leaving anything that isn't strictly necessary for viable interoperability until version 2 if doing it in version 1 would substantially complicate implementation. ie We MUST have eventual convergence (and atomicity and sequential ACI updates ;-) and SHOULD optimize for high update rates and network delay. So if you have an easily added way to do, or even prepare for, some optimization then it should be added, otherwise it should not. My belief was that it will be quite difficult to specify partial update vectors and therefore should not be done for version 1 as there is no requirement that we MUST do it. It looks like the assumptions behind my belief aren't very convincing so don't let that deter you from writing a spec. Hmm, I see an interesting parallel with an assumption that others may have made two years ago that atomicity would be difficult and was not required - unfortunately without actually having done the requirements analysis before deciding on a design and then doing the architecture. I suspect that because we currently don't have an architecture that meets even the MUST requirements, you may have plenty of time in which to write a spec for your addition - but I'd still recommend starting now ;-) From owner-ietf-ldup@mail.imc.org Wed Mar 7 03:43:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA28281 for ; Wed, 7 Mar 2001 03:43:16 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id AAA13386 for ietf-ldup-bks; Wed, 7 Mar 2001 00:16:05 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA13377 for ; Wed, 7 Mar 2001 00:16:03 -0800 (PST) Received: from gypsy.OpenLDAP.org (gypsy.boolean.net [10.192.1.2]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f278G6D79832; Wed, 7 Mar 2001 08:16:06 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010307000552.02ccf7d0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 07 Mar 2001 00:16:01 -0800 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: draft-ietf-ldup-subentry-07.txt Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 03:53 PM 3/1/01 -0700, Ed Reed wrote: >One remaining question for the list - as written (in the abstract, above) support for inheritableLDAPSubEntry is MUST, along with support for the ldapSubentry class and its visibility control. Should the inheritable class be MAY? Should it even be removed to its own draft? If the answer is "it should be a MUST", then I think this draft is ready for last call. I would prefer inheritableLDAPSubEntry be removed to its own draft, namely because I believe subentry inheritance is a can-of-worms (and an unnecessary complication). Editorially, I do not think the Abstract should state any requirements. In particular, it should not contain any uppercase imperatives (RFC 2119 keywords). Kurt From owner-ietf-ldup@mail.imc.org Wed Mar 7 08:17:10 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02773 for ; Wed, 7 Mar 2001 08:17:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id EAA12594 for ietf-ldup-bks; Wed, 7 Mar 2001 04:44:48 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA12589 for ; Wed, 7 Mar 2001 04:44:47 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01090; Wed, 7 Mar 2001 07:44:48 -0500 (EST) Message-Id: <200103071244.HAA01090@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rharrison-lburp-03.txt Date: Wed, 07 Mar 2001 07:44:47 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAP Bulk Update/Replication Protocol Author(s) : R. Harrison, J. Sermersheim, Y. Dong Filename : draft-rharrison-lburp-03.txt Pages : 16 Date : 06-Mar-01 The LDAP Bulk Update/Replication Protocol (LBURP) described in this document allows an LDAP client (a genuine client or an LDAP server acting as a client) to perform a bulk update to a replica on an LDAP server. The protocol groups a set of update operations using the LDAP framed protocol requests defined in [FRAMING] to notify the client that the update operations in the framed set are related. The update operations within the framed set are LDAPv3 extended operations each encapsulating a sequence number and one or more LDAPv3 update operations. The sequence number allows the server to process the update operations in the proper order even when they are sent asynchronously by the client, and the update operations can be grouped within the extended request to maximize the efficiency of client-server communication. The protocol may be used to initialize all of the entries in an LDAP replica or to incrementally update the existing entries in an LDAP replica. It is suitable for client utilities that need to efficiently initialize a replica with many entries or efficiently make a substantial set of update changes to a replica. It is also suitable as a protocol for replication between a single master replica and its slave replicas. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rharrison-lburp-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rharrison-lburp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rharrison-lburp-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010306125537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rharrison-lburp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-rharrison-lburp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010306125537.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Wed Mar 7 09:46:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06098 for ; Wed, 7 Mar 2001 09:46:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id GAA19442 for ietf-ldup-bks; Wed, 7 Mar 2001 06:07:57 -0800 (PST) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA19437 for ; Wed, 7 Mar 2001 06:07:53 -0800 (PST) Received: from e23.nc.us.ibm.com (e23.raleigh.ibm.com [9.37.2.62]) by admin.ny.us.ibm.com. (8.9.3/8.9.3) with ESMTP id NAA132188 for ; Mon, 5 Mar 2001 13:08:26 -0500 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA58804 for ; Mon, 5 Mar 2001 13:02:06 -0600 Received: from d04nm203.raleigh.ibm.com (d04nm203.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.11.2/NCO v4.95) with ESMTP id f25I8IC75112 for ; Mon, 5 Mar 2001 13:08:18 -0500 Importance: Normal Subject: URP, Replication Update Protocol, and atomic changes To: ietf-ldup@imc.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John McGarvey" Date: Mon, 5 Mar 2001 13:09:15 -0500 X-MIMETrack: Serialize by Router on D04NM203/04/M/IBM(Release 5.0.6 |December 14, 2000) at 03/05/2001 01:08:19 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Applications sometimes need to make atomic changes to an entry. One example is a simple counter, a single valued attribute that is incremented by replacing the current value with the incremented value. This works fine in a single master case. It does not work in a multimaster case using URP, because the value may be incremented, say from 4 to 5, on one of the servers and then, before that change has been propagated via replication, the counter might be incremented on a different server, also from 4 to 5. The value after replication would remain 5, but the desired result is 6. The problem of atomic changes to entries has been thoroughly discussed on the list. URP does not provide any application workaround for this problem. This is troubling. I would like to suggest a workaround for use in URP. Suppose, for any replication context, one server is defined as the master for any changes requiring atomicity. We would have to define a means to advertise the location of the master. If application needs, say, to increment a counter, it should be written make that change on the atomicity master for that replication context. If that master is unavailable, the change must not proceed. Changes not requiring atomicity -- probably the great majority of writes to the directory -- could proceed on any peer master. Of course, this approach to atomicity does not guarantee that conflicting changes do not occur concurrently on other servers, because some applications may fail to use the mechanism. But, for applications that do exploit this approach consistently, reliable counters and other data requiring atomic change could be stored in the directory. This approach could be extended to make an atomic change to a collection of entries, so as to offer simple transactional semantics without 2 phase commit: [control to begin atomic change] operation operation operation [control to end atomic change] If all of these grouped operations are on directory entries within replication contexts for which a single server is the atomicity master, that master evaluates the collection of changes, applying all or none of them. If the current server is not the atomicity master for all of the affected entries, it rejects, or possibly redirects, the group of operations. Of course, as for a single entry, conflicting changes may occur concurrently on other servers, if applications fail to use the mechanism. When changes corresponding to a group of operations are replicated, they should be applied as a unit, so that an application reading data from the directory is not returned data corresponding to an intermediate state in which some but not all entries affected by the group of operations have been updated. LDUP Replication Update Protocol currently groups changes to a single entry, so that such changes can be applied as a unit, but it does not provide a means of grouping changes to a collection of entries. Perhaps the protocol should be extended to support this kind of grouping. This suggestion would require two changes to the current LDUP drafts: (1) a means of identifying the atomicity master for a given replication context, and (2) a change to the replication update protocol to permit grouping of changes to multiple entries so that they can be treated as a unit. -- John McGarvey From owner-ietf-ldup@mail.imc.org Fri Mar 9 06:23:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10908 for ; Fri, 9 Mar 2001 06:22:59 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id CAA20074 for ietf-ldup-bks; Fri, 9 Mar 2001 02:49:28 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA20068 for ; Fri, 9 Mar 2001 02:49:27 -0800 (PST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.43.85]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id CAA23977; Fri, 9 Mar 2001 02:48:27 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f29AmNN19189; Fri, 9 Mar 2001 02:48:23 -0800 (PST) Received: from [192.168.1.24] (ssh-ams1.cisco.com [144.254.74.55]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id CAA15432; Fri, 9 Mar 2001 02:48:05 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <000001c0a878$f290ed60$6628a8c0@nowhere.com> References: <000001c0a878$f290ed60$6628a8c0@nowhere.com> Date: Fri, 9 Mar 2001 11:45:03 +0100 To: "Albert Langer" , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: LDUP WG - RFC 2026 s 6.5.4 appeal Cc: , "'Chris Apple'" , Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id CAA20074 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA10908 At 20.11 +1100 01-03-09, Albert Langer wrote: >To: Patrik Fältström and Ned Freed - Area Directors, Applications Area, IETF > >Date: 9 March 2001 AEST (all dates below are for the same year 2001 >and ldup list archive time zone except where explicitly indicated) > >From: Albert Langer > >This is a formal appeal (RFC 2026 s 6.5.4) concerning >the decisions made by the LDUP WG co-chairs (John >Strassner, and Chris Apple) itemized below together >with proposed resolution for each item. The proposed >resolutions include an appeal against continued >management of the WG by the current co-chairs and a >request for their replacement. > >I am CCing to LDUP WG lists for information. This is received. Can people in this wg which have relevant explicit comments to me personally on the note Albert Langer just sent? Only if you feel for it, and belive you have input. This mailing list should _NOT_ be used for discussion about this appeal. Patrik -- Patrik Fältström Internet Engineering Task Force Area Director, Applications Area http://www.ietf.org Phone: (Stockholm) +46-8-6859131 (San Jose) +1-408-525-8509 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From owner-ietf-ldup@mail.imc.org Fri Mar 9 06:28:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10951 for ; Fri, 9 Mar 2001 06:28:29 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id CAA20964 for ietf-ldup-bks; Fri, 9 Mar 2001 02:59:08 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA20956 for ; Fri, 9 Mar 2001 02:59:07 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.43.102]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id CAA17525; Fri, 9 Mar 2001 02:57:26 -0800 (PST) Received: from JSTRASSN-W2K1.cisco.com (bjjensen-isdn.cisco.com [10.49.150.73]) by mira-sjcm-1.cisco.com (Mirapoint) with ESMTP id ABM38120; Fri, 9 Mar 2001 02:58:34 -0800 (PST) Message-Id: <4.3.2.7.2.20010309022041.00b62740@mira-sjcm-1.cisco.com> X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Mar 2001 02:25:04 -0800 To: agenda@ietf.org From: John Strassner Subject: LDUP WG Agenda Cc: ietf-ldup@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please find below a finalized agenda. There was one request to change the order and have the profile discussion immediately follow the requirements discussion, which I have done. I also added 5 minutes to the agenda bashing session. 10 - Agenda Bashing 20 - Discussion of Changes Made to Requirements I-D draft-ietf-ldup-replica-req-07 15 - Discussion of Usage Profile I-D draft-ietf-ldup-usage-profile-00.txt 20 - Discussion of Changes Made to Architecture Document draft-ietf-ldup-model-06.txt 15 - Discussion on URP - ready for Last Call or not? draft-ietf-ldup-urp-03.txt 10 - Discussion on the LDUP Replication Update Protocol draft-ietf-ldup-protocol-02.txt 15 - Discussion on LDUP Subentry Schema draft-ietf-ldup-subentry-07.txt 10 - Discussion on LDAP Client Update Protocol draft-natkovich-ldap-lcup-02.txt 15 - Discussion of Policy Inheritance Mechanisms for LDAP draft-reed-ldup-inheritance-00.txt 10 - Discussion of other missing drafts 10 - any other business regards, John Strassner LDUP WG Co-Chair From owner-ietf-ldup@mail.imc.org Fri Mar 9 08:03:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12269 for ; Fri, 9 Mar 2001 08:03:43 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id EAA28916 for ietf-ldup-bks; Fri, 9 Mar 2001 04:36:36 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA28907 for ; Fri, 9 Mar 2001 04:36:34 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11702; Fri, 9 Mar 2001 07:36:33 -0500 (EST) Message-Id: <200103091236.HAA11702@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-model-06.txt Date: Fri, 09 Mar 2001 07:36:33 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAP Replication Architecture Author(s) : J. Merrells, E. Reed, U. Srinivasan Filename : draft-ietf-ldup-model-06.txt Pages : 48 Date : 08-Mar-01 This architectural document outlines a suite of schema and protocol extensions to LDAPv3 that enables the robust, reliable, server-to-server exchange of directory content and changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-model-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-model-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010308111034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-model-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-model-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010308111034.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Fri Mar 9 16:43:36 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06027 for ; Fri, 9 Mar 2001 16:43:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA17449 for ietf-ldup-bks; Fri, 9 Mar 2001 10:02:00 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id KAA17443 for ; Fri, 9 Mar 2001 10:01:38 -0800 (PST) Received: (qmail 16838 invoked from network); 9 Mar 2001 18:00:51 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 9 Mar 2001 18:00:51 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" , Cc: , , Subject: LDUP WG - RFC 2026 s 6.5.4 appeal Date: Sat, 10 Mar 2001 05:03:55 +1100 Message-ID: <000b01c0a8c3$549c6a80$6628a8c0@nowhere.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000C_01C0A91F.880CE280" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C0A91F.880CE280 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id KAA17449 Content-Transfer-Encoding: quoted-printable Sorry about any confusion. This is a repost as original was too big for mailbox and Paul Hoffman has now kindly raised the limit. Sorry about the length. Also corrected typo "No such milestone existed in the previous charter." (not typo "previous draft") Original to Chris bounced, am now using correct address (I hope) -----Original Message----- From: Albert Langer [mailto:Albert.Langer@Directory-Designs.org] Sent: Friday, March 09, 2001 8:11 PM To: 'Patrik F=E4ltstr=F6m'; 'ned.freed@innosoft.com' Cc: 'johns@cisco.com'; 'Chris Apple'; 'ietf-ldup@imc.org' Subject: LDUP WG - RFC 2026 s 6.5.4 appeal To: Patrik F=E4ltstr=F6m and Ned Freed - Area Directors, Applications Are= a, IETF Date: 9 March 2001 AEST (all dates below are for the same year 2001 and ldup list archive time zone except where explicitly indicated) From: Albert Langer This is a formal appeal (RFC 2026 s 6.5.4) concerning the decisions made by the LDUP WG co-chairs (John Strassner, and Chris Apple) itemized below together with proposed resolution for each item. The proposed resolutions include an appeal against continued management of the WG by the current co-chairs and a request for their replacement. I am CCing to LDUP WG lists for information. Grounds of appeal, relevant facts, references to documentation and argument are then provided separately for each item. The documentation for items 2 and 3 is included with item 1. Proposed resolution for items 1 and 2 is simple reversal of the decision, with a request for urgent and summary determination explained below. * Decisions Appealed * 1) Finalization of Proposed Standard before Architecture 2) No review of WG progress despite delays exceeding two years 3) Unauthorized posting of revised WG charter Proposed resolution: Re-chartering of WG. Direction that WG is to demonstrate that it is capable of doing the work it is chartered to do by first producing, through open discussion on the list, an agreed statement as to the lessons learned from its failure to do that work so far, or alternatively a statement of any remaining disagreements about that, with a list of which WG participants have explicitly endorsed each of the differing views concerning the nature of the problem and the solution. 4) Refusal to resolve technical issues in WG list Proposed resolution: Replacement of both WG co-chairs and appointment of additional WG staff as listed in RFC 2418 s 6 - Secretary (6.2), Facilitator (6.4), Consultant (6.6). 5) Bullying retaliation in response to formal objections by John Proposed resolution: Apology to WG and temporary exclusion from active participation for 3 months. During that period, John not permitted to speak at WG meetings or post any message directly to the list. (May contribute by submitting I-Ds and messages forwarded by other participants). Alternatively, no apology and temporary exclusion for 6 months. An additional item 6 that should not be published prior to resolution may follow separately. It does not affect the determination of items 1 to 5 and may be delayed and considered separately. * Background * The WG requirements editors have now proposed a requirement as follows: P7. The protocol MUST preserve atomicity of LDAP operations as defined in RFC2251 [RFC2251]. That fully meets the fundamental objection I raised at the Adelaide IETF nearly a year ago and I will now not be objecting to the current draft (07) at IETF last call, whether or not other changes I believe desirable are made in the next WG last call. It has also been endorsed by John, in response to the explanation given by the editors: *** > >Part I Sub-issue 7: removal of P6 (atomicity information) >... > >Action: This requirement needs to be explained and justified in the I-= D. > >The I-D should answer the question of whether it is propagating end-st= ate > >or propagating a set of operations required to replicate that end-stat= e, > >and WHY it is doing so. > >-We feel that discussion of propagating end state vs. changes is about >implementation. Rather, P6 (now P7 due to other changes) has been >rewritten to explicitly require propagation of atomicity of LDAP >operations as defined in RFC 2251. We feel it is now self justifying. As WG Co-Chair, this action meets my action item. *** http://www.imc.org/ietf-ldup/mail-archive/msg00926.html Unfortunately it took nearly a year to get there, during which no work was done to actually meet this requirement, despite it being, as pointed out by the editors, "self justifying" by simple reference to mandatory provisions of the base standards to which this WG is supposed to add replication. Nor was anything done to achieve a genuine consensus about it. A similar statement appeared in draft 0 of the architecture way back on 8 August 1998: *** 3.2 Document Objectives [...] c) To preserve the atomicity of LDAP operations. Updates to an entry, from multiple sources, will be combined such that the resultant entry is equivalent to a serial execution of the operations. 8.2.2 Incremental Update Transfer [...] Each individual change may contain a sequence of entry modifications that must be preserved when transferred. The atomicity of the LDAP operation must be preserved when it is applied to the Consumer Replica. http://www.imc.org/ietf-ldup/mail-archive/msg00138.html Subsequently, on 24 December 1998, after the WG charter had been submitted, the initial draft of URP appeared, which did not support the above provisions of the architecture: http://www.imc.org/ietf-ldup/mail-archive/msg00224.html It was published as an I-D on 18 Feb 1999: http://www.imc.org/ietf-ldup/mail-archive/msg00258.html The architecture was subsequently revised to accomodate URP on 28 June 1999: 3.2 [...] c) To preserve the LDAP Data Model and Operation Behaviour constraints defined for LDAP in RFC 2251. http://www.imc.org/ietf-ldup/mail-archive/msg00359.html http://www.imc.org/ietf-ldup/mail-archive/msg00360.html No clear explanation was reported in subsequent minutes of 31 July 1999, despite reference to concern about consistency model from IESG. Nor was any decision taken on the WG list. http://www.imc.org/ietf-ldup/mail-archive/msg00380.html Essentially the WG has gone full circle on this issue since it was first chartered and is currently back on track (though I doubt that there is a genuine "rough consensus" yet). Simply pretending that nothing happened, and allowing the WG co-chairs to continue as before, will not avoid further delays. It is now entirely possible that authors of the current architecture and URP drafts and others may wish to object at WG last call, as those drafts are clearly not capable of meeting that requirement and the proposal is part of a document that is now being taken seriously as actual requirements. They are fully entitled to do so and it is essential that any such objections be dealt with through the normal IETF process of open and fair technical discussion on the WG list with a view to reaching a *genuine* "rough consensus" that can be a basis for moving forward to actually meet the requirements finally agreed on by the WG by working together to get the job done. I do not believe that will be possible unless the WG co-chairs are told by someone they will listen to, that their refusal to deal with disagreements the IETF way and their refusal to seek a WG "rough consensus" on requirements and architecture through technical discussion on the list before deciding on detailed design, is a major factor preventing the WG getting its work done. I also believe that they have demonstrated an incapacity to manage, and even participate in, technical discussions through the WG list, after making a commitment to do so, that justifies immediate replacement. I request that Patrik not participate in the appeal concerning items 1 to 4 as doing so could give the appearance of reviewing decisions that he may have been involved in. No such problem arises concerning the remaining items, but they should be considered in the light of 1 to 4 by the same ADs that deal with items 1 to 4. Items 1 and 2 are both straight forward and urgent. I request that they be determined summarily prior to dealing with the other items that involve resolving disputes as to the facts. Reasons for urgency are explained below. If the WG co-chairs persist in John's claim that their decision reflects a consensus of the WG, rough or otherwise, then I request that the determination of items 1 and 2 should be made promptly on the basis that this claim is assumed correct, before consideration of whether it is correct or not (item 3) - as a 6.51(b) appeal simply asserting that: (b) the Working Group has made an incorrect technical choice which places the quality and/or integrity of the Working Group's product(s) in significant jeopardy. Item 2 is not strictly a "technical choice" but is based on the significant jeopardy to the quality and integrity of the WG products as a result of deciding not to review why there are no such products after more than two years, rather than being based on: (a) his or her own views have not been adequately considered by the Working Group My understanding is that decisions on these two items are within the scope of routine administrative authority of ADs under s 6.7 of RFC 2418. Area Directors are responsible for ensuring that working groups in their area produce coherent, coordinated, architecturally consistent and timely output as a contribution to the overall results of the IETF. Architecturally consistent output is hardly likely without finalizing architecture before URP and timely output from a WG more than 2 years behind schedule requires a an open review of progress on the WG list. Accordingly the determination could be made summarily as an exercise of AD responsibilities rather than being treated as an appeal against a WG decision. This could also have the advantage of item 3 becoming moot if the decisions by the WG chairs are reversed, although the facts concerning item 3 remain relevant as evidence concerning the remaining items and the proposed resolution could be included in those for item 4. Section 6.7 also relates to my request that Patrik not participate, as he was the AD directly assigned this responsibility with respect to LDUP, wh= o in my view ought to have acted on his own initiative on becoming aware of these 2 items, without waiting for an appeal and without publicly suggesting one while simultaneously indicating a possible prejudgment. http://www.imc.org/ietf-ldup/mail-archive/msg00822.html The remaining items could also be considered straight forward, however they involve questions of fact which John has clearly disputed and therefore may require less summary consideration of what the facts actually are, before deciding what to do about them. That could also be brief as all the relevant facts which John disputes are clearly on the public record at the links provided in this appeal, or in the attached emails. (See also the links within the items to which the links point). * Item 1 - Proposed Standard Protocol before Architecture * Public knowledge of the decision to finalize a Proposed Standard for URP prior to finalizing the architecture formally occurred on publication of a revised WG charter dated 10 February: http://www.ietf.org/html.charters/ldup-charter.html However no announcement of any such decision was made to the WG list and participants in the WG may not have been aware of it then. The grounds of appeal are that finalizing a Proposed Standard before finalizing its architecture lacks common sense. All messages relating directly or indirectly to this matter from the WG list archives are at the following links: http://www.imc.org/ietf-ldup/mail-archive/msg00783.html http://www.imc.org/ietf-ldup/mail-archive/msg00784.html http://www.imc.org/ietf-ldup/mail-archive/msg00791.html http://www.imc.org/ietf-ldup/mail-archive/msg00813.html http://www.imc.org/ietf-ldup/mail-archive/msg00815.html http://www.imc.org/ietf-ldup/mail-archive/msg00820.html http://www.imc.org/ietf-ldup/mail-archive/msg00822.html http://www.imc.org/ietf-ldup/mail-archive/msg00829.html http://www.imc.org/ietf-ldup/mail-archive/msg00833.html http://www.imc.org/ietf-ldup/mail-archive/msg00834.html http://www.imc.org/ietf-ldup/mail-archive/msg00837.html In addition, John sent me an email (attached) on 20 Feb (AEST) restating his position that he had the consent of the WG, CC'd to Patrik as AD and Chris as co-chair. I am unable to provide more specific grounds at present as no reason for the decision has been given by either the WG co-chairs or the AD in response to my objection and I am completely unable to guess what reasons there might be for the change. If anyone offers plausible reasons I will respond in more detail. Relevant facts are: a) The WG charter at the time of this decision provided for architecture and information model to be finalized before finalization of URP. Both URP and architecture were drafted on that basis. b) The architecture draft contains a fairly detailed description of the principles of URP, which is much easier to understand and discuss than the URP draft. c) The architecture uses the requirements language of RFC 2119 to constrain the design of URP and has no dependency on URP, which is not included in the references. d) That was a deliberate decision as noted on 1 March 2000 in the agenda for the Adelaide IETF: http://www.imc.org/ietf-ldup/mail-archive/msg00488.html e) The corresponding minutes record that architecture authors expected other documents to be tightly coupled to the architecture document: http://www.imc.org/ietf-ldup/mail-archive/msg00539.html f) The previous version 2 of URP was explicitly dependent by reference on the architecture document: http://www.imc.org/ietf-ldup/mail-archive/msg00440.html g) Version 3 has removed that explicit dependency, perhaps accidentally, as the description of changes since the previous version in 12.3 says: "The list of references has been expanded." The technical content, and therefore the previous actual dependency on architecture remains essentially the same. h) There is no reference in the minutes to removal of the dependency and no mention on the mailing list. I believe the above provides all relevant facts and documentation for a summary determination. However documents cited below may also be considered relevant. The following items are from the San Diego LDUP draft minutes published on 26 December 2000, (no final minutes are in the Proceedings of the 49th IETF): http://www.imc.org/ietf-ldup/mail-archive/msg00767.html *** 2. "LDUP Update Reconciliation Procedures" http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-03.txt Editor(s): Steven Legg, Alison Payne Steven gave a short presentation, reiterating that there were no comments to this version of the draft. The chair asked if anyone had any comments or suggestions on this draft, and no one did. An informal room vote was taken to see if this draft was ready for Last Call, and the room agreed that it was (but that the Requirements draft should be issued first). Action: Chairs to announce Last Call after Requirements draft returns from its Last Call 11. Revised charter discussion The dates were reviewed with the authors, and the chairs will issue a revised charter by the first of the year. *** I am not aware of any other documentation that anyone might consider relevant. Urgency: This matter is urgent because the January milestone scheduled for URP WG last call had already expired, (as had the URP draft itself), when the revised charter was published and the editors of the requirements draft have formally requested a last call on requirements commencing 26 March: http://www.imc.org/ietf-ldup/mail-archive/msg00922.html Consequently WG business could be disrupted if this item is not dealt with promptly and at least before the earliest likely date for a URP final call - shortly after 10 April. Nearly a year during which the architecture could have been reviewed and fixed has already been lost as a result of the WG chairs refusal to do so - as documented in item 4. If it is possible to determine that architecture must be finalized prior to a Proposed Standard before the next final call on the requirements draft, proposed for 26 March, that could greatly assist in ensuring a productive discussion (see item 5). * Item 2 - No Review of WG Progress * The grounds for asserting that refusal to review WG progress places the quality and/or integrity of the Working Group's product(s) in significant jeopardy is that the WG has produced no such product(s) in more than two years. Something obviously must have gone wrong and a decision not to review what has gone wrong must significantly jeopardize getting it right in future. A review of WG progress was formally requested in my objection to the proposed accelerated review of the WG charter on 14 January, with an explicit request that this be put to the WG list. *** [revision] Dec 01 Reevaluate Charter and Milestones [Albert] If nobody else thinks there should be an earlier reevaluation of the progress so far in the light of earlier milestones, fine. But WG members should be explicitly asked to reflect on this rather treating a consistent inability to achieve milestones as grounds for accelerating the process by which new milestones are adopted, especially when the proposed means to achieve new milestones is to for RFCs on detailed implementation to be settled before Information Model and Architecture. *** http://www.imc.org/ietf-ldup/mail-archive/msg00784.html Public knowledge of the decision not to open such a review in connection with the charter revision and not to ask the list whether the WG wanted to open such a review, formally came with the publication of the revised charter on 10 February, as for item 1. This adds a new milestone, "Reevaluate Charter and Milestones" for December. No such milestone existed in the previous charter. The effect of the charter including such a milestone could be to provide grounds for ruling out of order any discussion on the subject until December. John has supplemented his refusal to ask on the list whether WG members did or did not wish to conduct such a review by issuing an agenda for the IETF meeting with no such agenda item: http://www.imc.org/ietf-ldup/mail-archive/msg00927.html The relevant facts are as follows. This agenda has just the same old list of work that hasn't been completed for the last two years. It doesn't even list names of the "other missing drafts" any more. An I-D on "Mandatory Replica Management" was originally due in November 1998. That is a first draft, not a last call - still "missing" after more than 2 years. The original WG charter proposed on 23 September 1998 had milestones of October 1998 for last call on requirements and April 1999 for all work to be completed. Nearly two years after all work should have been completed some of the work has not even started and none has been completed. http://www.imc.org/ietf-ldup/mail-archive/msg00157.html All other relevant documentation concerning this decision and the lack of any explanation whatever of the reasons for this decision is included with item 1. * Item 3 - Unauthorized posting of WG charter * Public knowledge of the decision to post a revised WG charter without authorization from the WG occurred in exactly the same way as public knowledge of the decisions contained in it - by the (unannounced) posting of the revised charter dated 10 February, as for items 1 and 2. In his email of 20 Feb AEST (attached) John rationalizes his deliberate decision not to ask the question on the mailing list as follows (CC'd to Patrik and Chris): *** it is obvious that you don't understand IETF procedure here. Let me expla= in by first repeating what I stated below: >I posted the revised charter for discussion for this group. You were the >only person that made a comment. Silence means consent. The only other message was one complaining about lack of time, so I gave the working group another week to review the charter. At the end of the review period, there was only your comments. Therefore, I had working group consent for the charter as is. *** The relevant facts that would have been obvious to John if he had merely glanced at the WG archives before reaffirming his decisions are as follows: a) There were two people with comments on Proposed Standard before architecture - both expressing some level of incredulity ("lacks common sense" and "???"). b) John did not give the working group another week to review the charter. c) John did not ask the WG whether the URP Proposed Standard should be finalized before architecture and information model. d) John did not ask the WG whether there should be a review of progress. e) John did not announce that he had reached some conclusion about either of the above matters after considering the objections and indicate what course of action he intended to follow so that participants in the WG could respond if they disagreed with that course of action. f) John did not indicate by what revised date comments should be submitted in the light of my objection to expedited approval. g) Anything John may imagine that he did that resulted in him obtaining the consent of the WG for his decisions was in fact a fantasy. John said absolutely nothing at all to the WG. There was no way anyone in the WG could have known what John's intentions in dealing with the objection might be, or when they should submit comments by, unless they happened to share John's assumption, that if I propose something, John would of course disagree and the WG would of course share John's view - and also shared that assumption with respect to Tim. Evidently John takes that attitude so completely for granted, that he is genuinely perplexed that I would not find it obvious my objection had been rejected. But in a different context, without the attitude John has adopted, it is entirely possible that he might have *agreed* that architecture and information model should be finalized before protocol specifications or have *agreed* that a review of WG progress would be appropriate after more than 2 years. Whatever mystical powers John claims to possess for discerning other peoples views from their silence, I have never claimed to have any. I have only been able to attend one LDUP WG session - at the Adelaide IETF. My only participation in the WG has been through technical discussions in the WG list and I have no social contact with other WG participants. John had never emailed me on any subject, nor made any comment in response to anything I (or for that matter anyone else) had said in the WG list, where most of the business of the WG is supposed to be done, prior to my raising that objection on 14 January and still did not do so until I asked for an explanation of the posting of the unauthorized charter. There was no way that I or anybody else could have known that my objections had been rejected by a "consensus" of the WG. I didn't even know that John would be automatically opposed to them (though I do now). According to RFC 2418 s 3.3: It is left to the discretion of the working group chair how to evaluat= e the level of consensus. The most common method used is for the workin= g group chair to state what he or she believes to be the consensus view and. at the same time, requests comments from the list about the stated conclusion. Alternative methods are also available, such as asking everyone to explicitly indicate whether they agree or disagree. A method unavailable to a WG chair is not even *asking* and just listening to an inner voice in one's own head. That is not "declaring consensus", it is "hallucinating". Also even absolute dictators announce their decisions, but John does not. We are supposed to just guess what he has decided. Or more precisely we are supposed to *know*, and if we don't know what is going on in John's head, that means we don't understand IETF procedures. John's method is not called "silence is consent" - it is called "I don't give a damn what you think - and I assume nobody else does". There is also some obligation for a WG chair to answer simple questions about WG business. When responding to the request for charter review I wrote: *** [revision] The LDUP WG Chairs will assign one or two persons to be official LDUP WG liasons to ITU, to monitor X.500 replication work in the ITU, and to coordinate the work of the LDUP WG with similar work in ITU. [Albert] My understanding is that X.500 dropped the URP proposals for multi-master as a work item. Who is or are the liaisons and what coordination has been or is being done? *** I would really like to know the answer as I have a particular interest in X.500 issues affecting LDAP and LDUP and would like to discuss some of those issues with people aware of what's going on because they affect the architecture for LDUP as in the discussion below: http://www.imc.org/ietf-ldup/mail-archive/msg00728.html John won't tell me, presumably because he doesn't like me objecting, or perhaps because I submitted an I-D he didn't like opposing a protocol design he does like. Whatever it is, he has an obligation to perform the normal functions of a WG chair whether he likes me or not. Public knowledge that the decision to post the unauthorized WG charter was deliberate occurred on 17 February when John responded to my objection the same day. I had thought it likely that John simply forgot he had requested comments, as that seems to be the way the WG is managed generally. I suggested that possibility, drawing attention to the lack of response to the only other comment apart from mine: *** These included at least one minor editorial correction (typo) which I can= not imagine anybody would have taken exception to. Therefore I am inclined to assume the document was simply posted "as is" without bothering to consid= er any comments made on it, despite having asked for comments. Was that the case? Who took the decision, and why were we not informed? *** John refuted that possibility by saying: *** If you would be so kind as to actually read the charter, you'll find that your complaint of having LDUP appoint two liaisons was dropped from the charter. [...] I didn't issue a note to the working group because I was, and still am, O= N VACATION. I will now issue such a note, even though I am still ON VACATIO= N. As far as Tim's message, I simply did not see it. Thanks for the link, I'= ll take a look at it, and we can discuss the changes on the list next week, when I'm back from vacation. *** http://www.imc.org/ietf-ldup/mail-archive/msg00815.html From the SHOUTING, I gather I am supposed to *know* that he was gone on vacation on Feb 17. Presumably I am supposed to know this, because that is the natural conclusion to draw from him having issued a WG last call on Feb 5 and earnestly solicited our comments until Feb 20. I responded: *** Thank you, that answers my concern that the document might have simply be= en posted without bothering to look at the comments. In future when you propose to take some formal action on behalf of the WG= , and you happen to be on vacation, could you please postpone it until you are able to consult or at least inform the WG. There is no need to take such actions while on vacation just as there is no need to reply to this email while you are on vacation. *** http://www.imc.org/ietf-ldup/mail-archive/msg00820.html John's statement completely clarifies that he did not accidentally forget to respond to my objections and obtain a WG decision, but that he had evaluated my comments, although accidentally not noticing Tim's, had decided what to do about them, and was being sarcastic about my failure to even notice that one of my complaints had been met. That confirms that he deliberately chose to post the revised WG without asking the WG for its views on the objections and therefore without authorization from the WG for implementing his own views. Needless to say, he has not issued any note announcing his decision, although he has issued several memos telling us what we think about various issues discussed during his vacation and accepted the requirements editors report on the recent final call more than a week ago. My assumption that both WG co-chairs are involved in the decisions for items 1-3, though not necessarily both involved in the hallucinations, is based on the reference to "Chris and I", and the signature "John and Chris" on the message posted by John on 13 January requesting accelerated charter revision and the signature "John Strassner and Chris Apple" on the message posted by John on 5 February, opening a WG final call until 20 February. I have not actually seen anything directly from Chris, but I assume he should have been involved, and would have been, unless *both* WG co-chairs were "on vacation" while the WG was conducting a final call. That is possible as Chris has not been heard from since 17 January when he "forwarded" a message about X.500 liaison to the WG, which explained it had already been posted, instead of actually following up to propose any response to the important proposals it referenced. http://www.imc.org/ietf-ldup/mail-archive/msg00789.html http://www.imc.org/ietf-ldup/mail-archive/msg00790.html The proposed resolution is intended to underline the significance of the WG charter as a contract between the WG participants and the rest of the IETF as to work that will be undertaken. It is essential that the IESG be able to simply assume that requests for a routine extension and modification by a WG *are* made by the WG and not unilaterally by a WG co-chair without resolving objections. It is also intended to resolve the underlying problems for items 1 and 2 beyond what should be decided in a summary determination to reverse those decisions. * Item 4 - Refusal to resolve technical issues in WG list * According to RFC 2418 s 2.2 "Most of the work of an IETF working group will be conducted on the mailing list." s 6.1 The Chair should attempt to ensure that the discussions on this list are relevant and that they converge to consensus agreements. The Chair should make sure that discussions on the list are summarized and that the outcome is well documented (to avoid repetition). The Chair also may choose to schedule organized on- line "sessions" with agenda and deliverables. These can be structured as true meetings, conducted over the course of several days (to allow participation across the Internet). The following is a complete list of John's contributions to the mailing l= ist between when I joined following the Adelaide IETF at end of March 2000, a= nd my objection on 14 January: Revised work group charter for your review 13 Jan 2001 http://www.imc.org/ietf-ldup/mail-archive/msg00783.html Re: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt http://www.imc.org/ietf-ldup/mail-archive/msg00769.html 26 Dec 2000 DRAFT minutes for San Diego meeting 26 Dec 2000 http://www.imc.org/ietf-ldup/mail-archive/msg00767.html Draft minutes for LDUP 11 Aug 2000 http://www.imc.org/ietf-ldup/mail-archive/msg00688.html Fw: I-D ACTION:draft-langer-ldup-mdcr-00.txt 11 Apr 2000 http://www.imc.org/ietf-ldup/mail-archive/msg00543.html Draft Minutes for the LDUP WG meeting 10 Apr 2000 http://www.imc.org/ietf-ldup/mail-archive/msg00539.html The following is a similar list for Chris: RE: New version of draft-ietf-ldup-replica-req 16 November 2000 http://www.imc.org/ietf-ldup/mail-archive/msg00738.html RE: I-D ACTION:draft-ietf-ldup-replica-req-03.txt 8 August 2000 http://www.imc.org/ietf-ldup/mail-archive/msg00682.html RE: I-D ACTION:draft-ietf-ldup-replica-req-03.txt 4 August 2000 http://www.imc.org/ietf-ldup/mail-archive/msg00668.html LDUP Working Group Agenda 24 July 2000 http://www.imc.org/ietf-ldup/mail-archive/msg00631.html I-D Cut-Off Reminder 12 July 2000 http://www.imc.org/ietf-ldup/mail-archive/msg00593.html Pittsburgh LDUP WG Session 23 June 2000 http://www.imc.org/ietf-ldup/mail-archive/msg00575.html What's going on? 8 Jun 2000 http://www.imc.org/ietf-ldup/mail-archive/msg00559.html It is obvious that neither of the co-hairs were participating in "most of the work" *at all*, let alone performing their duties as moderators. John asked one (somewhat pointless) question (26 December 2000). The rest are just administrative except for one from Chris. Chris sent one message that he would probably regard as moderating the list, or even perhaps as participating in technical discussion, (above, 16 November 2000), though I regarded it as merely a display of bad temper following my statement on the previous day that I would be opposing the requirements draft at IETF last call: http://www.imc.org/ietf-ldup/mail-archive/msg00734.html I simply ignored it at the time, while hoping he would actually follow up on his intention to comment concerning atomicity and ACI. I am making no complaint about it now, but am just listing it as the *only* occasion on which either of them took part in any actual discussion on the list in that entire period. It also establishes that the issues concerning atomicity which John ordered me not to discuss during last call (item 5) had been explicitly identified as relevant to last call by his co-chair. All the rest of their messages are just administrative (including John opening a discussion of my I-D on 4 August, declaring the first order of business to be a response from the authors of the previous requirements draft, and then doing nothing when they did not respond). Apart from that one message by Chris, the WG co-chairs never responded to anything *anyone* said in any technical discussion about *anything*, let alone summarize and document the outcome etc in the entire period since I joined following the Adelaide IETF and my objection on 14 January. The message of 8 June 2000 from Chris is especially interesting as it indicates the state of the WG before I first posted a message: *** I haven't seen any recent list activity other than two SPAMs since April 25th. There are still deliverables that are/were due that have not been published. Please report on the status of your present (or pending) draft to the list. *** I raised my concerns about the manner in which the WG was being managed after reviewing the archives on joining, and lurking for a while when the WG was supposed to have been considering the objections I had raised at the IETF meeting and my alternative MDCR proposal to replace URP. The subsequent exchange of emails included a polite, but sufficiently thorough demonstration that neither of the WG chairs had been even following what was going on, for Chris to give a commitment to pay more attention in future. It also referred to the consequences of having settled on a design before requirements and architecture (item 1) and the possibility of rechartering the WG if the then current state continued (item 2). I do not think there was anything about my polite but insistent manner in that email, that would have led any rational person to imagine that I would just give up and go away in the event of anything like item 3 or item 5 happening or item 4 continuing. The whole of the attached emails from Chris of 18 and 20 July 2000 and the links within my included messages are important background for understanding the situation in the WG and item 5 of this appeal. For the purposes of this item 4, the following final message from Chris is relevant: *** OK. Here's the deal. There will be an agenda item for the Pittsburgh WG meeting to discuss the issues you have raised on the mailing. We'll publish a summary of that discussion in the meeting minutes. I'll craft and coordinate with my co-chair a reply to the official meeting minutes posting with a request for objections to a particular course of action relative to the issues you have raised on the mailing list. In this case, silence from a majority WG participants that John and I know to be actively participating in LDUP work will be interpretted as having achieved rough concensus on that course of action. I believe that's all any WG co-chair could reasonably be expected to do in a situation like this. I've been too swamped with day-to-day job responsibilities to pay much attention to this particular WG issue until the past week or so. Which is one reason for a change in who I am employed by effective 7/24. After that date, since my new employer is much more supportive of IETF work than my present employer, the situation that the WG is in now, will receive much more of my day-to-day attention. And, one way or the other, the issues you have raised will get resolved. John, Patrik, or Ned: do you have other opinions about how to proceed? Chris. *** That was never done. Both John and Chris know that they have never "crafted" any message to obtain a decision from the WG list on any issue I have raised. They know that is what they committed to do and they know it would resolve the issues "one way or the other". Consequently they both know that there has been no such decision. The "much more" of day-to-day attention from Chris consisted of continuing to do nothing on the list, including complete absence from the last call on requirements. In addition formally minuted commitments that would result in technical discussion in the list were not followed up: *** 7) LDUP Update Reconciliation Procedures (Steven) file: draft-ietf-ldup-urp-02.txt This draft did seem ready for last call, but now we may need to reconsider it given Mr. Langer=92s alternate proposal. The authors are looking at making a future revision to accommodate the updating of partial replicas. Steven and Alison point out that the main difference between URP and other approaches is whether conflicts are merged or resolved immediately. Steven and Alison also note that this subject keeps coming up. Therefore, Steven and Alison have volunteered to write up a new document that describes why URP ended up the way it did. The working group members that that this was a good idea, and Patrick OKed it. Chairs to revise the charter and send to list. *** It is of course unnecessary to amend the charter in order for a document to be submitted to and discussed seriously by the WG. It is however necessary for WG chairs to follow up on such minutes and ensure that technical disagreements are discussed properly in the list on the basis of such documents rather than just leaving them unresolved. Failure to initiate such measures themselves and refusal to implement them when agreed on despite their inactivity have resulted in the WG chairs preventing the WG from functionioning as part of a technical standards producing process. Public knowledge that the WG co-chairs had decided not to participate in the WG list at all did not occur on any specific date. It crystalized for me when John suddenly did start participating on 17 February following my complaint the same day about the unauthorized posting of the WG charter. He had ignored the last call discussion until then, posting only routine administrative messages. When he did join in, it quickly became apparant that he had no idea how to conduct himself in technical discussions. When he went ballistic as documented in item 5, it then became obvious that Chris wasn't around and had decided to remain a non-participant. The proposed remedies include appointing a Secretary to keep track of things, a Facilitator to ensure an open and fair process that converges in "rough consensus" and a Consultant with appropriate technical background, familiar with Internet Architecture and IETF process. These are well known remedies for problems in a WG, based on extensive IETF experience. The proposed remedy of replacing both WG co-chairs is equally well known. It is necessary in this case because there is no point seeking commitments concerning future behaviour when such commitments have already been given and not carried out, as documented above. These are of course purely administrative, not disciplinary measures. I believe Patrik should have considered these remedies when if first became obvious to him that the WG was going around in circles: http://www.imc.org/ietf-ldup/mail-archive/msg00834.html Especially so as Patrik was involved in, and had expressed his approval of, the commitments that were made by Chris on 20 July 2000, and stated an intention to follow up and enforce, the decisions that would have resulted from the WG co-chairs carrying out those commitments - see attached email from Patrik sent 20 July 2000 AEST. BTW Patrik's impressions are not quite accurate in the above recent public message to the list. I have only attended one IETF LDUP session, where it was Patrik who proposed that I be required to submit an I-D within a week and that this be discussed on the list. Any going around in circles about multi-master at meetings has not involved me as I wasn't there. Also a review of the archives of the list and minutes of earlier meetings will confirm that it was going around in circles long before I joined. As Chris put it in the agenda for the first meeting I attended, which was before I had joined the WG list: 2) Why are we so far behind? We're showing the signs of starting to die a flailing death. Don't let it happen if this work is important for your LDAP implementations. Working groups have, can, and will be killed for lack of activity similar to what I've seen since the last IETF meeting. http://www.imc.org/ietf-ldup/mail-archive/msg00488.html This was followed by a continuation of the situation described, with no discussion on the list. Instead of a report of a discussion at the meeting concerning the answer to the *question* posed by Chris, the minutes record the following "General Admonishment" by John: *** 3. General Admonishment ;-) (John) Your co-chairs are concerned that we're showing the signs of starting to die a flailing death. So, if this work is important for your LDAP implementations, please redouble your efforts to move these drafts along. Your co-chairs are here to help and facilitate this. We will be collecting expected times of updating the drafts today, so that we can update our charter. Working groups have, can, and will be killed for lack of activity, so please try and keep these new sets of dates. *** http://www.imc.org/ietf-ldup/mail-archive/msg00539.html * Item 5 - Bullying retaliation in response to formal objections by John = * The following extract is just one from several similar by John commenting on quotes from me, emphasizing each time that he was acting in his capacity as WG co-chair: http://www.imc.org/ietf-ldup/mail-archive/msg00850.html *** >My view is that the critically important requirement that applications >depend on >is simply that a change can be reliably made to exactly the entry you >thought you >were changing and not result in some mixture of updates combined with >unknown >concurrent changes by some other application. Albert, you presented your way, and it was the consensus of the working group that the behavior you proposed was NOT what the user would have expected. That is why the working group has adopted the approach it has. With the chair hat on, I would therefore ask you to stop bringing this up. If you have an explicit suggestion that would make our current approach better in some way, please say it. But simply stating that it won't work, or talking about your alternative, are not helping the working group make progress. Please stop. >That is essential for basic data integrity and easily achieved by the >provisions >regarding modify operations in the LDAP standards. The whole point of th= ose >provisions is that by explicitly asserting that all relevant attributes have >particular values at the start of a modify and particular values at the end, >you are guaranteed that the operation will fail if that turns out not to= be >the case due to some other change between when you read an entry and whe= n >you modified it, rather than ending up with randomly garbled entries. same comment as above, this doesn't help [Note] This is an explicit claim by a WG chair that a consensus had been reached on an item under discussion when no such decision had been put to the WG at all. Followed immediately by a demand that I cease arguing my position. No decisions have been put to the WG list about anything, since I joined and the only relevant minutes from WG meetings - published by John himself, explicitly record that various issues are still open and should be discussed on the list. http://www.imc.org/ietf-ldup/mail-archive/msg00688.html No subsequent meeting has recorded even a room consensus that any issue has been closed and should not be discussed on the list. John's co-chair Chris had specifically stated, as mentioned in item 4, that the specific issue I was referring to, was open for discussion in WG last call. John had never claimed before that any such decision had been made, and had not made any other comment concerning anything I said on the list= , prior to my raising a formal objection to his unauthorized posting of a revised WG charter. John's bullying, as documented above and below, is plainly in retaliation for that. John would however have been unaware that on the very issue he was bullyi= ng me about, the requirements editors would recommend adopting exactly what I h= ad insisted on since joining the WG: P7. The protocol MUST preserve atomicity of LDAP operations as defined in RFC2251 [RFC2251]. The sequence of events was as follows. A technical discussion relating to requirements last call was proceeding normally in these threads: http://www.imc.org/ietf-ldup/mail-archive/msg00807.html http://www.imc.org/ietf-ldup/mail-archive/msg00808.html http://www.imc.org/ietf-ldup/mail-archive/msg00809.html http://www.imc.org/ietf-ldup/mail-archive/msg00812.html http://www.imc.org/ietf-ldup/mail-archive/msg00816.html http://www.imc.org/ietf-ldup/mail-archive/msg00817.html http://www.imc.org/ietf-ldup/mail-archive/msg00819.html http://www.imc.org/ietf-ldup/mail-archive/msg00821.html http://www.imc.org/ietf-ldup/mail-archive/msg00824.html http://www.imc.org/ietf-ldup/mail-archive/msg00825.html http://www.imc.org/ietf-ldup/mail-archive/msg00826.html http://www.imc.org/ietf-ldup/mail-archive/msg00827.html http://www.imc.org/ietf-ldup/mail-archive/msg00828.html http://www.imc.org/ietf-ldup/mail-archive/msg00830.html John was not interested in the discussion at all, until *after* my exchange with Patrik on items 1 to 3 as documented in item 1. Then John suddenly takes an interest in a technical discussion, in an obvious attempt to start a flame war, claiming that the matters he had refused to put to the WG for decision had been decided. http://www.imc.org/ietf-ldup/mail-archive/msg00836.html I turn the other cheek. John tries again. http://www.imc.org/ietf-ldup/mail-archive/msg00839.html Two cheeks turned, I focus on the only positive and useful comments in it: http://www.imc.org/ietf-ldup/mail-archive/msg00841.html (Followed up later in these messages) http://www.imc.org/ietf-ldup/mail-archive/msg00890.html http://www.imc.org/ietf-ldup/mail-archive/msg00903.html So John tries a third time: http://www.imc.org/ietf-ldup/mail-archive/msg00850.html Having run out of my usually available cheeks, I am at a loss as to what to do. It is impossible to just continue a normal technical discussion under this kind of barrage. Fortunately, Ed Reed comments on exactly the quote John ordered me not to discuss further, correctly described by Ed as "the crux of the matter". http://www.imc.org/ietf-ldup/mail-archive/msg00855.html John tries a fourth time, proceeding to lecture me from a great height, talking about the "the feeling of several members" (who have said absolutely nothing about any such feeling themselves in the list or to me), that I am "promoting" my MDCR draft and should not refer to it. My MDCR draft was written specifically in support of my objections to the requirements draft, has not been rejected by the WG and was, as it happens mentioned in passing in only 1 of the dozen or so messages in the threads that John is trying to disrupt. I am perfectly entitled to refer to it during the requirements discussion - that is one of the things I-Ds are *for*. John repeats his claim that I had made "unprofessional" remarks, which he has now "explained" to me, although his email, sent simultaneously with his announcement of it, has done nothing of the sort. http://www.imc.org/ietf-ldup/mail-archive/msg00864.html Alas, I have but four cheeks. So when responding to Ed, I also make some passing indirect references to John's behaviour. http://www.imc.org/ietf-ldup/mail-archive/msg00873.html A review of the whole WG last call discussion, apart from these specific messages involving me, will make it pretty obvious there is an enormous difference between the manner in which others discuss things and the manner in which John does. The difference is that John is a bully, and his focus is on me is because I objected to his unauthorized posting of the WG charter, and dates precisely from that event. His harping on MDCR strongly suggests there is some burning resentment about that I-D, but it expired long ago and he never behaved this way while it was available, so it must primarily relate to the objection. Retaliation of any kind for raising issues in accordance with IETF procedures is completely unacceptable from any participant in IETF work because it undermines the open and fair standardization process conducted by the IETF. (Retaliation for publishing an I-D is of course no better). Such conduct requires formal disciplinary action when engaged in by anyone holding a responsible position. More so when it involves deliberate abuse of the authority of a WG chair by ordering the person being retaliated against not to present their technical arguments on a major issue critical to the direction of the WG in a WG last call. The disciplinary measures proposed are quite mild. John will not even be seriously inconvenienced by temporary exclusion as he is not a particularly effective advocate for his own views anyway, and would positively benefit from being forced to not respond instantly and have his comments passed through others for long enough to learn the normal practice of thinking before one speaks. The important thing is that the proposed resolution *does* include formal disciplinary measures, not just a direction to not repeat the behaviour. I doubt that the IETF has a great deal of experience with bullying, unlike its wealth of experience in dealing with disputes among reasonable people about technical issues. Consequently there is no advice about it in the BCPs. But it is a well established "best current practice" in institutions that do regularly have to deal with bullies, that it is *always* necessary to include actual disciplinary measures rather than just corrective and preventative measures. Otherwise the bully just feels "thwarted" and looks for an opportunity to strike again, whereas it is essential that they be made to understand the futility of persisting. Normally harsh measures are required immediately, because bullies usually select victims who are weak and powerless and they need reinforcement by support from a stronger authority in order to stand up for themselves. The rather mild measures proposed are because John is an exceptionally unskilled and obviously inexperienced bully or he would have picked a more suitable target. On the one hand that makes it more likely that he will learn his lesson easily and not repeat the behaviour. On the other hand it means that he will receive a full demonstration of the futility of bullying anyway, as I have already initiated the usual self-remedy for such behaviour and will continue until it stops. I will not permit John to interrupt a technical discussion by bullying again, although I have waited until after the WG final call was over on this occasion. The proposed differentiation between the disciplinary measures with and without an apology is because an apology is usually more beneficial in correcting and preventing such behaviour than the disciplinary measures themselves, provided it is accompanied by *some* such measures so that the bully cannot think the bullying strategy has merely been thwarted and is made fully aware of the futility of continuing. A harsher differentiation is inappropriate because: a) People accused of misconduct have a right to maintain their innocence after the charges are proved and should not be punished for doing so, but only for what was proved. b) Some people are simply incapable of admitting that they have made a mistake, let alone apologizing for it. This is a serious character flaw which makes a person unsuitable for responsible positions, but that is an administrative matter, not some misconduct that requires disciplinary measures in itself. Public knowledge that the behaviour John was engaged in was retaliatory bullying rather than getting carried away in the heat of the moment over some issue he felt passionately about, occurred on 1 March when John accepted the requirements editors decision on his "action item" by adopting precisely what I had been advocating and what John had ordered me to stop advocating, with the words: "As WG Co-Chair, this action meets my action item." If he had actually been upset concerning the issue he was bullying me about, he would have said then and there that he was opposed to the modified proposed requirement, either in a reasonable or in an unreasonable manner. Instead he confirmed that his behaviour was just retaliatory bullying about something else, pure and simple. * Process * I approached the WG chairs directly by email concerning the substance of the problems that led to items 1, 2 and 4 in July 2000. This correspondence was CC'd to both ADs as suggested by Chris. Commitments were made by Chris on behalf of the WG co-chairs concerning item 4 as shown in the attached email sent 20 July 2000 AEST and positive action to deal with requirements first by means of an independent review and the appointment of 2 additional editors did result in a greatly improved requirements document and led me to assume there would be no attempt to push a URP Proposed Standard through without WG review of architecture. Consequently I did not take those matters further then. The recent decisions in items 1, 2 and 3 and the ongoing decision in item 4 are a complete renunciation of commitments already made as a result of the earlier direct approach to the WG chairs. This make another try pointless. Also it is now more than 2 weeks since John stated publicly that he would discuss other comments, (but not my comments) re the charter on the list "next week". He has not done so. My request for an explanation of why the unauthorized WG charter had been posted was immediately met by an accusation of "unprofessional" remarks from John followed by an email, CC'd to Chris and Patrik, confirming that he would not change his decisions and then followed by item 5, which renders a direct approach undesirable as well as futile. I have therefore initiated this formal appeal as proposed publicly by Patrik, and also initiated the necessary direct remedy in response to item 5, without any further approach to the WG co-chairs. I will be happy to provide any additional information requested and to respond to any replies by the WG co-chairs. Sorry about the length. Albert Langer ------=_NextPart_000_000C_01C0A91F.880CE280 Content-Type: message/rfc822 Content-Disposition: attachment From: "John Strassner" To: Cc: "'John Strassner'" , "'John Strassner'" , "'Chris Apple'" , =?Windows-1252?Q?'Patrik_F=E4ltstr=F6m'?= References: <4.3.2.7.2.20010217130057.00b32598@mira-sjcm-1.cisco.com> Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D Date: Tue, 20 Feb 2001 14:11:07 +1100 Message-ID: <4.3.2.7.2.20010219184146.03d6fee8@mira-sjcm-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 X-Envelope-To: albert.langer@directory-designs.org In-reply-to: <002c01c0993d$afe13280$6628a8c0@nowhere.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: High X-Sender: jstrassn@mira-sjcm-1.cisco.com X-Message-Flag: Follow up Content-Transfer-Encoding: 7bit Albert, it is obvious that you don't understand IETF procedure here. Let me explain by first repeating what I stated below: >I posted the revised charter for discussion for this group. You were the >only person that made a comment. Silence means consent. The only other message was one complaining about lack of time, so I gave the working group another week to review the charter. At the end of the review period, there was only your comments. Therefore, I had working group consent for the charter as is. Having got that consent, the next item was for me to forward the charter to our ADs for approval. When Patrik saw the charter, he responded to me that a WG doesn't appoint liaisons. Note that the IESG has the power to change the charter of a WG. So Patrik and I worked out suitable text, which he has sent to you already. The problem lies in the early publishing of the charter without the added text. You then write: >Rather than having to do a diff to discover such changes I would >expect to know about them because they would have been put to and discussed >in the WG email list. There was no mention of any such change in the only >document you put to the WG. As stated above, the charter WAS discussed, and consensus was reached. As far as publishing a DIFF, that is probably a good idea. Most WGs don't do that. And I would note that I explicitly pointed out in my original message where the changes were. I won't belabor the liaison comments, as Patrik has already responded. You then write: >Certainly issuing the final call within a few days of the end of the month >successfully meets the objective (indeed something of a record as far as >LDUP schedules are concerned). My point however was simply that a revised >charter should not specify delivery dates that have already passed, which >is precisely what you did. Let me try again. The WG agreed to that charter. The fact that it got held up was not the WG's fault. I didn't think that we needed to change the dates, as those dates were precisely what the WG agreed to. And I was hopeful of issuing the two last calls, but we had additional discussion in January that needed to be resolved before those documents went out. Hence, we were late. It doesn't mean that the charter is worthless, it means that we missed the dates that we agreed to in the last WG meeting. You then write: >[Albert] >The minutes did not say we should discuss a draft that has not been written >yet and as I pointed out, and you seem to be confirming, they did not say >that >anybody had committed to producing such a draft by the end of March. Actually, we DID get author commitments for these drafts. You then continue: >The revised charter does say that LDUP is committed to produce a draft >by March 2001. My point was that under the circumstances it could be >unrealistic to commit to a schedule of March 2001 for an I-D. Do >you believe it is a realistic schedule? Or do you believe the schedule >in a charter does not involve any sort of commitment? This is insulting, and I'll thank you in advance to stop making such comments. This is a working group, and of course commitment is important. If you had attended the WG meeting, you would have known that I was very forceful in getting commitment from the new authors. You then write: >[Albert] >Propos[al] to finalize the Update Reconciliation Procedures >four months [actually 3 -AL] prior to finalizing the Information Model and >Architecture lacks common sense. >*** > >If you genuinely considered either of those references to be >"unprofessional" I would have expected some private email from you at the >time. Look at what you wrote. You said that our direction "lacks common sense". If that isn't insulting, I'd like to hear your definition of what is insulting. Not to mention the basic point that your approach has already been rejected. Your continued discussion of an approach that has been rejected by the WG is not helpful. Believe it or not, I have figured out that you don't agree with the approach, despite my "lack of common sense". I wish that you would figure out that your approach was rejected. So, if you are genuinely interested in contributing to the working group, make what we have better. Don't redesign it using a rejected approach. John At 10:59 AM 2/18/2001 +1100, Albert Langer wrote: >[John] >I posted the revised charter for discussion for this group. You were the >only person that made a comment. If you would be so kind as to actually >read the charter, you'll find that your complaint of having LDUP appoint >two liaisons was dropped from the charter. > >[Albert] >Thank you for your prompt response. > >I made no complaint about LDUP appointing two liaisons. I simply asked the >the following question: > >*** >[revision] >The LDUP WG Chairs will assign one or two persons to be official >LDUP WG liasons to ITU, to monitor X.500 replication work in the ITU, >and to coordinate the work of the LDUP WG with similar work in ITU. > >[Albert] >My understanding is that X.500 dropped the URP proposals for >multi-master as a work item. > >Who is or are the liaisons and what coordination has been or >is being done? >*** > >I did not notice that the charter had been amended to remove all reference >to appointing liasons, thank you for drawing that to my attention. > >Rather than having to do a diff to discover such changes I would >expect to know about them because they would have been put to and discussed >in the WG email list. There was no mention of any such change in the only >document you put to the WG. > >It appears that instead of answering my question, someone, perhaps you, has >taken a decision not to have liason with the ITU to monitor X.500 >replication >work in the ITU and to coordinate the work of the LDUP WG with similar work >in the ITU. > >Surely decisions about liasons between standards bodies require some degree >of formality. > >Who took that decision, why and why was the WG not asked for an opinion >about it? > >Since you appear to have misunderstood my question as a complaint, I will >volunteer >my opinion despite not having been asked for it. I believe it is important >that >there *should* be active liason with X.500 replication work and the reasons >for >URP being dropped as a work item there should be studied and thought about >here. > >Be that as it may, revision of the WG charter to remove a commitment to >establish >a liason is not something that should be done in response to a single >comment, >whether correctly understood or not. It should have been, and should now be, >put to the WG formally. > >[John] >As far as your complaint: > >[revision] Jan 01 LDAPv3 Directory Replication Requirements I-D goes to WG >Last Call as Informational. Jan 01 LDAPv3 Update Reconciliation Procedures >I-D goes to WG Last Call as Proposed Standard. >[Albert] I do not think it is appropriate to issue new deadlines that have >already passed. > >I would point out that Jan 01 means by the end of January, not 1 January. > >[Albert] >Thank you. I had not understood that 01 referred to 2001 in my original >comments >although I understood after seeing Timothy Hahn's reference to this. > >Nevertheless, the WG Final call was issued on 5 February and the revised >charter was subsequently issued on 10 February after 2 of the dates >had already expired, as I originally stated. > >[John] >We did successfully meet the first objective. We didn't meet the second >objective because we had some comments on the requirements draft, and I >felt uncomfortable issuing URP for last call until we had passed last call >for the requirements draft. > >[Albert] >Certainly issuing the final call within a few days of the end of the month >successfully meets the objective (indeed something of a record as far as >LDUP schedules are concerned). My point however was simply that a revised >charter should not specify delivery dates that have already passed, which >is precisely what you did. > >[John] >You objected that you haven't seen any mailing list activity on the drafts >from the new authors. The minutes simply said that the new authors would >write these drafts and make every effort to get them posted in the >repository before the next cut-off date. It didn't say that we had to >discuss a draft that hadn't been written yet. > >[Albert] >The minutes did not say we should discuss a draft that has not been written >yet and as I pointed out, and you seem to be confirming, they did not say >that >anybody had committed to producing such a draft by the end of March. > >The revised charter does say that LDUP is committed to produce a draft >by March 2001. My point was that under the circumstances it could be >unrealistic to >commit to a schedule of March 2001 for an I-D. Do you believe it is a >realistic >schedule? Or do you believe the schedule in a charter does not involve any >sort >of commitment? > >[John] >As far as your unprofessional remark about URP, you are the only person >objecting to it. > >Therefore, in the face of only one objection, and considering that we did >discuss charter updates at the WG meeting, there was clear consent of the >working group for adopting this new charter. The charter was so adopted. > >[Albert] >I made only two references to URP, the one quoted above, and the following: > >*** >[revision] >Apr 01 LDAPv3 Replication Information Model I-D goes to WG >Last Call as Proposed Standard. > >Apr 01 LDAPv3 Replication Architecture I-D goes to WG Last >Call as Informational. > >[...] >[Albert] >Propos[al] to finalize the Update Reconciliation Procedures >four months [actually 3 -AL] prior to finalizing the Information Model and >Architecture >lacks common sense. >*** > >If you genuinely considered either of those references to be >"unprofessional" I would have >expected some private email from you at the time. > >I cannot even imagine what it is you now claim to be "unprofessional" about >either of >them, but since you have said so publicly, please either justify your >statement or >withdraw it. > >If there is a consensus in the WG to finalize detailed protocols before >finalizing >architecture and information model then so be it. But the WG was originally >chartered >to decide on the architecture and information model before finalizing >protocol >details - for reasons that I believe are obvious, "common sense" and indeed >"professional". > >Any such consensus to reverse the normal and previously agreed sequence >should be >established on the mailing list by asking the participants what they think. >Once an >objection has been raised a consensus cannot be assumed on the basis of >discussions >at an IETF meeting. > >[John] >I didn't issue a note to the working group because I was, and still am, ON >VACATION. I will now issue such a note, even though I am still ON VACATION. > >As far as Tim's message, I simply did not see it. Thanks for the link, I'll >take a look at it, and we can discuss the changes on the list next week, >when I'm back from vacation. > >John > >[Albert] >Thank you, that answers my concern that the document might have simply been >posted without bothering to look at the comments. > >In future when you propose to take some formal action on behalf of the WG, >and you happen to be on vacation, could you please postpone it until you >are able to consult or at least inform the WG. > >There is no need to take such actions while on vacation just as there is >no need to reply to this email while you are on vacation. > >________________________________ > >At 07:47 AM 2/18/2001 +1100, Albert Langer wrote: > >[John and Chris] > >Silence means consent. > > > >Read, enjoy, and send your comments in! > > > >regards, > >John Strassner and Chris Apple > > > >[Albert] > >Could you please explain why a revised WG charter dated 10 February 2001 >was > >posted to: > > > >http://www.ietf.org/html.charters/ldup-charter.html > > > >with revised dates some of which expired the previous month, and with a > >schedule to > >adopt URP as a "proposed standard" 3 months prior to finalizing the > >architecture > >and information model? > > > >I objected formally to both those aspects: > > > >http://www.imc.org/ietf-ldup/mail-archive/msg00784.html > > > >I have checked the archives and am not aware of any response to those > >objections from the WG co-chairs or any attempt to seek a consensus from >the > >WG about them nor even any announcement to the WG that a consensus has in > >fact been reached. > > > >There were also some other comments and questions from Timothy Hahn: > > > >http://www.imc.org/ietf-ldup/mail-archive/msg00791.html > > > >These included at least one minor editorial correction (typo) which I >cannot > >imagine anybody would have taken exception to. Therefore I am inclined to > >assume the document was simply posted "as is" without bothering to consider > >any comments made on it, despite having asked for comments. > > > >Was that the case? > > > >Who took the decision, and why were we not informed? ------=_NextPart_000_000C_01C0A91F.880CE280 Content-Type: message/rfc822 Content-Disposition: attachment From: "Chris Apple" To: Cc: "'Chris Apple'" , , , References: <000601bff171$77456be0$17448490@vic.bigpond.net.au> Subject: Re: LDUP Requirements etc Date: Thu, 20 Jul 2000 04:30:04 +1100 Organization: AT&T Labs Message-ID: <3975E59C.AA9D359D@control.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit OK. Here's the deal. There will be an agenda item for the Pittsburgh WG meeting to discuss the issues you have raised on the mailing. We'll publish a summary of that discussion in the meeting minutes. I'll craft and coordinate with my co-chair a reply to the official meeting minutes posting with a request for objections to a particular course of action relative to the issues you have raised on the mailing list. In this case, silence from a majority WG participants that John and I know to be actively participating in LDUP work will be interpretted as having achieved rough concensus on that course of action. I believe that's all any WG co-chair could reasonably be expected to do in a situation like this. I've been too swamped with day-to-day job responsibilities to pay much attention to this particular WG issue until the past week or so. Which is one reason for a change in who I am employed by effective 7/24. After that date, since my new employer is much more supportive of IETF work than my present employer, the situation that the WG is in now, will receive much more of my day-to-day attention. And, one way or the other, the issues you have raised will get resolved. John, Patrik, or Ned: do you have other opinions about how to proceed? Chris. Albert Langer wrote: > > Chris, > > Thanks for your prompt and detailed response. > > In view of your suggestion below, I am CCing this to the ADs so that they > will have full background and in case they wish to offer any comments. At > this stage I am not formally requesting any action from them. However I do > request that they, as well as you, carefully read or re-read as essential > background, your request for status reports and my response to it: > > http://www.imc.org/ietf-ldup/mail-archive/msg00561.html > > and the other links included in this message below. > > Further comments are interspersed with the whole of your message below. > > -----Original Message----- > From: Chris Apple [mailto:capple@att.com] > Sent: Tuesday, July 18, 2000 6:16 AM > To: Albert.Langer@Directory-Designs.org > Cc: capple@control.att.com; johns@cisco.com > Subject: Re: Reply address from Chris bounced > > Albert Langer wrote: > > > > [Chris] > > > > Must be something wrong with the $%#!ing mail gateways again! > > > > Oh well. > > > > [Albert] > > Poorly designed replication protocols ;-) > > HA! Sloppy administration is more like it. I know the folks who > run the machines. :) > > [Albert] > Just as an aside, a background to my general concerns is a strongly held > view I have come to, that many of the problems such as email unreliability, > widely perceived as being due to sloppy administration, are in fact due to > the difficulty of administering without a directory service far more deeply > embedded in the general infrastructure than is actually feasible at the > moment. > > I believe that LDUP standards are of strategic importance for internet > development and are needed urgently. > > I also believe that unless LDUP gets it right, and does so soon, Microsoft > will end up dominating this strategic area, with consequences that could > include its domination of many other aspects of the internet. > > > > > [Chris] > > Too bad you can't make it. We were hoping you could be there > > to give an overview of your draft. I disagree with your > > assertion that these particular issues are more well suited to written > > discussions. Its clear to me that they are not based on the response > > they have received on the list. There has been insufficient traffic to > > judge concensus around the need or lack thereof to change any LDUP > > document. > > > > [Albert] > > I agree that there has been insufficient traffic to judge consensus, but I > > disagree that this is due to the topics being more suited to meetings. > > > > Meetings are good for quickly clarifying points of misunderstanding and > for > > resolving points of detail, but not for thinking through major technical > > issues. > > My experience says that you MUST have face-to-face meetings to > resolve major technical disputes. You may disagree with that. That's > fine. But I am in charge. :) > > [Albert] > No problem. Despite disagreeing, I have already said I would be delighted to > attend and do a presentation if I possibly could, but unfortunately I > cannot. Even if I had been unwilling I would certainly defer to your > preference on that, if I could. I will be repeating my invitation to the > authors of the URP draft to get togther for discussions as we all happen to > be in Melbourne. Perhaps you could join in encouraging them to do so? > > > > > My impression is that the lack of traffic is due to lack of interest, > rather > > than the difficulties of written discussions. The list seems to have > > recently been basically moribund between announcements of IETF meetings. > > Anyway, I'd love to be there, but unfortunately I cannot. > > > > On requirements, it is clear to me that the WG has not taken the need to > > analyse requirements before deciding architecture seriously at all. > Frankly > > I find it difficult to believe that people who have actually READ the > > current requirements draft would consider it ready for final call. I can > > only assume that those who have read it simply did not read it carefully > as > > a serious document that actually matters. > > [Chris] > I'll try to keep my emotions out of this and say the following: > > 1) I've read it CAREFULLY and believe that its ready. > 2) My co-chair has read it CAREFULLY and believes that its ready. > 3) Active members of the Working Group who represent a majority of > the most prevalent players in the LDAP industry have read it CAREFULLY, > many, many times and believe that its ready. > > [Albert] > I wasn't intending to stir up any emotions above. Since you say so, I can > only accept that you have indeed read it CAREFULLY and that we do have > fundamental differences as to what constitutes a "ready" document. > > There was no way I could have known that until now, as you have NOT > expressed that view in the mailing list in response to John's formal request > for discussion from the minutes of the Adelaide IETF LDUP meeting. > > Neither has John, and neither has any other member of the WG except Harald, > who initially expressed an opposite view but has indeed now stated that he > does believe it is ready now and given a reason for his conclusion. > > I have expressed arguments as to why I believe the reason he stated is > fallacious and additional reasons why he should change that view: > > http://www.imc.org/ietf-ldup/mail-archive/msg00569.html > > Harald has apparantly chosen not to respond, which he is perfectly entitled > to do. > > Now that I know you also hold that view, perhaps with different reasons, I > am asking you to respond to the above message, with your reasons for > disagreeing with my objections and arguments. Again you are of course > perfectly entitled not to do so, but it would certainly help kick off > substantive discussion, which you indicated below is something you would > like to see. > > I do not think it is surprising that most members of the WG have not > expressed a view in the list, as the "first order of business" was clearly > and formally stated by a WG co-chair in opening the discussion, to be a > response from the authors of the requirements draft. > > You have yourself stated (above) that "There has been insufficient traffic > to judge concensus around the need or lack thereof to change any LDUP > document." > > A "rough consensus" does not require MY agreement. If you are correct about > all of 1), 2) and 3), as you must be concerning 1), then there is a "rough > consensus", given that nobody else has expressed strong active opposition. > > But as you must know, since you have said it explicitly, silence in the > absence of a formal last call, is NOT the same as saying it is ready. You > simply don't KNOW whether there is now consensus or not because of the lack > of traffic, and therefore have quite rightly refrained from claiming that > there is, despite your own strong view that it is "ready". > > [Chris] > 4) Adding clarifications to the document such as adding an explicit > statement indicating that atomicity of operations will not be addressed > by LDUP can and should be handled DURING IETF Last Call. That's my > interpretation and position on how to handle comments like > this that are introduced after the WG last call window has elapsed. > > [Albert] > You issued a WG last call on 16 September 1999 with a very clear explanation > of what a WG last call is: > > http://www.imc.org/ietf-ldup/mail-archive/msg00418.html > > The draft was not ready then and was later replaced with 02, which expired > on 21 April. > > You were not present at the Melbourne IETF meeting and there may be some > misunderstanding about what has happened since. > > My understanding is that whether you like it or not, the issue was formally > reopened by your WG co-chair following discussion with an AD and the people > at the meeting, after my formal objection at the meeting. It is currently > before the WG and will remain so until such time as the WG co-chairs > announce in the mailing list that the discussion has concluded and a "rough > consensus" has been reached. You have not done so, and cannot do so at > present, based on your own statement quoted above. > > If I have misunderstood the current situation, please let me know. > > [Chris] > 5) If you believe that there are serious breeches in the requirements > having had adequate review and believe that it is directly related to > the way the WG processes are being managed by John and myself, you > should feel free to take that up directly with Patrik Faltstrom and Ned > Freed. > > I can assure you that there is absolutely no chance I will ever agree > with you about whether or not the document is ready for IETF Last Call. > And since I'm co-chair and John agrees with me, the request we have > made of the Applications ADs for IESG Review prior to IETF Last Call > WILL proceed. > > [Albert] > Sorry, I simply do not understand what you are referring to here. > > I have not seen any message in the mailing list about any request to the ADs > for "IESG Review prior to IETF Last Call" and I do not understand what that > implies as to where, when, to whom and how I should now state my objections. > Please explain. > > My current impression is that there is probably some simple > misunderstanding, either on your part or mine, which should be easily > resolved. This seems likely as you were not at the Melbourne IETF meeting > and I am a new participant since then. It is clear from the message by one > of the authors of the requirements draft, cited below, that at least > *somebody* is under a misconception as to what the current status is, and > the explanation given by that author concerning a communications breakdown > seems plausible and could also cause other difficulties. These things > happen. > > If however it turns out that the document has somehow changed status while > expired and without any announcement of the conclusion of the discussion > that was formally opened, then yes, I would conclude that there has been > some serious breech in IETF procedures and formally request that the ADs > intervene. > > Here's the "official" status: > > This Internet-Draft has expired and is no longer available. > > Unrevised documents placed in the Internet-Drafts directories have a > maximum life of six months. After that time, they must be updated, or > they will be deleted. This document was deleted on July 17, 2000. > > http://search.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-03.txt > > Note that I drew attention to the expiry in my response to your request for > status reports and that it was deleted nearly a month after the author > indicated he would "refresh" it, after reading and replying to that reminder > (see below). > > The original discussion was supposed to have concluded by Easter (only on > whether requirements should proceed to final call, not on MDCR/URP), ie > before expiry. But the "first order of business" has still not happened. > > [Chris] > You are welcome to raise the issue of putting in language which > clarifies that the requirements document doesn't intend to address > atomicity at that time. > > [Albert] > At present I believe that I have raised that issue, and the related issue of > putting in quite opposite language, and that both those issues are currently > before the WG. > > I also believe the WG is currently waiting for a response from the authors > of the requirements draft as clearly stated by one of the authors a month > ago: > > http://www.imc.org/ietf-ldup/mail-archive/msg00572.html > > See also my response: > > http://www.imc.org/ietf-ldup/mail-archive/msg00574.html > > When you explain otherwise I may have to revise my current belief, since you > are "in charge". But I cannot do so until you do explain. > > I certainly believe that language about what requirements LDUP standards are > and are not expected to meet is not a minor editorial clarification but an > essential feature of a requirements document that should be included PRIOR > to a formal "Last" call. > > > > > On URP and MDCR, it is not surprising or unreasonable that WG members > would > > not be interested in studying MDCR very carefully at this late stage. > > However I recommend that you go through the archives to review the earlier > > exhaustive and exhausting discussion of URP. It is quite clear from the > > archives that there was a great deal of doubts about it, but no positive > > alternatives. The discussions were bogged down in "preposterously complex" > > detail and would certainly have not been followed carefully by most > > participants in the WG. There was no consensus, rough or otherwise - just > > exhaustion. > > [Chris] > That is your opinion. It is quite obvious that John and I had other > opinions and decide to move forward. > > [Albert] > Fair enough. Obviously I believe that was a mistake and you and presumably > most if not all other participants do not, since I am currently the only > person with a formal objection. > > Actually I think it is *always* a mistake to proceed with architecture > decisions, let alone design decisions, before formally signing off on > "requirements". The WG charter clearly set out a timetable for requirements > to be the RFC published first, thus making input from others more likely > before proceeding with RFCs on actual standards. > > That was not done, and in my opinion, which you obviously do not share, is > an important reason for what I believe to be fundamental technical problems > in the actual standards, that WILL hold up actual deployment of viable > multi-master replication, whether the current drafts are approved as > proposed standards or not. > > For what its worth, I did see the requirements draft some time ago and > simply assumed it was a very early draft that would be fixed up. I only > concluded that some intervention was appropriate on reviewing the documents > for the Melbourne IETF and seeing that they were in essentially the same > state. It may be that others likewise assumed that there wouldn't be much > happening until a requirements draft that made sense was available for > comment. > > There is simply nothing in it to suggest that the WG had even started to > think about the issues for multi-master replication. (Reviewing the archives > since, shows the WG certainly had proceeded with details concerning > multi-master replication, but that was never the result of any requirements > analysis reflected in a requirements document). > > > > > BTW, could you please respond to my earlier question about whether there > is > > or was another "engineering" list and whether archives can be made > > available? > > There was an engineering team list, but there has been almost no traffic > on it since the beginning of the WG charter (when we were in a multiple > proposal "bake-off"). All discussion relevant to the specific issues you > have raised took place on the official WG Mailing list. > > I do not administer the old engineering team list, so I cannot > comment on the existance of archives for it. I'd be surprised if > there was one. It was mostly intended to get things going and > was never intended to be used after the WG was officially chartered. > > [Albert] > Thanks. That completely answers my question. > > Whatever misconceptions I may have as to what has happened in the LDUP WG I > am now confident it is not the result of having failed to study all the > relevant material. > > > > > [Chris] > > As a result, John and I are trying to get something going at > > the Pittsburgh LDUP WG Session to spark an adequate amount of > > discussion on the list: > > > > What we are trying to do is to get a third party to put together > > a slide presentation comparing your proposal's concepts with > > similar concepts already in the LDUP documents. Third party in > > this case would be one or more people who did not write either > > your document or any of the LDUP documents potentially affected > > by it - and someone who knows a thing or two about deploying > > LDAP-based services. The guilty party will be identified in the > > WG agenda to be posted on the IETF web site by 7/24. I'll post > > the proposed WG agenda to the WG mailing list within the next day > > or so just to make sure we didn't miss anything. > > > > This presentation will hopefully be enough food for thought in the WG > > session. We also plan to post these slides to the list with a text > > description of the slides. > > > > [Albert] > > Sounds like a great idea to spark an adequate amount of discussion re MDCR > > and URP. > > > > It would be useful if these could be posted to the list as early as > possible > > to clarify any issues before the meeting. Also it would be good to post > > drafts to Alison, Steve and myself a couple of days earlier for last > minute > > corrections/clarifications rather than doing that through the list. > > > > However, I should emphasize that there are 2 separate issues - my > objections > > to the requirements draft and my proposal for MDCR to be considered as an > > alternative to URP. > > > > The requirements issues do not need a third party presentation or slides. > > They need an answer from the authors of the requirements document. If the > WG > > reaches a consensus not to require atomicity then it should say so clearly > > and explain why in the requirements document. The discussion could result > in > > a consensus either way, but either way, some change is needed in the > > requirements document since it neither explains, nor even states any > > requirements whatever for multi-master replication. > > > > I request that you insist on the authors of the requirements draft > > responding to my formal objection to it on the mailing list before the > IETF > > meeting. Others are perfectly entitled to be simply disinterested in the > > objection. The authors do have an obligation to respond. That may well > > result in substantive discussion of requirements issues. > > [Chris] > I'll address this directly with the authors to see if they 1) believe > that they did respond or 2) if they admit to not responding, when they > will. > > [Albert] > Thanks again. That is exactly what I requested, although I do not understand > your 1) or the use of the word "admit" in 2). > > The wording confirms my concern that there is some misunderstanding since > one of the authors has quite clearly explained that he did not respond > earlier due to a communications breakdown and has now promised to do so (a > month ago), so there cannot be any possibility that he does "believe that > they did respond" (unless another communications breakdown has resulted in > me not seeing it - and also in the archives not recording it). Nothing has > appeared from either author since. > > Anyway, whatever misunderstanding there may be, can be easily cleared up, > since you are in fact contacting them as requested. > > [Chris] > My own opinion is that the requirements document itself was never > supposed to address detailed technical requirements for Multi-master > replication, but that this topic would be addressed in the LDAPv3 > Multi-Master Replication Profile document - which is currently missing > in action. I'll cover the issue directly with them and we'll see what > they have to say. > > You may disagree with even that sentiment, however, this the way the WG > is chartered. The appropriate time to have raised an issue like that, > would have been prior to the last time we revised the charter. With > that said, let me express my own frustration with being behind schedule > in producing the main deliverables: ARGH! > > [Albert] > I certainly wish I had been participating earlier and have already > apologized for the inconvenience of bringing up major issues at this late > stage. It would however be even more inconvenient if the results produced by > an IETF WG able to move directly to "proposed standard" instead of via > "experimental" in fact turned out to be unworkable and to have a major > negative impact on existing LDAP standards. > > As there was negligible response for over a week to your request for status > reports, in which you pointed out there had been no traffic on the list > apart from spam for a considerable time, I did propose then that the WG > should be re-chartered. Things HAVE improved more recently so I am not > currently pursuing that. But here's a reminder of YOUR views on the > situation in your draft agenda PRIOR to the Adelaide meeting: > > 2) Why are we so far behind? > > We're showing the signs of starting to die a flailing death. > Don't let it happen if this work is important for your > LDAP implementations. Working groups have, can, and will > be killed for lack of activity similar to what I've seen > since the last IETF meeting. > > http://www.imc.org/ietf-ldup/mail-archive/msg00488.html > > I do disagree with your view on what should be in a requirements document > and a profile and also disagree that this is currently the way the WG is > chartered. My view is that profiles are dependent on standards and standards > are dependent on requirements. The WG charter appears to be sequenced on > that view also. > > Alison has submitted a valuable "Contribution to Profiles Document > (Consistency Discussion)" > > http://www.imc.org/ietf-ldup/mail-archive/msg00548.html > > The Word version with properly formatted tables is at: > > http://www.imc.org/ietf-ldup/mail-archive/doc00000.doc > > It does include a frank and technically detailed exposition of (some of) the > consequences of the design choices that have been made, that I am concerned > about. > > In my view that document should be distributed as an I-D to solicit > discussion. > > So far there has been no discussion of it and its implications in the WG. > > It will not be enormously difficult to complete the missing "Multi-Master > Replication Profile" based on that contribution. > > What WILL be very difficult is persuading anybody to deploy in Multi-Master > mode given the problems doing so that are highlighted there, let alone other > problems that I have mentioned. > > This is what raises a fundamental requirements issue. Do user needs for > multi-master replication require different consistency guarantees from those > offered by the currently proposed solution to those needs? > > That, and not the technical details, is what needs to be in a requirements > document, but is clearly absent. > > BTW, during the Adelaide IETF meeting I had some discussions with someone > responsible for a large scale deployment of the pre-release of Active > Directory, who explained that they decided, based on actual deployment > experience, that they could not rely on multi-master precisely because of > the proliferation of "Transient Extraordinary States". > > > > > [Chris] > > And yes, concensus will be judged from the list as it always is, has > > been, and will be in the LDUP WG. If this attempt fails to produce > > significant and substantive traffic on the list in favor changing > > the documents based on your proposal, my own opinion is that this > > means that the WG doesn't feel strongly about doing so. > > > > Chris. > > > > [Albert] > > Understood. If there is no interest in MDCR there is no point in my > pushing > > it. > > > > However if the requirements draft stands I will object to the IETF final > > call as the document is simply absurd. Even an informational RFC should > > convey *some* useful information. > > [Chris] > There are quite a few people who believe that such an objection > is "simply absurd." I personally believe that it is quite a useful > document. You can keep your opinions about my own technical > abilities/strengths/lack-thereof to yourself! :) > > [Albert] > As this is our first substantive exchange of views by email and is primarily > about administrative rather than technical matters, and you have not made > any substantive technical contributions in the mailing list since I joined, > I have not yet formed any such opinions. > > When and if I do, I will duly refrain from letting you know ;-) > > For what its worth, in commenting on administrative matters, I am not > expressing, and in fact do not yet have, any particular view on your > administrative abilitites/strengths/lack-thereof either. You are responding, > so any misunderstandings or other problems can easily be resolved. That's > all I have a reasonable expectation of, and you are meeting that expectation > courteously and in detail. > > I was explicitly invited NOT to write an alternative draft for the > requirements document and have gladly complied with that request. > > If it proceeds to IETF final call, I will of course submit a detailed > demonstration of my claim that it is "simply absurd", from which others may > form their own opinions as to both my technical > abilitities/strengths/lack-thereof and those of the authors and any others > who claim to have read it carefully and concluded that it was ready. > > Meanwhile, I have done my best to encourage you to take another look. > > I will try to complete my promised reply to Steve in time for the IETF > meeting, but will unfortunately have to delay other correspondence for the > next week or so. > > So I look forward to any response in whatever detail you wish and whenever > is convenient for you to do so, and will respond accordingly, but I cannot > promise to respond immediately. > > Seeya, Albert > > > > > I believe it is a serious technical mistake to proceed with URP, whether > or > > not MDCR has any merit at all, which I am not in a position to judge > > independently. The third party presentation could hopefully result in > > substantive discussion of the issues within the WG and thus correct the > > mistake. But if it does not, it would remain a serious technical mistake. > > > > I will spell out some of the reasons in responding to Steve. > > > > Seeya, Albert > > Chris. > > -- > ------------------------------------------------------------------------ > Chris Apple Business Site: AnyWho Directory Service > Internet Directory Group http://www.anywho.com > AT&T Labs > capple@control.att.com > +1 973 236 6470 Tired of slow directories? Try AnyWho. > ------------------------------------------------------------------------ -- ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Labs capple@control.att.com +1 973 236 6470 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ ------=_NextPart_000_000C_01C0A91F.880CE280 Content-Type: message/rfc822 Content-Disposition: attachment From: "Chris Apple" To: Cc: , References: <001501bff01f$9f0c5060$17448490@vic.bigpond.net.au> Subject: Re: Reply address from Chris bounced Date: Tue, 18 Jul 2000 07:16:00 +1100 Organization: AT&T Labs Message-ID: <39736980.9C8988AE@att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Albert Langer wrote: > > [Chris] > > Must be something wrong with the $%#!ing mail gateways again! > > Oh well. > > [Albert] > Poorly designed replication protocols ;-) HA! Sloppy administration is more like it. I know the folks who run the machines. :) > > [Chris] > Too bad you can't make it. We were hoping you could be there > to give an overview of your draft. I disagree with your > assertion that these particular issues are more well suited to written > discussions. Its clear to me that they are not based on the response > they have received on the list. There has been insufficient traffic to > judge concensus around the need or lack thereof to change any LDUP > document. > > [Albert] > I agree that there has been insufficient traffic to judge consensus, but I > disagree that this is due to the topics being more suited to meetings. > > Meetings are good for quickly clarifying points of misunderstanding and for > resolving points of detail, but not for thinking through major technical > issues. My experience says that you MUST have face-to-face meetings to resolve major technical disputes. You may disagree with that. That's fine. But I am in charge. :) > > My impression is that the lack of traffic is due to lack of interest, rather > than the difficulties of written discussions. The list seems to have > recently been basically moribund between announcements of IETF meetings. > Anyway, I'd love to be there, but unfortunately I cannot. > > On requirements, it is clear to me that the WG has not taken the need to > analyse requirements before deciding architecture seriously at all. Frankly > I find it difficult to believe that people who have actually READ the > current requirements draft would consider it ready for final call. I can > only assume that those who have read it simply did not read it carefully as > a serious document that actually matters. I'll try to keep my emotions out of this and say the following: 1) I've read it CAREFULLY and believe that its ready. 2) My co-chair has read it CAREFULLY and believes that its ready. 3) Active members of the Working Group who represent a majority of the most prevalent players in the LDAP industry have read it CAREFULLY, many, many times and believe that its ready. 4) Adding clarifications to the document such as adding an explicit statement indicating that atomicity of operations will not be addressed by LDUP can and should be handled DURING IETF Last Call. That's my interpretation and position on how to handle comments like this that are introduced after the WG last call window has elapsed. 5) If you believe that there are serious breeches in the requirements having had adequate review and believe that it is directly related to the way the WG processes are being managed by John and myself, you should feel free to take that up directly with Patrik Faltstrom and Ned Freed. I can assure you that there is absolutely no chance I will ever agree with you about whether or not the document is ready for IETF Last Call. And since I'm co-chair and John agrees with me, the request we have made of the Applications ADs for IESG Review prior to IETF Last Call WILL proceed. You are welcome to raise the issue of putting in language which clarifies that the requirements document doesn't intend to address atomicity at that time. > > On URP and MDCR, it is not surprising or unreasonable that WG members would > not be interested in studying MDCR very carefully at this late stage. > However I recommend that you go through the archives to review the earlier > exhaustive and exhausting discussion of URP. It is quite clear from the > archives that there was a great deal of doubts about it, but no positive > alternatives. The discussions were bogged down in "preposterously complex" > detail and would certainly have not been followed carefully by most > participants in the WG. There was no consensus, rough or otherwise - just > exhaustion. That is your opinion. It is quite obvious that John and I had other opinions and decide to move forward. > > BTW, could you please respond to my earlier question about whether there is > or was another "engineering" list and whether archives can be made > available? There was an engineering team list, but there has been almost no traffic on it since the beginning of the WG charter (when we were in a multiple proposal "bake-off"). All discussion relevant to the specific issues you have raised took place on the official WG Mailing list. I do not administer the old engineering team list, so I cannot comment on the existance of archives for it. I'd be surprised if there was one. It was mostly intended to get things going and was never intended to be used after the WG was officially chartered. > > [Chris] > As a result, John and I are trying to get something going at > the Pittsburgh LDUP WG Session to spark an adequate amount of > discussion on the list: > > What we are trying to do is to get a third party to put together > a slide presentation comparing your proposal's concepts with > similar concepts already in the LDUP documents. Third party in > this case would be one or more people who did not write either > your document or any of the LDUP documents potentially affected > by it - and someone who knows a thing or two about deploying > LDAP-based services. The guilty party will be identified in the > WG agenda to be posted on the IETF web site by 7/24. I'll post > the proposed WG agenda to the WG mailing list within the next day > or so just to make sure we didn't miss anything. > > This presentation will hopefully be enough food for thought in the WG > session. We also plan to post these slides to the list with a text > description of the slides. > > [Albert] > Sounds like a great idea to spark an adequate amount of discussion re MDCR > and URP. > > It would be useful if these could be posted to the list as early as possible > to clarify any issues before the meeting. Also it would be good to post > drafts to Alison, Steve and myself a couple of days earlier for last minute > corrections/clarifications rather than doing that through the list. > > However, I should emphasize that there are 2 separate issues - my objections > to the requirements draft and my proposal for MDCR to be considered as an > alternative to URP. > > The requirements issues do not need a third party presentation or slides. > They need an answer from the authors of the requirements document. If the WG > reaches a consensus not to require atomicity then it should say so clearly > and explain why in the requirements document. The discussion could result in > a consensus either way, but either way, some change is needed in the > requirements document since it neither explains, nor even states any > requirements whatever for multi-master replication. > > I request that you insist on the authors of the requirements draft > responding to my formal objection to it on the mailing list before the IETF > meeting. Others are perfectly entitled to be simply disinterested in the > objection. The authors do have an obligation to respond. That may well > result in substantive discussion of requirements issues. I'll address this directly with the authors to see if they 1) believe that they did respond or 2) if they admit to not responding, when they will. My own opinion is that the requirements document itself was never supposed to address detailed technical requirements for Multi-master replication, but that this topic would be addressed in the LDAPv3 Multi-Master Replication Profile document - which is currently missing in action. I'll cover the issue directly with them and we'll see what they have to say. You may disagree with even that sentiment, however, this the way the WG is chartered. The appropriate time to have raised an issue like that, would have been prior to the last time we revised the charter. With that said, let me express my own frustration with being behind schedule in producing the main deliverables: ARGH! > > [Chris] > And yes, concensus will be judged from the list as it always is, has > been, and will be in the LDUP WG. If this attempt fails to produce > significant and substantive traffic on the list in favor changing > the documents based on your proposal, my own opinion is that this > means that the WG doesn't feel strongly about doing so. > > Chris. > > [Albert] > Understood. If there is no interest in MDCR there is no point in my pushing > it. > > However if the requirements draft stands I will object to the IETF final > call as the document is simply absurd. Even an informational RFC should > convey *some* useful information. There are quite a few people who believe that such an objection is "simply absurd." I personally believe that it is quite a useful document. You can keep your opinions about my own technical abilities/strengths/lack-thereof to yourself! :) > > I believe it is a serious technical mistake to proceed with URP, whether or > not MDCR has any merit at all, which I am not in a position to judge > independently. The third party presentation could hopefully result in > substantive discussion of the issues within the WG and thus correct the > mistake. But if it does not, it would remain a serious technical mistake. > > I will spell out some of the reasons in responding to Steve. > > Seeya, Albert Chris. -- ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Labs capple@control.att.com +1 973 236 6470 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ ------=_NextPart_000_000C_01C0A91F.880CE280 Content-Type: message/rfc822 Content-Disposition: attachment From: =?Windows-1252?Q?Patrik_F=E4ltstr=F6m?= To: "Chris Apple" , Cc: "'Chris Apple'" , , References: <000601bff171$77456be0$17448490@vic.bigpond.net.au><3975E59C.AA9D359D@control.att.com> Subject: Re: LDUP Requirements etc Date: Thu, 20 Jul 2000 11:25:14 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <3975E59C.AA9D359D@control.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Sender: pfaltstr@127.0.0.1 (Unverified) Content-Transfer-Encoding: 7bit At 13.30 -0400 00-07-19, Chris Apple wrote: >John, Patrik, or Ned: do you have other opinions about how to proceed? I think you have a plan, which for me looks like "discussions at the next IETF" and "then close the box by approving the minutes". I will see, as AD, that the box will close, and stay closed. Patrik ------=_NextPart_000_000C_01C0A91F.880CE280-- From owner-ietf-ldup@mail.imc.org Fri Mar 16 20:12:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16857 for ; Fri, 16 Mar 2001 20:12:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA27091 for ietf-ldup-bks; Fri, 16 Mar 2001 16:30:42 -0800 (PST) Received: from corpdns.drgama.com (nszx104.137.szptt.net.cn [202.104.139.201] (may be forged)) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA27087 for ; Fri, 16 Mar 2001 16:30:38 -0800 (PST) From: b4h443@arabia.com Received: from ns1.filetron.com ([63.62.253.24]) by corpdns.drgama.com with Microsoft SMTPSVC(5.0.2195.1600); Sat, 17 Mar 2001 08:26:21 +0800 Message-ID: <00001870381d$00004f86$000020a8@ns1.filetron.com> To: <8orqv6wms80zqjtolk5lq@mail.mecogroep.nl> Subject: I CAN HELP !!! Date: Fri, 16 Mar 2001 17:19:07 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: b4h443@arabia.com X-OriginalArrivalTime: 17 Mar 2001 00:26:22.0187 (UTC) FILETIME=[E4A793B0:01C0AE78] Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable





















Can't get email out to the masses without losing your ISP???


Don't know how
to get sales for your product???

Can't get traffic to your
site???


COLOR=3D"#ffffff">Call
1-888-242-5082





















Can't get email out to the masses without losing your ISP???


Don't know how
to get sales for your product???

Can't get traffic to your
site???


COLOR=3D"#ffffff">Call
1-888-242-5082

I have plenty of fresh verified
email names and can get you results.



BORDER=3D"0">




CELLSPACING=3D"0" >




SIZE=3D"+2">Price List
COLOR=3D"#008040">Discounts for larger
orders

FACE=3D"Times New Roman">100
Thousand - $200
500 Thousand -
$875
1 Million -
$1500
















It
is this easy!
COLOR=3D"#004080" SIZE=3D"+1">You simply furnish your message and I
do the rest. I guarantee you
100% delivery. It can even be done in full color at no
extra cost







COLOR=3D"#ffffff">NOTICE

Roman">Under
Bill s.1618 TITLE III passed by the 105th US Congress this letter
cannot be
considered spam as long as the sender includes contact information
and a method
of removal. To be removed, hit reply and type remove in the
subject
line.

/FONT>

I have plenty of fresh verified
email names and can get you results.



BORDER=3D"0">




CELLSPACING=3D"0" >




SIZE=3D"+2">Price List
COLOR=3D"#008040">Discounts for larger
orders

FACE=3D"Times New Roman">100
Thousand - $200
500 Thousand -
$875
1 Million -
$1500
















It
is this easy!
COLOR=3D"#004080" SIZE=3D"+1">You simply furnish your message and I
do the rest. I guarantee you
100% delivery. It can even be done in full color at no
extra cost







COLOR=3D"#ffffff">NOTICE

Roman">Under
Bill s.1618 TITLE III passed by the 105th US Congress this letter
cannot be
considered spam as long as the sender includes contact information
and a method
of removal. To be removed, hit reply and type remove in the
subject
line.





From owner-ietf-ldup@mail.imc.org Thu Mar 22 12:53:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16079 for ; Thu, 22 Mar 2001 12:53:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id JAA09598 for ietf-ldup-bks; Thu, 22 Mar 2001 09:21:28 -0800 (PST) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA09588 for ; Thu, 22 Mar 2001 09:21:25 -0800 (PST) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f2MHKlw32337 for ; Thu, 22 Mar 2001 10:20:47 -0700 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Thu, 22 Mar 2001 07:49:15 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Thu, 22 Mar 2001 07:49:05 -0700 From: "Ed Reed" To: , Subject: Candidate LDAP Administration Model Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id JAA09594 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Well - I tried to just add a sentence to the LDAP Subentries text describing an administrative area, and couldn't convince myself that it was sufficient. Instead, I studied the X.501 (2001) draft and came up with the following description of what is, I think, a compatible, simpler subset of the X.500 model. I present it here for your comment and feedback to see (1) if it is indeed simpler (2) if it is indeed compatible (3) if it is indeed a subset. Thanks. Your comments are requested. I suggest this be part of the LDAP Subentry draft, that should go onto the proposed standard track. Ed ============================================= 4 Administrative Areas in the Directory 4.1 X.501 Administrative Model Overview [X501] contains an extensive description of Administrative Areas and their role in the management and administration of directories. The LDAP administrative model defined here is intended to be a compatible, proper subset of the [X501] model. The description here draws heavily on the descriptions and concepts laid out in [X501]. An administrative area is a sub-tree of the directory information tree, rooted at an administrative point (the root-most entry in the sub-tree), where administrative entries (perhaps including subentries, operational attributes, or both) are located. Autonomous administrative areas are distinct partitions of the directory information tree whose entries are all administered by a single administrative authority. Each entry in the directory information tree is administered by exactly one autonomous administrative authority. There may be many aspects of administration defined by the directory and other applications for specific purposes, such as subschema administration areas, access control administration areas, collective-attribute administration areas, context default administrative areas, and service administrative areas. Within an autonomous administrative area, specific administrative areas for these (and other) different aspects may overlap one another. Specific administrative areas may be sub-partitioned by the applications or services which define them to facilitate delegation of authority or for other purposes. That means that a single entry in the directory may be part of many different specific administrative areas, but only be part of one specific administrative area (or sub-area) of each aspect of administration. The [X501] subentry specification optionally uses a SubtreeSpecification to indicate a subset of entries in a sub-tree with which the subentry is concerned. When the SubtreeSpecification is empty the scope of the [X501] subentry is implicitly defined by the context in which it occurs. 4.2 An LDAP Administrative Model The administrative model for LDAP defined here is a simplified version of the one described in [X501], in that the scope defined for the ldapSubentry object class is limited. The LDAP Subentry definition below specifically does not include a SubtreeSpecification, so its scope is explicitly the complete set of entries in the specific administrative area (or sub-area) in which it occurs. All administrative areas are considered to be specific administrative areas within an autonomous administrative area. If a specific administration area is not partitioned, then its extent (or scope) is said to be that of the autonomous administrative area in which it is defined. Applications and services which define specific administrative areas must specify whether the areas may be partitioned or not. By default, the scope of LDAP Subentries is limited to the sub-area of the partitioned specific administrative area in which they are present. ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Fri Mar 23 08:33:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10965 for ; Fri, 23 Mar 2001 08:33:11 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id FAA07148 for ietf-ldup-bks; Fri, 23 Mar 2001 05:03:10 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA07144 for ; Fri, 23 Mar 2001 05:03:08 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09019; Fri, 23 Mar 2001 08:03:07 -0500 (EST) Message-Id: <200103231303.IAA09019@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rharrison-ldap-framing-profile-00.txt Date: Fri, 23 Mar 2001 08:03:07 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Profile for Framing LDAPv3 Operations Author(s) : R. Harrison Filename : draft-rharrison-ldap-framing-profile-00.txt Pages : 5 Date : 22-Mar-01 The document 'LDAPv3: Grouping of Related Operations' [GROUPING] specifies a set of LDAPv3 operations and an LDAPv3 control that can be used to identify and manage sets of LDAP operations that are members of related groups. Collectively, these 'grouping' constructs provide a general framework for defining specific LDAPv3 grouping types with their associated processing semantics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rharrison-ldap-framing-profile-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rharrison-ldap-framing-profile-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rharrison-ldap-framing-profile-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010322122251.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rharrison-ldap-framing-profile-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rharrison-ldap-framing-profile-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010322122251.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Fri Mar 23 18:17:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05739 for ; Fri, 23 Mar 2001 18:17:51 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA10265 for ietf-ldup-bks; Fri, 23 Mar 2001 13:08:19 -0800 (PST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA10259 for ; Fri, 23 Mar 2001 13:08:16 -0800 (PST) Received: from qsun.mt.att.com ([135.16.157.16]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f2NL6c124610; Fri, 23 Mar 2001 16:06:38 -0500 (EST) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id QAA01671; Fri, 23 Mar 2001 16:06:36 -0500 Date: Fri, 23 Mar 2001 16:06:36 -0500 Message-Id: <200103232106.QAA01671@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: ietf-ldup@imc.org, internet-drafts@ietf.org Subject: New version of LDUP Requirements draft Cc: capple@ecal.com, estokes@tivoli.com, johns@cisco.com, rmoats@coreon.com, rweiser@digsigtrust.com Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Internet Drafts Editor - Please publish the attached draft as draft-ietf-ldup-replica-req-08.txt. LDUP mailing list - This draft includes all changes to draft -07 from the mailing list and the IETF meeting Monday evening. It also includes some fixed typos, etc. The changes include - - An explicit note that our definition of "Area of Replication" is a subset of the X.525 definiton (this was from the meeting on Monday). - Correction of the words that make up the ACID acronym (Atomicity, Consistency, Isolation, Durability rather than Atomicity, Concurrency, Independence, Durability) per an email comment from Albert Langer. - Addition of a new reference for Xerox Clearinghouse. The old reference was used for both Bayou and Clearinghouse but it just discussed Bayou. This was also from Albert. - Removal of requirement G8 which was identical to G2 and related renumbering of other G requirements (from meeting). - Correction of the URL for the NDS reference (after Joyce Reynolds said she trys all URLs as part of publishing RFCs, I found that some garbage had crept into this URL). - Changed a number of bullet lists to dash lists (they look better in ASCII) - Fixed the expiration date on pages 2ff - Changed Ellen's fax number - Fixed a number of minor typos and formatting errors John and Chris - Per the discussion at the IETF meeting last Monday and previous email on the list, we would like to go to last call on this draft as soon as possible. Rick Huber for the authors --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Internet-Draft Ellen J. Stokes LDAP Duplication/Replication/Update Tivoli Systems Protocols WG Russel F. Weiser Intended Category: Informational Digital Signature Trust Expires: September 2001 Ryan D. Moats Coreon, Inc. Richard V. Huber AT&T Laboratories March 2001 LDAPv3 Replication Requirements draft-ietf-ldup-replica-req-08.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt. The list of Internet-Drafts Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. Stokes, et al Expires September 2001 [Page 1] Internet-Draft LDAPv3 Replication Requirements March 2001 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Stokes, et al Expires September 2001 [Page 2] Internet-Draft LDAPv3 Replication Requirements March 2001 Table of Contents 1 Introduction.......................................................4 2 Terminology........................................................4 3 The Models.........................................................6 4 Requirements.......................................................8 4.1 General........................................................8 4.2 Model..........................................................9 4.3 Protocol......................................................10 4.4 Schema........................................................11 4.5 Single Master.................................................11 4.6 Multi-Master..................................................11 4.7 Administration and Management.................................12 4.8 Security......................................................13 5 Security Considerations...........................................13 6 Acknowledgements..................................................13 7 References........................................................13 A. APPENDIX A - Usage Scenarios....................................15 A.1. Extranet Example..............................................15 A.2. Consolidation Example.........................................15 A.3. Replication Heterogeneous Deployment Example..................15 A.4. Shared Name Space Example.....................................16 A.5. Supplier Initiated Replication................................16 A.6. Consumer Initiated Replication................................16 A.7. Prioritized attribute replication.............................17 A.8. Bandwidth issues..............................................17 A.9. Interoperable Administration and Management...................17 A.10. Enterprise Directory Replication Mesh........................18 A.11. Failure of the Master in a Master-Slave Replicated Directory 18 A.12. Failure of a Directory Holding Critical Service Information..18 B. APPENDIX B - Rationale..........................................19 B.1. Meta-Data Implications........................................19 B.2. Order of Transfer for Replicating Data........................19 B.3. Schema Mismatches and Replication.............................20 B.4. Detecting and Repairing Inconsistencies Among Replicas........21 B.5. Some Test Cases for Conflict Resolution in Multi-Master Replication........................................................22 B.6. Data Privacy During Replication...............................25 B.7. Failover in Single-Master Systems.............................26 B.8. Including Operational Attributes in Atomic Operations.........27 Authors' Addresses..................................................27 Full Copyright Statement............................................28 Stokes, et al Expires September 2001 [Page 3] Internet-Draft LDAPv3 Replication Requirements March 2001 1 Introduction Distributing directory information throughout the network provides a two-fold benefit: (1) it increases the reliability of the directory through fault tolerance, and (2) it brings the directory content closer to the clients using the data. LDAP's success as an access protocol for directory information is driving the need to distribute LDAP directory content within the enterprise and Internet. Currently, LDAP does not define a replication mechanism, and mentions LDAP shadow servers (see [RFC2251]) in passing. A standard mechanism for directory replication in a multi-vendor environment is critical to the continued success of LDAP in the market place. This document sets out the requirements for replication between multiple LDAP servers. While RFC 2251 and RFC 2252 [RFC2252] set forth the standards for communication between LDAP clients and servers there are additional requirements for server-to-server communication. Some of these are covered here. This document first introduces the terminology to be used, then presents the different replication models being considered. Requirements follow, along with security considerations. The reasoning that leads to the requirements is presented in the Appendices. This was done to provide a clean separation of the requirements from their justification. 2 Terminology The following terms are used in this document: Area of replication - A whole or portion of a Directory Information Tree (DIT) that makes up a distinct unit of data to be replicated. An area of replication is defined by a replication base entry and includes all or some of the depending entries contained therein on a single server. It divides directory data into partitions whose propagation behavior may be independently configured from other partitions. Areas of replication may overlap or be nested. This is a subset of the definition of a "replicated area" in X.525 [X.525]. Atomic operation - A set of changes to directory data which the LDAP standards guarantee will be treated as a unit; all changes will be made or all the changes will fail. Atomicity Information - Information about atomic operations passed as part of replication. Stokes, et al Expires September 2001 [Page 4] Internet-Draft LDAPv3 Replication Requirements March 2001 Conflict - A situation that arises when changes are made to the same directory data on different directory servers before replication can synchronize the data on the servers. When the servers do synchronize, they have inconsistent data - a conflict. Conflict resolution - Deterministic procedures used to resolve change information conflicts that may arise during replication. Critical OID - Attributes or object classes defined in the replication agreement as being critical to the operation of the system. Changes affecting critical OIDs cause immediate initiation of a replica cycle. An example of a critical OID might be a password or certificate. Fractional replication - The capability to filter a subset of attributes for replication. Incremental Update - An update that contains only those attributes or entries that have changed. Master Replica - A replica that may be directly updated via LDAP operations. In a Master-Slave Replication system, the Master Replica is the only directly updateable replica in the replica-group. Master-Slave, or Single Master Replication - A replication model that assumes only one server, the master, allows LDAP write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. Meta-Data - Data collected by the replication system that describes the status/state of replication. Multi-Master Replication - A replication model where entries can be written and updated on any of several master replica copies without requiring communication with other master replicas before the write or update is performed. One-way Replication - The process of synchronization in a single direction where the authoritative source information is provided to a replica. Partial Replication - Partial Replication is Fractional Replication, Sparse Replication, or both. Propagation Behavior - The behavior of the synchronization process between a consumer and a supplier. Replica - An instance of an area of replication on a server. Stokes, et al Expires September 2001 [Page 5] Internet-Draft LDAPv3 Replication Requirements March 2001 Replica-Group - The servers that hold instances of a particular area of replication. A server may be part of several replica-groups. Replica (or Replication) Cycle - The interval during which update information is exchanged between two or more replicas. It begins during an attempt to push data to, or pull data from, another replica or set of replicas, and ends when the data has successfully been exchanged or an error is encountered. Replication - The process of synchronizing data distributed across directory servers and rectifying update conflicts. Replication Agreement - A collection of information describing the parameters of replication between two or more servers in a replica- group. Replication Base Entry - The distinguished name of the root vertex of a replicated area. Replication Initiation Conflict - A Replication Initiation Conflict is a situation where two sources want to update the same replica at the same time. Replication Session - A session set up between two servers in a replica-group to pass update information as part of a replica cycle. Slave (or Read-Only) Replica - A replica that cannot be directly updated via LDAP requests. Changes may only be made via replication from a master replica. Read-only replicas may occur in both single- and multi-master systems. Sparse Replication - The capability to filter some subset of entries (other than a complete collection) of a replication base entry for replication. Topology - The shape of the directed graph describing the relationships between replicas. Two-way Replication - The process of synchronization where change information flows bi-directionally between two replicas. Update Propagation - Protocol-based process by which directory replicas are reconciled. 3 The Models Stokes, et al Expires September 2001 [Page 6] Internet-Draft LDAPv3 Replication Requirements March 2001 The objective is to provide an interoperable, LDAP v3 directory synchronization protocol that is simple, efficient and flexible; supporting both multi-master and master-slave replication. The protocol must meet the needs of both the Internet and enterprise environments. There are five data consistency models. Model 1: Transactional Consistency -- Environments that exhibit all four of the ACID properties (Atomicity, Consistency, Isolation, Durability) [ACID]. Model 2: Eventual (or Transient) Consistency -- Environments where definite knowledge of the topology is provided through predetermined replication agreements. Examples include X.500 Directories (the X.500 model is single-master only) [X.501, X.525], Bayou [XEROX], and NDS (Novell Directory Services) [NDS]. In this model, every update propagates to every replica that it can reach via a path of stepwise eventual connectivity. Model 3: Limited Effort Eventual (or Probabilistic) Consistency -- Environments that provide a statistical probability of convergence with knowledge of topology. An example is the Xerox Clearinghouse [XEROX2]. This model is similar to "Eventual Consistency", except where replicas may purge updates. Purging drops propagation changes when some replica time boundary is exceeded, thus leaving some changes replicated to only a portion of the topology. Transactional consistency is not preserved, though some weaker constraints on consistency are available. Model 4: Loosest Consistency -- Environments where information is provided from an opportunistic or simple cache until stale. Complete knowledge of topology may not be shared among all replicas. Model 5: Ad hoc -- A copy of a data store where no follow up checks are made for the accuracy/freshness of the data. Consistency models 1, 2 and 3 involve the use of prearranged replication agreements among servers. While model 1 may simplify support for atomicity in multi-master systems, the added complexity of the distributed 2-phase commit required for Model 1 is significant; therefor, model 1 will not be considered at this time. Models 4 and 5 involve unregistered replicas that "pull" updates from another directory server without that server's knowledge. These models violate a directory's security policies. Models 2 and 3 illustrate two replication scenarios that must be handled: policy configuration through security management parameters (model 2), and hosting relatively static data and address information Stokes, et al Expires September 2001 [Page 7] Internet-Draft LDAPv3 Replication Requirements March 2001 as in white-pages applications (model 3). Therefore, replication requirements are presented for models 2 and 3. Interoperability among directories using LDUP replication may be limited for implementations that add semantics beyond those specified by the LDAP core documents (RFC 2251-2256, 2829, 2830). 4 Requirements 4.1 General G1. LDAP Replication MUST support models 2 (Eventual Consistency) and 3 (Limited Effort Eventual Consistency) above. G2. LDAP Replication SHOULD NOT preclude support for model 1 (Transactional Consistency) in the future. G3. LDAP replication SHOULD have minimal impact on both the system and network performance. G4. The LDAP Replication Standard SHOULD NOT limit the replication transaction rate. G5. The LDAP replication standard SHOULD NOT limit the size of an area of replication or a replica. G6. Meta-data collected by the LDAP replication mechanism MUST NOT grow without bound. G7. All policy and state data pertaining to replication MUST be accessible via LDAP. G8. LDAP replication MUST be capable of replicating the following: - all userApplication attribute types - all directoryOperation and distributedOperation attribute types defined in the LDAP "core" specifications (RFC 2251- 2256, 2829-2830) - attribute subtypes - attribute description options (e.g. ";binary" and Language Tags) G9. LDAP replication SHOULD support replication of directoryOperation and distributedOperation attribute types defined in standards track LDAP extensions. Future standards track specifications MUST include a Stokes, et al Expires September 2001 [Page 8] Internet-Draft LDAPv3 Replication Requirements March 2001 "Replication Considerations" section which indicates how and whether the new feature operates in a replicated environment. G10. LDAP replication MUST NOT support replication of dsaOperation attribute types as such attributes are DSA-specific. 4.2 Model M1. The model MUST support the following triggers for initiation of a replica cycle: a) A configurable set of scheduled times b) Periodically, with a configurable period between replica cycles c) A configurable maximum amount of time between replica cycles d) A configurable number of accumulated changes e) Change in the value of a critical OID f) As the result of an automatic rescheduling after a replication initiation conflict g) A manual request for immediate replication With the exception of manual request, the specific trigger(s) and related parameters for a given server MUST be identified in a well- known place defined by the standard, e.g. the Replication Agreement(s). M2. The replication model MUST support both master-slave and multi- master relationships. M3. An attribute in an entry must eventually converge to the same set of values in every replica holding that entry. M4. LDAP replication MUST encompass schema definitions, attribute names and values, access control information, knowledge information, and name space information. M5. LDAP replication MUST NOT require all copies of the replicated information to be complete copies of the replicated object. The model MUST support Partial Replicas. M6. The determination of which OIDs are critical MUST be configurable in the replication agreement. M7. The parameters of the replication process among the members of the replica-group, including access parameters, necessary authentication credentials, and assurances of confidentiality (encryption) MUST be defined in a standard location (e.g. the replication agreements). Stokes, et al Expires September 2001 [Page 9] Internet-Draft LDAPv3 Replication Requirements March 2001 M8. The replication agreements SHOULD accommodate multiple servers receiving the same area of replication under a single predefined agreement. M9. LDAP replication MUST provide scalability to both enterprise and Internet environments, e.g. an LDAP server must be able to provide replication services to replicas within an enterprise as well as across the Internet. M10. While different directory implementations can support different/extended schema, schema mismatches between two replicating servers MUST be handled. One way of handling such mismatches might be to raise an error condition. M11. There MUST be a facility that can update, or totally refresh, a replica-group from a standard data format, such as LDIF format [RFC2849]. 4.3 Protocol P1. The replication protocol MUST provide for recovery and rescheduling of a replication session due to replication initiation conflicts (e.g. consumer busy replicating with other servers) and or loss of connection (e.g. supplier cannot reach a replica). P2. LDUP replication SHOULD NOT send an update to a consumer if the consumer has previously acknowledged that update. P3. An update received by a consumer more than once MUST NOT produce a different outcome than if the update were received only once. P4. The LDAP replication protocol MUST allow for full update to facilitate replica initialization and reset loading utilizing a standardized format such as LDIF [RFC2849] format. P5. Incremental replication MUST be allowed. P6. The replication protocol MUST allow either a master or slave replica to initiate the replication process. P7. The protocol MUST preserve atomicity of LDAP operations as defined in RFC2251 [RFC2251]. P8. The protocol MUST support a mechanism to report schema mismatches between replicas discovered during a replication session. Stokes, et al Expires September 2001 [Page 10] Internet-Draft LDAPv3 Replication Requirements March 2001 4.4 Schema SC1. A standard way to determine what replicas are held on a server MUST be defined. SC2. A standard schema for representing replication agreements MUST be defined. SC3. The semantics associated with modifying the attributes of replication agreements MUST be defined. SC4. A standard method for determining the location of replication agreements MUST be defined. SC5. A standard schema for publishing state information about a given replica MUST be defined. SC6. A standard method for determining the location of replica state information MUST be defined. SC7. It MUST be possible for appropriately authorized administrators, regardless of their network location, to access replication agreements in the DIT. SC8. Replication agreements of all servers containing replicated information MUST be accessible via LDAP. SC9. An entry MUST be uniquely identifiable throughout its lifetime. 4.5 Single Master SM1. A Single Master system SHOULD provide a fast method of promoting a slave replica to become the master replica. SM2. The master replica in a Single Master system SHOULD send all changes to read-only replicas in the order in which the master applied them. 4.6 Multi-Master MM1. The replication protocol SHOULD NOT saturate the network with redundant or unnecessary entry replication. MM2. The initiator MUST be allowed to determine whether it will become a consumer or supplier during the synchronization startup process. Stokes, et al Expires September 2001 [Page 11] Internet-Draft LDAPv3 Replication Requirements March 2001 MM3. During a replica cycle, it MUST be possible for the two servers to switch between the consumer and supplier roles. MM4. When multiple master replicas want to start a replica cycle with the same replica at the same time, the model MUST have an automatic and deterministic mechanism for resolving or avoiding replication initiation conflict. MM5. Multi-master replication MUST NOT lose information during replication. If conflict resolution would result in the loss of directory information, the replication process MUST store that information, notify the administrator of the nature of the conflict and the information that was lost, and provide a mechanism for possible override by the administrator. MM6. Multi-master replication MUST support convergence of the values of attributes and entries. Convergence may result in an event as described in MM5. MM7. Multi-master conflict resolution MUST NOT depend on the in-order arrival of changes at a replica to assure eventual convergence. 4.7 Administration and Management AM1. Replication agreements MUST allow the initiation of a replica cycle to be administratively postponed to a more convenient period. AM2. Each copy of a replica MUST maintain audit history information of which servers it has replicated with and which servers have replicated with it. AM3. Access to replication agreements, topologies, and policy attributes MUST be provided through LDAP. AM4. The capability to check the differences between two replicas for the same information SHOULD be provided. AM5. A mechanism to fix differences between replicas without triggering new replica cycles SHOULD be provided. AM6. The sequence of updates to access control information (ACI) and the data controlled by that ACI MUST be maintained by replication. AM7. It MUST be possible to add a 'blank' replica to a replica-group, and force a full update from (one of) the Master(s), for the purpose of adding a new directory server to the system. Stokes, et al Expires September 2001 [Page 12] Internet-Draft LDAPv3 Replication Requirements March 2001 AM8. Vendors SHOULD provide tools to audit schema compatibility within a potential replica-group. 4.8 Security S1. During initiation of a replication session, authentication and verification of authorization of both the replica and the source directory MUST be allowed before any data is transferred. S2. The transport for LDAP synchronization MUST permit assurance of the integrity and privacy of all data transferred. S3. To promote interoperability, there MUST be a mandatory-to- implement data privacy mechanism. S4. The transport for administrative access MUST permit assurance of the integrity and privacy of all data transferred. 5 Security Considerations This document includes security requirements (listed in section 4.8 above) for the replication model and protocol. As noted in Section 3, security may be impacted when replicating among servers that implement non-standard extensions to basic LDAP semantics. Access control is one common case which affects security; work to address this issue is going on in LDAPEXT as documented in RFC 2820 [RFC2820]. 6 Acknowledgements This document is based on input from IETF members interested in LDUP Replication. 7 References [ACID] T. Haerder, A. Reuter, "Principles of Transaction-Oriented Database Recovery", Computing Surveys, Vol. 15, No. 4 (December 1983), pp. 287-317. [NDS] Novell, "NDS Technical Overview", 104-000223-001, http://developer.novell.com/ndk/doc/ndslib/dsov_enu/data/h6tvg4z7.html, September, 2000. [RFC2119] S. Bradner, "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Stokes, et al Expires September 2001 [Page 13] Internet-Draft LDAPv3 Replication Requirements March 2001 [RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory Access Protocol", RFC 2251, December 1997. [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [RFC2253] S. Kille, M. Wahl, and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [RFC2254] T. Howes, "The String Representation of LDAP Search Filters", RFC 2254, December 1997. [RFC2255] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December 1997. [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. [RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access Control Requirements for LDAP", RFC 2820, May 2000. [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. "Authentication Methods for LDAP", RFC 2829, May 2000. [RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000. [RFC2849] Gordon Good, "The LDAP Data Interchange Format (LDIF)", RFC 2849, June 2000. [X.501] ITU-T Recommendation X.501 (1993), | ISO/IEC 9594-2: 1993, Information Technology - Open Systems Interconnection - The Directory: Models. [X.525] ITU-T Recommendation X.525 (1997), | ISO/IEC 9594-9: 1997, Information Technology - Open Systems Interconnection - The Directory: Replication. [XEROX] C. Hauser, "Managing update conflicts in Bayou, a weakly connected replicated storage system". Palo Alto, CA: Xerox PARC, Computer Science Laboratory; 1995 August; CSL-95-4. [CSL-95-04] [XEROX2] Alan D. Demers, Mark Gealy, Daniel Greene, Carl Hauser, Wesley Irish, John Larson, Sue Manning, Scott Shenker, Howard Sturgis, Daniel Swinehart, Douglas Terry, Don Woods, "Epidemic Algorithms for Stokes, et al Expires September 2001 [Page 14] Internet-Draft LDAPv3 Replication Requirements March 2001 Replicated Database Maintenance". Palo Alto, CA, Xerox PARC, January 1989. A. APPENDIX A - Usage Scenarios The following directory deployment examples are intended to validate our replication requirements. A heterogeneous set of directory implementations is assumed for all the cases below. This material is intended as background; no requirements are presented in this Appendix. A.1. Extranet Example A company has a trading partner with whom it wishes to share directory information. This information may be as simple as a corporate telephone directory, or as complex as an extranet workflow application. For performance reasons, the company wishes to place a replica of its directory within the Partner Company, rather than exposing its directory beyond its firewall. The requirements that follow from this scenario are: - One-way replication, single mastered. - Authentication of clients. - Common access control and access control identification. - Secure transmission of updates. - Selective attribute replication (Fractional Replication), so that only partial entries can be replicated. A.2. Consolidation Example Company A acquires company B. Each company has an existing directory. During the transition period, as the organizations are merged, both directory services must coexist. Company A may wish to attach company B's directory to its own. The requirements that follow from this scenario are: - Multi-Master replication. - Common access control model. Access control model identification. - Secure transmission of updates. - Replication between DITs with potentially differing schema. A.3. Replication Heterogeneous Deployment Example An organization may choose to deploy directory implementations from multiple vendors, to enjoy the distinguishing benefits of each. Stokes, et al Expires September 2001 [Page 15] Internet-Draft LDAPv3 Replication Requirements March 2001 In this case, multi-master replication is required to ensure that the multiple replicas of the DIT are synchronized. Some vendors may provide directory clients, which are tied to their own directory service. The requirements that follow from this scenario are: - Multi-Master replication - Common access control model and Access control model identification. - Secure transmission of updates. - Replication among DITs with potentially differing schemas. A.4. Shared Name Space Example Two organizations may choose to cooperate on some venture and need a shared name space to manage their operation. Both organizations will require administrative rights over the shared name space. The requirements that follow from this scenario are: - Multi-Master replication. - Common access control model and Access control model identification. - Secure transmission of updates. A.5. Supplier Initiated Replication This is a single master environment that maintains a number of replicas of the DIT by pushing changes based on a defined schedule. The requirements that follow from this scenario are: - Single-master environment. - Supplier-initiated replication. - Secure transmission of updates. A.6. Consumer Initiated Replication Again a single mastered replication topology, but the slave replica initiates the replication exchange rather than the master. An example of this is a replica that resides on a laptop computer that may run disconnected for a period of time. The requirements that follow from this scenario are: - Single-master environment. - Consumer initiated replication. - Open scheduling (anytime). Stokes, et al Expires September 2001 [Page 16] Internet-Draft LDAPv3 Replication Requirements March 2001 A.7. Prioritized attribute replication The password attribute can provide an example of the requirement for prioritized attribute replication. A user is working in Utah and the administrator resides in California. The user has forgotten his password. So the user calls or emails the administrator to request a new password. The administrator provides the updated password (a change). Under normal conditions, the directory replicates to a number of different locations overnight. But corporate security policy states that passwords are critical and the new value must be available immediately (e.g. shortly) after any change. Replication needs to occur immediately for critical attributes/entries. The requirements that follow from this scenario are: - Incremental replication of changes. - Immediate replication on change of certain attributes. - Replicate based on time/attribute semantics. A.8. Bandwidth issues The replication of Server (A) R/W replica (a) in Kathmandu is handled via a dial up phone link to Paris where server (B) R/W replica of (a) resides. Server (C) R/W replica of (a) is connected by a T1 connection to server (B). Each connection has a different performance characteristic. The requirements that follow from this scenario are: - Minimize repetitive updates when replicating from multiple replication paths. - Incremental replication of changes. - Provide replication cycles to delay and/or retry when connections cannot be reached. - Allowances for consumer initiated or supplier initiated replication. A.9. Interoperable Administration and Management The administrator with administrative authority of the corporate directory which is replicated by numerous geographically dispersed LDAP servers from different vendors notices that the replication process is not completing correctly as the change log is continuing to grow and/or error message informs him. The administrator uses his $19.95 RepCo LDAP directory replication diagnostics tools to look at Root DSE replica knowledge on server 17 and determines that server 42 made by LDAP'RUS Inc. is not replicating properly due to an Object conflict. Stokes, et al Expires September 2001 [Page 17] Internet-Draft LDAPv3 Replication Requirements March 2001 Using his Repco Remote repair tools he connects to server 42 and resolves the conflict on the remote server. The requirements that follow from this scenario are: - Provides replication audit history. - Provisions for managing conflict resolution. - Provide LDAP access to predetermined agreements, topology and policy attributes. - Provide operations for comparing replica's content for validity. - Provide LDAP access to status and audit information. A.10. Enterprise Directory Replication Mesh A Corporation builds a mesh of directory servers within the enterprise utilizing LDAP servers from various vendors. Five servers are holding the same area of replication. The predetermined replication agreement(s) for the enterprise mesh are under a single management, and the security domain allows a single predetermined replication agreement to manage the 5 servers' replication. The requirements that follow from this scenario are: - One predefined replication agreement that manages a single area of replication that is held on numerous servers. - Common support of replication management knowledge across vendor implementation. - Rescheduling and continuation of a replication cycle when one server in a replica-group is busy and/or unavailable. A.11. Failure of the Master in a Master-Slave Replicated Directory A company has a corporate directory that is used by the corporate email system. The directory is held on a mesh of servers from several vendors. A corporate relocation results in the closing of the location where the master copy of the directory is located. Employee information (such as mailbox locations and employee certificate information) must be kept up to date or mail cannot be delivered. The requirements that follow from this scenario are: - An existing slave replica must be "promote-able" to become the new master. - The "promotion" must be done without significant downtime, since updates to the directory will continue. A.12. Failure of a Directory Holding Critical Service Information Stokes, et al Expires September 2001 [Page 18] Internet-Draft LDAPv3 Replication Requirements March 2001 An ISP uses a policy management system that uses a directory as the policy data repository. The directory is replicated in several different sites on different vendors' products to avoid single points of failure. It is imperative that the directory be available and be updateable even if one site is disconnected from the network. Changes to the data must be traceable, and it must be possible to determine how changes made from different sites interacted. The requirements that follow from this scenario are: - Multi-master replication - Ability to reschedule replication sessions - Support for manual review and override of replication conflict resolution B. APPENDIX B - Rationale This Appendix gives some of the background behind the requirements. It is included to help the protocol designers understand the thinking behind some of the requirements and to present some of the issues that should be considered during design. With the exception of section B.8, which contains a suggested requirement for the update to RFC 2251, this Appendix does not state any formal requirements. B.1. Meta-Data Implications Requirement G4 states that meta-data must not grow without bound. This implies that meta-data must, at some point, be purged from the system. This, in turn, raises concerns about stability. Purging meta-data before all replicas have been updated may lead to incomplete replication of change information and inconsistencies among replicas. Therefore, care must be taken setting up the rules for purging meta- data from the system while still ensuring that meta-data will not grow forever. B.2. Order of Transfer for Replicating Data Situations may arise where it would be beneficial to replicate data out-of-order (e.g. send data to consumer replicas in a different order than it was processed at the supplier replica). One such case might occur if a large bulk load was done on the master server in a single- master environment and then a single change to a critical OID (a password change, for example) was then made. Rather than wait for all the bulk data to be sent to the replicas, the password change might be moved to the head of the queue and be sent before all the bulk data was transferred. Other cases where this might be considered are schema changes or changes to critical policy data stored in the directory. Stokes, et al Expires September 2001 [Page 19] Internet-Draft LDAPv3 Replication Requirements March 2001 While there are practical benefits to allowing out-of-order transfer, there are some negative consequences as well. Once out-of-order transfers are permitted, all receiving replicas must be prepared to deal with data and schema conflicts that might arise. As an example, assume that schema changes are critical and must be moved to the front of the replication queue. Now assume that a schema change deletes an attribute for some object class. It is possible that some of the operations ahead of the schema change in the queue are operations to delete values of the soon-to-be-deleted attribute so that the schema change can be done with no problems. If the schema change moves to the head of the queue, the consumer servers might have to delete an attribute that still has values, and then receive requests to delete the values of an attribute that is no longer defined. In the multi-master case, similar situations can arise when simultaneous changes are made to different replicas. Thus, multi- master systems must have conflict resolution algorithms in place to handle such situations. But in the single-master case conflict resolution is not needed unless the master is allowed to send data out- of-order. This is the reasoning behind requirement SM2, which recommends that data always be sent in order in single-master replication. Note that even with this restriction, the concept of a critical OID is still useful in single-master replication. An example of its utility can be found in section A.7. B.3. Schema Mismatches and Replication Multi-vendor environments are the primary area of interest for LDAP replication standards. Some attention must thus be paid to the issue of schema mismatches, since they can easily arise when vendors deliver slightly different base schema with their directory products. Even when both products meet the requirements of the standards [RFC2252], the vendors may have included additional attributes or object classes with their products. When two different vendor's products attempt to replicate, these additions can cause schema mismatches. Another potential cause of schema mismatches is discussed in section A.3. There are only a few possible responses when a mismatch is discovered. - Raise an error condition and ignore the data. This should always be allowed and is the basis for requirement P8 and the comment on M10. - Map/convert the data to the form required by the consuming replica. A system may choose this course; requirement M10 is intended to allow this option. The extent of the conversion is up to the Stokes, et al Expires September 2001 [Page 20] Internet-Draft LDAPv3 Replication Requirements March 2001 implementation; in the extreme it could support use of the replication protocol in meta-directories. - Quietly ignore (do not store on the consumer replica and do not raise an error condition) any data that does not conform to the schema at the consumer. Requirement M10 is intended to exclude the last option. Requirement AM8 suggests that vendors should provide tools to help discover schema mismatches when replication is being set up. But schema will change after the initial setup, so the replication system must be prepared to handle unexpected mismatches. Normal IETF practice in protocol implementation suggests that one be strict in what one sends and be flexible in what one receives. The parallel in this case is that a supplier should be prepared to receive an error notification for any schema mismatch, but a consumer may choose to do a conversion instead. The other option that can be considered in this situation is the use of fractional replication. If replication is set up so only the common attributes are replicated, mismatches can be avoided. One additional consideration here is replication of the schema itself. M4 requires that it be possible to replicate schema. If a consumer replica is doing conversion, extreme care should be taken if schema elements are replicated since some attributes are intended to have different definitions on different replicas. For fractional replication, the protocol designers and implementors should give careful consideration to the way they handle schema replication. Some options for schema replication include: - All schema elements are replicated. - Schema elements are replicated only if they are used by attributes that are being replicated. - Schema are manually configured on the servers involved in fractional replication; schema elements are not replicated via the protocol. B.4. Detecting and Repairing Inconsistencies Among Replicas Despite the best efforts of designers, implementors, and operators, inconsistencies will occasionally crop up among replicas in production directories. Tools will be needed to detect and to correct these inconsistencies. A special client may accomplish detection through periodic comparisons of replicas. This client would typically read two replicas of the same replication base entry and compare the answers, possibly by BINDing to Stokes, et al Expires September 2001 [Page 21] Internet-Draft LDAPv3 Replication Requirements March 2001 each of the two replicas to be compared and reading them both. In cases where the directory automatically reroutes some requests (e.g. chaining), mechanisms to force access to a particular replica should be supplied. Alternatively, the server could support a special request to handle this situation. A client would invoke an operation at some server. It would cause that server to extract the contents from some other server it has a replication agreement with and report the differences back to the client as the result If an inconsistency is found, it needs to be repaired. To determine the appropriate repair, the administrator will need access to the replication history to figure out how the inconsistency occurred and what the correct repair should be. When a repair is made, it should be restricted to the replica that needs to be fixed; the repair should not cause new replication events to be started. This may require special tools to change the local data store without triggering replication. Requirements AM2, AM4, and AM5 address these needs. B.5. Some Test Cases for Conflict Resolution in Multi-Master Replication Use of multi-master replication inevitably leads to the possibility that incompatible changes will be made simultaneously on different servers. In such cases, conflict resolution algorithms must be applied. As a guiding principle, conflict resolution should avoid surprising the user. One way to do this is to adopt the principle that, to the extent possible, conflict resolution should mimic the situation that would happen if there were a single server where all the requests were handled. While this is a useful guideline, there are some situations where it is impossible to implement. Some of these cases are examined in this section. In particular, there are some cases where data will be "lost" in multi-master replication that would not be lost in a single-server configuration. In the examples below, assume that there are three replicas, A, B, and C. All three replicas are updateable. Changes are made to replicas A and B before replication allows either replica to see the change made on the other. In discussion of the multi-master cases, we assume that Stokes, et al Expires September 2001 [Page 22] Internet-Draft LDAPv3 Replication Requirements March 2001 the change to A takes precedence using whatever rules are in force for conflict resolution. B.5.1. Create-Create A user creates a new entry with distinguished name DN on A. At the same time, a different user adds an entry with the same distinguished name on B. In the single-server case, one of the create operations would have occurred before the other, and the second request would have failed. In the multi-master case, each create was successful on its originating server. The problem is not detected until replication takes place. When a replication request to create a DN that already exists arrives at one of the servers, conflict resolution is invoked. (Note that the two requests can be distinguished even though they have the same DN because every entry has some sort of unique identifier per requirement SC9.) As noted above, in these discussions we assume that the change from replica A has priority based on the conflict resolution algorithm. Whichever change arrives first, requirement MM6 says that the values from replica A must be those in place on all replicas at the end of the replication cycle. Requirement MM5 states that the system cannot quietly ignore the values from replica B. The values from replica B might be logged with some notice to the administrators, or they might be added to the DIT with a machine generated DN (again with notice to the administrators). If they are stored with a machine generated DN, the same DN must be used on all servers in the replica-group (otherwise requirement M3 would be violated). Note that in the case where the entry in question is a container, storage with a machine generated DN provides a place where descendent entries may be stored if any descendents were generated before the replication cycle was completed. In any case, some mechanism must be provided to allow the administrator to reverse the conflict resolution algorithm and force the values originally created on B into place on all replicas if desired. B.5.2. Rename-Rename On replica A, an entry with distinguished name DN1 is renamed to DN. At the same time on replica B, an entry with distinguished name DN2 is renamed to DN. Stokes, et al Expires September 2001 [Page 23] Internet-Draft LDAPv3 Replication Requirements March 2001 In the single-server case, one rename operation would occur before the other and the second would fail since the target name already exists. In the multi-master case, each rename was successful on its originating server. Assuming that the change on A has priority in the conflict resolution sense, DN will be left with the values from DN1 in all replicas and DN1 will no longer exist in any replica. The question is what happens to DN2 and its original values. Requirement MM5 states that these values must be stored somewhere. They might be logged, they might be left in the DIT as the values of DN2, or they might be left in the DIT as the values of some machine generated DN. Leaving them as the values of DN2 is attractive since it is the same as the single-server case, but if a new DN2 has already been created before the replica cycle finishes, there are some very complex cases to resolve. Any of the solutions described in this paragraph would be consistent with requirement MM5. B.5.3. Locking Based on Atomicity of ModifyRequest There is an entry with distinguished name DN that contains attributes X, Y, and Z. The value of X is 1. On replica A, a ModifyRequest is processed which includes modifications to change that value of X from 1 to 0 and to set the value of Y to "USER1". At the same time, replica B processes a ModifyRequest which includes modifications to change the value of X from 1 to 0 and to set the value of Y to "USER2" and the value of Z to 42. The application in this case is using X as a lock and is depending on the atomic nature of ModifyRequests to provide mutual exclusion for lock access. In the single-server case, the two operations would have occurred sequentially. Since a ModifyRequest is atomic, the entire first operation would succeed. The second ModifyRequest would fail, since the value of X would be 0 when it was attempted, and the modification changing X from 1 to 0 would thus fail. The atomicity rule would cause all other modifications in the ModifyRequest to fail as well. In the multi-master case, it is inevitable that at least some of the changes will be reversed despite the use of the lock. Assuming the changes from A have priority per the conflict resolution algorithm, the value of X should be 0 and the value of Y should be "USER1" The interesting question is the value of Z at the end of the replication cycle. If it is 42, the atomicity constraint on the change from B has been violated. But for it to revert to its previous value, grouping information must be retained and it is not clear when that information can be safely discarded. Thus, requirement G6 may be violated. Stokes, et al Expires September 2001 [Page 24] Internet-Draft LDAPv3 Replication Requirements March 2001 B.5.4. General Principles With multi-master replication there are a number of cases where a user or application will complete a sequence of operations with a server but those actions are later "undone" because someone else completed a conflicting set of operations at another server. To some extent, this can happen in any multi-user system. If a user changes the value of an attribute and later reads it back, intervening operations by another user may have changed the value. In the multi- master case, the problem is worsened, since techniques used to resolve the problem in the single-server case won't work as shown in the examples above. The major question here is one of intended use. In LDAP standards work, it has long been said that replication provides "loose consistency" among replicas. At several IETF meetings and on the mailing list, usage examples from finance where locking is required have been declared poor uses for LDAP. Requirement G1 is consistent with this history. But if loose consistency is the goal, the locking example above is an inappropriate use of LDAP, at least in a replicated environment. B.5.5. Avoiding the Problem The examples above discuss some of the most difficult problems that can arise in multi-master replication. While they can be dealt with, dealing with them is difficult and can lead to situations that are quite confusing to the application and to users. The common characteristics of the examples are: - Several directory users/applications are changing the same data. - They are changing the data before previous changes have replicated. - They are using different directory servers to make these changes. - They are changing data that are parts of a distinguished name or they are using ModifyRequest to both read and write a given attribute value in a single atomic request. If any one of these conditions is reversed, the types of problems described above will not occur. There are many useful applications of multi-master directories where at least one of the above conditions does not occur. For cases where all four do occur, application designers should be aware of the possible consequences. B.6. Data Privacy During Replication Stokes, et al Expires September 2001 [Page 25] Internet-Draft LDAPv3 Replication Requirements March 2001 Directories will frequently hold proprietary information. Policy information, name and address information, and customer lists can be quite proprietary and are likely to be stored in directories. Such data must be protected during replication. In some cases, the network environment (e.g. a private network) may provide sufficient privacy for the application. In other cases, the data in the directory may be public and not require protection. For these reasons data privacy was not made a requirement for all replication sessions. But there are a substantial number of applications that will need data privacy, so there is a requirement (S2) that the protocol allow for data privacy in those cases where it is needed. This leaves the question of what privacy mechanism(s) to use. While this is ultimately a design/implementation decision, replication across different vendors' directory products is an important goal of the LDAP replication work at the IETF. If different vendors choose to support different data privacy mechanisms, the advantages of a standard replication protocol would be lost. Thus there is a requirement (S3) for a mandatory-to-implement data privacy mechanism. B.7. Failover in Single-Master Systems In a single-master system, all modifications must originate at the master. The master is therefore a single point of failure for modifications. This can cause concern when high availability is a requirement for the directory system. One way to reduce the problem is to provide a failover process that converts a slave replica to master when the original master fails. The time required to execute the failover process then becomes a major factor in availability of the system as a whole. Factors that designers and implementors should consider when working on failover include: - If the master replica contains control information or meta-data that is not part of the slave replica(s), this information will have to be inserted into the slave that is being "promoted" to master as part of the failover process. Since the old master is presumably unavailable at this point, it may be difficult to obtain this data. For example, if the master holds the status information of all replicas, but each slave replica only holds its own status information, failover would require that the new master get the status of all existing replicas, presumably from those replicas. Similar issues could arise for replication agreements if the master is the only system that holds a complete set. Stokes, et al Expires September 2001 [Page 26] Internet-Draft LDAPv3 Replication Requirements March 2001 - If data privacy mechanisms (e.g. encryption) are in use during replication, the new master would need to have the necessary key information to talk to all of the slave replicas. - It is not only the new master that needs to be reconfigured. The slaves also need to have their configurations updated so they know where updates should come from and where they should refer modifications. - The failover mechanism should be able to handle a situation where the old master is "broken" but not "dead". The slave replicas should ignore updates from the old master after failover is initiated. - The old master will eventually be repaired and returned to the replica-group. It might join the group as a slave and pick up the changes it has "missed" from the new master, or there might be some mechanism to bring it into sync with the new master and then let it take over as master. Some resynchronization mechanism will be needed. - Availability would be maximized if the whole failover process could be automated (e.g. failover is initiated by an external system when it determines that the original master is not functioning properly). B.8. Including Operational Attributes in Atomic Operations LDAPv3 [RFC2251] declares that some operations are atomic (e.g. all of the modifications in a single ModifyRequest). It also defines several operational attributes that store information about when changes are made to the directory (createTimestamp, etc.) and which ID was responsible for a given change (modifiersName, etc.). Currently, there is no statement in RFC2251 requiring that changes to these operational attributes be atomic with the changes to the data. It is RECOMMENDED that this requirement be added during the revision of RFC2251. In the interim, replication SHOULD treat these operations as though such a requirement were in place. Authors' Addresses Russel F. Weiser Digital Signature Trust Co. 1095 East 2100 South Suite #201 Salt Lake City, Utah 84106 USA E-mail: rweiser@digsigtrust.com Stokes, et al Expires September 2001 [Page 27] Internet-Draft LDAPv3 Replication Requirements March 2001 Telephone: +1 801 246 4323 Fax: +1 801 246 4361 Ellen J. Stokes Tivoli Systems 6300 Bridgepoint Parkway Austin, Texas 78731 USA E-mail: estokes@tivoli.com Telephone: +1 512 436 9098 Fax: +1 512 436 1190 Ryan D. Moats Coreon, Inc. 15621 Drexel Circle Omaha, NE 68135 USA E-Mail: rmoats@coreon.net Telephone: +1 402 894 9456 Richard V. Huber Room C3-3B30 AT&T Laboratories 200 Laurel Avenue South Middletown, NJ 07748 USA E-Mail: rvh@att.com Telephone: +1 732 420 2632 Fax: +1 732 368 1690 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Stokes, et al Expires September 2001 [Page 28] Internet-Draft LDAPv3 Replication Requirements March 2001 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Stokes, et al Expires September 2001 [Page 29] From owner-ietf-ldup@mail.imc.org Sun Mar 25 01:27:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26062 for ; Sun, 25 Mar 2001 01:27:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id VAA21505 for ietf-ldup-bks; Sat, 24 Mar 2001 21:55:18 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id VAA21501 for ; Sat, 24 Mar 2001 21:55:16 -0800 (PST) Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f2P5uaD59350; Sun, 25 Mar 2001 05:56:37 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010324215102.00aa6da0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 24 Mar 2001 21:53:16 -0800 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: Candidate LDAP Administration Model Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 05:49 AM 3/22/01 -0700, Ed Reed wrote: >Well - I tried to just add a sentence to the LDAP Subentries text describing an administrative area, and couldn't convince myself that it was sufficient. Instead, I studied the X.501 (2001) draft and came up with the following description of what is, I think, a compatible, simpler subset of the X.500 model. I present it here for your comment and feedback to see (1) if it is indeed simpler (2) if it is indeed compatible (3) if it is indeed a subset. > >Thanks. Your comments are requested. I suggest this be part of the LDAP Subentry draft, that should go onto the proposed standard track. I concur. The text seems reasonable at first glance. >Ed >============================================= >4 Administrative Areas in the Directory >4.1 X.501 Administrative Model Overview >[X501] contains an extensive description of Administrative Areas and their role in the management and administration of directories. The LDAP administrative model defined here is intended to be a compatible, proper subset of the [X501] model. The description here draws heavily on the descriptions and concepts laid out in [X501]. > >An administrative area is a sub-tree of the directory information tree, rooted at an administrative point (the root-most entry in the sub-tree), where administrative entries (perhaps including subentries, operational attributes, or both) are located. Autonomous administrative areas are distinct partitions of the directory information tree whose entries are all administered by a single administrative authority. Each entry in the directory information tree is administered by exactly one autonomous administrative authority. > >There may be many aspects of administration defined by the directory and other applications for specific purposes, such as subschema administration areas, access control administration areas, collective-attribute administration areas, context default administrative areas, and service administrative areas. Within an autonomous administrative area, specific administrative areas for these (and other) different aspects may overlap one another. > >Specific administrative areas may be sub-partitioned by the applications or services which define them to facilitate delegation of authority or for other purposes. That means that a single entry in the directory may be part of many different specific administrative areas, but only be part of one specific administrative area (or sub-area) of each aspect of administration. > >The [X501] subentry specification optionally uses a SubtreeSpecification to indicate a subset of entries in a sub-tree with which the subentry is concerned. When the SubtreeSpecification is empty the scope of the [X501] subentry is implicitly defined by the context in which it occurs. >4.2 An LDAP Administrative Model >The administrative model for LDAP defined here is a simplified version of the one described in [X501], in that the scope defined for the ldapSubentry object class is limited. > >The LDAP Subentry definition below specifically does not include a SubtreeSpecification, so its scope is explicitly the complete set of entries in the specific administrative area (or sub-area) in which it occurs. All administrative areas are considered to be specific administrative areas within an autonomous administrative area. > >If a specific administration area is not partitioned, then its extent (or scope) is said to be that of the autonomous administrative area in which it is defined. > >Applications and services which define specific administrative areas must specify whether the areas may be partitioned or not. By default, the scope of LDAP Subentries is limited to the sub-area of the partitioned specific administrative area in which they are present. > > >================= >Ed Reed >Reed-Matthews, Inc. >+1 801 796 7065 >http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Mon Mar 26 09:11:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25238 for ; Mon, 26 Mar 2001 09:11:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA21805 for ietf-ldup-bks; Mon, 26 Mar 2001 05:36:10 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id FAA21801 for ; Mon, 26 Mar 2001 05:36:09 -0800 (PST) Received: (qmail 613 invoked from network); 26 Mar 2001 13:35:10 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 26 Mar 2001 13:35:10 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: , Subject: Access Control, Administrative Areas, Replication and Distribution Date: Mon, 26 Mar 2001 23:39:17 +1000 Message-ID: <000101c0b5fa$28015000$6628a8c0@nowhere.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Following links highlight serious problems that can arise from not not working out access control together with replication carefully enough. Microsoft unable to supply a fix for more than a year due to having to fundamentally redesign Active Directory to fix it: http://www.nwfusion.com/archive/2001/117574_02-26-2001.html http://www.microsoft.com/windows2000/news/bulletins/multivalrep.asp Similar issues can arise with replication of administrative policy etc. Workarounds like Microsoft proposes are simply bizarre and negate the point of a directory. The description of their proposed future fix also looks like just a kludge. Workarounds like notifications to directory administrators are also unworkable in the long run. Changes to access control information (including group membership) are increasingly made directly by end users and their applications - such delegation being one of the main advantages of large scale directory deployment. In order to satisfy the currently recognized requirement for replication of access controls to work it will be necessary to actually implement both: 1) preservation of atomic operations 2) preservations of the sequence between access control related changes and changes to affected entries as specified in the current LDUP requirements draft. This will still not eliminate all possible anomalies, even together with profile advice on avoiding situations where changes are frequently made before previous changes have fully replicated. I therefore believe it is essential to add: 3) automatic notification to the DUA that made a change when that change is revoked as a result of a conflicting atomic operation. The current requirement for notification to administrators ensures that an architecture capable of being extended to also meet item 3) will not need complete redesign to provide that extension. Therefore I do not think it is necessary to oppose the current requirements draft at IETF final call, although it would certainly be better if this requirement was recognized now. However I would be opposed to adoption of any architecture that did not actually implement item 3 and am putting that on the record now. Some work will be necessary to actually standardize notification mechanisms - eg by email to the address given in DUA entries or via LCUP. It would be better if that work was started earlier rather than later. (Other objections to the meaningless requirements concerning "model 1" and "model 3" likewise don't really matter precisely because they are meaningless, though it would obviously be better to not include meaningless requirements. Ditto for the unhelpful examples which obscure the reasons for needing multi-master replication.) On item 2, there is no practical way to achieve it without implementing delivery of change reports from each originator DSA to each other DSA in exactly the same sequence as generated by the originator. This follows from the fact that an ACI change can affect an entire subtree, even leaving aside the fact that group membership can be from other parts of the DIT entirely. It is also necessary for minimizing restarts of replication sessions and use of full instead of incremental replication. Similar considerations may apply to administrative areas - perhaps with more problematic implications due to administration points being at the intersection between replicated areas. Single master replication (with failover) may well be essential for administrative points (and acceptable due to not needing the same fault tolerance and local availability of changeable copies as for other changes). Even namespace management is currently unclear. How is a modifyDN operation actually performed between different replicated areas within a single "Naming Context"? Changes from different originator DSAs would of course still be interleaved arbitrarily due to replication schedules and replication network links. As far as I can see items 1 and 2 can only be achieved by some method similar to the "tree" proposed in my MDCR draft (expired). That is because each DSA has to converge on the same serialized sequence of atomic operations and that sequence has to be consistent with the sequence in which changes were originally made at each originator DSA. Since the operations form a tree in reality, I cannot see any way to avoid modelling that tree within the conflict resolution protocol. There simply isn't any actual total ordering available. If there are any other ideas for meeting the proposed requirements, or if anyone believes that URP can meet them, it would be useful to provide an outline before the next LDUP requirements last call, so that there is time to think about it and avoid confusion during discussion. Concerning replication of admin policy and Ed's sub-entry draft I am not clear on the intended function of the paragraph about X.500. If the intention is simply to refer to the X.500 standards as the basis for expected future work on standardization of LDAP administrative areas and their relation to replication, I believe that is a very good idea. What should follow from that is promptly taking up the proposals for liasion put forward by an X.500 working group and doing detailed analysis on whether and how it maps to the sub-entry and replication proposals. Certainly the paragraph cannot actually substitute for that work. Defining any simplified subset requires very detailed work similar to the original LDAP standards. It is unclear to me whether the sub-entry draft is adequate for supporting appropriate administrative areas and replicating them. That could only be determined by actually doing the detailed analysis and mapping. It may turn out that the full "chop specification" with lower bounds as well as a base entry is necessary when taking into account the knowledge needed for distribution and replication. Administrative areas for some purposes such as access control may well need to be nestable rather than partitions. This needs a close inspection of the X.501 (2000) standard referenced by Ed, which is available from: ftp://ftp.bull.com/OSIdirectory/4thEditionTexts/ As background reading I would strongly recommend David Chadwick's online book on earlier versions: http://www.salford.ac.uk/its024/Version.Web/Contents.htm Section 11 of chapter 2 actually succeeds in making the administrative framework intelligible! BTW I believe adopting an access control model incompatible with X.500 and omitting the concept of a Directory Access Control Domain applying only to a subset of entry types is a mistake. Interoperability can best be facilitated by simplifying existing standards where possible, not by adopting "options" for different fundamental models. Such options conflict with well known internet architectural principles. Both administrative areas and access controls are more within LDAP-EXT than LDUP since they are just as important without replication. Liaison with replication work in LDUP and with the X.500 people themselves is clearly essential. These two areas relate closely to a third area - directory distribution - including operational bindings between DSAs (and replicated areas) within the global DIT. Lack of clarify about the interoperability issues arising in connection with that is hindering progress on other issues. A global internet scalable directory service really requires that this be dealt with first - and fortunately much of the work has already been done for it in X.500 as was the case with the original LDAP access standards as a compatible "Lightweight" substitute for X.500 DAP. LDAP was possible without having to do the work on access controls, replication, administrative boundaries or distribution because it was just an "Access Protocol". In standardizing replication it has become obvious that standardization of access controls, and administrative areas is closely related. In moving into these areas IETF is going far beyond issues for an "Access Protocol" and needs to take an architecturally coherent approach based on the X.500 standards. Distribution and then administrative areas is really the foundation for the others and needs serious work now in conjunction with the liason project alredy setup from the X.500 side. Who is doing that work? From owner-ietf-ldup@mail.imc.org Mon Mar 26 09:15:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25840 for ; Mon, 26 Mar 2001 09:15:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id FAA21790 for ietf-ldup-bks; Mon, 26 Mar 2001 05:35:43 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id FAA21785 for ; Mon, 26 Mar 2001 05:35:41 -0800 (PST) Received: (qmail 613 invoked from network); 26 Mar 2001 13:35:10 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 26 Mar 2001 13:35:10 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: , Subject: Access Control, Administrative Areas, Replication and Distribution Date: Mon, 26 Mar 2001 23:39:17 +1000 Message-ID: <000101c0b5fa$28015000$6628a8c0@nowhere.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Following links highlight serious problems that can arise from not not working out access control together with replication carefully enough. Microsoft unable to supply a fix for more than a year due to having to fundamentally redesign Active Directory to fix it: http://www.nwfusion.com/archive/2001/117574_02-26-2001.html http://www.microsoft.com/windows2000/news/bulletins/multivalrep.asp Similar issues can arise with replication of administrative policy etc. Workarounds like Microsoft proposes are simply bizarre and negate the point of a directory. The description of their proposed future fix also looks like just a kludge. Workarounds like notifications to directory administrators are also unworkable in the long run. Changes to access control information (including group membership) are increasingly made directly by end users and their applications - such delegation being one of the main advantages of large scale directory deployment. In order to satisfy the currently recognized requirement for replication of access controls to work it will be necessary to actually implement both: 1) preservation of atomic operations 2) preservations of the sequence between access control related changes and changes to affected entries as specified in the current LDUP requirements draft. This will still not eliminate all possible anomalies, even together with profile advice on avoiding situations where changes are frequently made before previous changes have fully replicated. I therefore believe it is essential to add: 3) automatic notification to the DUA that made a change when that change is revoked as a result of a conflicting atomic operation. The current requirement for notification to administrators ensures that an architecture capable of being extended to also meet item 3) will not need complete redesign to provide that extension. Therefore I do not think it is necessary to oppose the current requirements draft at IETF final call, although it would certainly be better if this requirement was recognized now. However I would be opposed to adoption of any architecture that did not actually implement item 3 and am putting that on the record now. Some work will be necessary to actually standardize notification mechanisms - eg by email to the address given in DUA entries or via LCUP. It would be better if that work was started earlier rather than later. (Other objections to the meaningless requirements concerning "model 1" and "model 3" likewise don't really matter precisely because they are meaningless, though it would obviously be better to not include meaningless requirements. Ditto for the unhelpful examples which obscure the reasons for needing multi-master replication.) On item 2, there is no practical way to achieve it without implementing delivery of change reports from each originator DSA to each other DSA in exactly the same sequence as generated by the originator. This follows from the fact that an ACI change can affect an entire subtree, even leaving aside the fact that group membership can be from other parts of the DIT entirely. It is also necessary for minimizing restarts of replication sessions and use of full instead of incremental replication. Similar considerations may apply to administrative areas - perhaps with more problematic implications due to administration points being at the intersection between replicated areas. Single master replication (with failover) may well be essential for administrative points (and acceptable due to not needing the same fault tolerance and local availability of changeable copies as for other changes). Even namespace management is currently unclear. How is a modifyDN operation actually performed between different replicated areas within a single "Naming Context"? Changes from different originator DSAs would of course still be interleaved arbitrarily due to replication schedules and replication network links. As far as I can see items 1 and 2 can only be achieved by some method similar to the "tree" proposed in my MDCR draft (expired). That is because each DSA has to converge on the same serialized sequence of atomic operations and that sequence has to be consistent with the sequence in which changes were originally made at each originator DSA. Since the operations form a tree in reality, I cannot see any way to avoid modelling that tree within the conflict resolution protocol. There simply isn't any actual total ordering available. If there are any other ideas for meeting the proposed requirements, or if anyone believes that URP can meet them, it would be useful to provide an outline before the next LDUP requirements last call, so that there is time to think about it and avoid confusion during discussion. Concerning replication of admin policy and Ed's sub-entry draft I am not clear on the intended function of the paragraph about X.500. If the intention is simply to refer to the X.500 standards as the basis for expected future work on standardization of LDAP administrative areas and their relation to replication, I believe that is a very good idea. What should follow from that is promptly taking up the proposals for liasion put forward by an X.500 working group and doing detailed analysis on whether and how it maps to the sub-entry and replication proposals. Certainly the paragraph cannot actually substitute for that work. Defining any simplified subset requires very detailed work similar to the original LDAP standards. It is unclear to me whether the sub-entry draft is adequate for supporting appropriate administrative areas and replicating them. That could only be determined by actually doing the detailed analysis and mapping. It may turn out that the full "chop specification" with lower bounds as well as a base entry is necessary when taking into account the knowledge needed for distribution and replication. Administrative areas for some purposes such as access control may well need to be nestable rather than partitions. This needs a close inspection of the X.501 (2000) standard referenced by Ed, which is available from: ftp://ftp.bull.com/OSIdirectory/4thEditionTexts/ As background reading I would strongly recommend David Chadwick's online book on earlier versions: http://www.salford.ac.uk/its024/Version.Web/Contents.htm Section 11 of chapter 2 actually succeeds in making the administrative framework intelligible! BTW I believe adopting an access control model incompatible with X.500 and omitting the concept of a Directory Access Control Domain applying only to a subset of entry types is a mistake. Interoperability can best be facilitated by simplifying existing standards where possible, not by adopting "options" for different fundamental models. Such options conflict with well known internet architectural principles. Both administrative areas and access controls are more within LDAP-EXT than LDUP since they are just as important without replication. Liaison with replication work in LDUP and with the X.500 people themselves is clearly essential. These two areas relate closely to a third area - directory distribution - including operational bindings between DSAs (and replicated areas) within the global DIT. Lack of clarify about the interoperability issues arising in connection with that is hindering progress on other issues. A global internet scalable directory service really requires that this be dealt with first - and fortunately much of the work has already been done for it in X.500 as was the case with the original LDAP access standards as a compatible "Lightweight" substitute for X.500 DAP. LDAP was possible without having to do the work on access controls, replication, administrative boundaries or distribution because it was just an "Access Protocol". In standardizing replication it has become obvious that standardization of access controls, and administrative areas is closely related. In moving into these areas IETF is going far beyond issues for an "Access Protocol" and needs to take an architecturally coherent approach based on the X.500 standards. Distribution and then administrative areas is really the foundation for the others and needs serious work now in conjunction with the liason project alredy setup from the X.500 side. Who is doing that work? From owner-ietf-ldup@mail.imc.org Mon Mar 26 15:01:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15278 for ; Mon, 26 Mar 2001 15:01:14 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id LAA19833 for ietf-ldup-bks; Mon, 26 Mar 2001 11:29:33 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA19829 for ; Mon, 26 Mar 2001 11:29:32 -0800 (PST) Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f2QJUwD62931; Mon, 26 Mar 2001 19:30:59 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010326110146.00a9bec0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 26 Mar 2001 11:27:06 -0800 To: From: "Kurt D. Zeilenga" Subject: Re: Access Control, Administrative Areas, Replication and Distribution Cc: , In-Reply-To: <000101c0b5fa$28015000$6628a8c0@nowhere.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:39 PM 3/26/01 +1000, Albert Langer wrote: >In standardizing replication it has become obvious that >standardization of access controls, and administrative >areas is closely related. I'd expand on this to say: In standardizing multi-master replication, it is obvious that the LDAP/X.500 data model will have to be redesigned as it only support single-master replication. >Who is doing that work? Personally, I rather we, the IETF, leave the redesign of the data model to ITU, and only deal with how to represent whatever model the ITU produces in LDAP. Kurt From owner-ietf-ldup@mail.imc.org Mon Mar 26 21:30:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25517 for ; Mon, 26 Mar 2001 21:30:26 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id SAA15722 for ietf-ldup-bks; Mon, 26 Mar 2001 18:01:56 -0800 (PST) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA15716 for ; Mon, 26 Mar 2001 18:01:50 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 26 Mar 2001 18:02:11 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Mar 2001 18:02:22 -0800 (Pacific Standard Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 26 Mar 2001 18:02:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4673.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Access Control, Administrative Areas, Replication and Distribution Date: Mon, 26 Mar 2001 18:02:22 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657406005BE6@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: Access Control, Administrative Areas, Replication and Distribution Thread-Index: AcC1+qv3ej0bgoeyTEKYSPg1A/ZnVwAZcesA From: "Paul Leach" To: , , X-OriginalArrivalTime: 27 Mar 2001 02:02:22.0351 (UTC) FILETIME=[F61C59F0:01C0B661] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id SAA15717 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Albert Langer [mailto:Albert.Langer@directory-designs.org] > Sent: Monday, March 26, 2001 5:39 AM > To: ietf-ldup@imc.org; ietf-ldapext@netscape.com > Subject: Access Control, Administrative Areas, Replication > and Distribution > > > Following links highlight serious problems that can arise > from not not working out access control together with > replication carefully enough. > > Microsoft unable to supply a fix for more than a year due to > having to fundamentally redesign Active Directory to fix it: > > http://www.nwfusion.com/archive/2001/117574_02-26-2001.html > > http://www.microsoft.com/windows2000/news/bulletins/multivalrep.asp > > Similar issues can arise with replication of administrative > policy etc. Nonsense. The "fundamental" flaw is that Active Directory is loosely consistent. It was proved almost two decades ago (by Brian Oki at PODC 1984, IIRC) that there is a hard instrinsic tradeoff between consistency and availability. For many purposes, availability is more important. Active Directory, and several other commercial products, are targeted at this space, and LDUP is attempting to standardize such a protocol. Many customers don't like intrinsic tradeoffs. They want both consistency and high availability, even if it can be proved that it is impossible. And almost no journalist understands any of this. BTW: the fix to this "security flaw" was to make the unit of replication finer grained. No "funadamental" redesign was needed. You should use better evidence in your campaign. From owner-ietf-ldup@mail.imc.org Tue Mar 27 03:04:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15021 for ; Tue, 27 Mar 2001 03:04:56 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id XAA02132 for ietf-ldup-bks; Mon, 26 Mar 2001 23:28:50 -0800 (PST) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.9.3/8.9.3) with SMTP id XAA02120 for ; Mon, 26 Mar 2001 23:28:46 -0800 (PST) Received: (qmail 21514 invoked from network); 27 Mar 2001 07:31:46 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 27 Mar 2001 07:31:46 -0000 Reply-To: From: "Steven Legg" To: "'Richard V Huber'" , Cc: , , Subject: RE: New LDUP requirements draft Date: Tue, 27 Mar 2001 17:30:00 +1000 Message-ID: <001801c0b68f$bd0cb8c0$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <200103232106.QAA01671@qsun.mt.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rick, et al, > -We feel that discussion of propagating end state vs. changes is about > implementation. Rather, P6 (now P7 due to other changes) has been > rewritten to explicitly require propagation of atomicity of LDAP > operations as defined in RFC 2251. We feel it is now self justifying. I don't know how I should interpret the new P7 requirement, reproduced immediately below. > P7. The protocol MUST preserve atomicity of LDAP operations as defined > in RFC2251 [RFC2251]. The wording is the same in draft-ietf-ldup-replica-req-07.txt and draft-ietf-ldup-replica-req-08.txt. At face value P7 could be interpreted as requiring a previously accepted update to be rejected during replication processing if any part of the update, e.g. a single modification in a modify request, is not performed because it is redundant, e.g. it attempts to insert a value that already exists, or has been superseded, e.g. a more recent update deleted the value. This interpretation is at odds with other sections of the requirements document, contrary to the author's position as I understood it, and contrary to the working group consensus, so P7 must mean something else. What exactly is P7 requiring of the LDUP protocol ? Regards, Steven From owner-ietf-ldup@mail.imc.org Tue Mar 27 08:14:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17744 for ; Tue, 27 Mar 2001 08:14:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id EAA08386 for ietf-ldup-bks; Tue, 27 Mar 2001 04:15:15 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA08382 for ; Tue, 27 Mar 2001 04:15:14 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA134612; Tue, 27 Mar 2001 07:13:52 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id HAA89942; Tue, 27 Mar 2001 07:10:47 -0500 To: Cc: "Ellen Stokes" , ietf-ldup@imc.org Subject: RE: New LDUP requirements draft X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: "Timothy Hahn" Message-ID: Date: Tue, 27 Mar 2001 07:15:08 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V507_03012001.dev00 |March 9, 2001) at 03/27/2001 07:15:09 AM, Serialize complete at 03/27/2001 07:15:09 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00427DE185256A1C_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00427DE185256A1C_= Content-Type: text/plain; charset="us-ascii" Steven, I agree that it seems there is a need to clarify this requirement. I think that it may be interpreted differently. If this is the intent (i.e. leave it intentionally vague - perhaps to allow for lattitude in implementations?) then so be it. If the intent is to make something more clear, then the requirement should be clarified/explained in more detail. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 "Steven Legg" Sent by: owner-ietf-ldup@mail.imc.org 03/27/2001 02:30 AM Please respond to steven.legg To: "'Richard V Huber'" , cc: Ellen Stokes/Tivoli Systems@Tivoli Systems, , Subject: RE: New LDUP requirements draft Rick, et al, > -We feel that discussion of propagating end state vs. changes is about > implementation. Rather, P6 (now P7 due to other changes) has been > rewritten to explicitly require propagation of atomicity of LDAP > operations as defined in RFC 2251. We feel it is now self justifying. I don't know how I should interpret the new P7 requirement, reproduced immediately below. > P7. The protocol MUST preserve atomicity of LDAP operations as defined > in RFC2251 [RFC2251]. The wording is the same in draft-ietf-ldup-replica-req-07.txt and draft-ietf-ldup-replica-req-08.txt. At face value P7 could be interpreted as requiring a previously accepted update to be rejected during replication processing if any part of the update, e.g. a single modification in a modify request, is not performed because it is redundant, e.g. it attempts to insert a value that already exists, or has been superseded, e.g. a more recent update deleted the value. This interpretation is at odds with other sections of the requirements document, contrary to the author's position as I understood it, and contrary to the working group consensus, so P7 must mean something else. What exactly is P7 requiring of the LDUP protocol ? Regards, Steven --=_alternative 00427DE185256A1C_= Content-Type: text/html; charset="us-ascii"
Steven,

I agree that it seems there is a need to clarify this requirement.  I think that it may be interpreted differently.  If this is the intent (i.e. leave it intentionally vague - perhaps to allow for lattitude in implementations?) then so be it.  If the intent is to make something more clear, then the requirement should be clarified/explained in more detail.
Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681


"Steven Legg" <steven.legg@adacel.com.au>
Sent by: owner-ietf-ldup@mail.imc.org

03/27/2001 02:30 AM
Please respond to steven.legg

       
        To:        "'Richard V Huber'" <rvh@qsun.mt.att.com>, <ietf-ldup@imc.org>
        cc:        Ellen Stokes/Tivoli Systems@Tivoli Systems, <rmoats@coreon.com>, <rweiser@digsigtrust.com>
        Subject:        RE: New LDUP requirements draft

       



Rick, et al,

> -We feel that discussion of propagating end state vs. changes is about
> implementation.  Rather, P6 (now P7 due to other changes) has been
> rewritten to explicitly require propagation of atomicity of LDAP
> operations as defined in RFC 2251. We feel it is now self justifying.

I don't know how I should interpret the new P7 requirement, reproduced
immediately below.

> P7.  The protocol MUST preserve atomicity of LDAP operations as defined
> in RFC2251 [RFC2251].

The wording is the same in draft-ietf-ldup-replica-req-07.txt and
draft-ietf-ldup-replica-req-08.txt.

At face value P7 could be interpreted as requiring a previously accepted
update to be rejected during replication processing if any part of the
update, e.g. a single modification in a modify request, is not performed
because it is redundant, e.g. it attempts to insert a value that already
exists, or has been superseded, e.g. a more recent update deleted the
value.

This interpretation is at odds with other sections of the requirements
document, contrary to the author's position as I understood it, and
contrary to the working group consensus, so P7 must mean something else.

What exactly is P7 requiring of the LDUP protocol ?

Regards,
Steven

--=_alternative 00427DE185256A1C_=-- From owner-ietf-ldup@mail.imc.org Wed Mar 28 12:17:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05380 for ; Wed, 28 Mar 2001 12:17:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA15235 for ietf-ldup-bks; Wed, 28 Mar 2001 08:23:46 -0800 (PST) Received: from ns.oncalldba.com (cpe-66-1-184-87.ut.sprintbbd.net [66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA15230 for ; Wed, 28 Mar 2001 08:23:43 -0800 (PST) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f2SGNUw32751 for ; Wed, 28 Mar 2001 09:23:31 -0700 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Wed, 28 Mar 2001 06:22:38 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 28 Mar 2001 06:22:22 -0700 From: "Ed Reed" To: , Cc: , Subject: RE: New LDUP requirements draft Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id IAA15232 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hahahaha...hahaha...haha... This requirement is there, I believe, to placate Albert. I believe the requirement MAY be satisfied IFF log-based replication is used to retransmit the update via LDUP as long as no one else has gotten to the modified entry first via an update to some other master (i.e, as long as there are no conflicting collisions). If there are conflicting updates, I think the result that Albert would like to see is that the update that collides is bounced in some way for administrative resolution. For state-based replication the requirement is meaningless, since state-based replication has as its goal to make all the replicas hold the same values, and it never pretends to try to reproduce the operations which were entered to get them to that state - it doesn't care, because it is the ultimate state that is important. Believers in state-based replication believe the end justifies whatever means are necessary to achieve a common view of the data. Believers in log-based replication think getting there is most of the fun. Thus, my long-held belief that it MAY BE possible to replicate transactional semantics of some sort via log-based replication schemes (who can record and playback the transactions in question), but it will NEVER be possible to do so with state-based replication schemes. I would strike the requirement, as I don't think its either useful or interesting to the class of applications for which I expect LDUP to be used for - distributed administration of policy information. There are other applications, which require the behavior specified in this requirement in order to provide a test- and-set form of operation which I do not believe LDUP will ever adequately support. At least not with the protocol mechanism as we've attempted to define it so far. I honestly believe that the most useful protocol for us to define at the moment is one that interleaves non-conflicting attribute value changes occuring to an entry at various master replicas in such a way that when all the replicas have received the modifications from all the other replicas, they all present the same entry to readers. The only way to achieve that is to share administration of attributes "liberally", and to restrict consistency requirements only on those attributes that are effectively "private" to the application that has the requirement for special consistency. So my interpretation of the "be liberal in what you accept and conservative in what you send" is that applications ought not expect atomic in-sequence application of modification operations to propagate via replication (be liberal in what they accept from the server), and servers ought not be obliged to attempt to provide it (be conservative in what they send during replication). I'm so glad we ducked this converation at the meeting... I could see this conversation coming from a mile off. I've completed a review of the requirements document from the perspective of the information model and architecture documents, and will post my results later this week. Ed >>> "Timothy Hahn" 03/27/01 05:15AM >>> Steven, I agree that it seems there is a need to clarify this requirement. I think that it may be interpreted differently. If this is the intent (i.e. leave it intentionally vague - perhaps to allow for lattitude in implementations?) then so be it. If the intent is to make something more clear, then the requirement should be clarified/explained in more detail. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 "Steven Legg" Sent by: owner-ietf-ldup@mail.imc.org 03/27/2001 02:30 AM Please respond to steven.legg To: "'Richard V Huber'" , cc: Ellen Stokes/Tivoli Systems@Tivoli Systems, , Subject: RE: New LDUP requirements draft Rick, et al, > -We feel that discussion of propagating end state vs. changes is about > implementation. Rather, P6 (now P7 due to other changes) has been > rewritten to explicitly require propagation of atomicity of LDAP > operations as defined in RFC 2251. We feel it is now self justifying. I don't know how I should interpret the new P7 requirement, reproduced immediately below. > P7. The protocol MUST preserve atomicity of LDAP operations as defined > in RFC2251 [RFC2251]. The wording is the same in draft-ietf-ldup-replica-req-07.txt and draft-ietf-ldup-replica-req-08.txt. At face value P7 could be interpreted as requiring a previously accepted update to be rejected during replication processing if any part of the update, e.g. a single modification in a modify request, is not performed because it is redundant, e.g. it attempts to insert a value that already exists, or has been superseded, e.g. a more recent update deleted the value. This interpretation is at odds with other sections of the requirements document, contrary to the author's position as I understood it, and contrary to the working group consensus, so P7 must mean something else. What exactly is P7 requiring of the LDUP protocol ? Regards, Steven ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Wed Mar 28 13:56:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07781 for ; Wed, 28 Mar 2001 13:56:41 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA21253 for ietf-ldup-bks; Wed, 28 Mar 2001 10:25:10 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA21249 for ; Wed, 28 Mar 2001 10:25:09 -0800 (PST) Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f2SIQRD73282; Wed, 28 Mar 2001 18:26:27 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010328100331.01f5c180@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 28 Mar 2001 10:21:55 -0800 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: RE: New LDUP requirements draft Cc: , , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:22 AM 3/28/01 -0700, Ed Reed wrote: >This requirement is there, I believe, to placate Albert. it placated me as well. :-) I believe it critical that the replication system be capable of detecting and reporting operations which would were guaranteed to fail in the X.500 data and service model. In particular, if two clients independently request (in a single modify) "Delete value X, Add value Y" to the same attribute (which has value X) of the same entry and the directory system only one can succeed (per existing LDAP/X.500 specification). However, in face of multiple-master replication (with less than model 1 consistency between masters), both could succeed (if issued on different masters). As there are existing applications which make use of the atomic properties of LDAP/X.500, it is critical that if conflicts were to arise in a deployment, the system should be capable of notifying the administrator of the conflict. I concur with Ed in that this requirement would rule out state-based replication designs. I disagree that the requirement should be stricken. Kurt From owner-ietf-ldup@mail.imc.org Wed Mar 28 14:11:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08380 for ; Wed, 28 Mar 2001 14:11:38 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA21629 for ietf-ldup-bks; Wed, 28 Mar 2001 10:38:52 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA21625 for ; Wed, 28 Mar 2001 10:38:51 -0800 (PST) Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f2SIeDD73352; Wed, 28 Mar 2001 18:40:13 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010328103101.01f61b90@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 28 Mar 2001 10:35:40 -0800 To: "Paul Leach" From: "Kurt D. Zeilenga" Subject: RE: Access Control, Administrative Areas, Replication and Distribution Cc: , , In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657406005BE6@DF-BOWWOW.platinu m.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 06:02 PM 3/26/01 -0800, Paul Leach wrote: >The "fundamental" flaw is that Active Directory is loosely >consistent. > >BTW: the fix to this "security flaw" was to make the unit of replication >finer grained. No "funadamental" redesign was needed. I don't see how making replication finer grained removes the "fundamental" flaw, "loose consistency" between masters. Kurt From owner-ietf-ldup@mail.imc.org Wed Mar 28 14:42:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09550 for ; Wed, 28 Mar 2001 14:42:49 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA22500 for ietf-ldup-bks; Wed, 28 Mar 2001 10:57:12 -0800 (PST) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA22493 for ; Wed, 28 Mar 2001 10:57:11 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Wed, 28 Mar 2001 10:57:58 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 28 Mar 2001 10:58:10 -0800 (Pacific Standard Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 28 Mar 2001 10:58:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4678.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Access Control, Administrative Areas, Replication and Distribution Date: Wed, 28 Mar 2001 10:57:28 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657406005C19@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: Access Control, Administrative Areas, Replication and Distribution Thread-Index: AcC3tv8owm/MaK8NTD+Lm7V/joaRmQAAJRhw From: "Paul Leach" To: "Kurt D. Zeilenga" Cc: , , X-OriginalArrivalTime: 28 Mar 2001 18:58:10.0398 (UTC) FILETIME=[086407E0:01C0B7B9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id KAA22494 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I didn't say it removed the "fundamental" flaw, just the "security flaw". The "security flaw" was that updates to objects that were really a collection of finer grained objects were getting lost. Scenario: Big object X is composed of set of small objects {A, B, C, ...} User 1 changes X to {A', B, C, ...} User 2 changes X to {A, B', C, ...} before user 1's changes get to him. Whichever one wins the conflict resolution, the other one's change is lost. These are "false conflicts", analagous to "false sharing" in DSM systems. If instead, A, B, C, were individually replicatable objects, then this wouldn't happen. Only conflicts on individual items would be subject to conflict. That's intrinsic. Users just didn't expect the updates to X to get lost -- X in this case was a group of users, and they were operating on _different_ users, so they expected it to work. > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Wednesday, March 28, 2001 10:36 AM > To: Paul Leach > Cc: Albert.Langer@directory-designs.org; ietf-ldup@imc.org; > ietf-ldapext@netscape.com > Subject: RE: Access Control, Administrative Areas, > Replication and Distribution > > > At 06:02 PM 3/26/01 -0800, Paul Leach wrote: > >The "fundamental" flaw is that Active Directory is loosely > consistent. > > > >BTW: the fix to this "security flaw" was to make the unit of > >replication finer grained. No "funadamental" redesign was needed. > > I don't see how making replication finer grained removes > the "fundamental" flaw, "loose consistency" between masters. > > Kurt > > From owner-ietf-ldup@mail.imc.org Wed Mar 28 15:11:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10158 for ; Wed, 28 Mar 2001 15:11:05 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id KAA21658 for ietf-ldup-bks; Wed, 28 Mar 2001 10:40:08 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA21654 for ; Wed, 28 Mar 2001 10:40:07 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA90478 for ; Wed, 28 Mar 2001 13:38:49 -0500 Received: from d01mlc96.pok.ibm.com (d01mlc96.pok.ibm.com [9.117.250.33]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id NAA131822 for ; Wed, 28 Mar 2001 13:35:44 -0500 To: ietf-ldup@imc.org Subject: RE: New LDUP requirements draft X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 From: "Timothy Hahn" Message-ID: Date: Wed, 28 Mar 2001 13:40:07 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V507_03012001.dev00 |March 9, 2001) at 03/28/2001 01:40:07 PM, Serialize complete at 03/28/2001 01:40:07 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 006571B085256A1D_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 006571B085256A1D_= Content-Type: text/plain; charset="us-ascii" Yes, the requirement does represent something of a problem now. I think that for the LDUP WG to do "due diligence", the requirement must either be removed (no concensus on what the requirement means), or the requirement must be clarified (so we all know what it means - whether or not we agree with). Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 --=_alternative 006571B085256A1D_= Content-Type: text/html; charset="us-ascii"
Yes, the requirement does represent something of a problem now.

I think that for the LDUP WG to do "due diligence", the
requirement must either be removed (no concensus on what the requirement
means), or the requirement must be clarified (so we all know what it means -
whether or not we agree with).
Regards,
Tim Hahn

Internet: hahnt@us.ibm.com
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681
 --=_alternative 006571B085256A1D_=-- From owner-ietf-ldup@mail.imc.org Wed Mar 28 16:50:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13036 for ; Wed, 28 Mar 2001 16:50:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA00873 for ietf-ldup-bks; Wed, 28 Mar 2001 13:13:03 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA00865 for ; Wed, 28 Mar 2001 13:13:01 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA91422 for ; Wed, 28 Mar 2001 16:11:45 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.5.39.28]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id QAA135072 for ; Wed, 28 Mar 2001 16:08:39 -0500 Importance: Normal Subject: operations that cross areas of replication To: "ldup mailing list" X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "John McMeeking" Date: Wed, 28 Mar 2001 15:13:19 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 5.0.6a |January 17, 2001) at 03/28/2001 03:13:19 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At the last IETF LDAP WG I raised a question about how a given server knows what the bounds of an area of replication are, and how LDUP should behave in cases where an operation crosses those boundaries. Any given server may not know what other areas of replication exist (the boundaries) and thus a client could do things like create an entry that conflicted with the root of another area of replication on another server, or delete the parent of an area of replication. These can result in areas of replication getting renamed, moved into lost and found, etc., when replicated, which seemed undesirable. I have a possible solution for this problem. First, to restate the problem[s]: If an area of replication has nested areas of replication, and a given replica contains the parent area of replication, but does not contain all of the nested areas, that replica does not know the bounds of the area of replication. This can give rise to situations where a client does something on that replica that affects the other areas of replication. There are two variants of this problem: 1. There is no server which contains both the parent and child areas of replication. 2. The parent area of replication is present on at least one server that also contains the nested areas of replication. In some sense both of these are "broke" without replication. A DIT that has been distributed across servers ought to have within it knowledge of the entire DIT. One approach to this problem is to define referrals representing the roots of the areas of replication that are not present on a server. In variant 1, this can be accomplished by an administrator creating the appropriate referral entries to link the directories/DIT. Variant 2 cannot be addressed in quite this fashion; there would exist two conflicting definitions of the areas of replication root entries which could be replicated to the same servers; one entry being the true entry, the other entry being a referral. A related question is whether LDUP supports (should support?) renaming entries which are roots or parents of areas of replication. I do not believe that LDUP can handle this situation properly in all circumstances. LDUP replication identifies the root of the area of replication as part of the StartReplicationRequest operation. If an area of replication is renamed, what DN should be specified? The new name will not be recognized by other replicas, which suggests the old name be used. In the face of both supplier and consumer initiated replication, it implies that any server that has received the change must be able to handle replication under either name for some period of time. This is not unsolvable by any means, but I think it would be much cleaner to disallow any operation which has the effect of renaming an area of replication, moving it into lost and found, etc.. Here is the solution I propose: If a server has knowledge of nested areas of replication that are not present on that server, it can behave appropriately, by failing a client a request that might otherwise have been allowed, returning a referral, etc.. Any one server has knowledge of all areas of replication present on that server. Suppose we define an operational attribute of the replicaSubEntry objectclass, areasOfReplication, that identifies the areas of replication present on that server. This operational attribute is replicated to other servers via LDUP (replicaSubentry is replicated?). Every server that has a replica of a given area of replication thus has knowledge of all other areas of replication in the replica group. A server can now fail or refer operations which reference non-present areas of replication: add, delete, and modRdn/Dn operations fail, search or modify operations can return a referral. CSNs for this operational attribute are generated like any other CSN based on the addition or removal of areas of replication, with the possible restriction that this be replicated as delete attribute/add attribute value primitive pair, similar to a modify-replace. The attribute may have to be replicated each time a server is started; if a server is restored to an ealier state, assuming the clock is set properly, this will ensure that other servers are properly informed. By way of example: DIT: AR1 | --------------- | | AR2 AR3 | AR4 Servers and replicas they hold: S1: AR1, AR2, and AR3 S2: AR1, AR2 S3: AR3, AR4 replicaSubEntries would have the following "otherAreasOfReplication" values: naming convention: Sx-ARy = replica subentry for server x in area of replication y DN: S1-AR1,-AR2,-AR3 areasOfReplication: AR1 AR2 AR3 DN: S2-AR1,2 areasOfReplication: AR1 AR2 DN: S3-AR3,4 areasOfReplication: AR3 AR4 - S1 knows about AR1,2,3 since they are present on the server. From S2-AR3 it learns about AR4. - S2 knows about AR1,2 since they are present on the server. From S1-AR1 (or AR2) it learns about AR3 and 4. - S3 knows about AR3,4 since they are present on the server. From S1-AR3 it learns about AR1 and 2. This allows a server to learn what other areas of replication are "reachable" via replication of a area of replication present on that server. It is done automatically via LDUP. No administrative action is required to set this up or ensure that referrals remain correct as replicas and areas of replication are added and removed. Also, using this attribute to populate the root DSE altServer attribute would be helpful to a replication management app, or to clients that need to direct all requests to one server (it might be able to find one). The server could use the areasOfReplication information to generate better referrals. John McMeeking, IBM OS/400 Directory Services jmcmeek@us.ibm.com From owner-ietf-ldup@mail.imc.org Wed Mar 28 20:02:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16104 for ; Wed, 28 Mar 2001 20:02:27 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id QAA14658 for ietf-ldup-bks; Wed, 28 Mar 2001 16:30:01 -0800 (PST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA14649 for ; Wed, 28 Mar 2001 16:29:58 -0800 (PST) Received: from qsun.mt.att.com ([135.16.30.2]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f2T0TQ717115; Wed, 28 Mar 2001 19:29:27 -0500 (EST) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id TAA27435; Wed, 28 Mar 2001 19:29:25 -0500 Date: Wed, 28 Mar 2001 19:29:25 -0500 Message-Id: <200103290029.TAA27435@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: ietf-ldup@imc.org Subject: RE: New LDUP requirements draft Cc: estokes@tivoli.com, rmoats@coreon.net, rweiser@digsigtrust.com Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This started out as a reply to Steven Legg's message, but I guess it is now also a reply to Tim Hahn, Ed Reed, and Kurt Zeilenga. P7 is a protocol requirement. The change between previous drafts and draft -07 was to make it clearer what atomicity information has to be carried by the protocol. I don't think this clarification makes it inconsistent with other parts of the document. Requirements MM5 and MM6 address what happens when conflicts arise in multi-master replication that cannot be resolved by the normal conflict resolution mechanism and would thus cause data loss: MM5. Multi-master replication MUST NOT lose information during replication. If conflict resolution would result in the loss of directory information, the replication process MUST store that information, notify the administrator of the nature of the conflict and the information that was lost, and provide a mechanism for possible override by the administrator. MM6. Multi-master replication MUST support convergence of the values of attributes and entries. Convergence may result in an event as described in MM5. So P7 talks about what atomicity information the LDUP protocol must carry; MM5 and MM6 talk about what happens when you get an "unresolvable" conflict. I think they are mutually consistent. Rick Huber : From: "Steven Legg" : To: "'Richard V Huber'" , : Cc: , , : Subject: RE: New LDUP requirements draft : : Rick, et al, : : > -We feel that discussion of propagating end state vs. changes is about : > implementation. Rather, P6 (now P7 due to other changes) has been : > rewritten to explicitly require propagation of atomicity of LDAP : > operations as defined in RFC 2251. We feel it is now self justifying. : : I don't know how I should interpret the new P7 requirement, reproduced : immediately below. : : > P7. The protocol MUST preserve atomicity of LDAP operations as defined : > in RFC2251 [RFC2251]. : : The wording is the same in draft-ietf-ldup-replica-req-07.txt and : draft-ietf-ldup-replica-req-08.txt. : : At face value P7 could be interpreted as requiring a previously accepted : update to be rejected during replication processing if any part of the : update, e.g. a single modification in a modify request, is not performed : because it is redundant, e.g. it attempts to insert a value that already : exists, or has been superseded, e.g. a more recent update deleted the : value. : : This interpretation is at odds with other sections of the requirements : document, contrary to the author's position as I understood it, and : contrary to the working group consensus, so P7 must mean something else. : : What exactly is P7 requiring of the LDUP protocol ? : : Regards, : Steven From owner-ietf-ldup@mail.imc.org Wed Mar 28 20:40:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16626 for ; Wed, 28 Mar 2001 20:40:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA15223 for ietf-ldup-bks; Wed, 28 Mar 2001 16:41:24 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id QAA15219 for ; Wed, 28 Mar 2001 16:41:22 -0800 (PST) Received: (qmail 18498 invoked from network); 29 Mar 2001 00:40:52 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 29 Mar 2001 00:40:52 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Ed Reed'" , , Cc: , Subject: RE: New LDUP requirements draft Date: Thu, 29 Mar 2001 10:19:26 +1000 Message-ID: <000101c0b7e9$75451ae0$6628a8c0@nowhere.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id QAA15223 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA16626 [Ed] Hahahaha...hahaha...haha... This requirement is there, I believe, to placate Albert. [Albert] The proposed requirement is there because the requirements editors have proposed it. They have certainly made no attempt to placate me concerning the meaningless requirements to support ACID transactions and eventual divergence, so I doubt that they are unduly concerned about placating me ;-) I fully agree with all of the following included in the original messages you are responding to: a) Tim's view that it needs to be explained and justified (whether in the requirements document or elsewhere). b) Steven's view that it is contrary to what was previously understood to be the prevailing view in the WG and cannot be regarded as indicating any kind of consensus on that proposal. Ed, you chose not to respond further after initiating this discussion yourself during the last WG call and indicating in email that you would be doing so. http://www.imc.org/ietf-ldup/mail-archive/msg00855.html http://www.imc.org/ietf-ldup/mail-archive/msg00873.html You of all people should have seen it coming. Like it or not any decision either way will have to be thoroughly justified to the WG in technical discussion on this list - and very likely in I-Ds if disagreement continues at IETF final call. If it had not come up as a result of WG last call, it would have come up at IETF last call. Somebody is going to have present arguments for the current conflict resolution approach in the architecture that will withstand careful IETF scrutiny. Judging from Steven's remark so far that "it must mean something else", it looks like that person may have to be you. Please put aside anything else and focus entirely on those arguments. You aren't going to get past IETF final call with either "it must mean something else" or "Hahahaha...hahaha...haha..." etc. This is your chance to polish up the arguments - *now*. [Ed] I believe the requirement MAY be satisfied IFF log-based replication is used to retransmit the update via LDUP as long as no one else has gotten to the modified entry first via an update to some other master (i.e, as long as there are no conflicting collisions). If there are conflicting updates, I think the result that Albert would like to see is that the update that collides is bounced in some way for administrative resolution. [Albert] The definition of atomicity is that an operation either succeeds or fails as a whole. There is a clear separate requirement which has been there since September last year that if any directory information is lost as a result of conflict resolution there must be administrative notification. If you are opposed to that requirement you should have said so then, and should say so now, and should do so without attributing to me views opposite to those I have repeatedly stated. My view is that it is sufficient in the requirements document to only require administrative notification only because that is enough to be able to move on and start actually reviewing the architecture. It ensures that any architecture which actually meets the requirement will be capable of being extended to support notification to whoever is responsible for the DUA that changed whatever got "bounced" (eg by email and/or LCUP). However I do not believe administrative notification is sufficient even for create/rename conflicts and have already put on record that I will oppose at IETF final call any architecture that does not actually implement direct notification of any loss of directory information arising out of multi-master replication that would not have occurred with single master. My reasons are: a) Multi-master will be deployed alongside single master in a developing global internet (not "enterprise") directory service specifically designed to present a uniform "Directory Information Tree" in which applications do not need to know much about the specific servers they are using provided they are LDAP servers, and are routinely given referrals to other servers that they have no previous knowledge of. Applications already deployed to expect the behaviour of single master (immediate failure response for operations that fail), will break when referred to servers that do not support the existing behaviour. Unexpected behaviour cannot be avoided with multi-master, but everything possible must be done to minimize any negative effects while obtaining the positive benefits. Prompt notification as soon as possible after the unexpected event is both the most and the least we can do, so as an IETF WG concerned with global internet standardization we have an obligation to do it. Standards are about *squelching* ideas that hinder interoperability, not about endorsing vendors bad ideas. b) Multi-master is unsuitable in situations where update conflicts frequently occur within the period for propagation of updates across the replication network. As well as you having explicitly agreed with that, nobody has so far expressed any continuing disagreement, so I believe it is safe to assume there is a consensus on that unless somebody speaks up now. (Though it would probably be useful to document an explanation of why, as there is obvious confusion about many such issues). Consequently any architecture that can support the long standing proposed requirement for administrative notification will not be greatly burdened by adding support for direct notification to DUAs. The minimum just needs some work on the information model to specify that the originator DSA of a change that "bounced" is responsible for promptly informing the email address listed for the DN of the DUA that was the creator or modifier of the lost information, plus a format for such messages. Further extensions may be desirable, but that's the minimum and it's no big deal. c) Even a very low rate of lost directory information is completely inappropriate for manual resolution by administrators. They aren't the sources of the data and would either have to ignore the notifications or contact the users concerned to fix the problem. Directory administration is being delegated downwards to end users with no technical knowledge, and to automated applications, as rapidly as possible and DSA or DMD administrators have more important things to do than fix broken protocols manually. If you disagree with that perspective it would be helpful if you presented your arguments about it at the same time as this atomicity discussion as the two are closely related and will both end up having to be discussed during architecture review and/or IETF final call. [Ed] For state-based replication the requirement is meaningless, since state-based replication has as its goal to make all the replicas hold the same values, and it never pretends to try to reproduce the operations which were entered to get them to that state - it doesn't care, because it is the ultimate state that is important. [Albert] There is a clear requirement for eventual convergence which nobody has dissented from and can be assumed to be a consensus. Assuming that you are not suggesting that atomic replication cannot support eventual convergence, there is no technical content in the above paragraph. There is no proposed requirement that we use a state-based replication scheme. If you think there should be such a requirement you should have proposed it two years ago rather than designing an architecture before signing off on requirements and you should propose it now since it simply isn't there. [Ed] Believers in state-based replication believe the end justifies whatever means are necessary to achieve a common view of the data. Believers in log-based replication think getting there is most of the fun. [Albert] There is no technical content in that paragraph whatever, with or without any plausible assumption about what you may or may nor believe. I do not find a "belief" that the "end justifies whatever means are necessary" an appealing philosophy. The issue is what is the end and what means are necessary. Figuring out where we want to go and how to get there can indeed be fun. [Ed] Thus, my long-held belief that it MAY BE possible to replicate transactional semantics of some sort via log-based replication schemes (who can record and playback the transactions in question), but it will NEVER be possible to do so with state-based replication schemes. [Albert] As part of this discussion I believe it would be very useful both for LDUP work and possible publication for the benefit of users to reach a common understanding of terminology and publish that as soon as possible as an I-D. The current discusison is about requirement P7, not about "transactional semantics". P7. The protocol MUST preserve atomicity of LDAP operations as defined in RFC2251 [RFC2251]. Are you saying above that "it will NEVER be possible" to comply with P7 "with state-based replication schemes"? If so: 1. You were a co-author of the first architecture draft (00), dated 1 August 1998 and submitted prior to the WG charter being approved. That draft included the following provisions: 3.2 Document Objectives [...] c) To preserve the atomicity of LDAP operations. Updates to an entry, from multiple sources, will be combined such that the resultant entry is equivalent to a serial execution of the operations. 8.2.2 Incremental Update Transfer [...] Each individual change may contain a sequence of entry modifications that must be preserved when transferred. The atomicity of the LDAP operation must be preserved when it is applied to the Consumer Replica. http://www.imc.org/ietf-ldup/mail-archive/msg00138.html 1. Did you believe then that the objective and specification you proposed was: 1.1 Desirable. 1.2 Required in order to comply with LDAP standards and obtain a charter for the LDUP WG? 1.3 "NEVER be possible to do so with state-based replication schemes" 2. Was any technical explanation published when you decided to remove these from the architecture draft? If so, please provide the URL. 3. What is the protocol distinction relevant to IETF standardization of the "on the wire" protocol, between the term "state-based" replication scheme and the term "non-atomic" replication scheme? Does a "state-based" replication scheme have some other feature that distinguishes it from a replication scheme capable of complying with P7 and RFC 2251? 3.1 What are the technical benefits of a "state-based" replication scheme that would justify not preserving the atomicity of LDAP operations as defined in RFC2251? (In other words, why should the IETF care about whether a "state-based" scheme could comply, as opposed to a vendor proposing a "state-based" scheme caring?) 3.2 Are "state based", ie non-atomic, replication schemes capable of reliably supporting an access control standard similar to either: a) The current LDAP-EXT draft. b) The X.500 standards c) Any non-proprietary widely used approach to access control such as those derived from UMich implementations? 3.3 What are the consequences for deployment of LDAP and X.500 applications across the global internet with DSAs passing referrals to other DSAs, some of which support atomic operations when others do not? 3.4 Should RFC 2251 be altered to remove the requirement for atomic operations? 3.5 Should similar changes be made to the X.500 international standards? 3.6 Has anyone proposed any such changes? These are questions which should all have been addressed when LDUP first considered adopting a non-atomic replication scheme and must be addressed now. It is up to you to address them. Please do so - *now*. 4. Do you agree with the proposed requirements then numbered P6, and MM5 and MM6 (unchanged) and the definitions that have been in previous drafts since September last year: vvvvvvvvvvvvvvvv Atomic operation - A set of changes to directory data which the LDAP standards guarantee will be treated as a unit; all changes will be made or all the changes will fail. Atomicity Information - Information about atomic operations passed as part of replication. Conflict - A situation that arises when changes are made to the same directory data on different directory servers before replication can synchronize the data on the servers. When the servers do synchronize, they have inconsistent data - a conflict. Conflict resolution - Deterministic procedures used to resolve change information conflicts that may arise during replication. Update Propagation - Protocol-based process by which directory replicas are reconciled. P6. The protocol MUST support propagation of atomicity information. MM5. Multi-master replication MUST NOT lose information during replication. If conflict resolution would result in the loss of directory information, the replication process MUST store that information, notify the administrator of the nature of the conflict and the information that was lost, and provide a mechanism for possible override by the administrator. MM6. Multi-master replication MUST support convergence of the values of attributes and objects. Convergence may result in an event as described in MM5. ^^^^^^^^^^^^^^^^^^^^^ 4.1 If you support the above, how could a "state-based" implementation support the propagation of information about atomic operations required in order to store directory information that would otherwise be lost, notify administrators and provide an overide mechanism, if it is not also able to "preserve atomicity of LDAP operations as defined in RFC2251". In particular why is it both possible and desirable to do so for create and rename conflicts handled atomically by "state-based" implementations but either not possible and/or not desirable to do so for other conflicts as specified in the LDAP standards? 4.2 If you do not agree with those requirements and definitions, why did you as an author of the architecture draft, not raise any objection to them in the last six months during which they went through revisions 04, 05, 06 and 07 before reaching the purely editorial corrections announced for 08? 4.3 Do you now agree with my view that those requirements did not clearly enough resolve an issue that must be resolved, one way or another? [Ed] I would strike the requirement, as I don't think its either useful or interesting to the class of applications for which I expect LDUP to be used for - distributed administration of policy information. [Albert] What is there about distributed administration of policy information that makes preservation of atomic operations less useful for that class of applications than for other applications envisaged by the X.500 and LDAP standards in imposing that requirement on DSAs? In the earlier discussion at the first two URLs above, you quoted my statement: "My view is that the critically important requirement that applications depend on is simply that a change can be reliably made to exactly the entry you thought you were changing and not result in some mixture of updates combined with unknown concurrent changes by some other application." You agreed that this was "the crux of the matter" in rejecting that view. You have not responded to my reply and I cannot even imagine why you would think that administration of policy information (eg access control information) is *less* dependent than other applications on being able to reliably change exactly what you thought you were changing rather than implementing a "policy" based on a combination with unknown concurrent changes. [Ed] There are other applications, which require the behavior specified in this requirement in order to provide a test- and-set form of operation which I do not believe LDUP will ever adequately support. At least not with the protocol mechanism as we've attempted to define it so far. [Albert] What specifically are those other applications and why do you think the X.500 standards and the LDAP standards made provision for their needs? [Ed] I honestly believe that the most useful protocol for us to define at the moment is one that interleaves non-conflicting attribute value changes occuring to an entry at various master replicas in such a way that when all the replicas have received the modifications from all the other replicas, they all present the same entry to readers. [Albert] There nothing in the technical part of the above paragraph that is either inconsistent with P7 or not completely covered by: M3. An attribute in an entry must eventually converge to the same set of values in every replica holding that entry. I will not form an opinion about the non-technical part of this paragraph until after I have carefully studied your response to all my questions above. If you stick to relevant technical arguments from now on I will respond to those arguments on their merits regardless of what opinion I may form as to matters that are now in the past. We have a job to do and it must be done on the basis of the WG as a whole fully understanding the technical issues, and reaching a "rough consensus", which may well include strong disagreements, but must be based on a common understanding of the issues being resolved. That cannot be based on discussion of what anybody believes about "non-conflicting attribute value changes" or "eventually converging to the same set of values", or how honestly they believe it. [Ed] The only way to achieve that is to share administration of attributes "liberally", and to restrict consistency requirements only on those attributes that are effectively "private" to the application that has the requirement for special consistency. So my interpretation of the "be liberal in what you accept and conservative in what you send" is that applications ought not expect atomic in-sequence application of modification operations to propagate via replication (be liberal in what they accept from the server), and servers ought not be obliged to attempt to provide it (be conservative in what they send during replication). [Albert] I do not understand these two paragraphs at all. Please elaborate. My view is that multi-master replication with "eventual convergence" necessarily requires absolutely identical behaviour - both as to what is received and as to what is sent, by all DSAs holding a replica. Therefore I do not regard the well known architectural principal of "be liberal in what you accept and conservative in what you send" as being applicable to LDUP work. If it is applicable, I simply do not understand what you are getting at in your application of it. [Ed] I'm so glad we ducked this converation at the meeting... I could see this conversation coming from a mile off. [Albert] I too am glad that we are now having a technical discussion on these issues in the WG mailing list. I was much further away and saw it coming much earlier. "Hahahaha...hahaha...haha..." Sorry, couldn't resist ;-) [Ed] I've completed a review of the requirements document from the perspective of the information model and architecture documents, and will post my results later this week. [Albert] Looking forward to it. It would also be helpful if Steven and Alison were now to follow up on the following item from the minutes of the Adelaide IETF WG session a year ago: vvvvv 7) LDUP Update Reconciliation Procedures (Steven) file: draft-ietf-ldup-urp-02.txt This draft did seem ready for last call, but now we may need to reconsider it given Mr. Langer’s alternate proposal. The authors are looking at making a future revision to accommodate the updating of partial replicas. Steven and Alison point out that the main difference between URP and other approaches is whether conflicts are merged or resolved immediately. Steven and Alison also note that this subject keeps coming up. Therefore, Steven and Alison have volunteered to write up a new document that describes why URP ended up the way it did. The working group members that that this was a good idea, and Patrick OKed it. Chairs to revise the charter and send to list. ^^^^^ There is no need to revise the charter in order to submit an ID explaining issues under discussion and following up on that would be far more useful than Steve's statement below that "it must mean something else". The subject did keep coming up in the previous year, has continued to keep coming up in the year since and should now be settled through the IETF process of open and fair technical discussion. Alison posted a valuable "Contribution to Profiles Document (Consistency Discussion)" which does explain some of the consequences of the URP approach to multi-master replication and should be included together with the explanation of why URP ended up the way it did. http://www.imc.org/ietf-ldup/mail-archive/msg00548.html The Word version with properly formatted tables is at: http://www.imc.org/ietf-ldup/mail-archive/doc00000.doc It was never discussed and should be discussed now. (Remainder below is the originals Ed was responding to). >>> "Timothy Hahn" 03/27/01 05:15AM >>> Steven, I agree that it seems there is a need to clarify this requirement. I think that it may be interpreted differently. If this is the intent (i.e. leave it intentionally vague - perhaps to allow for lattitude in implementations?) then so be it. If the intent is to make something more clear, then the requirement should be clarified/explained in more detail. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT) phone: 607.752.6388 tie-line: 8/852.6388 fax: 607.752.3681 "Steven Legg" Sent by: owner-ietf-ldup@mail.imc.org 03/27/2001 02:30 AM Please respond to steven.legg To: "'Richard V Huber'" , cc: Ellen Stokes/Tivoli Systems@Tivoli Systems, , Subject: RE: New LDUP requirements draft Rick, et al, > -We feel that discussion of propagating end state vs. changes is about > implementation. Rather, P6 (now P7 due to other changes) has been > rewritten to explicitly require propagation of atomicity of LDAP > operations as defined in RFC 2251. We feel it is now self justifying. I don't know how I should interpret the new P7 requirement, reproduced immediately below. > P7. The protocol MUST preserve atomicity of LDAP operations as defined > in RFC2251 [RFC2251]. The wording is the same in draft-ietf-ldup-replica-req-07.txt and draft-ietf-ldup-replica-req-08.txt. At face value P7 could be interpreted as requiring a previously accepted update to be rejected during replication processing if any part of the update, e.g. a single modification in a modify request, is not performed because it is redundant, e.g. it attempts to insert a value that already exists, or has been superseded, e.g. a more recent update deleted the value. This interpretation is at odds with other sections of the requirements document, contrary to the author's position as I understood it, and contrary to the working group consensus, so P7 must mean something else. What exactly is P7 requiring of the LDUP protocol ? Regards, Steven ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From owner-ietf-ldup@mail.imc.org Thu Mar 29 03:30:35 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24994 for ; Thu, 29 Mar 2001 03:30:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id XAA14510 for ietf-ldup-bks; Wed, 28 Mar 2001 23:46:06 -0800 (PST) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.9.3/8.9.3) with SMTP id XAA14491 for ; Wed, 28 Mar 2001 23:46:02 -0800 (PST) Received: (qmail 32685 invoked from network); 29 Mar 2001 07:49:32 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 29 Mar 2001 07:49:32 -0000 Reply-To: From: "Steven Legg" To: "'Ed Reed'" Cc: Subject: Conflict Detection within the Current Architecture, was RE: New LDUP requirements draft Date: Thu, 29 Mar 2001 17:47:24 +1000 Message-ID: <000001c0b824$7f388d80$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ed, > I believe the requirement MAY be satisfied IFF log-based replication > is used to retransmit the update via LDUP as long as no one else > has gotten to the modified entry first via an update to some other > master (i.e, as long as there are no conflicting collisions). > If there > are conflicting updates, I think the result that Albert would like to > see is that the update that collides is bounced in some way for > administrative resolution. > > For state-based replication the requirement is meaningless, since > state-based replication has as its goal to make all the replicas > hold the same values, and it never pretends to try to reproduce > the operations which were entered to get them to that state - > it doesn't care, because it is the ultimate state that is important. > > Believers in state-based replication believe the end justifies > whatever means are necessary to achieve a common view > of the data. Believers in log-based replication think getting > there is most of the fun. > > Thus, my long-held belief that it MAY BE possible to replicate > transactional semantics of some sort via log-based replication > schemes (who can record and playback the transactions > in question), but it will NEVER be possible to do so with > state-based replication schemes. I thought about this today and I think I've found a relatively painless way to add atomicity information and conflict detection to LDUP that is friendly to state-based implementations. The conflict detection scheme I'm about to describe relies on comparing the before and after states of entries being updated. Updates on a single master will produce a neat sequence where the after state of one update matches the before state of the next update in the sequence. In the multimaster case, there will be some updates that share the same before state and some updates whose before states reflect different incomplete sequences of updates. These are the updates in conflict. The before state of an update is described by a start vector, which is a set of CSNs that is formed by looking at the CSNs on the contents of the entry being modified. The highest CSN for each replica ID is retained in the start vector. I started out by just copying the current update vector but this approach produces more false positive indications of conflicts. The after state of an update is described by an end vector that is formed in the same way as the start vector, except it looks at the entry after the update has been performed. I'll collectively refer to start and end vectors as state vectors. A state vector SV1 "covers" another state vector SV2 if the CSN in SV1 for each replica ID is greater than or equal to the CSN for the same replica ID in SV2. The start vector tells us what updates have been applied prior to the update of interest, i.e. the previous updates that are "seen". Two updates are in conflict if neither of them completely sees the after state of the other. More precisely, two updates U1 and U2 are not in conflict if and only if the start vector for U1 covers the end vector for U2 or the start vector for U2 covers the end vector for U1. If the start vector for U2 covers the end vector for U1 then U2 "sees" the entry after U1 has been performed, and therefore logically follows U1 and there is no conflict. Similarly for the reverse case. In the simplest cases, two updates are in conflict if they modify the same entry "simultaneously" at different replicas, without regard to what they are actually doing to the entry. Consequently, some of the detected conflicting updates might actually turn out to be independent changes to the same entry. Time for an example of conflict detection. Let's suppose there are two replicas R1 and R2, where everything is in a quiescent state. A state vector would actually use CSNs but it is sufficient for this example to just use the timestamp component. I'll represent a state vector as a tuple (x, y) where x is a timestamp (CSN) generated by R1 and y is a timestamp (CSN) generated by R2. At time t0, the state vector for the entry E is (t0,t0) at both replicas. Update U1 on entry E is performed at R1 at time t1. Thus the start vector for U1 is (t0,t0) and the end vector is (t1,t0). Simultaneously, update U2 is performed at R2. The start vector for U2 is also (t0,t0) and the end vector is (t0,t1). At time t2, U1 is propagated to R2. The effects of U1 and U2 are merged as described by URP giving a new state vector for E of (t1,t1). Update U3 on entry E is performed at R1 at time t3. The start vector for U3 is (t1,t0) and the end vector is (t3,t0). Update U4 on entry E is performed at R2 at time t3. The start vector for U4 is (t1,t1) and the end vector is (t1,t3). I'll summarize the start and end vectors to make this easier. start end U1: (t0,t0) -> (t1,t0) U2: (t0,t0) -> (t0,t1) U3: (t1,t0) -> (t3,t0) U4: (t1,t1) -> (t1,t3) Using the conflict detection rule above we come up with the following conflicts: U1 conflicts with U2. U2 conflicts with U1 and U3. U3 conflicts with U2 and U4. U4 conflicts with U3. Of particular note, U4 does not conflict with U1 or U2. It sees the merged output of these conflicting updates but that doesn't make it "conflicted" itself. We have to draw a line somewhere. To detect conflicts we need to propagate the start and end vectors of an update in the protocol, along with the UUID of the relevant entry. The end vector is just the start vector with the CSN for the originating replica replaced by the CSN for the update, so we can condense this to a single CSN, which also serves to uniquely identify the update. The start vector is a set of CSNs, like an update vector, but generally shorter since not all replicas will be represented by CSNs on the entry contents (because they've never made a change to the entry, or the CSNs on their changes have long since been purged, or these CSNs are now old enough to be purged). The CSN on the conflict detection information can be used in the same way as the CSN on a replication primitive to decide when the information needs to be propagated. Because the conflict detection information and the replication primitives for a specific update have the same CSN they will necessarily propagate around together. State-based implementations can still propagate only the net state change, i.e. they can omit superseded replication primitives, because no information from the primitives is being used to detect conflicts. The above provides enough information for any replica to detect every conflict. Given M replicas originating an average of N updates, that's roughly (M by N) squared comparisons. If we leave it up to the originating replica to test only for conflicts against its own updates the number of comparisons can be reduced to N squared by M. The scheme extends easily to accommodate grouped operations. All the replication primitives generated from the one set of grouped operations really need to have the same CSN (ignoring the least significant modification number component) so one CSN is still enough for the end vector. The start vector is generated by considering all the entries targeted by the grouped operations, instead of just one entry. Transactions can be similarly accommodated, though if searches are part of the transaction we should drop the UUID and test the vectors against updates for all entries when looking for conflicts. We can also tighten up the conflict detection by adding to the conflict detection information, lists of the attribute types the update reads and writes. If the read and write sets of two updates are mutually disjoint they can't be in conflict even if they modify the same entry at the same time Comments anyone ? Regards, Steven From owner-ietf-ldup@mail.imc.org Thu Mar 29 16:08:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10936 for ; Thu, 29 Mar 2001 16:08:06 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id MAA25806 for ietf-ldup-bks; Thu, 29 Mar 2001 12:32:44 -0800 (PST) Received: from hawk.ummail.com (hawk.ummail.com [216.33.108.234]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA25794 for ; Thu, 29 Mar 2001 12:32:41 -0800 (PST) Received: from ex01.ummail.com [216.33.108.253:25] by hawk.ummail.com with SMTP id K0329-1532-6aa700; Thu, 29 Mar 2001 20:32:20 GMT Received: by ex01.ummail.com with Internet Mail Service (5.5.2650.21) id ; Thu, 29 Mar 2001 15:29:48 -0500 Message-ID: From: Christopher Apple To: "'ietf-ldup@imc.org'" Subject: Co-Chair E-mail Address Change Date: Thu, 29 Mar 2001 15:29:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B88E.FF4B5DD0" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0B88E.FF4B5DD0 Content-Type: text/plain; charset="iso-8859-1" FYI. My new e-mail address is: christopher.apple@unitedmessaging.com A request has been made to change the WG Charter Page on the IETF Web Site to reflect this. Chris Apple. ------_=_NextPart_001_01C0B88E.FF4B5DD0 Content-Type: text/html; charset="iso-8859-1"

FYI. My new e-mail address is:
 
 
A request has been made to change the WG Charter Page on the IETF Web Site to
reflect this.
 
Chris Apple.
------_=_NextPart_001_01C0B88E.FF4B5DD0-- From owner-ietf-ldup@mail.imc.org Thu Mar 29 18:17:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17152 for ; Thu, 29 Mar 2001 18:17:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA01988 for ietf-ldup-bks; Thu, 29 Mar 2001 14:16:20 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA01984 for ; Thu, 29 Mar 2001 14:16:17 -0800 (PST) Received: (qmail 7293 invoked from network); 29 Mar 2001 22:15:47 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 29 Mar 2001 22:15:47 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: , "'Ed Reed'" Cc: Subject: RE: Conflict Detection within the Current Architecture, was RE: New LDUP requirements draft Date: Fri, 30 Mar 2001 08:19:58 +1000 Message-ID: <000d01c0b89e$6482a140$6628a8c0@nowhere.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <000001c0b824$7f388d80$b05508cb@osmium.adacel.com.au> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In response to Steve's request for comments: 1) The fact that Steve is now looking for a way to meet requirements is a major step forward, which I welcome. By offering his new idea he has at least confirmed that URP 03 currently lacks a "way to add atomicity information and conflict detection". 2) I have read the material below several times but do not understand it. 3) That is not surprising as it states clearly that Steve "thought about this today" (although the relevant requirements for "atomicity information and conflict detection" were present since 04 in September 2000 after a room consensus on that in June 2000). 4) Steve should now write an initial I-D giving a clear explanation of his new idea so that the WG can discuss it properly. Then a formal discussion should be opened, managed and concluded. We should not attempt to do that while it is in it's present form as it is clearly just initial thoughts about a new idea on the same day that the idea was thought of. 5) I was given 1 week to produce such an initial I-D when bringing up an alternative proposal a year ago. That was not unreasonable as it was then understood that the WG had settled on Steve and Alison's proposal after working for a year. It is now a year later and it is clear that the WG has not in fact even reached real consensus on requirements. So Steve should be given more time to do a presentable draft. He should also first do the draft explaining "why URP ended up the way it did" that he committed to a year ago. 6) I did a "necessarily half baked" proposal (MDCR) a year ago as required and it has still not been properly discussed, so I have let it expire. I am posting that to the WG list in my next message. 7) A facilitator should be appointed to conduct the necessary discussions in the list, insist on questions and arguments being answered, sum up issues outstanding etc etc, so that we actually converge on a decision rather than just exchanging and ignoring various "points". BTW for some insight into design issues, consider the problems of conflict resolution within LDUP WG itself in the absence of a functioning conflict resolution mechanism and accurate propagation of knowledge of what the current state actually is. The inevitable result has been periodic announcements that documents are "ready" when they are not, without actual progress towards getting them ready and much time lost ;-) 8) My preliminary view of what I can understand of Steve's idea is that it still appears to be based on a fundamental misconception that there exists some inherent total ordering of conflicting updates to an entry which can be approximated in some way by timestamps. In reality multi-master conflicts form a tree which is only partially ordered. I do not think it is *possible* to "add in" atomicity information and conflict detection as an afterthought to a replication scheme that was not designed for it from the ground up. Conflict detection is after all a necessary precondition for conflict resolution, which is the part of the architecture that URP was supposed to have been providing. Alarm bells should have gone off when it was renamed to "update reconciliation". I will nevertheless study Steve's proposal carefully when he presents it. Meanwhile, here's some points to think about. Once an initial version of an entry last changed at R0 has split into two versions R0.R1 and R0.R2 due to concurrent changes at different replicas R1 and R2, it can, and therefore will, sometimes split into further versions eg R0.R1.R3 and R0.R2.R4 as a result of both those versions being visible and available for DUAs to make further changes to until the conflict is resolved. Depending on replication links and schedules the original "stable" version R0 and the first two variations R0.R1 and R0.R2 may also all be visible at some replica at once. Each variation can be named by the series of replica Ids at which the change was made, starting from the original stable version. As shown in MDCR it is not necessary to store the entire path name, as the "version" number or depth in the tree, plus the previous and current replica Ids of the originator DSAs for the two most recent changes is sufficient in the report propagation protocol to maintain the links between conflicting versions in the tree. This only requires storing the previous replica Id and version number in the visible entry at each replica. But it is not possible to serialize operations without some means of maintaining the tree and it is not possible to maintain information about atomic operations or detect conflicts between them without a means for serializing the operations. I see no recognition of that in Steve's material below. Any partially ordered tree can be embedded in a total ordering, but a total ordering based on timestamps would simply be arbitrary. The problem to be solved is how to deal with the fact that each replica only has an incomplete knowledge of both the actual state of the tree and of the similar knowledge possessed by other replicas while the conflict remains unresolved. For atomicity and eventual convergence, the algorithm must result in each replica only making visible entries that represent the result of a serializable sequence of successful operations that have actually been performed by DUAs and must *not* make visible "transient states" arising from internal processing by the DSAs. Otherwise access control and other decisions would be based on those transient states intended by nobody and not on the intended policies. The unavoidable "loose consistency" inevitably results in changes that will ultimately not be converged to being initially reported as having been successfully made, and therefore results in further changes based on those changes sometimes being made. But it must never result in entry state that is not the result of a serializable sequence of changes made by some DUAs becoming visible at any DSA and it must be capable of generating notificatins when a DUA has been told that it's change was accepted but the change is eventually suppressed due to conflicts. A necessary precondition is that all replicas must eventually receive the same set of reports about all the conflicting changes. This precludes a design where changes are merged while being transitively replicated and only the merged changes based on incomplete knowledge of the conflict reported to other replicas. A separate report propagation layer is essential, as required by sound architectural principles anyway. Since multi-master is inherently unsuitable for any situation with a high rate of concurrent changes there is no significant increase in bandwidth as a result of forwarding all changes to all replicas. Not doing so "saves" transmission of precisely the information needed for conflict detection by discarding it on the way with different information discarded at different replicas along each path. For all replicas to eventually converge on the same visible entries they must all eventually select the same sequence. Therefore they must all keep track of the state of the entire tree while the conflict is being resolved. That is not a burden on implementations as the tree pointers only need about 12 bytes of RAM for each version until the conflict is resolved. Most of the conflict trees are trivial since multi-master is unsuitable for situations with a high rate of concurrent changes anyway. Using a total ordering based on 32 bit timestamps would just save about 8 bytes of RAM per unresolved conflicting change, at the expense of correct serialization of changes and therefore of any hope of maintaining atomicity information and detecting conflicts. 64 bit timestamps would only save 4 bytes of RAM. Version numbers are needed for correct serialization as recognized in all research on distributed concurrent changes. They also simplify and compress report propagation and tree storage by making it unnecessary to transmit and store the full path names of the variations or do complex calculations, let alone the O3 comparisons mentioned by Steve below. Detecting atomicity conflicts requires that all replicas receive reports of all changes, update their trees based on their current knowledge of conflicting changes, make entries visible based on a common algorithm for selecting a serialized sequence and do not purge the information they need until they know that other replicas have already seen and rejected anything that could be a basis for future changes that might be accepted. I am unable to detect any trace of these fundamental principles in the material below. Maintaining distributed ACID transactions is of course much harder, but I would recommend studying some of the concepts involved in the serialization graphs for a replicated data history in a text on that subject before embarking on protocol design for the simpler problem LDUP has to deal with. One needs to understand what serializability graphs and replicated data histories are, in order to design procedures for detecting atomicity conflicts. See for example chapter 8 at: http://research.microsoft.com/pubs/ccontrol/ The Coda papers recommended a year ago are of course a better introduction for the simpler problems in directory replication (as are the Bayou materials referenced there). http://www.cs.cmu.edu/afs/cs/project/coda/Web/docs-coda.html -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Steven Legg Sent: Thursday, March 29, 2001 5:47 PM To: 'Ed Reed' Cc: ietf-ldup@imc.org Subject: Conflict Detection within the Current Architecture, was RE: New LDUP requirements draft Ed, > I believe the requirement MAY be satisfied IFF log-based replication > is used to retransmit the update via LDUP as long as no one else > has gotten to the modified entry first via an update to some other > master (i.e, as long as there are no conflicting collisions). > If there > are conflicting updates, I think the result that Albert would like to > see is that the update that collides is bounced in some way for > administrative resolution. > > For state-based replication the requirement is meaningless, since > state-based replication has as its goal to make all the replicas > hold the same values, and it never pretends to try to reproduce > the operations which were entered to get them to that state - > it doesn't care, because it is the ultimate state that is important. > > Believers in state-based replication believe the end justifies > whatever means are necessary to achieve a common view > of the data. Believers in log-based replication think getting > there is most of the fun. > > Thus, my long-held belief that it MAY BE possible to replicate > transactional semantics of some sort via log-based replication > schemes (who can record and playback the transactions > in question), but it will NEVER be possible to do so with > state-based replication schemes. I thought about this today and I think I've found a relatively painless way to add atomicity information and conflict detection to LDUP that is friendly to state-based implementations. The conflict detection scheme I'm about to describe relies on comparing the before and after states of entries being updated. Updates on a single master will produce a neat sequence where the after state of one update matches the before state of the next update in the sequence. In the multimaster case, there will be some updates that share the same before state and some updates whose before states reflect different incomplete sequences of updates. These are the updates in conflict. The before state of an update is described by a start vector, which is a set of CSNs that is formed by looking at the CSNs on the contents of the entry being modified. The highest CSN for each replica ID is retained in the start vector. I started out by just copying the current update vector but this approach produces more false positive indications of conflicts. The after state of an update is described by an end vector that is formed in the same way as the start vector, except it looks at the entry after the update has been performed. I'll collectively refer to start and end vectors as state vectors. A state vector SV1 "covers" another state vector SV2 if the CSN in SV1 for each replica ID is greater than or equal to the CSN for the same replica ID in SV2. The start vector tells us what updates have been applied prior to the update of interest, i.e. the previous updates that are "seen". Two updates are in conflict if neither of them completely sees the after state of the other. More precisely, two updates U1 and U2 are not in conflict if and only if the start vector for U1 covers the end vector for U2 or the start vector for U2 covers the end vector for U1. If the start vector for U2 covers the end vector for U1 then U2 "sees" the entry after U1 has been performed, and therefore logically follows U1 and there is no conflict. Similarly for the reverse case. In the simplest cases, two updates are in conflict if they modify the same entry "simultaneously" at different replicas, without regard to what they are actually doing to the entry. Consequently, some of the detected conflicting updates might actually turn out to be independent changes to the same entry. Time for an example of conflict detection. Let's suppose there are two replicas R1 and R2, where everything is in a quiescent state. A state vector would actually use CSNs but it is sufficient for this example to just use the timestamp component. I'll represent a state vector as a tuple (x, y) where x is a timestamp (CSN) generated by R1 and y is a timestamp (CSN) generated by R2. At time t0, the state vector for the entry E is (t0,t0) at both replicas. Update U1 on entry E is performed at R1 at time t1. Thus the start vector for U1 is (t0,t0) and the end vector is (t1,t0). Simultaneously, update U2 is performed at R2. The start vector for U2 is also (t0,t0) and the end vector is (t0,t1). At time t2, U1 is propagated to R2. The effects of U1 and U2 are merged as described by URP giving a new state vector for E of (t1,t1). Update U3 on entry E is performed at R1 at time t3. The start vector for U3 is (t1,t0) and the end vector is (t3,t0). Update U4 on entry E is performed at R2 at time t3. The start vector for U4 is (t1,t1) and the end vector is (t1,t3). I'll summarize the start and end vectors to make this easier. start end U1: (t0,t0) -> (t1,t0) U2: (t0,t0) -> (t0,t1) U3: (t1,t0) -> (t3,t0) U4: (t1,t1) -> (t1,t3) Using the conflict detection rule above we come up with the following conflicts: U1 conflicts with U2. U2 conflicts with U1 and U3. U3 conflicts with U2 and U4. U4 conflicts with U3. Of particular note, U4 does not conflict with U1 or U2. It sees the merged output of these conflicting updates but that doesn't make it "conflicted" itself. We have to draw a line somewhere. To detect conflicts we need to propagate the start and end vectors of an update in the protocol, along with the UUID of the relevant entry. The end vector is just the start vector with the CSN for the originating replica replaced by the CSN for the update, so we can condense this to a single CSN, which also serves to uniquely identify the update. The start vector is a set of CSNs, like an update vector, but generally shorter since not all replicas will be represented by CSNs on the entry contents (because they've never made a change to the entry, or the CSNs on their changes have long since been purged, or these CSNs are now old enough to be purged). The CSN on the conflict detection information can be used in the same way as the CSN on a replication primitive to decide when the information needs to be propagated. Because the conflict detection information and the replication primitives for a specific update have the same CSN they will necessarily propagate around together. State-based implementations can still propagate only the net state change, i.e. they can omit superseded replication primitives, because no information from the primitives is being used to detect conflicts. The above provides enough information for any replica to detect every conflict. Given M replicas originating an average of N updates, that's roughly (M by N) squared comparisons. If we leave it up to the originating replica to test only for conflicts against its own updates the number of comparisons can be reduced to N squared by M. The scheme extends easily to accommodate grouped operations. All the replication primitives generated from the one set of grouped operations really need to have the same CSN (ignoring the least significant modification number component) so one CSN is still enough for the end vector. The start vector is generated by considering all the entries targeted by the grouped operations, instead of just one entry. Transactions can be similarly accommodated, though if searches are part of the transaction we should drop the UUID and test the vectors against updates for all entries when looking for conflicts. We can also tighten up the conflict detection by adding to the conflict detection information, lists of the attribute types the update reads and writes. If the read and write sets of two updates are mutually disjoint they can't be in conflict even if they modify the same entry at the same time Comments anyone ? Regards, Steven From owner-ietf-ldup@mail.imc.org Thu Mar 29 18:18:21 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17223 for ; Thu, 29 Mar 2001 18:18:20 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA01995 for ietf-ldup-bks; Thu, 29 Mar 2001 14:16:26 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id OAA01989 for ; Thu, 29 Mar 2001 14:16:21 -0800 (PST) Received: (qmail 7293 invoked from network); 29 Mar 2001 22:15:47 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 29 Mar 2001 22:15:47 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: , "'Ed Reed'" Cc: Subject: RE: Conflict Detection within the Current Architecture, was RE: New LDUP requirements draft Date: Fri, 30 Mar 2001 08:19:58 +1000 Message-ID: <000d01c0b89e$6482a140$6628a8c0@nowhere.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <000001c0b824$7f388d80$b05508cb@osmium.adacel.com.au> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In response to Steve's request for comments: 1) The fact that Steve is now looking for a way to meet requirements is a major step forward, which I welcome. By offering his new idea he has at least confirmed that URP 03 currently lacks a "way to add atomicity information and conflict detection". 2) I have read the material below several times but do not understand it. 3) That is not surprising as it states clearly that Steve "thought about this today" (although the relevant requirements for "atomicity information and conflict detection" were present since 04 in September 2000 after a room consensus on that in June 2000). 4) Steve should now write an initial I-D giving a clear explanation of his new idea so that the WG can discuss it properly. Then a formal discussion should be opened, managed and concluded. We should not attempt to do that while it is in it's present form as it is clearly just initial thoughts about a new idea on the same day that the idea was thought of. 5) I was given 1 week to produce such an initial I-D when bringing up an alternative proposal a year ago. That was not unreasonable as it was then understood that the WG had settled on Steve and Alison's proposal after working for a year. It is now a year later and it is clear that the WG has not in fact even reached real consensus on requirements. So Steve should be given more time to do a presentable draft. He should also first do the draft explaining "why URP ended up the way it did" that he committed to a year ago. 6) I did a "necessarily half baked" proposal (MDCR) a year ago as required and it has still not been properly discussed, so I have let it expire. I am posting that to the WG list in my next message. 7) A facilitator should be appointed to conduct the necessary discussions in the list, insist on questions and arguments being answered, sum up issues outstanding etc etc, so that we actually converge on a decision rather than just exchanging and ignoring various "points". BTW for some insight into design issues, consider the problems of conflict resolution within LDUP WG itself in the absence of a functioning conflict resolution mechanism and accurate propagation of knowledge of what the current state actually is. The inevitable result has been periodic announcements that documents are "ready" when they are not, without actual progress towards getting them ready and much time lost ;-) 8) My preliminary view of what I can understand of Steve's idea is that it still appears to be based on a fundamental misconception that there exists some inherent total ordering of conflicting updates to an entry which can be approximated in some way by timestamps. In reality multi-master conflicts form a tree which is only partially ordered. I do not think it is *possible* to "add in" atomicity information and conflict detection as an afterthought to a replication scheme that was not designed for it from the ground up. Conflict detection is after all a necessary precondition for conflict resolution, which is the part of the architecture that URP was supposed to have been providing. Alarm bells should have gone off when it was renamed to "update reconciliation". I will nevertheless study Steve's proposal carefully when he presents it. Meanwhile, here's some points to think about. Once an initial version of an entry last changed at R0 has split into two versions R0.R1 and R0.R2 due to concurrent changes at different replicas R1 and R2, it can, and therefore will, sometimes split into further versions eg R0.R1.R3 and R0.R2.R4 as a result of both those versions being visible and available for DUAs to make further changes to until the conflict is resolved. Depending on replication links and schedules the original "stable" version R0 and the first two variations R0.R1 and R0.R2 may also all be visible at some replica at once. Each variation can be named by the series of replica Ids at which the change was made, starting from the original stable version. As shown in MDCR it is not necessary to store the entire path name, as the "version" number or depth in the tree, plus the previous and current replica Ids of the originator DSAs for the two most recent changes is sufficient in the report propagation protocol to maintain the links between conflicting versions in the tree. This only requires storing the previous replica Id and version number in the visible entry at each replica. But it is not possible to serialize operations without some means of maintaining the tree and it is not possible to maintain information about atomic operations or detect conflicts between them without a means for serializing the operations. I see no recognition of that in Steve's material below. Any partially ordered tree can be embedded in a total ordering, but a total ordering based on timestamps would simply be arbitrary. The problem to be solved is how to deal with the fact that each replica only has an incomplete knowledge of both the actual state of the tree and of the similar knowledge possessed by other replicas while the conflict remains unresolved. For atomicity and eventual convergence, the algorithm must result in each replica only making visible entries that represent the result of a serializable sequence of successful operations that have actually been performed by DUAs and must *not* make visible "transient states" arising from internal processing by the DSAs. Otherwise access control and other decisions would be based on those transient states intended by nobody and not on the intended policies. The unavoidable "loose consistency" inevitably results in changes that will ultimately not be converged to being initially reported as having been successfully made, and therefore results in further changes based on those changes sometimes being made. But it must never result in entry state that is not the result of a serializable sequence of changes made by some DUAs becoming visible at any DSA and it must be capable of generating notificatins when a DUA has been told that it's change was accepted but the change is eventually suppressed due to conflicts. A necessary precondition is that all replicas must eventually receive the same set of reports about all the conflicting changes. This precludes a design where changes are merged while being transitively replicated and only the merged changes based on incomplete knowledge of the conflict reported to other replicas. A separate report propagation layer is essential, as required by sound architectural principles anyway. Since multi-master is inherently unsuitable for any situation with a high rate of concurrent changes there is no significant increase in bandwidth as a result of forwarding all changes to all replicas. Not doing so "saves" transmission of precisely the information needed for conflict detection by discarding it on the way with different information discarded at different replicas along each path. For all replicas to eventually converge on the same visible entries they must all eventually select the same sequence. Therefore they must all keep track of the state of the entire tree while the conflict is being resolved. That is not a burden on implementations as the tree pointers only need about 12 bytes of RAM for each version until the conflict is resolved. Most of the conflict trees are trivial since multi-master is unsuitable for situations with a high rate of concurrent changes anyway. Using a total ordering based on 32 bit timestamps would just save about 8 bytes of RAM per unresolved conflicting change, at the expense of correct serialization of changes and therefore of any hope of maintaining atomicity information and detecting conflicts. 64 bit timestamps would only save 4 bytes of RAM. Version numbers are needed for correct serialization as recognized in all research on distributed concurrent changes. They also simplify and compress report propagation and tree storage by making it unnecessary to transmit and store the full path names of the variations or do complex calculations, let alone the O3 comparisons mentioned by Steve below. Detecting atomicity conflicts requires that all replicas receive reports of all changes, update their trees based on their current knowledge of conflicting changes, make entries visible based on a common algorithm for selecting a serialized sequence and do not purge the information they need until they know that other replicas have already seen and rejected anything that could be a basis for future changes that might be accepted. I am unable to detect any trace of these fundamental principles in the material below. Maintaining distributed ACID transactions is of course much harder, but I would recommend studying some of the concepts involved in the serialization graphs for a replicated data history in a text on that subject before embarking on protocol design for the simpler problem LDUP has to deal with. One needs to understand what serializability graphs and replicated data histories are, in order to design procedures for detecting atomicity conflicts. See for example chapter 8 at: http://research.microsoft.com/pubs/ccontrol/ The Coda papers recommended a year ago are of course a better introduction for the simpler problems in directory replication (as are the Bayou materials referenced there). http://www.cs.cmu.edu/afs/cs/project/coda/Web/docs-coda.html -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Steven Legg Sent: Thursday, March 29, 2001 5:47 PM To: 'Ed Reed' Cc: ietf-ldup@imc.org Subject: Conflict Detection within the Current Architecture, was RE: New LDUP requirements draft Ed, > I believe the requirement MAY be satisfied IFF log-based replication > is used to retransmit the update via LDUP as long as no one else > has gotten to the modified entry first via an update to some other > master (i.e, as long as there are no conflicting collisions). > If there > are conflicting updates, I think the result that Albert would like to > see is that the update that collides is bounced in some way for > administrative resolution. > > For state-based replication the requirement is meaningless, since > state-based replication has as its goal to make all the replicas > hold the same values, and it never pretends to try to reproduce > the operations which were entered to get them to that state - > it doesn't care, because it is the ultimate state that is important. > > Believers in state-based replication believe the end justifies > whatever means are necessary to achieve a common view > of the data. Believers in log-based replication think getting > there is most of the fun. > > Thus, my long-held belief that it MAY BE possible to replicate > transactional semantics of some sort via log-based replication > schemes (who can record and playback the transactions > in question), but it will NEVER be possible to do so with > state-based replication schemes. I thought about this today and I think I've found a relatively painless way to add atomicity information and conflict detection to LDUP that is friendly to state-based implementations. The conflict detection scheme I'm about to describe relies on comparing the before and after states of entries being updated. Updates on a single master will produce a neat sequence where the after state of one update matches the before state of the next update in the sequence. In the multimaster case, there will be some updates that share the same before state and some updates whose before states reflect different incomplete sequences of updates. These are the updates in conflict. The before state of an update is described by a start vector, which is a set of CSNs that is formed by looking at the CSNs on the contents of the entry being modified. The highest CSN for each replica ID is retained in the start vector. I started out by just copying the current update vector but this approach produces more false positive indications of conflicts. The after state of an update is described by an end vector that is formed in the same way as the start vector, except it looks at the entry after the update has been performed. I'll collectively refer to start and end vectors as state vectors. A state vector SV1 "covers" another state vector SV2 if the CSN in SV1 for each replica ID is greater than or equal to the CSN for the same replica ID in SV2. The start vector tells us what updates have been applied prior to the update of interest, i.e. the previous updates that are "seen". Two updates are in conflict if neither of them completely sees the after state of the other. More precisely, two updates U1 and U2 are not in conflict if and only if the start vector for U1 covers the end vector for U2 or the start vector for U2 covers the end vector for U1. If the start vector for U2 covers the end vector for U1 then U2 "sees" the entry after U1 has been performed, and therefore logically follows U1 and there is no conflict. Similarly for the reverse case. In the simplest cases, two updates are in conflict if they modify the same entry "simultaneously" at different replicas, without regard to what they are actually doing to the entry. Consequently, some of the detected conflicting updates might actually turn out to be independent changes to the same entry. Time for an example of conflict detection. Let's suppose there are two replicas R1 and R2, where everything is in a quiescent state. A state vector would actually use CSNs but it is sufficient for this example to just use the timestamp component. I'll represent a state vector as a tuple (x, y) where x is a timestamp (CSN) generated by R1 and y is a timestamp (CSN) generated by R2. At time t0, the state vector for the entry E is (t0,t0) at both replicas. Update U1 on entry E is performed at R1 at time t1. Thus the start vector for U1 is (t0,t0) and the end vector is (t1,t0). Simultaneously, update U2 is performed at R2. The start vector for U2 is also (t0,t0) and the end vector is (t0,t1). At time t2, U1 is propagated to R2. The effects of U1 and U2 are merged as described by URP giving a new state vector for E of (t1,t1). Update U3 on entry E is performed at R1 at time t3. The start vector for U3 is (t1,t0) and the end vector is (t3,t0). Update U4 on entry E is performed at R2 at time t3. The start vector for U4 is (t1,t1) and the end vector is (t1,t3). I'll summarize the start and end vectors to make this easier. start end U1: (t0,t0) -> (t1,t0) U2: (t0,t0) -> (t0,t1) U3: (t1,t0) -> (t3,t0) U4: (t1,t1) -> (t1,t3) Using the conflict detection rule above we come up with the following conflicts: U1 conflicts with U2. U2 conflicts with U1 and U3. U3 conflicts with U2 and U4. U4 conflicts with U3. Of particular note, U4 does not conflict with U1 or U2. It sees the merged output of these conflicting updates but that doesn't make it "conflicted" itself. We have to draw a line somewhere. To detect conflicts we need to propagate the start and end vectors of an update in the protocol, along with the UUID of the relevant entry. The end vector is just the start vector with the CSN for the originating replica replaced by the CSN for the update, so we can condense this to a single CSN, which also serves to uniquely identify the update. The start vector is a set of CSNs, like an update vector, but generally shorter since not all replicas will be represented by CSNs on the entry contents (because they've never made a change to the entry, or the CSNs on their changes have long since been purged, or these CSNs are now old enough to be purged). The CSN on the conflict detection information can be used in the same way as the CSN on a replication primitive to decide when the information needs to be propagated. Because the conflict detection information and the replication primitives for a specific update have the same CSN they will necessarily propagate around together. State-based implementations can still propagate only the net state change, i.e. they can omit superseded replication primitives, because no information from the primitives is being used to detect conflicts. The above provides enough information for any replica to detect every conflict. Given M replicas originating an average of N updates, that's roughly (M by N) squared comparisons. If we leave it up to the originating replica to test only for conflicts against its own updates the number of comparisons can be reduced to N squared by M. The scheme extends easily to accommodate grouped operations. All the replication primitives generated from the one set of grouped operations really need to have the same CSN (ignoring the least significant modification number component) so one CSN is still enough for the end vector. The start vector is generated by considering all the entries targeted by the grouped operations, instead of just one entry. Transactions can be similarly accommodated, though if searches are part of the transaction we should drop the UUID and test the vectors against updates for all entries when looking for conflicts. We can also tighten up the conflict detection by adding to the conflict detection information, lists of the attribute types the update reads and writes. If the read and write sets of two updates are mutually disjoint they can't be in conflict even if they modify the same entry at the same time Comments anyone ? Regards, Steven From owner-ietf-ldup@mail.imc.org Thu Mar 29 22:03:27 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00017 for ; Thu, 29 Mar 2001 22:03:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id RAA10751 for ietf-ldup-bks; Thu, 29 Mar 2001 17:05:20 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by above.proper.com (8.9.3/8.9.3) with SMTP id RAA10741 for ; Thu, 29 Mar 2001 17:05:11 -0800 (PST) Received: (qmail 18798 invoked from network); 30 Mar 2001 01:04:31 -0000 Received: from cpe-144-132-70-18.vic.bigpond.net.au (HELO w98) (144.132.70.18) by relay1.pair.com with SMTP; 30 Mar 2001 01:04:31 -0000 X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: Subject: Multiple Drafts Conflict Resolution (MDCR) Date: Fri, 30 Mar 2001 11:08:40 +1000 Message-ID: <001001c0b8b5$f59ef2c0$6628a8c0@nowhere.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Now that Steve has acknowledged that URP draft 03 does not meet either the current requirements draft 07 and forthcoming 08 or the previous requirements drafts 04, 05 and 06 because it does not currently have a "way to add atomicity information and conflict detection", there may be more interest in considering other alternatives as well as any forthcoming further proposals based on URP from Steve, but there is no online copy of MDCR currently available. I'm posting the "necessarily half-baked" 00 version of MDCR to the list below as it was not posted previously and I let it expire as an I-D when there was no interest in discussion of it. Please review it together with Steve's latest proposals: http://www.imc.org/ietf-ldup/mail-archive/msg00965.html See also my comments on those proposals: http://www.imc.org/ietf-ldup/mail-archive/msg00967.html I'm not planning to do a new I-D version until after the WG has reached a decision on requirements and more feedback on this version has been obtained, depending on whether or not there is actual interest. (Help from anyone interested in becoming a joint author would also be welcome). Based on feedback so far, a next version would include: 1. Spelling out a mechanism, mentioned as omitted in section 9 on "Weeding and Summarizing", to ensure full compliance with: G6. Meta-data collected by the LDAP replication mechanism MUST NOT grow without bound. The present sketch does not guarantee compliance under all circumstances - as pointed out by Steve. The requirements correctly insist that any design MUST avoid this problem. The proposed mechanism would involve designation of an authoritative "floating" or "failover" single master responsible for adding new replicas to a replication network and excluding replicas that fail to respond to propagation of a regular "heartbeat" update within the configurable replication diameter for the network. That is needed for "eventual convergence" anyway, but has not so far been specified in the architecture. The "heartbeat" updates would be used to determine when "durable" drafts can be separated from "ephemeral" weeds and the "weeding and summarizing" finalized. I still haven't thought this through in detail and would especially welcome any other ideas about it. Details of the designation and replacement of such a single master would be left to other documents to be specified in the architecture (eg by "pecking order" based on replica id), since similar single masters are also needed for other aspects such as management of partitioning into replicated areas, administrative areas, hierarchical operational binding of naming contexts, schema management etc as well as for future extensions such as replication of backlinks providing referential integrity and modifyDN operations between more than one replicated area. See the various "floating masters" used in Active Directory for a plausible approach. Some clarification in the architecture draft about any use that can be made of the replication of subentries with CSNs from each replica may also be necessary. It could be used as a form of heartbeat. Distributed protocols for agreeing on who is within the set of replicas and who is excluded at any given time are actually quite complicated. Obviously "eventual convergence" cannot be achieved robustly without a common authoritative view as to which DSAs updates must have been received and converged with before marking conflicted drafts as durable and discarding metadata to prevent it growing without bound. Otherwise the replication network could be partitioned with no means of repair. For example the original Link Access Protocol which only had to ensure both sides of a two way data link had the same view on whether the link was up or down within a time limit, turned out to be broken and had to be replaced with LAPB after international standardization of X.25. Expertize from other areas of IETF more familiar with such issues should be sought. (eg reliable multi-cast transport WG). Similar considerations apply to optimization of replication schedules and the links in the directed graph of the replication network. A replication network capable of converging must be a "strong labelled digraph" (a path in each direction exists from each labelled node to each other labelled node). The number of such non-isomorphic replication networks with just 7 nodes is: 35,223,091,615,568 (more than 35 million million) - that's without taking into account weighted arcs for actual costs and availability. http://www.research.att.com/cgi-bin/access.cgi/as/njas/sequences/eisA.cgi?An um=A003030 Management of replication agreements could be "non-trivial" ;-) Fortunately that is outside the scope of the conflict resolution procedures, but it needs to be dealt with somewhere in the architecture. 2. Using the term "grouped operations" instead of "transactions" to avoid confusion with ACID transactions. This change would also include an explanation of why it is logically impossible for any multi-master replication scheme to avoid precluding future work on ACID transactions as currently required by: G2. LDAP Replication SHOULD NOT preclude support for model 1 (Transactional Consistency) in the future. and the definition of model 1 (Transactional Consistency) as exhibiting all four of the ACID properties (Atomicity, Consistency, Isolation and Durability). It would also include an explanation of why such work is irrelevant to LDUP since any set of servers replicating with ACID transactions would be indistinguishable to LDAP protocols from a single LDAP DSA with multiple addresses, like any other compliant DSA that happens to be internally a distributed system. Work on replication of ACID transactions is the concern of replicated DBMS standardization (currently considered too immature for standardization) and not within the competence or charter of a WG on directory replication. It may also include an explanation of why no attempt has been made to support model 3, as required by: G1. LDAP Replication MUST support models 2 (Eventual Consistency) and 3 (Limited Effort Eventual Consistency) above. At present the explanation would simply be that nobody has given any plausible reason as to why we MUST do so, no other proposal is attempting to do so and any such work would be well outside the scope of the LDUP charter and beyond the competence of participants in the WG. Some tutorial background on issues concerning concurrent updates in multi-master replication may also be included although it would be better if that was done separately from a protocol design document and by someone better able to write tutorials. 3. An explanation of the necessity to guarantee sequential delivery of reports from each originator DSA to every other DSA for both reliable eventual convergence and atomicity as well as to meet requirements AM6 and G3: AM6. The sequence of updates to access control information (ACI) and the data controlled by that ACI MUST be maintained by replication. G3. LDAP replication SHOULD have minimal impact on both the system and network performance. Enforcement of that guarantee by immediate rejection of out of sequence updates is (with a robust protocol for ensuring they do get delivered in sequence) assumed to be sufficient for MDCR to comply with MM7, although the wording of MM7 seems inappropriate: MM7. Multi-master conflict resolution MUST NOT depend on the in-order arrival of changes at a replica to assure eventual convergence. I am not aware of any other aspects in which the MDCR version 00 design approach could be said to be not capable of satisfying the current requirements draft (07 and 08) and would especially appreciate any comments drawing attention to any such issues. Hopefully discussion of inadequacies in the requirements draft could be omitted after finalization of requirements. (Version 00 was written primarily to demonstrate that an alternative was possible in support of my formal objection to requirements draft 02 as failing to provide meaningful criteria that would make it obvious that URP and corresponding parts of the current architecture draft does not meet necessary requirements for viable multi-master replication). Remaining items below are intended to be improvements in further work rather than dealing with requirements issues. 4. Better presentation of section 9, perhaps with examples and diagrams. 5. Elaboration of how the separate layering of the report propagation protocol could facilitate moving on towards interim standards for single master replication that would be consistent with migration paths from existing "changelog" implementations to future multi-master standards still being worked on. That could help the WG actually deliver something while it remains stuck on multi-master issues. As mentioned, the approach to report propagation is also applicable to any other approach to conflict resolution that the WG might wish to consider and provides the minimum lower layer needed for any such approach to meet current requirements, without adding any complications or obstacles to other approaches to other issues, so it ought to be possible to reach agreement about that separately and earlier. 6. Elaboration of the paragraph on splitting entries and attributes that are frequently manipulated independently into a family of entries in the light of Microsoft having had to redesign core aspects of Active Directory and not being able to fix security flaws for another year as a result of not grasping this point. Also elaboration of related material on "add self" operations for group membership. 7. An explanation of how it would be possible to include changes from strands of the conflict tree other than the selected fully serialized strand when they are not in direct conflict and why I think this would be an unnecessary and undesirable complication, better handled by mandatory retraction notifications. 8. Additional and updated references including more specific references to Active Directory, Coda and Bayou papers and background material on concurrency issues including the the usual approaches for fully ACID distributed transactions described in Chapter 8 of: http://research.microsoft.com/pubs/ccontrol/ in contrast to the simpler approach described below for just achieving atomicity without providing any application specific conflict resolution as intended with Bayou, but using the same Bayou/Coda inspired update vectors as the current architecture and "embracing and extending" much of the Microsoft implementation of Active Directory ;-) 9. Additional acknowledgement to Steve for drawing attention to the need for requirement G6 and the lack of an adequate mechanism to meet such a requirement in draft 00. ========== LDUP Multiple Draft Conflict Resolution Albert Langer Internet-Draft Directory Designs Document: draft-langer-ldup-mdcr-00.txt 7 April 2000 Intended Category: Informational Expires: 7 October 2000 LDUP Multiple Draft Conflict Resolution (MDCR) Copyright (C) The Internet Society (2000). All Rights Reserved. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This draft is an individual submission to the IETF LDUP Working Group. Distribution of this document is unlimited. Comments should be sent to the LDUP Replication mailing list and to the author. This Internet-Draft expires on 7 October 2000. 1. Abstract Concurrent changes in a Multi-Master directory are a partially ordered tree. "LDUP Update Reconciliation Procedures" (URP) uses timestamps to impose a strict linear order on this tree, and merges changes to fit that imposed order. Merged changes violate the semantics of the LDAP/X.500 data model. No specific "modifierName" can be assigned to a merged change and requirements to support audit trails and access controls and not to break applications or impede future work on transactions cannot be met. The current LDUP requirements draft avoids dealing with these critical issues. Langer Informational - Expires 7 October 2000 [Page 1] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 This memo, "Multiple Drafts Conflict Resolution" (MDCR) proposes an alternative. MDCR stores the tree of conflicts as "multiple drafts" of entries at each replica, and resolves the conflicts between the drafts without merging, based on the actual ordering of the tree. MDCR guarantees atomic, coherent, isolated, and serialized changes to individual entries, with convergence to eventual consistency between replicas. The trade off is that some suppressed conflicting changes become ephemeral. A complete history enables notification support for durability and rollbacks by DUAs. The choices that must be made between maintaining coherence of entries and minimizing ephemeral changes should be addressed in LDUP requirements. 2. Key terms used in this document A "change" is an LDAP v3 protocol add, del, modify or modifyDN request for which the requesting Directory User Agent (DUA) has been sent a success response by an "originator" Directory Service Agent (DSA) after schema and access control checks and application of the change to a replicated entry. A "report" is a specification of a change, published by the originator and propagated in messages forwarded to and by other DSAs that hold a replica of the same NamingContext (NC). A "record" is a copy of a report stored by the originator or a receiver. An "update" is an alteration, performed in response to receiving a report, on an entry within a replica by the DSA holding that replica. A "retraction" is an asynchronous notification that a previous success response to a DUA has been invalidated due to conflicting concurrent changes. A "confirmation" is an asynchronous notification that no retraction will be issued. A "draft" is the result of any change or update for which no confirmation has been issued. Drafts are visible to DUAs as the current state of an entry at a particular replica and may be the basis on which further changes are made by those DUAs. Transient inconsistencies between replicas affect subsequent changes as well as reads when multi-master replication is used. Entry drafts may not just be out of date like shadow copies in a single master directory, but also ephemeral like Internet-Drafts. It is inappropriate for DUAs to rely on them as anything more than "work in progress". (It is even more inappropriate for DSAs to pretend otherwise by eclectically merging drafts and randomly assigning an author ;-). Langer Informational - Expires 7 October 2000 [Page 2] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 These distinctions are maintained by a complete separation of report propagation from update processing. Change propagation is the end result of a deliberate synthesis of both, and may include the propagation of retractions and confirmations to DUAs or their users. The key words "MUST NOT IMPEDE" are a prohibition of specifications that would make it significantly more difficult to later standardize functionality generally described by the words immediately following. Conformity is established by reference to some plausible mechanism that might be used to implement that functionality, despite the consequences of the conforming standard. Actual complete specification of the future functionality and suggested mechanism is of course left to future work. The key words "SHOULD NOT IMPEDE" mean that the needs of future standardization have been taken fully into account in drafting the conforming standard. Conformity is established either by satisfying "MUST NOT IMPEDE", or by showing that there is no known plausible mechanism by which the functionality provided by the conforming standard could do so, and by explaining the implications of the choices made. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Introduction Multi-Master LDAP replication MUST NOT break applications that rely on the LDAP v3 X.500 data model and SHOULD NOT IMPEDE extensions for transactions, referential integrity, audit trails, signed operations, management of replicas with heterogeneous conforming server implementations etc. The key goals of MDCR are to satisfy those requirements, which are not satisfied by URP [3] and some of which are either omitted or ambiguously stated in the current LDUP requirements draft [4]. URP merges concurrent modifications made by different DUAs at different replicas, to attributes and values of a single entry. This inevitably breaks the semantics of "modifiersName", a mandatory operational attribute actually understood by the directory service. Grouping or transactions affecting multiple entries becomes impossible when even single entries have lost coherence. For the same reasons, URP must inevitably break the semantics of other relationships between attributes values understood only by applications. Among those applications are the management of prescriptive access controls and other policy information, and hence the viability of multi-master replication itself. Langer Informational - Expires 7 October 2000 [Page 3] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 The relationships between a named set of attributes are precisely what DUAs manipulate when they make changes to a directory entry. If the attributes could be manipulated independently, they should be stored in different entries. This can conveniently be done using compound families of entries [5]. For example a DistributionList or AccessControlGroup family parent could have a family child entry for each member. This could be combined with translation of add and delete attribute value operations for backward compatability with existing DUAs that are unaware of multi-master replication issues. An LDAP success response when making a change is not reliable if replication updates cause the final result to differ from that expected by each of the DUAs to which success is reported. A success response is also not reliable if it can sometimes be followed by a revocation. But at least applications can then be designed to take some corrective action before end users are affected, rather than after perplexing application behaviour has been reported from end users to help desks. The first thing anyone responding to a problem report would want to know is "who changed what?". If Multi-Master replication makes it impossible to answer that question, it is broken. System administrators are in short supply and have better things to do. The consequences of not supporting "modifiersName" are easily understood by directory users and could turn out to be a major competitive disadvantage for vendors making that choice (guess who ;-) - unless of course such vendors are rescued by adoption of standards endorsing their choice. The following alternative proposals are not based on any implementation or operational experience and so are necessarily half baked. They are presented purely for feedback. Hopefully there is enough here to enable meaningful discussion of feasability, and to prompt clarification of requirements to specify just what guarantees are actually provided by LDUP multi-master protocols and what are not. Decisions to break the data model of LDAP v3 should not just be glossed over or buried within architecture of procedural documents. They should be clearly explained and justified in a requirements document, so as to actively solicit input from the many other areas that will be relying on directory services. 4. Architecture Overview Each replica reports each change it originates to all other replicas. These reports are stored and propagated whether or not they result in updates. The records for each entry are not a linear or totally ordered log, but a partially ordered tree or forest. Subsequent reports may result in a previously ignored report being Langer Informational - Expires 7 October 2000 [Page 4] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 used in an update, switching from draft entries in one branch of the tree to another. Each replica independently builds a tree faithfully reflecting the actual state of conflicting concurrent changes to an entry at all replicas, based on its knowledge from reports received. Each replica independently applies deterministic procedures to update its own copy of an entry based on the knowledge it has. This knowledge includes the "modifiersName" of the DUA that made each change, so that conflicts with concurrent changes to access control information affecting a change can also be detected. The knowledge converges as reports propagate, so the state of the entry at all replicas converges when all conflicting changes have been propagated. The update procedures select a sequence of changes that could have been made as atomic, isolated and serialized changes at a single master DSA, even though they may have actually been made at different replicas. These changes may become durable. Conflicting concurrent changes, not part of a durable sequence, are suppressed by convergence to the entry state resulting from a durable sequence. The conflicting changes are ephemeral. As each replica has a complete history of any conflict, DUAs whose changes were ephemeral and those whose changes were durable, can be notified with retractions and confirmations. The history can then be discarded, but can also be kept as a valuable audit trail. This prepares a foundation for enabling transactions that affect more than one entry. The use of protocolOps to describe changes instead of primitives avoids impeding future standardization of signed operations. Clock synchronization is not required. Report propagation procedures are designed to minimize replication bandwidth by eliminating duplication and making it feasible for replicas that have failed to resynchronize after restoration from backups, using incremental rather than full replication. (Full replication is the main source of bandwidth problems because it causes undesirable peaks). Sequential delivery of reports from each originator is guaranteed, despite interleaved delivery of reports from different originators concerning changes to the same entry. Multi-Master DSAs (MMDSAs) must also act as suppliers to Single- Master DSAs (SMDSAs). Migration of existing single master implementations to support single master LDUP and later multi-master LDUP is made easier by the use of protocolOps and a ChangeLog in MDCR. MMDSAs always know the previous state of an entry that they have supplied to a consumer and can forward reports for the same updates that they apply to that entry themselves. SMDSAs only Langer Informational - Expires 7 October 2000 [Page 5] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 receive reports that they can apply immediately as updates and do not need to implement MMDSA conflict resolution procedures. They implement exactly the same report propagation procedures (restricted to one way propagation to consumer SMDSAs), providing a natural migration path for later upgrade to support Multi-Master replication. Supplying read only shadow copies also involves partial and fractional replicated areas not supported for Multi-Master replication, so details are not discussed here. Essentially MMDSAs forward reports to shadow consumers only when they are applied in updates (and local changes) instead of whenever they are received. SMDSAs forward reports to other secondary shadow consumer SMDSAs whenever they are received, just as MMDSAs do among themselves. "Relay" DSAs could also be supported, connecting groups of MMDSAs but only providing read only copies to DUAs. Likewise separate "Connector" DUAs could implement the report propagation procedures between existing DSA implementations and LDUP compliant DSAs. The complete separation of report propagation from update processing also enables possible future use of broadcast or multicast protocols. The directory is intended for non-volatile data, so conflicts are rare and the probability of a particular number of concurrent conflicts decreases exponentially with the number. The goals of Multi-Master replication are high availability and local availability of changeable copies. Occasional concurrent changes to the same entry are not a goal but an unavoidable consequence. Much of the detail below is needed only to avoid manual repairs when the unusual does happen, as it inevitably does in any large distributed system. Actual performance is dominated by simple changes with no conflicts, so there is no point in implementations attempting to optimize the performance, as opposed to the correctness, of handling conflicts. Typically an implementation would just add change records to a simple log file and keep the trees of transient conflicts in RAM, resulting in greater simplicity and efficiency than state based approaches. MDCR is aimed at improved handling of conflicting modify changes. It does not directly offer any significant improvement for add, del or modifyDN changes. These are already handled by URP, so details have been omitted pending further discussion with the URP authors. Actual use of the "modifiersName" preserved by MDCR to ensure updates are consistent with concurrent changes to access controls involves consideration of all four types of changes and access control mechanisms. This has therefore also been deferred. Actual use of the history preserved by MDCR to issue confirmations and retractions is closely related to work on notifications and Langer Informational - Expires 7 October 2000 [Page 6] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 general grouping or transactions affecting more than one entry. This has therefore also been deferred. 6. Information Model When performing a change, a numbered report is generated listing where the change was made, which entry was changed, what version of that entry was changed, who changed it, when and how. (The great remaining question, "why?" is beyond the scope of directory standardization). report ::= SEQUENCE { originatorRSN ReportSequenceNumber -- report number entryID UUID, -- which originator ReplicaNumber, -- where previous ReplicaNumber, -- what version INTEGER, -- what modifiersName DistinguishedName, -- who modifyTimestamp UTCTime, -- when protocolOp OCTETSTRING, -- how oldParentID UUID OPTIONAL, -- how newParentID UUID OPTIONAL -- how } The report number, originatorRSN, is described under Report Propagation. It is not used for update processing. 6.1 Which "EntryID" is the UUID of the entry that was the target DN of the ProtocolOp at the originator. Having both entryID and target DN is may be important for detecting certain conflicts resulting from concurrent access control and possibly schema changes. These issues not discussed in this draft. 6.2 Where "Originator" is the ReplicaNumber of the DSA where the change was performed and is stored as an operational attribute of each entry. 6.3 What "Previous" is the value of originator that was stored with the entry immediately prior to performing the change. Previous = originator when an entry is first created. "Version" is another operational attribute, initially 1 when an entry is first created, and incremented by 1 for each change. A change and incrementation may occur at one or more different replicas, resulting in one or more different change reports with the Langer Informational - Expires 7 October 2000 [Page 7] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 same next higher version but different originators. Further conflicts may add more branches to the tree until all conflicting reports have been fully propagated. The combination of entryID, version and originator uniquely identifies a report since changes are atomic and an originator increments the version to the next consecutive number when performing a change. It also uniquely identifies the attributes and values of an entry draft, as explained below. Updates are not changes and do not increment the version. Updates do replace the version with a version that is not smaller, as well as replacing other attributes. The replacement version from an update is usually, but not always, larger. Successive versions of an entry are not always consecutive but are always monotonically increasing. The lexical ordering of version, modifyTimestamp and originator of an entry is always strictly monotonically increasing. Version has priority, so modifyTimestamp may move backwards. This priority is based on detailed research done for the Coda file system, a successor to the Andrew File System, and adopted by Microsoft in Active Directory. It eliminates the need for accurate clock synchronization and has other advantages. The Coda work also supports "sometimes connected" clients with notifications by servers about concurrent changes to information they have cached and resynchronization of servers when the replication topology has become disconnected. It has many other important ideas that should be studied for LDUP work and provides complete open source code for implementors (included in FreeBSD and some Linux distributions). 6.5 Who, When and How "ModifiersName" and "modifyTimestamp" correspond to the creatorsName and createTimestamp when an entry is first created and to the usual operational attributes later. "ProtocolOp" is the BER encoding of the actual add, del, modify or modifyDN successful request operation as specified for the protocolOp component of LDAPMessage in 4.1.1 of RFC 2251 [3]. OldParentID and NewParentID are not used for the modify operations discussed in this draft. They are for processing updates where the protocolOp is an add, del or modifyDN request. "NewParentID" is the entryID of the parent of the entry at the originator, immediately after performing a change. Present iff protocolOp is a modifyDN that specifies a new parent DN. "OldParentID" is the entryID of the parent of the entry at the originator, immediately prior to performing a change. Present iff protocolOp is an add, del or a modifyDN. Langer Informational - Expires 7 October 2000 [Page 8] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 7. Report Propagation 7.1 Report Sequence Numbers A ReportSequenceNumber (RSN) is a 64 bit non-negative integer. Each DSA maintains a currentRSN monotonically incremented when any record is stored, whether from a report generated by a local change or a report received. It is also incremented for each replication session (so that it is incremented even if no change reports are received). The currentRSN applies to a DSA as a whole and is not specific to a replica within the DSA. RSNs are not necessarily consecutive in any context. They are just unique, ordered and strictly monotonically increasing. The currentRSN of the originator is assigned as originatorRSN when a change is performed, and is included in the report generated. A localRSN is added to each report as a record number whenever a record is stored at any replica. A record is just a report with the localRSN record number added. The localRSN is the currentRSN of the DSA holding the replica in which the record is stored. When the replica is also the originator, localRSN is equal to originatorRSN. The localRSN assigned to a report is also sent with any message containing the report. The message sent is just a copy of the record held by the sender. The value of localRSN included in a message is not stored with the record by the receiver. Instead the highest localRSN received from a supplier during a replication session is noted by the consumer as a HighwaterMark for that supplier. The consumer DSA's own currentRSN is stored as the localRSN for the record of a report stored by the consumer. record ::= SEQUENCE { localRSN ReqportSequenceNumber, -- sequential local record number report } message ::= record -- localUSN for a message is senders sequential message number Each replica has an UpdatedMark for every replica. This holds, for each originator, the highest originatorRSN of any record generated by that originator which has been stored by the replica holding the UpdatedMark. Langer Informational - Expires 7 October 2000 [Page 9] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 Each replica also has a SeenMark for every replica. This holds, for each originator, the lowest UpdatedMark for that originator, known by the replica holding the SeenMark to be held by any replica. 7.2 Replication Sessions The supplier HighwaterMark held by the consumer is transmitted to the supplier at the start of the replication session and used by the supplier to select only records that have a localUSN at least as high as that HighwaterMark. Messages MUST be transmitted from the supplier to the consumer in strictly increasing order by localRSN, so that the new HighwaterMark recorded by the consumer at the end of the session (including the end of an interrupted session) enables resuming the next session from where the last session left off. Records MUST be stored in the same sequence as messages are received, so that the sequence is preserved when applying updates and propagating copies of records to other neighbors. The full set of UpdatedMarks held by the consumer is also transmitted to the supplier at the start of the replication session. It is used to further select from among the records selected by the HighwaterMark, only those that have not already been received by the consumer via other replication agreements (including changes previously reported to the supplier by the consumer through replication in the opposite direction). This causes gaps in the sequence of localUSNs of the messages that were sent from the supplier to the consumer. Since each replica propagates reports strictly in order of localRSN, it also publishes the reports corresponding to local changes strictly in order of originatorRSN, and this order is preserved by subsequent propagation. Although reports can arrive via multiple redundant paths, with interleaving of reports from different originators, the originatorRSNs from each originator can only arrive in order. Any gaps in the sequence of originatorRSNs received from a particular originator can only result from non-consecutive originatorRSNs issued by that originator, eg because it holds multiple replicas or is distributed among multiple processors. The correct sequence of originatorRSNs for each originator is maintained because any consumer always requests earlier reports before later ones, by sending their set of UpdatedMarks to the supplier. Any supplier either obtained the reports in sequence as a consumer or generated them in sequence as the originator and therefore has the earlier reports and will deliver them to the consumer in sequence. Interruption of a session and resumption from another supplier will merely continue where the previous supplier Langer Informational - Expires 7 October 2000 [Page 10] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 left off, whether or not the substitute supplier also has later reports than the failed supplier. The replacement supplier will have to check more of its records because the consumer cannot supply a suitable HighwaterMark, but it will only transmit those records not yet seen by the consumer, and with the same sequence of originatorRSN for each originator (but different interleaving among originators). If a failed replica is restored from backups any reports it holds that have already been propagated will not be requested by its neighbours and any that have not been propagated will have also prevented the propagation of later reports from the same originator that have a higher originatorRSN. The failed replica will resynchronize through a normal incremental session using it's restored HighwaterMark and set of UpdatedMarks and will not cause a bandwidth spike by full replication. Thus the highest originatorUSN stored as the UpdatedMark for an originator guarantees that the replica holding that mark has received every report from that originator with a lower or equal originatorUSN and has not received any with a higher originatorRSN. Likewise the SeenMark stored for an originator at any replica guarantees than any records stored at that replica with that originator and an equal or higher originatorUSN have also been stored at every other replica. Note: These invariants still hold when reports in transit are destroyed by the complete failure of intermediate replicas without backups, or transmitted late after restoration from backups, provided the replication topology remains connected. It also applies even if an originator is excluded from the set of replicas as a result of being offline for too long, since that results in later reports being discarded before the failed replica can rejoin, and does not affect the earlier reports already in transit. However it does not follow that any similar invariants hold with respect to the sequence of version numbers of entries. The invariant only applies to reports generated at each originator separately. A supplier MUST transmit only records with a higher originatorUSN than the UpdateMark for the originator of the same record, as provided by the consumer. The combination of a HighwaterMark and a full set of UpdatedMarks corresponds to the replicaUpdateVector in the current LDUP protocol, but has a different syntax and semantics. Likewise the set of SeenMarks corresponds to the PurgeVector defined in the current LDUP architecture, but is used differently, as explained in section 9 below. Langer Informational - Expires 7 October 2000 [Page 11] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 No significant change to the current LDUP protocol [6], as distinct from the procedures, would be required by adoption of these procedures. Nor are there any significant changes to the current drafts for subschema [7], operation framing [8], architecture [9] or information model [10], so far as they describe replication agreements. The current draft architecture mixes update reconciliation and report propagation, so sections 4.5, 4.6 and 10.5 are substantially affected, with minor changes elsewhere and to some of the related syntax in the information model. Note: The above approach to propagation can also be applied on a per attribute or even a per attribute value basis, with replication of primitives instead of operations, and update reconciliation instead of conflict resolution. Active Directory does this on a per attribute basis. The highest localRSN for any of the attributes of an entry is copied to a changedRSN for the entry as a whole and the HighwaterMark is based on changedRSN instead of localRSN. The UpdatedMarks are used as above to eliminate changes to particular attributes or attribute values that have an originatorRSN not greater than the UpdatedMark for the corresponding originator. (ActiveDirectory does not store a "modifiersName" per attribute. It does not store one per entry either, because the semantics are completely broken by replicating even entire attributes independently, let alone attribute values). Also note that each replica has all the information it needs to generate the "primitives" used by URP, or any other update processing method, when protocolOps are propagated instead of primitives. Provided that the procedures at each replica are deterministic and not dependent on clock synchronization, no reports need to be obsoleted by update processing during report propagation and likewise no additional reports need to be generated. This avoids a combinatorial explosion of reports about merged reports, even if merging is being done at each replica, provided it is done deterministically and independently. Thus it would be possible to combine the URP approach and the MDCR approach to update processing described below, by allowing certain operations in other branches of the tree to affect updates to entries. For example "add self" and "delete self" operations could be applied to the member attribute of an entry for a group of names, even though they are not properly serialized with respect to other concurrent changes to the entry. This might not break the semantics of that operation and could avoid unnecessary suppression of concurrent changes that could reasonably be merged. It would still break the semantics of "modifierName", but in this particular case, the DUA name is the added or deleted attribute value anyway. Other variations and combinations are also possible. Architectural decisions about report propagation should be independent of update processing. Langer Informational - Expires 7 October 2000 [Page 12] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 8. Update Processing Each replica stores a record for each new report as it is received, to build a local complete history of the known changes made by all replicas to each entry. Any resulting update is then applied to the local entry based on that known history. Each replica independently processes its current records about an entry whenever a new record about that entry is stored, and appends the record to a tree rooted at the record of the first change, ie the creation of the entry. The tree is usually trivial and becomes empty when no further conflicting changes are being propagated for an entry. Typically implementations would simply append records to a log file and hash extracts from the records in RAM for each recently used the entryID. The RAM extracts might contain shorter primitives referencing only attribute value assertions and entryIDs, derived from the protocolOps and other attributes held only in the log file after initial processing. It could contain nothing but the links, unsorted as a blob of memory for each recently changed entry. The position of each record in this tree is specified by the attributes version, originator and previous of the corresponding report. Total overhead is 12 bytes per record, allowing for 4 billion changes per entry, 16 thousand replicas per NC and a pointer into a 4 GB log file (whose relevant records would usually still be in disk cache buffers when needed). The previous attribute of a report is identical to the originator attribute of its predecessor report. A predecessor report with that originator attribute and the next lower version must exist, because it was generated for the predecessor change that resulted in the immediately previous state of the entry at the originator when a change was made. The version is the depth of the record node in the tree because consecutive changes result in consecutive version numbers and updates do not generate reports. The originator is unique among siblings, since the combination of version and originator uniquely determines a report within an entry, and all siblings have the same version. Each node is therefore named by the sequence of originator attributes from the root. This corresponds to a sequence of replicas at which fully serialized atomic, isolated changes were applied to each previous draft to produce the next, just as though the changes were made at a single master DSA without any conflicts. For the initial add operation and subsequent modify operations, applying the protocolOp in the report will generate the attributes and values of the entry state corresponding to each successive version from its predecessor. Langer Informational - Expires 7 October 2000 [Page 13] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 The tree constructed at any replica is consistent with that at any other replica, ie if nodes with the same name exist in trees at two replicas, they contain the same report. Again this follows because nodes with the same name must have the same version as well as the same originator and this uniquely determines a report. Propagation delays result in different replicas having different records and applying different updates. The trees converge as reports propagate, resulting in convergence of the updates for "eventual consistency". Records may arrive out of order. The tree can be constructed despite this, leaving any out of order records unattached until the gap is filled. When a new record is stored, if a record already attached to the tree for the same entry has the next lower version and originator equal to previous for the new record, the new record is attached as a child. Otherwise it remains unattached. If it was attached, any existing unattached records for that entry are checked to see if they can now be attached, recursively. There cannot be more than one predecessor to which a new child could be attached because: a) The previous attribute in a report is uniquely determined as the originator attribute present in the entry immediately before the change described by the report. b) Any predecessor has an originator attribute equal to that previous attribute and a version one less than the successor version. c) This combination of the predecessors originator and version uniquely specifies a report within an entry. The above pedantry establishes that the trees of records at each replica based on each replica's limited current knowledge of reports are always faithfully consistent with the state of the real trees of conflicts. A longest strand of the tree is selected, from the root to a leaf, and the sequence of protocolOps in the records is applied in turn to generate an update. This update replaces the current entry at that replica. The longest strands are those with the highest version number at the leaf. If there is more than one longest strand, those with the latest modifyTimestamp are selected. If there is still more than one, the one with the highest originator is selected. This is unique because the combination of version and originator is unique. Langer Informational - Expires 7 October 2000 [Page 14] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 The operational attributes listed in the report at the leaf of the selected strand replace those attributes of the updated entry, without modification. Procedures for applying add, del and modifyDN protocolOps are not discussed in this draft. Procedures for modify are obvious and result in identical user attributes and values for entries that have the same version and originator at different replicas. An update is not a change. It is a replication of a previous state of an entry, already made visible at some other replica. No new report results from applying an update and no new conflicting draft entries are created. 9. Weeding and Summarizing Weeding purges records of ephemeral changes that have been suppressed and can no longer influence future updates to an entry. Summarization consolidates records of durable changes that cannot be suppressed by subsequent changes. Notification procedures may be added to inform DUAs that made changes about retraction of success responses for their ephemeral changes or confirmation for their durable changes. When a SeenMark for an originator rises above or equal to the originatorRSN of a record of a change made by that originator, the replica holding the SeenMark and record knows that all replicas must have stored their own records of that change, so the record is marked as "Seen". Each replica MUST apply any update resulting from storing a change record before the next increment of its currentRSN. This prevents it from accepting a change from a DUA based on its version of the entry prior to the update. That is necessary for the procedures below. Note: A weaker requirement may be desirable to not constrain implementations from optimizing their processing of updates. This could need more complex specified delays and procedures than those below. Any such specifications MUST be standardized as independent optimizations are unlikely to interoperate correctly. When a record and all its predecessors in the tree have been marked "Seen", no subsequent change can occur unless it has a higher version than that record. This follows because: a) Each record in the sequence has a corresponding record stored at every replica which has been appended to its predecessor in the tree for its entry at that replica by the recursive update processing Langer Informational - Expires 7 October 2000 [Page 15] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 procedures, regardless of the order in which those records arrived at any replica. b) Each replica has also updated its copy of the entry when necessary to ensure it has the highest version number among all records in the tree. c) The entry at all replicas therefore has a version not less than the last of that sequence of records marked "Seen". d) Therefore no originator can make a change that does not increment the version to a higher version. If no more conflicts are occurring for an entry, report propagation must result in the SeenMark rising until all records have been marked seen. When the strand of the tree ending at the record with the same version and originator as the entry, has all been marked as "Seen", none of the other leaves with the same, highest, version number can be visible at any replica, even if they have previously been marked "Seen". This follows because they all have either an earlier modifyTimestamp or the same modifyTimestamp and a smaller originator. Once that has happened, if, after a delay based on the maximum possible time for propagation of a change from another replica, no further reports have been received that cause an update to the entry, any future updates to the entry will be based on the entry. The delay is necessary because changes could have been made at some other replica before the current state of the entry was seen, that have reached a higher version and are still propagating to this replica. Note: The method of dynamically calculating the delay needs careful specification. It ought to be possible to improve these procedures when doing so. It may well be possible to do earlier weeding and summarizing. After the delay, the record with the same version and originator as the entry and any predecessors in the tree are marked "Durable". Those changes are the basis from which all future changes will be made. All other records are marked "Ephemeral". They have no effect on the current state of the entry at any replica and cannot have any future effect. Any DSA that has a record marked "Durable" or "Ephemeral" and is originator of that record, is responsible for any notifications to users of the DUAs listed as "modifierName" for those entries. Notifications could include the protocolOp, the state of the entry before and after the change and the current state. Langer Informational - Expires 7 October 2000 [Page 16] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 Sending notifications would presumably depend on controls the DUAs used in their operations, attributes in the directory entry, perhaps in some other NC, for the DUAs DN (modifiersName) etc. Details should be considered in connection with other work on notifications and transactions as the complete history maintained by these procedures are likely to be relevant to both. "Ephemeral" records may be weeded after issueing any notifications, or if the originator was a different replica. This may only involve detaching them from the tree in RAM, while retaining a full audit trail in the log file. "Durable" records can likewise be detached from the tree, as they are summarized by the current visible entry. However this consolidation must be preserved as the root of the tree of records when the next change or update is applied, so that the protocolOps in subsequent records have a base to start from when calculating further updates. (If record extracts are converted to primitives it may be possible for implementations to work backwards from the current entry, and then forwards to a replacement). 11. Security Considerations The directory is commonly used to hold security related information and Multi-Master replication is particularly useful for providing local and high availability of changeable authentication and authorization information in a "single sign-on" environment. Great care is required to maintain coherence between prescriptive and entry access control information, other policy information and the names and other attributes of entries, and to maintain an accurate audit trail. This and other proposals for Multi-Master replication need careful evaluation of security considerations, which has not yet been done. 12. Acknowledgements The courtesy of the LDUP working group in postponing a final call on the current requirements draft to consider this very late submission from a previous non-participant is appreciated. Thanks also to Steven Legge, Alison Payne, Ed Reed and Uppili Srinivasan for taking time out for discussion during a hectic IETF meeting. The proposed mechanisms for propagation dampening and prioritization of change notifications are based on those developed as part of the Coda file system project [11] and implemented in Microsoft Active Directory [12]. The preference for resolving rather than reconciling conflicts and the basic concept of dynamically maintaining monolithic unity by a Langer Informational - Expires 7 October 2000 [Page 17] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 distributed process of letting a hundred schools of thought contend, selecting a most progressive path, weeding obsolete paths and summing up while moving on, is of course derived from Mao [13]. The related concept of "Multiple Drafts" contending for visibility, with branching rather than linear causality, has connections to theories concerning the emergence of consciousness in large neural networks promoted by Daniel Dennett [14] as well as some philosophies of quantum mechanics. 13. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 3 Legg, S. and Payne, A., "LDUP Update Reconciliation Procedures", Internet-Draft, draft-ietf-ldup-urp-02.txt, October 1999. 4 Weiser, R.F. and Stokes, E. "LDAP V3 Replication Requirements", Internet-Draft, draft f - -ldup-replica-req-02.txt, October 1999. 5 Chadwick, D.W., "Compound (Families of) Entries", Internet-Draft, draft-chadwick-families-00.txt, (expired) 5 December 1999. 6 Stokes, E. and Good, G., "The LDUP Replication Update Protocol", Internet-Draft, draft-ietf-ldup-protocol-01.txt, March 2000. 7 Reed, E. "LDAP Subentry Schema", Internet-Draft, draft-ietf-ldup- subentry-02.txt, March 2000. 8 Stokes, E., Harrison, A. and Good, G., "Extended Operations for Framing LDAP Operations", Internet-Draft, draft-ietf-ldup- framing-00.txt, March 2000. 9 Merrels, J., Reed, E. and Srinivasan, U. "LDAP Replication Architecture", draft-ietf-ldup-model-03.txt, March 2000. 10 Reed, E., "LDUP Replication Information Model", Internet-Draft, draft-ietf-ldup-infomod-01.txt, March 2000. 11 "Scientific Papers from the Coda Project", http://www.cs.cmu.edu/afs/cs/project/coda/Web/docs-coda.html 12 "Active Directory Replication", Chapter 6 of "Microsoft Windows 2000 Server Distributed Systems Guide", Microsoft Press, 2000. Also downloadable in file act_dir_guide.zip from www.msdn.com. Langer Informational - Expires 7 October 2000 [Page 18] INTERNET-DRAFT Multiple Draft Conflict Resolution - MDCR 7 April 2000 13 Mao Tsetung, "Four Essays on Philosophy", Foreign Languages Press, Peking, 1966. 14 Dennett, D.C,. "Consciousness Explained", Penguin 1992. 14. Author's Address Albert Langer Directory Designs PO Box 1116 North Fitzroy VIC 3068 AUSTRALIA Email: Albert.Langer@Directory-Designs.Org Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Langer Informational - Expires 7 October 2000 [Page 19] From owner-ietf-ldup@mail.imc.org Thu Mar 29 23:26:49 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09796 for ; Thu, 29 Mar 2001 23:26:48 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id TAA19402 for ietf-ldup-bks; Thu, 29 Mar 2001 19:53:29 -0800 (PST) Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA19398 for ; Thu, 29 Mar 2001 19:53:28 -0800 (PST) Received: from gypsy.OpenLDAP.org (root@router.boolean.net [198.144.206.49]) by pretender.boolean.net (8.11.1/8.11.1/Boolean/Hub) with ESMTP id f2U3t4D82108; Fri, 30 Mar 2001 03:55:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010329194047.00a80090@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 29 Mar 2001 19:55:02 -0800 To: From: "Kurt D. Zeilenga" Subject: Re: Multiple Drafts Conflict Resolution (MDCR) Cc: In-Reply-To: <001001c0b8b5$f59ef2c0$6628a8c0@nowhere.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:08 AM 3/30/01 +1000, Albert Langer wrote: >2. Using the term "grouped operations" instead of "transactions" >to avoid confusion with ACID transactions. So as to avoid confusion with "Grouping of Related Operations" (currently being considered by this WG as an alternative to "Framing" of Related Operations), I recommend against using the term "grouped operations" instead of "transactions." I suggest "associated operations" be used instead of "transactions". I also suggest you refresh (bump the revision number and resubmit to the repository maintainers) your MDCR I-D if you intend to solicit comment upon it. Kurt From owner-ietf-ldup@mail.imc.org Fri Mar 30 00:46:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18983 for ; Fri, 30 Mar 2001 00:46:13 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id VAA22796 for ietf-ldup-bks; Thu, 29 Mar 2001 21:14:38 -0800 (PST) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.9.3/8.9.3) with SMTP id VAA22787 for ; Thu, 29 Mar 2001 21:14:34 -0800 (PST) Received: (qmail 9731 invoked from network); 30 Mar 2001 05:18:23 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 30 Mar 2001 05:18:23 -0000 Reply-To: From: "Steven Legg" To: Cc: Subject: RE: Conflict Detection within the Current Architecture Date: Fri, 30 Mar 2001 15:16:01 +1000 Message-ID: <000b01c0b8d8$84ef83f0$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: <000d01c0b89e$6482a140$6628a8c0@nowhere.com> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Albert, Albert Langer wrote: > In response to Steve's request for comments: > > 1) The fact that Steve is now looking for a way to meet > requirements is > a major step forward, which I welcome. By offering his new idea he > has at least confirmed that URP 03 currently lacks a "way to add > atomicity information and conflict detection". Just reading URP makes it clear that it says nothing about conflict detection. Conflict detection has always been considered outside the scope for that document, so it lacks nothing it was supposed to have. > 2) I have read the material below several times but do not > understand it. At what point did I lose you ? > 3) That is not surprising as it states clearly that Steve > "thought about > this today" (although the relevant requirements for > "atomicity information > and conflict detection" were present since 04 in September > 2000 after a > room consensus on that in June 2000). I wasn't aware of a requirement to satisfy all requirements immediately upon them becoming known. In any case, I spent a few hours having a preliminary look at a solution on August 14, 2000, which was enough to give me confidence that a suitable mechanism could be added to the current architecture. Ed's email and the discussion about requirement P7 prompted me to have a closer look. The solution turned out to be easier than I expected. > 8) My preliminary view of what I can understand of Steve's idea is > that it still appears to be based on a fundamental misconception > that there exists some inherent total ordering of conflicting > updates to an entry which can be approximated in some way by > timestamps. > > In reality multi-master conflicts form a tree which is only > partially ordered. In reality, the working group has decided that none of the updates in conflict are going to be rejected. The end states of the updates in conflict are to be merged instead. This means that conflicts have to be modelled as a directed acyclic graph instead of a tree. I liken it to a braided stream, where streamlets constantly split and merge. > I do not think it is *possible* to "add in" atomicity information > and conflict detection as an afterthought to a replication scheme > that was not designed for it from the ground up. Strange. I thought I just did. Regards, Steven From owner-ietf-ldup@mail.imc.org Fri Mar 30 00:54:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19956 for ; Fri, 30 Mar 2001 00:54:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id VAA23141 for ietf-ldup-bks; Thu, 29 Mar 2001 21:23:29 -0800 (PST) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.9.3/8.9.3) with SMTP id VAA23137 for ; Thu, 29 Mar 2001 21:23:26 -0800 (PST) Received: (qmail 10685 invoked from network); 30 Mar 2001 05:27:16 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 30 Mar 2001 05:27:16 -0000 Reply-To: From: "Steven Legg" To: Cc: Subject: RE: Multiple Drafts Conflict Resolution (MDCR) Date: Fri, 30 Mar 2001 15:24:57 +1000 Message-ID: <000c01c0b8d9$c2ecb280$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: <001001c0b8b5$f59ef2c0$6628a8c0@nowhere.com> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Albert, Albert Langer wrote: > Now that Steve has acknowledged that URP draft 03 does not meet either > the current requirements draft 07 and forthcoming 08 or the previous I deny that. I maintain that URP *does* meet version 08 of the requirements draft. > requirements drafts 04, 05 and 06 because it does not currently Old versions of drafts are irrelevant. > have a "way to add atomicity information and conflict detection", > there may be more interest in considering other alternatives as > well as any forthcoming further proposals based on URP from Steve, > but there is no online copy of MDCR currently available. Steven From owner-ietf-ldup@mail.imc.org Fri Mar 30 02:08:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10291 for ; Fri, 30 Mar 2001 02:08:16 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id WAA24582 for ietf-ldup-bks; Thu, 29 Mar 2001 22:36:31 -0800 (PST) Received: from arnie.adacel.com.au (arnie.adacel.com.au [203.36.26.147]) by above.proper.com (8.9.3/8.9.3) with SMTP id WAA24570 for ; Thu, 29 Mar 2001 22:36:19 -0800 (PST) Received: (qmail 17672 invoked from network); 30 Mar 2001 06:40:04 -0000 Received: from unknown (HELO osmium) (203.8.85.176) by arnie.adacel.com.au with SMTP; 30 Mar 2001 06:40:04 -0000 Reply-To: From: "Steven Legg" To: "'Richard V Huber'" , Cc: , , Subject: RE: New LDUP requirements draft Date: Fri, 30 Mar 2001 16:37:42 +1000 Message-ID: <000d01c0b8e3$ecebfeb0$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: <200103290029.TAA27435@qsun.mt.att.com> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rick, Richard V Huber wrote: > This started out as a reply to Steven Legg's message, but I > guess it is > now also a reply to Tim Hahn, Ed Reed, and Kurt Zeilenga. > > P7 is a protocol requirement. The change between previous drafts and > draft -07 was to make it clearer what atomicity information has to be > carried by the protocol. In my opinion, the requirement is now less clear. The requirement might now clarify what atomicity information has to be carried by the protocol but we've lost the immediate context that we are talking about "atomicity information that must be carried in the protocol". It don't think it is enough to expect readers will fill in the missing context by noting it is a *protocol* requirement. Incidentally, the current draft defines the term "Atomicity Information" but doesn't use it anywhere. > I don't think this clarification makes it > inconsistent with other parts of the document. Given the understanding that P7 is still about what atomicity information is required to be carried in the protocol then I agree that it is consistent with other parts of the document, but my problem is that I believe the current wording suggests other (possibly inconsistent) interpretations. A casual reader might not notice that their interpretation doesn't fit with the rest of the document. Each requirement should be clear and able to stand on its own without having to analyse the other requirements to weed out the correct interpretation. Regards Steven From owner-ietf-ldup@mail.imc.org Fri Mar 30 08:02:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12656 for ; Fri, 30 Mar 2001 08:02:13 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id EAA08675 for ietf-ldup-bks; Fri, 30 Mar 2001 04:30:45 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.9.3/8.9.3) with ESMTP id EAA08669 for ; Fri, 30 Mar 2001 04:30:44 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10888; Fri, 30 Mar 2001 07:30:46 -0500 (EST) Message-Id: <200103301230.HAA10888@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldup@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldup-replica-req-08.txt Date: Fri, 30 Mar 2001 07:30:45 -0500 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Duplication/Replication/Update Protocols Working Group of the IETF. Title : LDAPv3 Replication Requirements Author(s) : E. Stokes, R. Weiser, R. Moats, R. Huber Filename : draft-ietf-ldup-replica-req-08.txt Pages : 29 Date : 29-Mar-01 This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica-req-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldup-replica-req-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldup-replica-req-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010329145213.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-replica-req-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-replica-req-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010329145213.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Fri Mar 30 10:05:51 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19401 for ; Fri, 30 Mar 2001 10:05:50 -0500 (EST) Received: by above.proper.com (8.9.3/8.9.3) id GAA19463 for ietf-ldup-bks; Fri, 30 Mar 2001 06:37:04 -0800 (PST) Received: from mail.coreon.net (IDENT:mirapoint@mail.coreon.net [216.74.131.6]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA19456 for ; Fri, 30 Mar 2001 06:37:02 -0800 (PST) Received: from rmoats2 (wenjus3.coreon.net [216.74.131.3]) by mail.coreon.net (Mirapoint) with ESMTP id AAA65594 (AUTH rmoats); Fri, 30 Mar 2001 09:36:40 -0500 (EST) From: "Ryan Moats" To: , "'Richard V Huber'" , Cc: , , Subject: RE: New LDUP requirements draft Date: Fri, 30 Mar 2001 08:45:59 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <000d01c0b8e3$ecebfeb0$b05508cb@osmium.adacel.com.au> Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit See ... inline below... Ryan Rick, Richard V Huber wrote: > This started out as a reply to Steven Legg's message, but I > guess it is > now also a reply to Tim Hahn, Ed Reed, and Kurt Zeilenga. > > P7 is a protocol requirement. The change between previous drafts and > draft -07 was to make it clearer what atomicity information has to be > carried by the protocol. In my opinion, the requirement is now less clear. The requirement might now clarify what atomicity information has to be carried by the protocol but we've lost the immediate context that we are talking about "atomicity information that must be carried in the protocol". It don't think it is enough to expect readers will fill in the missing context by noting it is a *protocol* requirement. Steve, you've totally lost me here. I don't see where the context has been lost. The section talks about protocol and it say specifically what the protocol must carry. I disagree that it is less clear. Incidentally, the current draft defines the term "Atomicity Information" but doesn't use it anywhere. That's true, but I think we should wait until consensus on P7 before removing that definition. We may find we need it again. > I don't think this clarification makes it > inconsistent with other parts of the document. Given the understanding that P7 is still about what atomicity information is required to be carried in the protocol then I agree that it is consistent with other parts of the document, but my problem is that I believe the current wording suggests other (possibly inconsistent) interpretations. A casual reader might not notice that their interpretation doesn't fit with the rest of the document. Each requirement should be clear and able to stand on its own without having to analyse the other requirements to weed out the correct interpretation. I saw a similar problem with the previous version and so we added the reference to RFC 2251 specifically to provide some clarity. Are you asking for "LDAP operations" to be replaced by "LDAP modify operations"? Regards Steven From owner-ietf-ldup@mail.imc.org Fri Mar 30 12:19:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26854 for ; Fri, 30 Mar 2001 12:19:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA00922 for ietf-ldup-bks; Fri, 30 Mar 2001 08:34:00 -0800 (PST) Received: from ns.oncalldba.com ([66.1.184.87]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA00914 for ; Fri, 30 Mar 2001 08:33:56 -0800 (PST) Received: from reed.oncalldba.com (reed.OnCallDBA.COM [192.168.1.3]) by ns.oncalldba.com (8.11.0/8.8.7) with SMTP id f2UGXHh01554 for ; Fri, 30 Mar 2001 09:33:17 -0700 Received: from RMINC_DOM-Message_Server by reed.oncalldba.com with Novell_GroupWise; Fri, 30 Mar 2001 06:22:33 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Fri, 30 Mar 2001 06:22:20 -0700 From: "Ed Reed" To: Cc: Subject: Conflict Detection within the Current Architecture, was RE: New LDUP requirements draft Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id IAA00918 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Thanks for the idea, Steve - let me see if I understand the main points... 1) The ending CSN vector you'd propagate in the update protocol for each entry would really be the originating replica's CSN for whatever set of modifications are being reported (in the state based replication system) for the entry - if the replica had several updates to the same entry since the last replication cycle or replication session with another replica, it would be the CSN assigned to the last of those changes by the originating replica. 2) The starting CSN vector would be what, the vector of CSNs constructed by looking at the pre-image version of the entry attribute values being modified at the replica where the modification was entered? Not the whole entry's CSN, nor the CSN vector constructed from the entire entry, but a CSN vector constructed by looking at the attributes which were changed on the entry and using the CSNs of each of those attributes/values. I can see that (1), if I understand it correctly, is essentially what we call for in LDUP, now - the state based system sends the entry's attribute/values with CSN values later than the CSN in the update CSN vector corresponding to the replica consuming the replication information for that session, which would include the CSNs for each "updated" attribute/value - so the end vector you describe would be implicitly sent. I'm having some greater trouble getting my head around (2). The starting vector you describe sounds like would be constructed from a pre-modification image of the entry prior to (each? any? all?) modifications subsequent to the last replication session with the consuming replica. Some questions about that: Since the supplier replica may have replica agreements with several other replicas, the start vector of CSNs for each entry might need to be different for the modified entry for each replication session with the different replicas, right? In other words, if there are three other replicas, the update vector held by the the supplier replica for each of the other replicas might indicate that each of the other three have received a different set of updates with regard to the supplying replica, and so the supplier would need to be able to construct a start vector (from a different starting point) for each entry that is correct for each consuming replica? (This is hard to talk about - pictures might be easier). If that is the case, then it sounds like each entry needs to keep the start vector constructed from the pre-image view of that entry for each modification made to the entry (at least for changes originating at this replica - I haven't figured out whether it will also need start vectors associated with each replicated modification received, but suspect that it will). The storage of such start vectors for each modification would provide some compression of space in comparison to the storage of the actual modification (storing CSNs instead of CSNs + operations + values). But one can think of situations where the storage would not be much less (a group with 10 members has changes (deletes) made to 3 of the members in a single modification would have one CSN to store with the modification, but could have up to one CSN per modified value if each of the pre-existing members have come from different replicas, so as many as 3 CSNs in this case. It seems like there is some reduction in log storage requirements versus simply storing the modification itself, but not an order of magnitude difference. For a modest improvement, it seems it might be simpler and more straight forward to simply have logged the modification in its entirity, and to gain the benefits that a full log-based replication system would have to offer in terms of being able to completely replay operations in sequence. In my mind, the principle benefit a state based replication scheme has to offer is that the information retention requirements are simply the values of the data and their last CSNs. The CSNs add storage requirements above and beyond those needed for the data alone, but storeage increases linearly with the number of entries, attributes, and values, without regard to the rate of change, the number of changes, or the length of time elapsed since replication cycles were last completed. Even deletions, which can't be purged until the replication cycle is complete with all other replicas, are limited in their storage requirements. So, the rational for using a state based replication system is all about data storage, and sharply bounding the storage requirements in the face of lots of changes. Adding the need to hold start vectors of CSNs for entry modifications seems to re-introduce a possibly unbounded storage requirement, which is counter to the objective of the state based replication scheme. Do I understand your proposal, and am I correct in my assumption that the storage of entry start vectors grows as the number of unreplicated changes grows? Regards, Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM >>> "Steven Legg" 03/29/01 12:47AM >>> Ed, > I believe the requirement MAY be satisfied IFF log-based replication > is used to retransmit the update via LDUP as long as no one else > has gotten to the modified entry first via an update to some other > master (i.e, as long as there are no conflicting collisions). > If there > are conflicting updates, I think the result that Albert would like to > see is that the update that collides is bounced in some way for > administrative resolution. > > For state-based replication the requirement is meaningless, since > state-based replication has as its goal to make all the replicas > hold the same values, and it never pretends to try to reproduce > the operations which were entered to get them to that state - > it doesn't care, because it is the ultimate state that is important. > > Believers in state-based replication believe the end justifies > whatever means are necessary to achieve a common view > of the data. Believers in log-based replication think getting > there is most of the fun. > > Thus, my long-held belief that it MAY BE possible to replicate > transactional semantics of some sort via log-based replication > schemes (who can record and playback the transactions > in question), but it will NEVER be possible to do so with > state-based replication schemes. I thought about this today and I think I've found a relatively painless way to add atomicity information and conflict detection to LDUP that is friendly to state-based implementations. The conflict detection scheme I'm about to describe relies on comparing the before and after states of entries being updated. Updates on a single master will produce a neat sequence where the after state of one update matches the before state of the next update in the sequence. In the multimaster case, there will be some updates that share the same before state and some updates whose before states reflect different incomplete sequences of updates. These are the updates in conflict. The before state of an update is described by a start vector, which is mpler and more straight forward to sim a set of CSNs that is formed by looking at the CSNs on the contents of the entry being modified. The highest CSN for each replica ID is retained in the start vector. I started out by just copying the current update vector but this approach produces more false positive indications of conflicts. The after state of an update is described by an end vector that is formed in the same way as the start vector, except it looks at the entry after the update has been performed. I'll collectively refer to start and end vectors as state vectors. A state vector SV1 "covers" another state vector SV2 if the CSN in SV1 for each replica ID is greater than or equal to the CSN for the same replica ID in SV2. The start vector tells us what updates have been applied prior to the update of interest, i.e. the previous updates that are "seen". Two updates are in conflict if neither of them completely sees the after state of the other. More precisely, two updates U1 and U2 are not in conflict if and only if the start vector for U1 covers the end vector for U2 or the start vector for U2 covers the end vector for U1. If the start vector for U2 covers the end vector for U1 then U2 "sees" the entry after U1 has been performed, and therefore logically follows U1 and there is no conflict. Similarly for the reverse case. In the simplest cases, two updates are in conflict if they modify the same entry "simultaneously" at different replicas, without regard to what they are actually doing to the entry. Consequently, some of the detected conflicting updates might actually turn out to be independent changes to the same entry. Time for an example of conflict detection. Let's suppose there are two replicas R1 and R2, where everything is in a quiescent state. A state vector would actually use CSNs but it is sufficient for this example to just use the timestamp component. I'll represent a state vector as a tuple (x, y) where x is a timestamp (CSN) generated by R1 and y is a timestamp (CSN) generated by R2. At time t0, the state vector for the entry E is (t0,t0) at both replicas. Update U1 on entry E is performed at R1 at time t1. Thus the start vector for U1 is (t0,t0) and the end vector is (t1,t0). Simultaneously, update U2 is performed at R2. The start vector for U2 is also (t0,t0) and the end vector is (t0,t1). At time t2, U1 is propagated to R2. The effects of U1 and U2 are merged as described by URP giving a new state vector for E of (t1,t1). Update U3 on entry E is performed at R1 at time t3. The start vector for U3 is (t1,t0) and the end vector is (t3,t0). Update U4 on entry E is performed at R2 at time t3. The start vector for U4 is (t1,t1) and the end vector is (t1,t3). I'll summarize the start and end vectors to make this easier. start end U1: (t0,t0) -> (t1,t0) U2: (t0,t0) -> (t0,t1) U3: (t1,t0) -> (t3,t0) U4: (t1,t1) -> (t1,t3) Using the conflict detection rule above we come up with the following conflicts: U1 conflicts with U2. U2 conflicts with U1 and U3. U3 conflicts with U2 and U4. U4 conflicts with U3. Of particular note, U4 does not conflict with U1 or U2. It sees the merged output of these conflicting updates but that doesn't make it "conflicted" itself. We have to draw a line somewhere. To detect conflicts we need to propagate the start and end vectors of an update in the protocol, along with the UUID of the relevant entry. The end vector is just the start vector with the CSN for the originating replica replaced by the CSN for the update, so we can condense this to a single CSN, which also serves to uniquely identify the update. The start vector is a set of CSNs, like an update vector, but generally shorter since not all replicas will be represented by CSNs on the entry contents (because they've never made a change to the entry, or the CSNs on their changes have long since been purged, or these CSNs are now old enough to be purged). The CSN on the conflict detection information can be used in the same way as the CSN on a replication primitive to decide when the information needs to be propagated. Because the conflict detection information and the replication primitives for a specific update have the same CSN they will necessarily propagate around together. State-based implementations can still propagate only the net state change, i.e. they can omit superseded replication primitives, because no information from the primitives is being used to detect conflicts. The above provides enough information for any replica to detect every conflict. Given M replicas originating an average of N updates, that's roughly (M by N) squared comparisons. If we leave it up to the originating replica to test only for conflicts against its own updates the number of comparisons can be reduced to N squared by M. The scheme extends easily to accommodate grouped operations. All the replication primitives generated from the one set of grouped operations really need to have the same CSN (ignoring the least significant modification number component) so one CSN is still enough for the end vector. The start vector is generated by considering all the entries targeted by the grouped operations, instead of just one entry. Transactions can be similarly accommodated, though if searches are part of the transaction we should drop the UUID and test the vectors against updates for all entries when looking for conflicts. We can also tighten up the conflict detection by adding to the conflict detection information, lists of the attribute types the update reads and writes. If the read and write sets of two updates are mutually disjoint they can't be in conflict even if they modify the same entry at the same time Comments anyone ? Regards, Steven