From owner-ietf-ldup@mail.imc.org Tue Jan 2 14:35:01 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21989 for ; Tue, 2 Jan 2001 14:35:01 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA15320 for ietf-ldup-bks; Tue, 2 Jan 2001 10:42:30 -0800 (PST) Received: from mailgate1.austin.ibm.com (mg01.austin.ibm.com [192.35.232.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA15316 for ; Tue, 2 Jan 2001 10:42:29 -0800 (PST) Received: from austin.ibm.com (netmail.austin.ibm.com [9.53.250.98]) by mailgate1.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA62670; Tue, 2 Jan 2001 12:47:14 -0600 Received: from estokes.austin.ibm.com (estokes.hq.tivoli.com [146.84.99.129]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA38604; Tue, 2 Jan 2001 12:46:48 -0600 Message-Id: <5.0.1.4.0.20010102124444.00aef7e8@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Tue, 02 Jan 2001 12:46:48 -0600 To: "Kurt D. Zeilenga" , "Mark Brown (REDMOND)" From: Ellen Stokes Subject: Re: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Cc: In-Reply-To: <5.0.0.25.0.20001220181159.00a73df0@router.boolean.net> References: <5B90AD65A9E8934987DB0C8C0762657493DD26@DF-BOWWOW.platinum. corp.microsoft.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: Kurt, At least part of your request for applicability (in your second paragraph) will be covered in the Master-slave and multi-master profile documents being authored by Rick Huber. Ellen At 06:43 PM 12/20/2000 -0800, Kurt D. Zeilenga wrote: >Unless the servers are truly equally capable, which is unlikely >if provided by different developers, the replicates will not >be equally capable regardless of well they interoperate with >each other and LDAP clients. That is, application protocol >interoperability in no way guarantees that multiple implementations >behave in the exact same manner given exact replication of >information between them. > >However, an applicability statement can help by narrowing >the options available to LDAP/LDUP implementors. I believe the >LDUP WG should, in addition to specifying a replication protocol, >provide an applicability statement stating whatever additional >requirements there are of LDAP/LDUP servers such that each >replica is "equally capable" of processing an operation. > >Kurt > > >At 03:08 PM 12/20/00 -0800, Mark Brown (REDMOND) wrote: > >In San Diego there was some discussion of the limits of LDUP > >interoperability. > >John Strassner suggested that I draft some material for inclusion in the > >requirements draft. Here it is. > > > >The following material is meant to go right after the first paragraph of > >Section 3 > >("The Models"), and just before the sentence "There are five data > >consistency > >models." > > > >* * * * * > > > >The objective is limited to replication between directory servers that > >implement a passive store fully described by its LDAP schema. There are > >two > >ways in which directory servers commonly implement semantics that go > >beyond > >what the LDAP access protocol defines: > > > >* Access control. LDAP does not currently define an access control > >system. > > (The ldapext WG is working to extend LDAP with an access control > >system.) > > Most directory servers implement an access control system. > > > > Replication between directory servers with different access control > >systems > > will compromise directory security. > > > >* Application triggers. Directory servers commonly integrate one or more > > specific applications. To achieve this integration the directory > >server > > may intercept updates and run application-specific "trigger" code. > > Such triggers enforce directory invariants that cannot be expressed by > >the > > LDAP schema. > > > > A simple trigger example is password policy enforcement. A directory > >server might > > interpret a request to replace the current value of the userPassword > >attribute > > with some new value as a request to first check that the new value > >conforms > > to the server's password policy (e.g. the value is sufficiently long > >and complex) > > before storing the new value. Using this trigger the directory server > >avoids the > > security risk associated with passwords that are easy to attack. > > > > A more complex trigger example is password hashing. A directory server > >might interpret > > a request to replace the current value of the userPassword attribute > >with some > > new value as a request to compute one or more secure hashes of the new > >value > > and store these hashes in one or more attributes, storing no value in > >the > > userPassword attribute. Using this trigger the directory server avoids > >the > > security exposure of storing the plaintext password. > > > > Replication between directory servers with different application > >triggers > > will compromise directory integrity. > > > >* * * * * > > > >--mark From owner-ietf-ldup@mail.imc.org Fri Jan 5 17:49:07 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24921 for ; Fri, 5 Jan 2001 17:49:06 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA11917 for ietf-ldup-bks; Fri, 5 Jan 2001 13:18:03 -0800 (PST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11911 for ; Fri, 5 Jan 2001 13:18:00 -0800 (PST) Received: from qsun.mt.att.com ([135.16.30.2]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id f05LKLY22915; Fri, 5 Jan 2001 16:20:22 -0500 (EST) Received: by qsun.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id QAA14249; Fri, 5 Jan 2001 16:20:20 -0500 Date: Fri, 5 Jan 2001 16:20:20 -0500 Message-Id: <200101052120.QAA14249@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: ietf-ldup@imc.org Subject: New version of draft-ietf-ldup-replica-req Cc: capple@ecal.com, internet-drafts@ietf.org, johns@cisco.com, mabrown@Exchange.MICROSOFT.com, 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: Internet Drafts Editor - Please publish the draft below as draft-ietf-ldup-replica-req-06.txt It replaces the -05 draft from November. LDUP Mailing list - The attached version of the draft incorporates changes to address the comments from San Diego. We trimmed Mark's proposed changes since we were concerned that they went into too much detail that wasn't really LDUP related. Our specific changes are: Insert the following as the last paragraph in Section 3: Interoperability of replicas between directory servers may be limited by servers that implement semantics that go beyond what the LDAP access protocol defines. Examples (not an exhaustive list) of such semantics include: (1) replication among directory servers with different access control systems/semantics may compromise directory security, and (2) replication among directory servers with different application trigger semantics may compromise directory data integrity. Add the following at the end of the Security Considerations Section: 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 documented in RFC 2820 [RFC2820]. Add the new reference to the References: [RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access Control Requirements for LDAP", RFC 2820, May 2000. Change the draft number and the publication and expiration dates. As always, please send comments to the list. Rick Huber --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Internet-Draft Ellen J. Stokes LDAP Duplication/Replication/Update Tivoli Systems Protocols WG Russel F. Weiser Intended Category: Informational Digital Signature Trust Expires: July 2001 Ryan D. Moats Coreon, Inc. Richard V. Huber AT&T Laboratories January 2001 LDAPv3 Replication Requirements draft-ietf-ldup-replica-req-06.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 February 2001 [Page 1] Internet-Draft LDAPv3 Replication Requirements August 2000 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 August 2000 Table of Contents 1 Introduction.......................................................4 2 Terminology........................................................4 3 The Possible Models................................................6 4 Requirements.......................................................8 4.1 General.........................................................8 4.2 Model...........................................................8 4.3 Protocol........................................................9 4.4 Schema.........................................................10 4.5 Single Master..................................................11 4.6 Multi-Master...................................................11 4.7 Administration and Management..................................12 4.8 Security.......................................................12 5 Security Considerations...........................................12 6 Acknowledgements..................................................13 7 References........................................................13 A.APPENDIX A - Usage Scenarios......................................14 A.1.Extranet Example...............................................14 A.2.Consolidation Example..........................................14 A.3.Replication Heterogeneous Deployment Example...................14 A.4.Shared Name Space Example......................................15 A.5.Supplier Initiated Replication.................................15 A.6.Consumer Initiated Replication.................................15 A.7.Prioritized attribute replication..............................16 A.8.Bandwidth issues...............................................16 A.9.Interoperable Administration and Management....................16 A.10.Enterprise Directory Replication Mesh.........................17 A.11.Failure of the Master in a Master-Slave Replicated Directory..17 A.12.Failure of a Directory Holding Critical Service Information...18 B.APPENDIX B - Rationale............................................18 B.1.Meta-Data Implications.........................................18 B.2.Order of Transfer for Replicating Data.........................18 B.3.Schema Mismatches and Replication..............................19 B.4.Detecting and Repairing Inconsistencies Among Replicas.........20 B.5.Some Test Cases for Conflict Resolution in Multi-Master Replication........................................................21 B.6.Data Privacy During Replication................................24 B.7.Failover in Single-Master Systems..............................25 B.8.Including Operational Attributes in Atomic Operations..........26 Authors' Addresses..................................................26 Full Copyright Statement............................................27 Stokes, et al Expires February 2001 [Page 3] Internet-Draft LDAPv3 Replication Requirements August 2000 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. This may also be known as "unit of replication". 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. Stokes, et al Expires February 2001 [Page 4] Internet-Draft LDAPv3 Replication Requirements August 2000 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 - A replica 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 ring. 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 updateable replica copies without requiring communication with other updateable replicas before the write or update is performed. Naming Context - Suffix of a sub-tree of entries held in a single server [X.500]. For replication, this is the vertex of a replica. 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 - A collection of entries in the DIT, defined by a naming context, and including all or some of the depending entries contained therein, which divides directory data into a discrete partition whose Stokes, et al Expires February 2001 [Page 5] Internet-Draft LDAPv3 Replication Requirements August 2000 propagation behavior may be independently configured from other partitions. Replicas may overlap or be nested. Replica-Ring - The servers that hold a particular replica. A server may be part of several replica-rings. 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 ring. Replication Initiation Conflict - In multi-master replication, a Replication Initiation Conflict is a situation where two masters want to update the same replica at the same time. Replication Session - A session set up between two servers in a replica ring 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 naming context 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. Updateable Replica - A copy of the replicated information that may be read and written via LDAP requests. 3 The Models Stokes, et al Expires February 2001 [Page 6] Internet-Draft LDAPv3 Replication Requirements August 2000 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, 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 replica 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. 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 as in white-pages applications (model 3). Therefore, replication requirements are presented for models 2 and 3. Stokes, et al Expires February 2001 [Page 7] Internet-Draft LDAPv3 Replication Requirements August 2000 Interoperability of replicas between directory servers may be limited by servers that implement semantics that go beyond what the LDAP access protocol defines. Examples (not an exhaustive list) of such semantics include: (1) replication among directory servers with different access control systems/semantics may compromise directory security, and (2) replication among directory servers with different application trigger semantics may compromise directory data integrity. 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 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. 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 Stokes, et al Expires February 2001 [Page 8] Internet-Draft LDAPv3 Replication Requirements August 2000 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. A value shared between replicas in a replica ring must eventually converge to the same value on all of its constituent replicas. M4. LDAP replication MUST encompass schema definitions, attribute names and values, access control 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-ring, 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 replica 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-ring from a standard data format, such as LDIF format [RFC2849]. 4.3 Protocol Stokes, et al Expires February 2001 [Page 9] Internet-Draft LDAPv3 Replication Requirements August 2000 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. The supplier MUST track updates sent to the consumer and not resend already acknowledged ones, even in the event of recovery from a failed replica cycle. P3. 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. P4. Incremental replication MUST be allowed. P5. The replication protocol MUST allow either a master or slave replica to initiate the replication process. P6. The protocol MUST support propagation of atomicity information. P7. The protocol SHOULD NOT preclude support of Transactional Consistency (model 1). 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. Stokes, et al Expires February 2001 [Page 10] Internet-Draft LDAPv3 Replication Requirements August 2000 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. 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. Stokes, et al Expires February 2001 [Page 11] Internet-Draft LDAPv3 Replication Requirements August 2000 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 policies 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. Access control information (ACI) associated with sensitive data MUST be deleted after or simultaneously with the deletion of the sensitive data. Likewise, during Adds, ACI MUST be added first or simultaneously with the addition of that data. AM7. It MUST be possible to add a 'blank' replica to a replica-ring, 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-ring. 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 Stokes, et al Expires February 2001 [Page 12] Internet-Draft LDAPv3 Replication Requirements August 2000 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 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. [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. [RFC2820] E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access Control Requirements for LDAP", RFC 2820, 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. [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 13] Internet-Draft LDAPv3 Replication Requirements August 2000 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. In this case, multi-master replication is required to ensure that the multiple updateable replicas of the DIT are synchronized. Some vendors Stokes, et al Expires February 2001 [Page 14] Internet-Draft LDAPv3 Replication Requirements August 2000 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 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 15] Internet-Draft LDAPv3 Replication Requirements August 2000 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 Stokes, et al Expires February 2001 [Page 16] Internet-Draft LDAPv3 Replication Requirements August 2000 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: . Predefined replication agreements that manage more than 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 ring 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 17] Internet-Draft LDAPv3 Replication Requirements August 2000 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 18] Internet-Draft LDAPv3 Replication Requirements August 2000 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 19] Internet-Draft LDAPv3 Replication Requirements August 2000 . 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 20] Internet-Draft LDAPv3 Replication Requirements August 2000 A special client may accomplish detection through periodic comparisons of replicas. This client would typically read two replicas of the same naming context 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. 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 Stokes, et al Expires February 2001 [Page 21] Internet-Draft LDAPv3 Replication Requirements August 2000 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 ring (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 February 2001 [Page 22] Internet-Draft LDAPv3 Replication Requirements August 2000 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 process 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 February 2001 [Page 23] Internet-Draft LDAPv3 Replication Requirements August 2000 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 at the same time . 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 February 2001 [Page 24] Internet-Draft LDAPv3 Replication Requirements August 2000 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 February 2001 [Page 25] Internet-Draft LDAPv3 Replication Requirements August 2000 . 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 ring. It might join the ring 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 Stokes, et al Expires February 2001 [Page 26] Internet-Draft LDAPv3 Replication Requirements August 2000 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, 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 Stokes, et al Expires February 2001 [Page 27] Internet-Draft LDAPv3 Replication Requirements August 2000 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 28] From owner-ietf-ldup@mail.imc.org Mon Jan 8 01:02:25 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14666 for ; Mon, 8 Jan 2001 01:02:24 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA13816 for ietf-ldup-bks; Sun, 7 Jan 2001 21:08:05 -0800 (PST) Received: from tor-exchange.goldfarbconsultants.com (mail.goldfarbconsultants.com [204.101.222.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA13806 for ; Sun, 7 Jan 2001 21:07:51 -0800 (PST) Received: from shieldsmtp.goldfarbconsultants.com (SHIELDSMTP [151.51.192.28]) by tor-exchange.goldfarbconsultants.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Z5MVMPKS; Sun, 7 Jan 2001 23:36:58 -0500 Received: FROM mail.mindspring.com BY shieldsmtp.goldfarbconsultants.com ; Sat Jan 06 06:28:48 2001 -0500 From: To: Date: Sat, 6 Jan 2001 02:47:59 Message-Id: <496.158101.566153@mail.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL TO OUR OFFICE. YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! FRONT PAGE EXTENSIONS are FULLY SUPPORTED. A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 if you are outside the USA, please fax 240 337 8325 Webhosting International From owner-ietf-ldup@mail.imc.org Mon Jan 8 18:51:38 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18766 for ; Mon, 8 Jan 2001 18:51:38 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA10272 for ietf-ldup-bks; Mon, 8 Jan 2001 14:59:39 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA10268 for ; Mon, 8 Jan 2001 14:59:38 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 8 Jan 2001 14:58:15 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Jan 2001 14:59:00 -0800 (Pacific Standard Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Mon, 8 Jan 2001 14:59:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Date: Mon, 8 Jan 2001 14:58:59 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657493DD30@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Thread-Index: AcB07GXyM/qOt8HKT7OkfNUW6D268gE0yyIg From: "Mark Brown (REDMOND)" To: "Ellen Stokes" , "Kurt D. Zeilenga" Cc: X-OriginalArrivalTime: 08 Jan 2001 22:59:00.0650 (UTC) FILETIME=[96C740A0:01C079C6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA10269 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit The essential question is, if I've got directory servers A and B that both say they support LDUP, how do I know that it is OK to hook them together to replicate via LDUP? Suppose for instance that server A has a change-password trigger that recomputes password hashes, and server B doesn't. And suppose I set up A and B to replicate in a multi-master fashion. Then a user who changes her password on server B won't be able to authenticate on server A once server B replicates to server A. The problem created by replication goes beyond A and B having "different capabilities." B has broken an invariant that A was trying to maintain. B was working before A came on the scene, but now B is broken. So we need some way to characterize the servers that are OK to hook together. Pairwise testing is obviously not the answer. The suggestion I've made below is to limit LDUP to "replication between directory servers that implement a passive store fully described by its LDAP schema." It seems quite plausible that we can achieve replication between such servers without compromising their functionality. It may be possible to relax this suggested limit, but I'm not sure how. If someone on the list knows how, they should make a proposal. It seems pretty important to deal with this issue in the requirements draft, since it is squarely a requirements issue. --mark -----Original Message----- From: Ellen Stokes [mailto:stokes@austin.ibm.com] Sent: Tuesday, January 02, 2001 10:47 AM To: Kurt D. Zeilenga; Mark Brown (REDMOND) Cc: ietf-ldup@imc.org Subject: Re: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Kurt, At least part of your request for applicability (in your second paragraph) will be covered in the Master-slave and multi-master profile documents being authored by Rick Huber. Ellen At 06:43 PM 12/20/2000 -0800, Kurt D. Zeilenga wrote: >Unless the servers are truly equally capable, which is unlikely >if provided by different developers, the replicates will not >be equally capable regardless of well they interoperate with >each other and LDAP clients. That is, application protocol >interoperability in no way guarantees that multiple implementations >behave in the exact same manner given exact replication of >information between them. > >However, an applicability statement can help by narrowing >the options available to LDAP/LDUP implementors. I believe the >LDUP WG should, in addition to specifying a replication protocol, >provide an applicability statement stating whatever additional >requirements there are of LDAP/LDUP servers such that each >replica is "equally capable" of processing an operation. > >Kurt > > >At 03:08 PM 12/20/00 -0800, Mark Brown (REDMOND) wrote: > >In San Diego there was some discussion of the limits of LDUP > >interoperability. > >John Strassner suggested that I draft some material for inclusion in the > >requirements draft. Here it is. > > > >The following material is meant to go right after the first paragraph of > >Section 3 > >("The Models"), and just before the sentence "There are five data > >consistency > >models." > > > >* * * * * > > > >The objective is limited to replication between directory servers that > >implement a passive store fully described by its LDAP schema. There are > >two > >ways in which directory servers commonly implement semantics that go > >beyond > >what the LDAP access protocol defines: > > > >* Access control. LDAP does not currently define an access control > >system. > > (The ldapext WG is working to extend LDAP with an access control > >system.) > > Most directory servers implement an access control system. > > > > Replication between directory servers with different access control > >systems > > will compromise directory security. > > > >* Application triggers. Directory servers commonly integrate one or more > > specific applications. To achieve this integration the directory > >server > > may intercept updates and run application-specific "trigger" code. > > Such triggers enforce directory invariants that cannot be expressed by > >the > > LDAP schema. > > > > A simple trigger example is password policy enforcement. A directory > >server might > > interpret a request to replace the current value of the userPassword > >attribute > > with some new value as a request to first check that the new value > >conforms > > to the server's password policy (e.g. the value is sufficiently long > >and complex) > > before storing the new value. Using this trigger the directory server > >avoids the > > security risk associated with passwords that are easy to attack. > > > > A more complex trigger example is password hashing. A directory server > >might interpret > > a request to replace the current value of the userPassword attribute > >with some > > new value as a request to compute one or more secure hashes of the new > >value > > and store these hashes in one or more attributes, storing no value in > >the > > userPassword attribute. Using this trigger the directory server avoids > >the > > security exposure of storing the plaintext password. > > > > Replication between directory servers with different application > >triggers > > will compromise directory integrity. > > > >* * * * * > > > >--mark From owner-ietf-ldup@mail.imc.org Mon Jan 8 20:17:39 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19276 for ; Mon, 8 Jan 2001 20:17:38 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA12590 for ietf-ldup-bks; Mon, 8 Jan 2001 16:26:30 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA12586 for ; Mon, 8 Jan 2001 16:26:29 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 8 Jan 2001 16:26:22 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Jan 2001 16:27:07 -0800 (Pacific Standard Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Mon, 8 Jan 2001 16:27:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Date: Mon, 8 Jan 2001 16:27:06 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657493DD32@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Thread-Index: AcBvlZpMPt1HmZ63T+e1zt/Y2+X7bgKPOWrA From: "Mark Brown (REDMOND)" To: "John Strassner" , X-OriginalArrivalTime: 09 Jan 2001 00:27:07.0213 (UTC) FILETIME=[E5D0BFD0:01C079D2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id QAA12587 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I'm OK with either wording. The essential point is that the application is quite strongly tied to the server, e.g. is able to run code sychronously with request processing. --mark -----Original Message----- From: John Strassner [mailto:jstrassn@cisco.com] Sent: Tuesday, December 26, 2000 3:46 PM To: Mark Brown (REDMOND); ietf-ldup@imc.org Subject: Re: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Hmm, looks like my message got truncated, let's try again. Hi Mark, thanks for your note. One small suggestion: in your second point about application triggers, you say "Directory servers commonly integrate one or more specific applications". I think you meant that one or more applications may integrate with a given directory server, right? regards, John ----- Original Message ----- From: "Mark Brown (REDMOND)" To: Sent: Wednesday, December 20, 2000 3:08 PM Subject: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt > In San Diego there was some discussion of the limits of LDUP > interoperability. > John Strassner suggested that I draft some material for inclusion in the > requirements draft. Here it is. > > The following material is meant to go right after the first paragraph of > Section 3 > ("The Models"), and just before the sentence "There are five data > consistency > models." > > * * * * * > > The objective is limited to replication between directory servers that > implement a passive store fully described by its LDAP schema. There are > two > ways in which directory servers commonly implement semantics that go > beyond > what the LDAP access protocol defines: > > * Access control. LDAP does not currently define an access control > system. > (The ldapext WG is working to extend LDAP with an access control > system.) > Most directory servers implement an access control system. > > Replication between directory servers with different access control > systems > will compromise directory security. > > * Application triggers. Directory servers commonly integrate one or more > specific applications. To achieve this integration the directory > server > may intercept updates and run application-specific "trigger" code. > Such triggers enforce directory invariants that cannot be expressed by > the > LDAP schema. > > A simple trigger example is password policy enforcement. A directory > server might > interpret a request to replace the current value of the userPassword > attribute > with some new value as a request to first check that the new value > conforms > to the server's password policy (e.g. the value is sufficiently long > and complex) > before storing the new value. Using this trigger the directory server > avoids the > security risk associated with passwords that are easy to attack. > > A more complex trigger example is password hashing. A directory server > might interpret > a request to replace the current value of the userPassword attribute > with some > new value as a request to compute one or more secure hashes of the new > value > and store these hashes in one or more attributes, storing no value in > the > userPassword attribute. Using this trigger the directory server avoids > the > security exposure of storing the plaintext password. > > Replication between directory servers with different application > triggers > will compromise directory integrity. > > * * * * * > > --mark From owner-ietf-ldup@mail.imc.org Tue Jan 9 07:41:19 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09833 for ; Tue, 9 Jan 2001 07:41:18 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA25359 for ietf-ldup-bks; Tue, 9 Jan 2001 03:44:07 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA25355 for ; Tue, 9 Jan 2001 03:44:06 -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 GAA08885; Tue, 9 Jan 2001 06:49:01 -0500 (EST) Message-Id: <200101091149.GAA08885@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-06.txt Date: Tue, 09 Jan 2001 06:49:01 -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-06.txt Pages : 28 Date : 08-Jan-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-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-replica-req-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-replica-req-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: <20010108124856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldup-replica-req-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldup-replica-req-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010108124856.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldup@mail.imc.org Tue Jan 9 10:49:52 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14333 for ; Tue, 9 Jan 2001 10:49:51 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA06249 for ietf-ldup-bks; Tue, 9 Jan 2001 06:41:00 -0800 (PST) Received: from mailgate1.austin.ibm.com (mg01.austin.ibm.com [192.35.232.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06245 for ; Tue, 9 Jan 2001 06:40:58 -0800 (PST) Received: from austin.ibm.com (netmail.austin.ibm.com [9.53.250.98]) by mailgate1.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA27718; Tue, 9 Jan 2001 08:46:15 -0600 Received: from estokes.austin.ibm.com (lig32-225-39-195.us.lig-dial.ibm.com [32.225.39.195]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id IAA47008; Tue, 9 Jan 2001 08:45:45 -0600 Message-Id: <5.0.2.1.0.20010109084006.00a640c0@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 09 Jan 2001 08:45:40 -0600 To: "Mark Brown (REDMOND)" , "Kurt D. Zeilenga" From: Ellen Stokes Subject: RE: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Cc: In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657493DD30@DF-BOWWOW.platinum. corp.microsoft.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: Mark, The types of things you're talking about are typically ldap extensions which are advertised in the root DSE by (registered) OID. So one could conclude that the replication admin program could check to see that servers wanting to replicate support the same extensions and allow the admin to decide if to proceed in setting up the replicas. I'm not sure I understand your 'passive store' statement. Can you explain? Is there a flip side you're thinking about if the word passive changes to active? Ellen At 02:58 PM 1/8/2001 -0800, Mark Brown (REDMOND) wrote: >The essential question is, if I've got directory >servers A and B that both say they support LDUP, >how do I know that it is OK to hook them together >to replicate via LDUP? > >Suppose for instance that server A has a >change-password trigger that recomputes password hashes, >and server B doesn't. And suppose I set up A and B to >replicate in a multi-master fashion. Then a user who >changes her password on server B won't be able to >authenticate on server A once server B replicates to >server A. > >The problem created by replication goes beyond A and B >having "different capabilities." B has broken an >invariant that A was trying to maintain. B was working >before A came on the scene, but now B is broken. > >So we need some way to characterize the servers that are >OK to hook together. Pairwise testing is obviously not >the answer. The suggestion I've made below is to limit LDUP >to "replication between directory servers that implement >a passive store fully described by its LDAP schema." >It seems quite plausible that we can achieve replication >between such servers without compromising their >functionality. > >It may be possible to relax this suggested limit, but I'm >not sure how. If someone on the list knows how, they should >make a proposal. > >It seems pretty important to deal with this issue in the >requirements draft, since it is squarely a requirements >issue. > >--mark > >-----Original Message----- >From: Ellen Stokes [mailto:stokes@austin.ibm.com] >Sent: Tuesday, January 02, 2001 10:47 AM >To: Kurt D. Zeilenga; Mark Brown (REDMOND) >Cc: ietf-ldup@imc.org >Subject: Re: interoperability limits: proposed addition to >draft-ietf-ldup-replica-req-05.txt > >Kurt, > >At least part of your request for applicability (in your second >paragraph) will be covered in the Master-slave and multi-master >profile documents being authored by Rick Huber. > >Ellen > > >At 06:43 PM 12/20/2000 -0800, Kurt D. Zeilenga wrote: > >Unless the servers are truly equally capable, which is unlikely > >if provided by different developers, the replicates will not > >be equally capable regardless of well they interoperate with > >each other and LDAP clients. That is, application protocol > >interoperability in no way guarantees that multiple implementations > >behave in the exact same manner given exact replication of > >information between them. > > > >However, an applicability statement can help by narrowing > >the options available to LDAP/LDUP implementors. I believe the > >LDUP WG should, in addition to specifying a replication protocol, > >provide an applicability statement stating whatever additional > >requirements there are of LDAP/LDUP servers such that each > >replica is "equally capable" of processing an operation. > > > >Kurt > > > > > >At 03:08 PM 12/20/00 -0800, Mark Brown (REDMOND) wrote: > > >In San Diego there was some discussion of the limits of LDUP > > >interoperability. > > >John Strassner suggested that I draft some material for inclusion in >the > > >requirements draft. Here it is. > > > > > >The following material is meant to go right after the first paragraph >of > > >Section 3 > > >("The Models"), and just before the sentence "There are five data > > >consistency > > >models." > > > > > >* * * * * > > > > > >The objective is limited to replication between directory servers >that > > >implement a passive store fully described by its LDAP schema. There >are > > >two > > >ways in which directory servers commonly implement semantics that go > > >beyond > > >what the LDAP access protocol defines: > > > > > >* Access control. LDAP does not currently define an access control > > >system. > > > (The ldapext WG is working to extend LDAP with an access control > > >system.) > > > Most directory servers implement an access control system. > > > > > > Replication between directory servers with different access control > > >systems > > > will compromise directory security. > > > > > >* Application triggers. Directory servers commonly integrate one or >more > > > specific applications. To achieve this integration the directory > > >server > > > may intercept updates and run application-specific "trigger" code. > > > Such triggers enforce directory invariants that cannot be expressed >by > > >the > > > LDAP schema. > > > > > > A simple trigger example is password policy enforcement. A >directory > > >server might > > > interpret a request to replace the current value of the >userPassword > > >attribute > > > with some new value as a request to first check that the new value > > >conforms > > > to the server's password policy (e.g. the value is sufficiently >long > > >and complex) > > > before storing the new value. Using this trigger the directory >server > > >avoids the > > > security risk associated with passwords that are easy to attack. > > > > > > A more complex trigger example is password hashing. A directory >server > > >might interpret > > > a request to replace the current value of the userPassword >attribute > > >with some > > > new value as a request to compute one or more secure hashes of the >new > > >value > > > and store these hashes in one or more attributes, storing no value >in > > >the > > > userPassword attribute. Using this trigger the directory server >avoids > > >the > > > security exposure of storing the plaintext password. > > > > > > Replication between directory servers with different application > > >triggers > > > will compromise directory integrity. > > > > > >* * * * * > > > > > >--mark From owner-ietf-ldup@mail.imc.org Tue Jan 9 19:19:36 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23541 for ; Tue, 9 Jan 2001 19:19:35 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA03180 for ietf-ldup-bks; Tue, 9 Jan 2001 15:03:50 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA03176 for ; Tue, 9 Jan 2001 15:03:49 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 9 Jan 2001 15:05:27 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 09 Jan 2001 15:05:34 -0800 (Pacific Standard Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Tue, 9 Jan 2001 15:06:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 content-class: urn:content-classes:message Subject: RE: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 9 Jan 2001 15:05:33 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657493DD34@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Thread-Index: AcB6Wqn4spDRiZnyTXOox33n3H5NOQALfpAQ From: "Mark Brown (REDMOND)" To: "Ellen Stokes" , "Kurt D. Zeilenga" Cc: X-OriginalArrivalTime: 09 Jan 2001 23:06:09.0966 (UTC) FILETIME=[C1156CE0:01C07A90] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA03177 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit None of the examples I've used are things you'd register as LDAP extensions, because they have no effect on LDAP as an access protocol: You can add access control capabilities to a directory server without extending LDAP -- clients perform LDAP requests, the server returns appropriate results (including LDAP result codes such as "insufficientAccessRights") after doing its internal access checking. No extension to LDAP. A password policy can be viewed as a specialized access control rule -- the server simply fails password change requests that don't conform to the policy. All the LDAP client sees is a failed Modify request. No extension to LDAP. A change-password trigger that computes and stores password hashes is just a specialized Modify operation. The server stores the hashes in attributes that are well-known to the authentication packages that read them. These authentication packages cohabit the directory server process and read the hashes as needed via an internal API, not using LDAP. From the LDAP client perspective the change-password is just a Modify. No extension to LDAP. In summary, the capabilities I'm talking about are things that change the semantics of directory entries without any impact on the access protocol. In contrast, many LDAP extensions extend the access protocol without changing the semantics of directory entries. Their goal is to give you a way to express your access in a more efficient way. Examples include a control that lets you delete a sub-tree of entries in a single operation, and a control that lets you "cursor" through the results of a search (VLV.) There is no inherent difficulty replicating between a server that supports (say) sub-tree delete and a server that doesn't. So it would be unnecessarily restrictive to limit LDUP to operate only between servers that implement the same LDAP extensions. The "passive store" characterization is meant to capture the idea that the directory server stores the entries that come in over the wire and retrieves them later -- period. You can store something, then read it back later and you get what you stored. Any restrictions on what you can store must be expressed in the schema, and any restrictions on who can do the writing and reading must be expressed in terms of some standardized access control scheme. This is in contrast to an "active store" that implements triggers or other rules that extend the semantics of entries beyond what's implied by LDAP. --mark -----Original Message----- From: Ellen Stokes [mailto:stokes@austin.ibm.com] Sent: Tuesday, January 09, 2001 6:46 AM To: Mark Brown (REDMOND); Kurt D. Zeilenga Cc: ietf-ldup@imc.org Subject: RE: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Mark, The types of things you're talking about are typically ldap extensions which are advertised in the root DSE by (registered) OID. So one could conclude that the replication admin program could check to see that servers wanting to replicate support the same extensions and allow the admin to decide if to proceed in setting up the replicas. I'm not sure I understand your 'passive store' statement. Can you explain? Is there a flip side you're thinking about if the word passive changes to active? Ellen At 02:58 PM 1/8/2001 -0800, Mark Brown (REDMOND) wrote: >The essential question is, if I've got directory >servers A and B that both say they support LDUP, >how do I know that it is OK to hook them together >to replicate via LDUP? > >Suppose for instance that server A has a >change-password trigger that recomputes password hashes, >and server B doesn't. And suppose I set up A and B to >replicate in a multi-master fashion. Then a user who >changes her password on server B won't be able to >authenticate on server A once server B replicates to >server A. > >The problem created by replication goes beyond A and B >having "different capabilities." B has broken an >invariant that A was trying to maintain. B was working >before A came on the scene, but now B is broken. > >So we need some way to characterize the servers that are >OK to hook together. Pairwise testing is obviously not >the answer. The suggestion I've made below is to limit LDUP >to "replication between directory servers that implement >a passive store fully described by its LDAP schema." >It seems quite plausible that we can achieve replication >between such servers without compromising their >functionality. > >It may be possible to relax this suggested limit, but I'm >not sure how. If someone on the list knows how, they should >make a proposal. > >It seems pretty important to deal with this issue in the >requirements draft, since it is squarely a requirements >issue. > >--mark > >-----Original Message----- >From: Ellen Stokes [mailto:stokes@austin.ibm.com] >Sent: Tuesday, January 02, 2001 10:47 AM >To: Kurt D. Zeilenga; Mark Brown (REDMOND) >Cc: ietf-ldup@imc.org >Subject: Re: interoperability limits: proposed addition to >draft-ietf-ldup-replica-req-05.txt > >Kurt, > >At least part of your request for applicability (in your second >paragraph) will be covered in the Master-slave and multi-master >profile documents being authored by Rick Huber. > >Ellen > > >At 06:43 PM 12/20/2000 -0800, Kurt D. Zeilenga wrote: > >Unless the servers are truly equally capable, which is unlikely > >if provided by different developers, the replicates will not > >be equally capable regardless of well they interoperate with > >each other and LDAP clients. That is, application protocol > >interoperability in no way guarantees that multiple implementations > >behave in the exact same manner given exact replication of > >information between them. > > > >However, an applicability statement can help by narrowing > >the options available to LDAP/LDUP implementors. I believe the > >LDUP WG should, in addition to specifying a replication protocol, > >provide an applicability statement stating whatever additional > >requirements there are of LDAP/LDUP servers such that each > >replica is "equally capable" of processing an operation. > > > >Kurt > > > > > >At 03:08 PM 12/20/00 -0800, Mark Brown (REDMOND) wrote: > > >In San Diego there was some discussion of the limits of LDUP > > >interoperability. > > >John Strassner suggested that I draft some material for inclusion in >the > > >requirements draft. Here it is. > > > > > >The following material is meant to go right after the first paragraph >of > > >Section 3 > > >("The Models"), and just before the sentence "There are five data > > >consistency > > >models." > > > > > >* * * * * > > > > > >The objective is limited to replication between directory servers >that > > >implement a passive store fully described by its LDAP schema. There >are > > >two > > >ways in which directory servers commonly implement semantics that go > > >beyond > > >what the LDAP access protocol defines: > > > > > >* Access control. LDAP does not currently define an access control > > >system. > > > (The ldapext WG is working to extend LDAP with an access control > > >system.) > > > Most directory servers implement an access control system. > > > > > > Replication between directory servers with different access control > > >systems > > > will compromise directory security. > > > > > >* Application triggers. Directory servers commonly integrate one or >more > > > specific applications. To achieve this integration the directory > > >server > > > may intercept updates and run application-specific "trigger" code. > > > Such triggers enforce directory invariants that cannot be expressed >by > > >the > > > LDAP schema. > > > > > > A simple trigger example is password policy enforcement. A >directory > > >server might > > > interpret a request to replace the current value of the >userPassword > > >attribute > > > with some new value as a request to first check that the new value > > >conforms > > > to the server's password policy (e.g. the value is sufficiently >long > > >and complex) > > > before storing the new value. Using this trigger the directory >server > > >avoids the > > > security risk associated with passwords that are easy to attack. > > > > > > A more complex trigger example is password hashing. A directory >server > > >might interpret > > > a request to replace the current value of the userPassword >attribute > > >with some > > > new value as a request to compute one or more secure hashes of the >new > > >value > > > and store these hashes in one or more attributes, storing no value >in > > >the > > > userPassword attribute. Using this trigger the directory server >avoids > > >the > > > security exposure of storing the plaintext password. > > > > > > Replication between directory servers with different application > > >triggers > > > will compromise directory integrity. > > > > > >* * * * * > > > > > >--mark From owner-ietf-ldup@mail.imc.org Tue Jan 9 21:02:54 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24477 for ; Tue, 9 Jan 2001 21:02:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA05093 for ietf-ldup-bks; Tue, 9 Jan 2001 16:53:07 -0800 (PST) Received: from pretender.boolean.net (router.boolean.net [198.144.206.49]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA05087 for ; Tue, 9 Jan 2001 16:52:56 -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 f0A0sHh03224; Wed, 10 Jan 2001 00:54:17 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.0.2.1.0.20010109164825.00a969a0@router.boolean.net> X-Sender: guru@router.boolean.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 09 Jan 2001 16:54:16 -0800 To: "Mark Brown (REDMOND)" From: "Kurt D. Zeilenga" Subject: RE: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Cc: "Ellen Stokes" , In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657493DD34@DF-BOWWOW.platinum. 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: Mark, Replication in the face of triggers or any other LDAP extension should be specified in extensions to the LDUP. LDUP should assume 'passive' servers as this, I believe, is the LDAP/X.500 data model. That is, servers should not muck with user data. Kurt From owner-ietf-ldup@mail.imc.org Thu Jan 11 11:34:08 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07002 for ; Thu, 11 Jan 2001 11:34:06 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA28812 for ietf-ldup-bks; Thu, 11 Jan 2001 07:13:06 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA28800 for ; Thu, 11 Jan 2001 07:13:04 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA120124 for ; Thu, 11 Jan 2001 10:16:48 -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 KAA167204 for ; Thu, 11 Jan 2001 10:14:57 -0500 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA328204 for ; Thu, 11 Jan 2001 09:00:38 -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 IAA48338 for ; Thu, 11 Jan 2001 08:58:47 -0500 X-Priority: 3 (Normal) Reply-To: "Timothy Hahn" Importance: Normal X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 MIME-Version: 1.0 Subject: Comments on draft-ietf-ldup-model-05.txt To: ietf-ldup@imc.org Message-ID: From: "Timothy Hahn" Date: Thu, 11 Jan 2001 10:05:16 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.6 |January 4, 2001) at 01/11/2001 10:17:41 AM Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings, General: From a replication management/configuration and server perspective, it seems we ought to define a standard way for setting and/or looking up a server's replica ID. A server needs to know its own ID to generate CSNs, and to configure replication you need to be able to determine the IDs of the other participating servers. This might be better addresed in the information model. Proposal: Add a root DSE attribute, replicaID, that "advertises" the server's ID. How this value is set could be implementation defined, but if I were developiong a replication management tool, I would like to be able to set this attribute via LDAP operations from the management tool. I suggest that this attribute must be modifiable via a modify operation on the root DSE. Alternately, I could see that it might be desirable to make this an attribute of the replication area "name context" object -- though I don't know of any need for a "per replication area" replicaID. General - I feel that this document should have a section that shows which requirements (from the replication requirements draft) are addressed and which are not - instead of leaving this as an "exercize for the reader". 3.3.e - Please clarify what is meant by "overlapping replicated regions". 4.1 - I think that replica Type should have a setting for listing the replica as "partial". 4.4 - What is the format/algorithm for generating entry UUIDs? What is the canonical string representation for an entry's UUID? Where is the full attribute type definition and OID for "entryUUID" defined? Will there be a new syntax? 4.5 - If a Modify operation MUST assign one CSN per modification, is there an order here? I assume that CSNs are assigned IN ORDER of the modification list, one CSN per modification item in the list. Is this the intent? 4.5.1 - What is the recommended format and choice for the replica ID, as used in the CSN and elsewhere? Common use of the term replica ID and replica Identifier would be nice. Some refer to this as the "rdn attribute", others, including examples, use integers. If this is an integer, shouldn't the integer value be in the replicaSubentry as a separate attribute? 4.6 - Do all attribute values have CSN's or only those that have been modified or deleted? 4.6.1 - Need more explanation on the last sentence of this section: "A CSN is recorded for both the RDN, and the Superior DN of the entry." Does LDUP require storing the Superior DN and/or Superior UUID with every entry? Is the "superior entry" marked as updated? Or do there exist separate CSNs in EACH ENTRY corresponding to rdnCSN and superiorDNCSN, in addition to createdEntryCSN and deletedEntryCSN? 5.1 - It seems like the schema is always associated with the naming context, and that naming contexts can be nested. Is this right? Is there any meaning for the subschema entry pointed to by the rootDSE? How are subschema entries related to replication contexts - if at all? 5.1 - The CSN format seems to imply that the naming attribute for replicaSubentry entries MUST be caseIgnoreIA5. This should be stipulated. 5.2 - What are the rootDSE attributes needed for LDUP replication? I don't see them in the information model. In section 7.3, I saw a reference to to a 'supportedReplicationProtocols' attribute - there may be others. 5.4 - It should it be noted that Fractional replicas can ONLY be read-only. 5.5 - What is the DN of the Lost and Found entry? 5.6 - How should the authentication credentials be stored securely? 6.1 - Need clarification relative to the meaning of the subschemasubentry attribute in the rootDSE. Does paragraph two then imply a requirement that schema be updateable (as well as published)? Should this be a setting (whether or not to replicate schema updates) in the replica agreement? Recommend we allow choice in replication agreement of whether schema should be replicated. 6.1 - "Given the strict ordering of replication events, schema modifications will naturally be replicated ...". I don't recall such an ordering requirement. It may be implicit in a log-based implementation, but not in a state-based implementation. It does seem, though, that some ordering of schema changes and entry changes is required. This could be a problem in implementations (many) where the schema is server-wide. Proposal(s): 1) Replace this statement with a MUST(?) requirement to the effect: "To ensure that schema modifications precede entry creations/modifications that use them and follow data deletions which eliminate references to schema elements to be changed or deleted, replication MUST preserve the ordering of schema changes with respect to other directory entry changes." 2) Alternately, it seems that a requirement could be imposed for the servers to recheck "damaged" entries as schema changes come in, the goal in either case being that at the end of successful replication of entry changes and associated schema changes, no entries be in an "administrative action required" state. I do not have a feel for which is better, but I do feel that as currently stated, the "strict ordering" referred to does not exist, making it possible that an administrator might have to do some sort of repair for entries that either aren't really broken, and needn't have become broken. What other LDUP drafts will clarify this? 7.1.1 - says that the credentials for authenticated bind to another replica are kept as attributes within replication agreements. The information model shows no such attributes. 7.3 - required changes to the rootDSE should be summarized somewhere - information model draft perhaps? 9.1 - Full Update Transfer: This seems impractical for large naming contexts, because it would take too long. Are there any alternatives that should be considered? 9.4 - This paragraph seems to imply that replicaSubentry objects are also replicated between replica servers. However, in absence of this information (becuase the "new" replica isn't "well known" yet - unknown updateVector information, for example), how does the supplier know that it should be keeping track of updates? Maybe this only applies to log-based replication? 9.4 - The paragraph, as written, seems to imply that if a full update is to be performed, then prior to starting, a 'snapshot' of the whole replication context must be taken so that incremental changes that come in can thence be sent to the replica. If so, this should be clarified/pointed out. 10 - What is the recommended error code? LDAP_UNWILLING_TO_PERFORM? Serializing all replication operations would seem to require some explanation as to why. 10.5.4 - What is the mechanism for marking an entry as requiring "administrative repair"? Is this information intended to be LDAP accessible? Proposal: I would like to see this (needs administrative repair) accessible via LDAP, with some information as to the nature of the error. To this end, we could add an operational attribute(?), replicationSchemaError, which is present if replication introduces a schema violation. A subsequent LDAP (or replication) operation which corrects this error will result in the replicationSchemaError attribute no longer being returned on a search. If a schema change is required to correct the error, the mechanism for correcting the error would be to update the schema, then perform an LDAP modify operation to delete the replicationSchemaError attribute. If the object no longer violates the schema, the operation will succeed. The syntax of this attribute would be directory string. Implementations should set the attribute to a string describing the error (for example, "attribute xxx not allowed"). Implementations may return the attribute as an empty string. 10.5.7 - "The resolution procedure is to break the cycle by changing the parent of the entry closest to be the lost and found entry." Closest to what? To the root? Why not say "the resolution procedure is to move the entry (and possibly whole sub-tree) into the lost+found area"? 12 - How much of replication management entries are replicated? 12 - Step one of the example scenario; what is a "context prefix"? 12 - Why is step 5 necessary? Why isn't this information just replicated over on the next replication between the two replicas? 13 - hat is the diference between serverClocksOutOfSync (72) and excessiveCSNskew (200), defined in the LDUP Replication Update Protocol? ExcessiveCSNskew is not referenced outside of the protocol draft. 14 - There appears to be a "special case" in replication processing in that the "authentication information" that is presumably stored in replication agreement subentries should NOT be replicated. Thus, servers must code special work-arounds to avoid replicating this information. Is this the intent? 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 From owner-ietf-ldup@mail.imc.org Thu Jan 11 19:16:48 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16713 for ; Thu, 11 Jan 2001 19:16:47 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA04824 for ietf-ldup-bks; Thu, 11 Jan 2001 15:08:00 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA04819 for ; Thu, 11 Jan 2001 15:07:58 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 11 Jan 2001 15:09:44 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Jan 2001 15:10:27 -0800 (Pacific Standard Time) Received: from DINO.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Thu, 11 Jan 2001 15:10:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Date: Thu, 11 Jan 2001 15:10:26 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657493DD40@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Thread-Index: AcB6sWFl1T8240cNSPKDgwJWatqJvgBYCxTQ From: "Mark Brown (REDMOND)" To: "Ellen Stokes" , "Kurt D. Zeilenga" Cc: X-OriginalArrivalTime: 11 Jan 2001 23:10:27.0103 (UTC) FILETIME=[AF2CEAF0:01C07C23] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA04820 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit We appear to be in total agreement. So I suggest inserting the following paragraph right after the first paragraph of Section 3 ("The Models") of the requirements draft (just before the sentence "There are five data consistency models.") --mark * * * * * The objective is limited to replication between directory servers that implement a passive store fully described by its LDAP interface. "Passive store" means that the servers are limited to storing entries that come in via LDAP and retrieving those entries later in response to LDAP requests. The entire semantics of the passive store is defined by its LDAP interface. Any restrictions on what the server can store must be expressed in the server's schema, and any restrictions on the access that clients have to the store must be expressed in terms of a standardized LDAP access control scheme. This is in contrast to an "active store" that implements triggers or other rules that extend the semantics of entries beyond what's implied by LDAP. Replication between such active stores should be specified in extensions to LDUP. * * * * * --mark -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Tuesday, January 09, 2001 4:54 PM To: Mark Brown (REDMOND) Cc: Ellen Stokes; ietf-ldup@imc.org Subject: RE: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Mark, Replication in the face of triggers or any other LDAP extension should be specified in extensions to the LDUP. LDUP should assume 'passive' servers as this, I believe, is the LDAP/X.500 data model. That is, servers should not muck with user data. Kurt From owner-ietf-ldup@mail.imc.org Thu Jan 11 23:53:40 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21963 for ; Thu, 11 Jan 2001 23:53:39 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA10511 for ietf-ldup-bks; Thu, 11 Jan 2001 19:51:26 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA10507 for ; Thu, 11 Jan 2001 19:51:24 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 11 Jan 2001 19:39:53 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Jan 2001 19:40:37 -0800 (Pacific Standard Time) Received: from DINO.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Thu, 11 Jan 2001 19:40:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Date: Thu, 11 Jan 2001 19:40:35 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657404088418@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Thread-Index: AcB6sWFl1T8240cNSPKDgwJWatqJvgBYCxTQAA017FA= From: "Mark Brown (REDMOND)" To: "Ellen Stokes" , "Kurt D. Zeilenga" Cc: X-OriginalArrivalTime: 12 Jan 2001 03:40:36.0177 (UTC) FILETIME=[6C895410:01C07C49] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id TAA10508 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Oops, I left off the examples. Let's try again: I suggest inserting the following material right after the first paragraph of Section 3 ("The Models") of the requirements draft (just before the sentence "There are five data consistency models.") --mark * * * * * The objective is limited to replication between directory servers that implement a passive store fully described by its LDAP interface. "Passive store" means that the servers are limited to storing entries that come in via LDAP and retrieving those entries later in response to LDAP requests. The entire semantics of the passive store is defined by its LDAP interface. Any restrictions on what the server can store must be expressed in the server's schema, and any restrictions on the access that clients have to the store must be expressed in terms of a standardized LDAP access control scheme. This is in contrast to an "active store" that implements triggers or other rules that extend the semantics of entries beyond what's implied by LDAP. Replication between such active stores should be specified in extensions to LDUP. Here are some examples of ways in which directory servers implement semantics that go beyond what the LDAP access protocol defines: * Access control. LDAP does not currently define an access control scheme. (The ldapext WG is working to extend LDAP with an access control scheme.) Most directory servers implement an access control scheme. Replication between directory servers with different access control schemes would compromise directory security, so such replication is not supported by LDUP. * Password policy. Some directory servers restrict changes to password attributes, requiring that the new password value conform to a specific security policy (e.g. the value is sufficiently long and complex.) Doing so reduces the security risk associated with passwords that are easy to attack. Replication between directory servers with different password policies (e.g. one server implements a password policy and a second server implements no policy) would compromise directory security, so such replication is not supported by LDUP. * Password hashing. Some directory servers don't store a user's password directly, but instead store one or more secure hashes of the password. Doing so makes it less likely that anyone (even an administrator) can discover the password. Replication between a directory server that stores passwords and a directory server that stores only hashes will compromise directory integrity, causing authentications to fail unexpectedly, so such replication is not supported by LDUP. * * * * * -----Original Message----- From: Mark Brown (REDMOND) Sent: Thursday, January 11, 2001 3:10 PM To: Ellen Stokes; 'Kurt D. Zeilenga' Cc: ietf-ldup@imc.org Subject: RE: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt We appear to be in total agreement. So I suggest inserting the following paragraph right after the first paragraph of Section 3 ("The Models") of the requirements draft (just before the sentence "There are five data consistency models.") --mark * * * * * The objective is limited to replication between directory servers that implement a passive store fully described by its LDAP interface. "Passive store" means that the servers are limited to storing entries that come in via LDAP and retrieving those entries later in response to LDAP requests. The entire semantics of the passive store is defined by its LDAP interface. Any restrictions on what the server can store must be expressed in the server's schema, and any restrictions on the access that clients have to the store must be expressed in terms of a standardized LDAP access control scheme. This is in contrast to an "active store" that implements triggers or other rules that extend the semantics of entries beyond what's implied by LDAP. Replication between such active stores should be specified in extensions to LDUP. * * * * * --mark -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Tuesday, January 09, 2001 4:54 PM To: Mark Brown (REDMOND) Cc: Ellen Stokes; ietf-ldup@imc.org Subject: RE: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Mark, Replication in the face of triggers or any other LDAP extension should be specified in extensions to the LDUP. LDUP should assume 'passive' servers as this, I believe, is the LDAP/X.500 data model. That is, servers should not muck with user data. Kurt From owner-ietf-ldup@mail.imc.org Fri Jan 12 03:17:15 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06128 for ; Fri, 12 Jan 2001 03:17:14 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA20325 for ietf-ldup-bks; Thu, 11 Jan 2001 23:28:28 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA20319 for ; Thu, 11 Jan 2001 23:28:26 -0800 (PST) Received: (qmail 22841 invoked from network); 12 Jan 2001 07:33:04 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 12 Jan 2001 07:33:04 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'Mark Brown \(REDMOND\)'" , "'Ellen Stokes'" , "'Kurt D. Zeilenga'" Cc: Subject: RE: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt Date: Fri, 12 Jan 2001 18:35:41 +1100 Message-ID: <000201c07c6a$44726860$17448490@vic.bigpond.net.au> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_01C07CC6.77E2E060" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <5B90AD65A9E8934987DB0C8C0762657404088418@DF-BOWWOW.platinum.corp.microsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MS-TNEF-Correlator: 000000003893B2F86024D41184F100E0296560F7A4AF8500 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_0003_01C07CC6.77E2E060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit [Mark] Here are some examples of ways in which directory servers implement semantics that go beyond what the LDAP access protocol defines: * Access control. LDAP does not currently define an access control scheme. (The ldapext WG is working to extend LDAP with an access control scheme.) Most directory servers implement an access control scheme. Replication between directory servers with different access control schemes would compromise directory security, so such replication is not supported by LDUP. [Albert] Essentially this simply means that LDUP is pretty useless until an access control scheme is specified. Problem is that without atomicity, it will remain pretty useless when the current drafts for access controls are finalized. But that's another topic - still waiting for promised response from Chris. [Mark] * Password policy. Some directory servers restrict changes to password attributes, requiring that the new password value conform to a specific security policy (e.g. the value is sufficiently long and complex.) Doing so reduces the security risk associated with passwords that are easy to attack. Replication between directory servers with different password policies (e.g. one server implements a password policy and a second server implements no policy) would compromise directory security, so such replication is not supported by LDUP. [Albert] This may be overstated. It might be possible to instead deal with this problem by requiring that LDUP protocols provide special case handling for schema elements that are designated as passwords by some per server entry that specifies a password policy identifier, so that other servers will not make accessible (but will still forward) replication of those attributes when they do not understand and implement the required policy. That could be messy and could still result in flaky behaviour of passwords being available from some servers and not from others, but it would not compromise directory security and therefore would not be a complete show-stopper, since implementations suffering could fix the problem incrementally instead of LDUP being completely useless (ie unable to replicate between major implementations since they have different password policy techniques). Requirement should be for mandatory disclosure of password policy mechanisms by implementations claiming conformance, with some sort of IANA registry. [Mark] * Password hashing. Some directory servers don't store a user's password directly, but instead store one or more secure hashes of the password. Doing so makes it less likely that anyone (even an administrator) can discover the password. Replication between a directory server that stores passwords and a directory server that stores only hashes will compromise directory integrity, causing authentications to fail unexpectedly, so such replication is not supported by LDUP. [Albert] Again, it may be possible to special case this rather than declaring that LDUP is fundamentally incapable of providing interoperability between major directory implementations. [Mark - from previous message] The objective is limited to replication between directory servers that implement a passive store fully described by its LDAP interface. "Passive store" means that the servers are limited to storing entries that come in via LDAP and retrieving those entries later in response to LDAP requests. The entire semantics of the passive store is defined by its LDAP interface. Any restrictions on what the server can store must be expressed in the server's schema, and any restrictions on the access that clients have to the store must be expressed in terms of a standardized LDAP access control scheme. This is in contrast to an "active store" that implements triggers or other rules that extend the semantics of entries beyond what's implied by LDAP. Replication between such active stores should be specified in extensions to LDUP. [Albert] I'm not clear about this. Triggers are not extensions to LDUP, but to LDAP, since they are equally relevant without replication. There are LDAP extensions specifying drafts or standards for an LDAP client to subscribe to notifications about particular types of changes. If that, or any other mechanism results in an application external to the directory service making changes to directory entries, then those changed entries must be replicated normally. It is not clear to me that the fact that some implementations actually make such changes internally within the directory server rather than via an external application makes any difference. In principle it is still something outside the directory service (as specified by LDAP and X500) making changes to directory entries. Conformance to LDUP simply requires that those changes, however made, be replicated. eg if Microsoft Active Directory "backlinks" are visible in the replication schema, then conformance would require that you replicate the changes to the backlink as well as the forward link via LDUP, even though replication to other Microsoft servers within the replication area could more efficiently just rely on each server performing an update to the backlink independently when the forward link is changed. ------=_NextPart_000_0003_01C07CC6.77E2E060 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IioHAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHAQAMABIAIwAAAAUAHwEB A5AGAPgPAAAoAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAABRAAAAaW50ZXJvcGVyYWJpbGl0eSBsaW1pdHM6IHByb3Bvc2VkIGFkZGl0aW9u IHRvIGRyYWZ0LWlldGYtbGR1cC1yZXBsaWNhLXJlcS0wNS50eHQAAAAAAgFxAAEAAAAWAAAAAcB8 akOw11ZOZeixEdSE8wDgKWVg9wAAAgEdDAEAAAApAAAAU01UUDpBTEJFUlQuTEFOR0VSQERJUkVD VE9SWS1ERVNJR05TLk9SRwAAAAALAAEOAAAAAEAABg4AajoranzAAQIBCg4BAAAAGAAAAAAAAAA4 k7L4YCTUEYTxAOApZWD3woAAAAMAFA4BAAAACwAfDgEAAAACAQkQAQAAAPkKAAD1CgAAxhcAAExa RnWXzJLGAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUHshElDlED AQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFAzCwkBZDM2FlAL piBbsk0KwGtdCqIKgEgEkOxlIArAHeBzA3Ad4A7ADGFtC1AHkW9mIHdcYXkEIAuAH0BoDeBoSCBk aRggY3QFsHnrHjAEkHYEkHMdVAdwHtFvB4ACMCDBA4F0DeAEIHQDE+AFQGdvIGJleT0CIGQfwSMB IuAd4ExEZEFQHfBjYweQITVwfwNgIIAXkSAgARALgAeQOtsdVB1UKhDAJMMgBaACMEkDYGwuJFRk bweRbt8lkCfACHAYIAIwbCCwJgT3HfADoCS6ICfGHjAT0CHhCShAKFQkMWxkYXBZDsJXRx+QBCB3 BbBr/QuAZyLQI0AOwQnwI7AkYl8q5gPwIuAqSCteKQXQb/5zBUAgPyrmIagvzyvWJoq5K0BSZQtQ DeAjAGkCIPkjUXR3CeExvy1xL4I3oH8BIB3BAjAq5jQvLAItcnX/LLAnwR7AA2EEAB3gN6opQfkv gHksKuYeQB4wGtAgEJ8YIDaILWEpAj6AcHAXwU8JgCNQILAkYFVQNXtb3EFsI2AAIB1FRQQQIgH/ BzEpsSLgLWEAkB7BILAHgH8GIiLjQNItUiVwFCA9oCDudRQQHuEEIHUigRgAHWPXM/8r1S1Scyzg YwaQCJD6ZChAUANgAmAh4C1SIuP/L3IIYDmVIwA8QUkAPaEfkP9KYkNAPsEAwB+hRX0f0Ddx5yQi KUU3kHJhAYAhNQIQPwXAR0wEIB4CJiEHQGl67UlCQkrQItMnUNEpASQwywXAMhBwDeAgLQrjCoD/ MZBMQh9QL4At0k+yPCUjsL8YIEjQAiA8cQNSEiBoBRDOc0EcHQknQFBhBBAtkdcjsEAwNpF5KEBT HlI3r/9VkigADeApIRPgLeAHkCrm3y4RCrBYpSMAWzFiStAHkPNL4BggcXUx0C3TI+YmQPcH4Fy2 KuZ2B0AKUCfCT7H7SeAuEWFIxlNQPUZZBSxQfSwwZyhAJCJgczLXQ7F1/wEgS5EphBewLeEAcDvU HuDyeDFBRG8t0j5RGCEa0N8HkSQhPddiRlahax3wBBD/JbAHMEBiL3NctiLFHgJEULpzQ2FvOacC QADQazV//zaPWd84ryr1XLdZEwiQBCD/YzQCIB4hIOMzSFDRX29ixf9l8mGBBZEjoXNvKPFZBTFQ /zuTKug8Hz0pPk8/WD3XQB//QS9CNyxwLWEAwCCwI2AfEG8hAgGQffEoQEkFQHngZ/5oBUCA4X3A BBBdgB7gLgL/C4AxkERQI7ABAAdAL2MdVP9DgyVxSbN+MV4NRPMldoTz/HZpAQBIxIPxbjAUEB1U /VuhZG4QVKUr42GARgF0JPdrFwEAAJBnUVB98liQamn/fjEeQiUVEoF25SIBIKEi479I1nRqYraH 4SKBSSFye1J/hGYjAVK0b8hMUSkCAMBr9x3hJMOC0yhdkUwkU/RPsfsfUAsgKR1Ue/ofIUqhegH/ XUhN1ynBI0ApAkZgBIGBUf92IiOgIU4kIl4EfgFZFSaK/yxwIwEFoDuygOEHgWvBZfS/O7JT9FWh O7AFQB+hZgtg/muAwhPgh9AIYR8SancdVP8jYC3SoVALcAtgguJWMx5D/2/GZfIpAlYzUrNd0ZUi TAL/eMgpA3mfPRll41LCARAFsO8d4DuUKQKA4WEdVGY0DrDzHjBKsHctMZBTII3xe1H/C4Ak0DNI bkNktAZxLeGeNP0mIHhn2IUWrTFMga3iQ0J/g1YfIUTzouSrtimxReYo/wiQHVRGYKOTLhF79h3g bqb9AMBqBbGtj60zmUOI5iEAf3CIkA8OsBPQAwBeIAeQKf9s+23gnEMh9EqxnmRPsgOB/yzAMhNv IATwF7B7oB3RocnfWQUdVAeAW5IEAG2NA7b+/77gC3CoEK7zYPMAcCTQS+AfL3OkNBfBHVQfIUlB TvpBe+FnBACOwVbfV+8jsD8T4KxALdFZf2/GKLBuJ+8iITIRHeFF0nJSYHEvyYT/KbCmNYNlywRz Ir3iqjI9Q/9kF8iiHvQkIly2KEBm15QS/x+BBUBGE24QlDBDUyMAOad2biOBlPFlIQAqYSphZP/D AcYSvlIxUG4wbwIE8IES/9DsbQ9uH2GAyY6O9csSjGn/0/h2MtpP21oCICmx0FVMM/+nuCrmyYgL gA6wCcBLs24wf0XgowNK0E3xIpGuFS4RZv+jYSrmRmAOwEjhffHNUnt/zz9vfg9/Hx2BQWcLcUvj /4ClgpqIKkN01fFS01uhJfHvwsFeUpH5RPZmmgEesLE4/24wCrCC4qHCh7Mt0uIiA2D/jfEBoAMQ PZGihrY64YmtnP/Gb2lQU3BWM0VxoWKAgSThTmFb0H/ngPFiajHxaf+5IS1h2RCoEOgytUlubzIf /5JEM1lco/nSywTwAENCi6H/BQEjYOhTL4AEIC648lPkgNsk0ChAIliC/vciRDokIv+khx3R+khT lk/ALdKOonKC/yLjp7FIgdoAh9BhgCRkI6H/RYEGsYfQXnOYAgaF2GSg0P/ycR+SVacuESRjXgJb EfYQ/iAsckLyz0MiZh8ghGbRFL/++C1hKeQAe/JEAfRB1ID/lpZbJK4z2XEj13bl1mLLBP5tReCC Qthk5WFVoVViH6H/BAhSYYoUS+CadIWiEoxn5/9HRQcE+yB0M7kDLhEEAxS6/x6BFfrygMFgxQdh gZpillHfUYIkWitfgFMhYm6rVifx74xQJAFhYdoAIh/Q+cMC5ff9rAORVqBnW9D9Jk/BUrT+cjuw BtYuRQQEDZgGd6sQ/9SRePUTYlJhm0JJMehkCDD/SWDY7/wB5lMjRAWoj8G9OH9I16CCJ0OUsOQV 6K/pvEm+J0ngp3Oz8JZQ3VBiSsG/Q3MMoSU1UOOlQi+/UD3F/82SC6WtBplDa2O7UEMzZ2D/s/Bg cL0BSoXmmtf1+THLMu+LcQgTNTlI1HnjEk70zuJ/Hrbv4U/CIdUIExrE7CN1/mIAFORCpUFh4q4V M2S8If/jsa9AMzGpYEjgHfhblYGx/5fC/cBL4D7TYxBStMDnoBX/IaLVM+fwK7YVdvJxUVEbhv/8 PFtQnqGUIK7jW6TkQvw4/waFNlXjcpfVW5RqAAaGHGb/tXelIsOhsXHX+4HR52UzBP/kUclRXqcB 8V7SjyIHY62d/yNBOKSUEi115mJLJvJTSOH/s5FwQhZ13Y/tigfSPwZIl99HidJVGDJwlgISSdoA hwD98OFp/hHSsmSilcItdclBf1gyibAzgZSwh/FYj0pjKA+MUS7oKvVl41g1MDDvloVKv0vPDJFD w2gwVq0R/6vRhaYKBgO1TcimIaxR1PH/vfIP4KYxT2rX+8Xw8NDFcH5NGMCn8KQwPbARwPm0RCn8 RyJiH9BriYFrc/8DMItih9CUtBZ0lp8XZ01T38NZqmWcJY701JB1cUxg5P9lKWECb3aMQtnQn/GM UVMz/5YkCiV30gfUNjEc0NUCObL/giDmm+RRRaRtty11kxdYN//mqothHpCeNM8jD/BBgT/y+//A 2GRqFRI5AUWBL5Ef0P/EUVl0jfHDguMT2gDn4L5B/xt3b3YBRg/gj2CaEYEimOe/lgbTMXfh52FO Bdf1fYlQAAAAHgBCEAEAAABRAAAAPDVCOTBBRDY1QTlFODkzNDk4N0RCMEM4QzA3NjI2NTc0MDQw ODg0MThAREYtQk9XV09XLnBsYXRpbnVtLmNvcnAubWljcm9zb2Z0LmNvbT4AAAAAAwAJWQEAAAAL AACACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCF AAAAAAAAAwAOgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAADAB2ACCAGAAAAAADAAAAAAAAA RgAAAABShQAAJ2oBAB4AHoAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAALAB+A CCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAsAI4AIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAA AAAAAwAkgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADACaACCAGAAAAAADAAAAAAAAARgAA AAAYhQAAAAAAAB4ANYAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeADaACCAG AAAAAADAAAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgA3gAggBgAAAAAAwAAAAAAAAEYAAAAA OIUAAAEAAAABAAAAAAAAAAIB+A8BAAAAEAAAADiTsvhgJNQRhPEA4CllYPcCAfoPAQAAABAAAAA4 k7L4YCTUEYTxAOApZWD3AgH7DwEAAACIAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRs bAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxXSU5ET1dTXExvY2FsIFNldHRpbmdzXEFwcGxpY2F0 aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcRGlyZWN0b3J5LURlc2lnbnMucHN0AAMA/g8FAAAA AwANNP03AAACAX8AAQAAADEAAAAwMDAwMDAwMDM4OTNCMkY4NjAyNEQ0MTE4NEYxMDBFMDI5NjU2 MEY3QTRBRjg1MDAAAAAAAwAGEFBg4y4DAAcQBREAAAMAEBABAAAAAwAREAEAAAAeAAgQAQAAAGUA AABNQVJLSEVSRUFSRVNPTUVFWEFNUExFU09GV0FZU0lOV0hJQ0hESVJFQ1RPUllTRVJWRVJTSU1Q TEVNRU5UU0VNQU5USUNTVEhBVEdPQkVZT05EV0hBVFRIRUxEQVBBQ0NFU1NQAAAAALaC ------=_NextPart_000_0003_01C07CC6.77E2E060-- From owner-ietf-ldup@mail.imc.org Sun Jan 14 03:09:27 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00663 for ; Sun, 14 Jan 2001 03:09:26 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA26237 for ietf-ldup-bks; Sat, 13 Jan 2001 22:58:42 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA26227 for ; Sat, 13 Jan 2001 22:58:40 -0800 (PST) Received: from mira-sjcm-1.cisco.com (mira-sjcm-1.cisco.com [171.69.2.212]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id XAA11056; Sat, 13 Jan 2001 23:03:26 -0800 (PST) Received: from jstrassnlap ([171.69.108.130]) by mira-sjcm-1.cisco.com (Mirapoint) with SMTP id AJM03409; Sat, 13 Jan 2001 23:03:21 -0800 (PST) Message-ID: <000101c07df8$a080c950$826c45ab@cisco.com> Reply-To: "John Strassner" From: "John Strassner" To: Cc: , "Chris Apple" , =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Revised work group charter for your review Date: Fri, 12 Jan 2001 15:34:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi LDUPers, below is a revised charter for our workgroup. Chris and I need your comments asap, so that we can present our new charter to our AD. Please especially note the new dates for our delierables. I'd like this review closed as soon as possible. If anyone objects to review ending next Friday 19 January, please object soon. regards, John and Chris LDAP Duplication/Replication/Update Protocols (ldup) Chair(s): Chris Apple John C. Strassner Applications Area Director(s): Patrik Falstrom Ned Freed Applications Area Advisor: Patrik Falstrom Mailing Lists: General Discussion:ietf-ldup@imc.org To Subscribe: ietf-ldup-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-ldup/ Description of Working Group: As LDAPv3 becomes more widely deployed, replication of data across servers running different implementations becomes an important part of providing a distributed directory service. However, the LDAPv3 community, to date, has focused on standardizing the client-server access protocol. Therefore, this group will standardize master-slave and multi-master LDAPv3 replication as defined below: o Multi-Master Replication - A replication model where entries can be written and updated on any of several replica copies, without requiring communication with other masters before the write or update is performed. o Master-Slave, or Single-Master Replication - A replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. The WG's approach is to first develop a set of requirements for LDAPv3 directory replication and write an applicability statement defining scenarios on which replication requirements are based. An engineering team was formed consisting of different vendors and the co-chairs in order to harmonize the existing approaches into a single standard approach. All of these have been accomplished during the pre-working group stage. It should be noted, however, that replication using heterogeneous servers is dependent on resolving access control issues, which are the domain of other working groups. The new replication architecture support all forms of replication mentioned above. Seven areas of working group focus have been identified through LDUP Engineering Team discussions, each leading to one or more documents to be published: o LDAPv3 Replication Architecture This documents a general-purpose LDAPv3 replication architecture, defines key components of this architecture, describes how these key components functionally behave, and describes how these components interact with each other when in various modes of operation o LDAPv3 Replication Information Model Defines the schema and semantics of information used to operate, administer, maintain, and provision replication between LDAPv3 servers. Specifically, this document will contain common schema specifications intended to facilitate interoperable implementations with respect to: + replication agreements + consistency models + replication topologies + managing deleted objects and their states + administration and management o LDAPv3 Replication Information Transport Protocol LDAPv3 extended operation and control specifications required to allow LDAPv3 to be used as the transport protocol for information being replicated o LDAPv3 Mandatory Replica Management Specifications required to allow administration, maintenance, and provisioning of replicas and replication agreements. These specifications may take the form of definitions for LDAPv3 extended operations, controls, and/or new schema elements. o LDAPv3 Update Reconciliation Procedures Procedures for detection and resolution of conflicts between the state of multiple replicas that contain information from the same unit of replication. o LDAPv3 Profiles Including the LDAPv3 Replication Architecture, Information Model, Protocol Extensions, and Update Reconciliation Procedures for: + LDAPv3 Master-Slave Directory Replication + LDAPv3 Multi-Master Directory Replication o LDAPv3 Client Update A protocol that enables an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. The 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. Goals and Milestones: Done Submit I-D on LDAPv3 Directory Replication Requirements. Done Submit Internet-Draft on LDAPv3 Replication Information Model Done Submit I-D on LDAPv3 Update Reconciliation Procedures. Done Revise I-D on LDAPv3 Directory Replication Requirements. Done Revise I-D on LDAPv3 Replication Architecture. Done Revise I-D on LDAPv3 Replication Architecture. Done Submit I-D on LDAPv3 Replication Information Transport Protocol. Done Revise I-D on LDAPv3 Replication Information Model. Done Submit I-D on LDAPv3 Subentry Schema Done Submit I-D on LDAPv3 Client Update Protocol Done Submit I-D on Extended Operations for Framing LDAP Operations 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. Mar 01 Submit I-D on LDAPv3 Mandatory Replica Management. Mar 01 Submit I-D on LDAPv3 Multi-Master Replication Profile. Mar 01 Submit I-D on LDAPv3 Master-Slave Replication Profile. 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. Apr 01 LDAPv3 Subentry Schema goes to WG Last Call (joint with LDAPEXT) as Proposed Standard. Jun 01 LDAPv3 Replication Information Transport Protocol I-D goes to WG Last Call as Proposed Standard. Jun 01 LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard Aug 01 LDAPv3 Extended Operations for Framing I-D goes to WG Last Call as Proposed Standard. Dec 01 LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as Proposed Standard. Dec 01 LDAPv3 Master-Slave Replication Profile I-D goes t WG Last Call as Proposed Standard. Dec 01 LDAPv3 Multi-Master Replication Profile I-D goes to WG Last Call as Proposed Standard. Dec 01 Reevaluate Charter and Milestones Current Internet-Drafts http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica- req-05.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-03.t xt http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-05 .txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod- 01.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry -05.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol -02.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing- 00.txt http://www.ietf.org/internet-drafts/draft-natkovich-ldap-lcu p-02.txt Current RFCs None From owner-ietf-ldup@mail.imc.org Sun Jan 14 05:46:48 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07587 for ; Sun, 14 Jan 2001 05:46:48 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA21361 for ietf-ldup-bks; Sun, 14 Jan 2001 01:58:24 -0800 (PST) Received: from relay1.pair.com (relay1.pair.com [209.68.1.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA21357 for ; Sun, 14 Jan 2001 01:58:21 -0800 (PST) Received: (qmail 23861 invoked from network); 14 Jan 2001 10:03:10 -0000 Received: from cpe-144-132-68-23.vic.bigpond.net.au (HELO w98sysrec) (144.132.68.23) by relay1.pair.com with SMTP; 14 Jan 2001 10:03:10 -0000 X-pair-Authenticated: 144.132.68.23 Reply-To: From: "Albert Langer" To: "'John Strassner'" , Cc: "'Chris Apple'" , "=?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?=" Subject: RE: Revised work group charter for your review Date: Sun, 14 Jan 2001 21:05:55 +1100 Message-ID: <000e01c07e11$965a0680$17448490@vic.bigpond.net.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 CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <000101c07df8$a080c950$826c45ab@cisco.com> Importance: Normal Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [John and Chris revision] Hi LDUPers, below is a revised charter for our workgroup. Chris and I need your comments asap, so that we can present our new charter to our AD. Please especially note the new dates for our delierables. I'd like this review closed as soon as possible. If anyone objects to review ending next Friday 19 January, please object soon. regards, John and Chris [Albert] This was dated 13 January and received here on 14 January. In my view charter revision should be taken as an opportunity to formally review the progress and direction of the WG and should therefore not be pushed through casually with less time for comment than a WG final call. [...revision] o LDAPv3 Client Update A protocol that enables an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. [Albert] This appears to the only change other than dates. I support that addition. Other changes may also be considered desirable after review. [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? [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. BTW the 2 documents are radically inconsistent with each other, as will emerge when the WG does start last call discussions on them together. [revision] Mar 01 Submit I-D on LDAPv3 Mandatory Replica Management. Mar 01 Submit I-D on LDAPv3 Multi-Master Replication Profile. Mar 01 Submit I-D on LDAPv3 Master-Slave Replication Profile. [Albert] According to item 9 of the San Diego minutes new authors "expressed interest" and "volunteered" on 26 December and there is an action item note "Please try to produce a draft before the March meeting in Minneapolois". I have not noticed anything in the mailing list to confirm that anybody has either been assigned or has accepted an assignment to produce a draft by 1 March. [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] Propose to finalize the Update Reconciliation Procedures four months prior to finalizing the Information Model and Architecture lacks common sense. [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. From owner-ietf-ldup@mail.imc.org Sun Jan 14 19:25:40 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11457 for ; Sun, 14 Jan 2001 19:25:39 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA03685 for ietf-ldup-bks; Sun, 14 Jan 2001 15:35:56 -0800 (PST) Received: from exchange.parex.co.nz ([203.167.234.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA03674 for ; Sun, 14 Jan 2001 15:35:52 -0800 (PST) From: sadspd@spbu.ru To: Date: Sun, 14 Jan 2001 09:37:36 Message-Id: <465.324445.146319@mail.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit GET YOUR OWN 150 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL TO OUR OFFICE. YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! FRONT PAGE EXTENSIONS are FULLY SUPPORTED. A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 if you are outside the USA, please fax 240 337 8325 Webhosting International From owner-ietf-ldup@mail.imc.org Mon Jan 15 09:09:54 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05645 for ; Mon, 15 Jan 2001 09:09:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA23321 for ietf-ldup-bks; Mon, 15 Jan 2001 05:16:39 -0800 (PST) Received: from exchange.parex.co.nz ([203.167.234.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA23288 for ; Mon, 15 Jan 2001 05:16:25 -0800 (PST) From: dawdwa@sld.cu To: Date: Mon, 15 Jan 2001 04:35:34 Message-Id: <789.19820.172807@mail.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit GET YOUR OWN 150 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL TO OUR OFFICE. YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! FRONT PAGE EXTENSIONS are FULLY SUPPORTED. A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 if you are outside the USA, please fax 240 337 8325 Webhosting International From owner-ietf-ldup@mail.imc.org Wed Jan 17 00:00:50 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00297 for ; Wed, 17 Jan 2001 00:00:50 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA11942 for ietf-ldup-bks; Tue, 16 Jan 2001 20:00:21 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA11937 for ; Tue, 16 Jan 2001 20:00:19 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id XAA403696 for ; Tue, 16 Jan 2001 23:04:59 -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 XAA77136 for ; Tue, 16 Jan 2001 23:03:01 -0500 Reply-To: hahnt@us.ibm.com X-Priority: 3 (Normal) Importance: Normal To: ietf-ldup@imc.org Subject: Comments on draft-ietf-ldup-model-05.txt X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 From: "Timothy Hahn" Message-ID: Date: Tue, 16 Jan 2001 23:05:51 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.6 |January 4, 2001) at 01/16/2001 11:05:53 PM, Serialize complete at 01/16/2001 11:05:53 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00165043852569D7_=" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00165043852569D7_= Content-Type: text/plain; charset="us-ascii" Greetings, (My apologies for the re-post if you see this twice - I did not see it come through the mailing list). General: From a replication management/configuration and server perspective, it seems we ought to define a standard way for setting and/or looking up a server's replica ID. A server needs to know its own ID to generate CSNs, and to configure replication you need to be able to determine the IDs of the other participating servers. This might be better addresed in the information model. Proposal: Add a root DSE attribute, replicaID, that "advertises" the server's ID. How this value is set could be implementation defined, but if I were developiong a replication management tool, I would like to be able to set this attribute via LDAP operations from the management tool. I suggest that this attribute must be modifiable via a modify operation on the root DSE. Alternately, I could see that it might be desirable to make this an attribute of the replication area "name context" object -- though I don't know of any need for a "per replication area" replicaID. General - I feel that this document should have a section that shows which requirements (from the replication requirements draft) are addressed and which are not - instead of leaving this as an "exercize for the reader". 3.3.e - Please clarify what is meant by "overlapping replicated regions". 4.1 - I think that replica Type should have a setting for listing the replica as "partial". 4.4 - What is the format/algorithm for generating entry UUIDs? What is the canonical string representation for an entry's UUID? Where is the full attribute type definition and OID for "entryUUID" defined? Will there be a new syntax? 4.5 - If a Modify operation MUST assign one CSN per modification, is there an order here? I assume that CSNs are assigned IN ORDER of the modification list, one CSN per modification item in the list. Is this the intent? 4.5.1 - What is the recommended format and choice for the replica ID, as used in the CSN and elsewhere? Common use of the term replica ID and replica Identifier would be nice. Some refer to this as the "rdn attribute", others, including examples, use integers. If this is an integer, shouldn't the integer value be in the replicaSubentry as a separate attribute? 4.6 - Do all attribute values have CSN's or only those that have been modified or deleted? 4.6.1 - Need more explanation on the last sentence of this section: "A CSN is recorded for both the RDN, and the Superior DN of the entry." Does LDUP require storing the Superior DN and/or Superior UUID with every entry? Is the "superior entry" marked as updated? Or do there exist separate CSNs in EACH ENTRY corresponding to rdnCSN and superiorDNCSN, in addition to createdEntryCSN and deletedEntryCSN? 5.1 - It seems like the schema is always associated with the naming context, and that naming contexts can be nested. Is this right? Is there any meaning for the subschema entry pointed to by the rootDSE? How are subschema entries related to replication contexts - if at all? 5.1 - The CSN format seems to imply that the naming attribute for replicaSubentry entries MUST be caseIgnoreIA5. This should be stipulated. 5.2 - What are the rootDSE attributes needed for LDUP replication? I don't see them in the information model. In section 7.3, I saw a reference to to a 'supportedReplicationProtocols' attribute - there may be others. 5.4 - It should it be noted that Fractional replicas can ONLY be read-only. 5.5 - What is the DN of the Lost and Found entry? 5.6 - How should the authentication credentials be stored securely? 6.1 - Need clarification relative to the meaning of the subschemasubentry attribute in the rootDSE. Does paragraph two then imply a requirement that schema be updateable (as well as published)? Should this be a setting (whether or not to replicate schema updates) in the replica agreement? Recommend we allow choice in replication agreement of whether schema should be replicated. 6.1 - "Given the strict ordering of replication events, schema modifications will naturally be replicated ...". I don't recall such an ordering requirement. It may be implicit in a log-based implementation, but not in a state-based implementation. It does seem, though, that some ordering of schema changes and entry changes is required. This could be a problem in implementations (many) where the schema is server-wide. Proposal(s): 1) Replace this statement with a MUST(?) requirement to the effect: "To ensure that schema modifications precede entry creations/modifications that use them and follow data deletions which eliminate references to schema elements to be changed or deleted, replication MUST preserve the ordering of schema changes with respect to other directory entry changes." 2) Alternately, it seems that a requirement could be imposed for the servers to recheck "damaged" entries as schema changes come in, the goal in either case being that at the end of successful replication of entry changes and associated schema changes, no entries be in an "administrative action required" state. I do not have a feel for which is better, but I do feel that as currently stated, the "strict ordering" referred to does not exist, making it possible that an administrator might have to do some sort of repair for entries that either aren't really broken, and needn't have become broken. What other LDUP drafts will clarify this? 7.1.1 - says that the credentials for authenticated bind to another replica are kept as attributes within replication agreements. The information model shows no such attributes. 7.3 - required changes to the rootDSE should be summarized somewhere - information model draft perhaps? 9.1 - Full Update Transfer: This seems impractical for large naming contexts, because it would take too long. Are there any alternatives that should be considered? 9.4 - This paragraph seems to imply that replicaSubentry objects are also replicated between replica servers. However, in absence of this information (becuase the "new" replica isn't "well known" yet - unknown updateVector information, for example), how does the supplier know that it should be keeping track of updates? Maybe this only applies to log-based replication? 9.4 - The paragraph, as written, seems to imply that if a full update is to be performed, then prior to starting, a 'snapshot' of the whole replication context must be taken so that incremental changes that come in can thence be sent to the replica. If so, this should be clarified/pointed out. 10 - What is the recommended error code? LDAP_UNWILLING_TO_PERFORM? Serializing all replication operations would seem to require some explanation as to why. 10.5.4 - What is the mechanism for marking an entry as requiring "administrative repair"? Is this information intended to be LDAP accessible? Proposal: I would like to see this (needs administrative repair) accessible via LDAP, with some information as to the nature of the error. To this end, we could add an operational attribute(?), replicationSchemaError, which is present if replication introduces a schema violation. A subsequent LDAP (or replication) operation which corrects this error will result in the replicationSchemaError attribute no longer being returned on a search. If a schema change is required to correct the error, the mechanism for correcting the error would be to update the schema, then perform an LDAP modify operation to delete the replicationSchemaError attribute. If the object no longer violates the schema, the operation will succeed. The syntax of this attribute would be directory string. Implementations should set the attribute to a string describing the error (for example, "attribute xxx not allowed"). Implementations may return the attribute as an empty string. 10.5.7 - "The resolution procedure is to break the cycle by changing the parent of the entry closest to be the lost and found entry." Closest to what? To the root? Why not say "the resolution procedure is to move the entry (and possibly whole sub-tree) into the lost+found area"? 12 - How much of replication management entries are replicated? 12 - Step one of the example scenario; what is a "context prefix"? 12 - Why is step 5 necessary? Why isn't this information just replicated over on the next replication between the two replicas? 13 - hat is the diference between serverClocksOutOfSync (72) and excessiveCSNskew (200), defined in the LDUP Replication Update Protocol? ExcessiveCSNskew is not referenced outside of the protocol draft. 14 - There appears to be a "special case" in replication processing in that the "authentication information" that is presumably stored in replication agreement subentries should NOT be replicated. Thus, servers must code special work-arounds to avoid replicating this information. Is this the intent? 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 00165043852569D7_= Content-Type: text/html; charset="us-ascii"
Greetings,

(My apologies for the re-post if you see this twice - I did not see it come through the mailing list).

General: From a replication management/configuration and server perspective, it seems we ought to define a standard way for setting and/or looking up a server's replica ID.  A server needs to know its own ID to generate CSNs, and to configure replication you need to be able to determine the IDs of the other participating servers.  This might be better addresed in the information model.
Proposal:  Add a root DSE attribute, replicaID, that "advertises" the server's ID.  How this value is set could be implementation defined, but if I were developiong a replication management tool, I would like to be able to set this attribute via LDAP operations from the management tool.  I suggest that this attribute must be modifiable via a modify operation on the root DSE.  Alternately, I could see that it might be desirable to make this an attribute of the replication area "name context" object -- though I don't know of any need for a "per replication area" replicaID.

General - I feel that this document should have a section that shows which requirements (from the replication requirements draft) are addressed and which are not - instead of leaving this as an "exercize for the reader".

3.3.e - Please clarify what is meant by "overlapping replicated regions".

4.1 - I think that replica Type should have a setting for listing the replica as "partial".

4.4 - What is the format/algorithm for generating entry UUIDs?   What is the canonical string representation for an entry's UUID?  Where is the full attribute type definition and OID for "entryUUID" defined?  Will there be a new syntax?

4.5 - If a Modify operation MUST assign one CSN per modification, is there an order here?  I assume that CSNs are assigned IN ORDER of the modification list, one CSN per modification item in the list.  Is this the intent?

4.5.1 - What is the recommended format and choice for the replica ID, as used in the CSN and elsewhere? Common use of the term replica ID and replica Identifier would be nice.  Some refer to this as the "rdn attribute", others, including examples, use integers.  If this is an integer, shouldn't the integer value be in the replicaSubentry as a separate attribute?

4.6 - Do all attribute values have CSN's or only those that have been modified or deleted?

4.6.1 - Need more explanation on the last sentence of this section: "A CSN is recorded for both the RDN, and the Superior DN of the entry."  Does LDUP require storing the Superior DN and/or Superior UUID with every entry?  Is the "superior entry" marked as updated?  Or do there exist separate CSNs in EACH ENTRY corresponding to rdnCSN and superiorDNCSN, in addition to createdEntryCSN and deletedEntryCSN?

5.1 - It seems like the schema is always associated with the naming context, and that naming contexts can be nested.  Is this right?  Is there any meaning for the subschema entry pointed to by the rootDSE?  How are subschema entries related to replication contexts - if at all?

5.1 -  The CSN format seems to imply that the naming attribute for replicaSubentry entries MUST be caseIgnoreIA5.  This should be stipulated.

5.2 -  What are the rootDSE attributes needed for LDUP replication?  I don't see them in the information model.  In section 7.3, I saw a reference to to a 'supportedReplicationProtocols' attribute - there may be others.

5.4 - It should it be noted that Fractional replicas can ONLY be read-only.

5.5 -  What is the DN of the Lost and Found entry?

5.6 -  How should the authentication credentials be stored securely?

6.1 -  Need clarification relative to the meaning of the subschemasubentry attribute in the rootDSE.  Does paragraph two then imply a requirement that schema be updateable (as well as published)?  Should this be a setting (whether or not to replicate schema updates) in the replica agreement?  Recommend we allow choice in replication agreement of whether schema should be replicated.

6.1 - "Given the strict ordering of replication events, schema modifications will naturally be replicated ...".  I don't recall such an ordering requirement.  It may be implicit in a log-based implementation, but not in a state-based implementation.  It does seem, though, that some ordering of schema changes and entry changes is required.  This could be a problem in implementations (many) where the schema is server-wide.
Proposal(s):
1)  Replace this statement with a MUST(?) requirement to the effect: "To ensure that schema modifications precede entry creations/modifications that use them and follow data deletions which eliminate references to schema elements to be changed or deleted, replication MUST preserve the ordering of schema changes with respect to other directory entry changes."
2) Alternately, it seems that a requirement could be imposed for the servers to recheck "damaged" entries as schema changes come in, the goal in either case being that at the end of successful replication of entry changes and associated schema changes, no entries be in an "administrative action required" state.
I do not have a feel for which is better, but I do feel that as currently stated, the "strict ordering" referred to does not exist, making it possible that an administrator might have to do some sort of repair for entries that either aren't really broken, and needn't have become broken.  What other LDUP drafts will clarify this?

7.1.1 -  says that the credentials for authenticated bind to another replica are kept as attributes within replication agreements.  The information model shows no such attributes.

7.3 - required changes to the rootDSE should be summarized somewhere - information model draft perhaps?

9.1 - Full Update Transfer: This seems impractical for large naming contexts, because it would take too long.  Are there any alternatives that should be considered?

9.4 - This paragraph seems to imply that replicaSubentry objects are also replicated between replica servers.  However, in absence of this information (becuase the "new" replica isn't "well known" yet - unknown updateVector information, for example), how does the supplier know that it should be keeping track of updates? Maybe this only applies to log-based replication?
9.4 - The paragraph, as written, seems to imply that if a full update is to be performed, then prior to starting, a 'snapshot' of the whole replication context must be taken so that incremental changes that come in can thence be sent to the replica.  If so, this should be clarified/pointed out.

10 - What is the recommended error code?  LDAP_UNWILLING_TO_PERFORM?  Serializing all replication operations would seem to require some explanation as to why.

10.5.4 - What is the mechanism for marking an entry as requiring "administrative repair"?  Is this information intended to be LDAP accessible?
Proposal:  I would like to see this (needs administrative repair) accessible via LDAP, with some information as to the nature of the error.  To this end, we could add an operational attribute(?), replicationSchemaError, which is present if replication introduces a schema violation.  A subsequent LDAP (or replication) operation which corrects this error will result in the replicationSchemaError attribute no longer being returned on a search.  If a schema change is required to correct the error, the mechanism for correcting the error would be to update the schema, then perform an LDAP modify operation to delete the replicationSchemaError attribute.  If the object no longer violates the schema, the operation will succeed.  The syntax of this attribute would be directory string.  Implementations should set the attribute to a string describing the error (for example, "attribute xxx not allowed").  ! ! Implementations may return the attribute as an empty string.

10.5.7 - "The resolution procedure is to break the cycle by changing the parent of the entry closest to be the lost and found entry."  Closest to what?  To the root?  Why not say "the resolution procedure is to move the entry (and possibly whole sub-tree) into the lost+found area"?

12 -  How much of replication management entries are replicated?
12 - Step one of the example scenario; what is a "context prefix"?
12 - Why is step 5 necessary?  Why isn't this information just replicated over on the next replication between the two replicas?

13 - hat is the diference between serverClocksOutOfSync (72) and excessiveCSNskew (200), defined in the LDUP Replication Update Protocol?  ExcessiveCSNskew is not referenced outside of the protocol draft.

14 - There appears to be a "special case" in replication processing in that the "authentication information" that is presumably stored in replication agreement subentries should NOT be replicated.  Thus, servers must code special work-arounds to avoid replicating this information.  Is this the intent?

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 00165043852569D7_=-- From owner-ietf-ldup@mail.imc.org Wed Jan 17 00:14:26 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00441 for ; Wed, 17 Jan 2001 00:14:26 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA12649 for ietf-ldup-bks; Tue, 16 Jan 2001 20:28:02 -0800 (PST) Received: from webserver.onlineevents.com.au ([203.111.80.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA12639 for ; Tue, 16 Jan 2001 20:28:00 -0800 (PST) From: bk12bk27@yahoo.com Received: from max1-34.losangeles.corecomm.net by webserver.onlineevents.com.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1459.44) id C0CGL63A; Wed, 17 Jan 2001 14:54:42 +1100 DATE: 16 Jan 01 6:44:52 PM Message-ID: <2pD8g8NqEIdEMX> SUBJECT: RE; THANK YOU Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Friend and Partner, Think of all the things you could do if you had more free time and money wasn't an object What kind of car would you be driving? Where would you live? Where would you go on vacation? Now, for a limited time, 300+ money making and saving secrets can be yours for less than $10.00. Click here http://www.300moneysecrets.com/ and ORDER NOW!!!!!!!!!!!!!! Get information now, that could make you millions!!!! ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** To be removed from our mailing list, please email sandywho1212@yahoo.com All REMOVE requests AUTOMATICALLY honored upon receipt. PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list as it will be impossible to take anyone off the list if the remove instruction can not be received. From owner-ietf-ldup@mail.imc.org Wed Jan 17 13:46:37 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24130 for ; Wed, 17 Jan 2001 13:46:36 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA20574 for ietf-ldup-bks; Wed, 17 Jan 2001 09:53:34 -0800 (PST) Received: from mail1.ecal.com ([216.150.139.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20568 for ; Wed, 17 Jan 2001 09:53:32 -0800 (PST) Received: from pacapple ([216.150.139.2]) by mail1.ecal.com (Post.Office MTA v3.5.2 release 221 ID# 30-55765U3000L300S0V35) with SMTP id com for ; Wed, 17 Jan 2001 12:58:34 -0500 Reply-To: From: capple@ecal.com (Christopher Apple) To: "Ietf-Ldup@Imc. Org" Subject: FW: LDAP/X.500 Alignment Date: Wed, 17 Jan 2001 12:58:34 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002C_01C08085.331A4820" 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.50.4133.2400 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_002C_01C08085.331A4820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit FYI. Chris Apple capple@ecal.com -----Original Message----- From: Slone, Skip [mailto:skip.slone@lmco.com] Sent: Wednesday, January 17, 2001 12:55 PM To: LDAPExt Mailing List (E-mail) Subject: LDAP/X.500 Alignment At the San Diego meeting, a new X.500-initiated work item on "maximizing alignment between LDAP and X.500" was briefly introduced to the ldapext WG. The philosophy behind this work is one of removing barriers -- barriers to LDAP/X.500 interoperability, and barriers to implemention resulting from X.500's OSI legacy. The goal of this work is to combine the collective talents of LDAP and X.500 experts in a way that facilitates the development of directory solutions that are both compelling and pragmatic. The document describing this work can be found at ftp://ftp.bull.com/pub/OSIdirectory/Orlando2000Output/LDAPalignmentWD.pdf. The document contains about four pages of real content, and the major section headers are as follows: - General Philosophy - Removal of Barriers - Distributed Operations - Related Entries - Name Resolution - Protocol / Presentation Interoperability - Schema - Replication and Metadirectory - Security - New Functionality I will be attending the X.500 group's upcoming meeting the week of January 29, and would welcome the perspective of members of this group. I invite interested parties to take a look at this document and to share your thoughts with me during the time remaining before the X.500 meeting. I also plan to attend the IETF meeting in Minneapolis, where I should be available to discuss the latest developments from the X.500 group's perspective. Because the topic list covers a wide range, the resulting work is likely to span multiple LDAP-related WGs. Accordingly, I am sending this initial message to several WG lists. However, to minimize cross-postings, I am sending the initial message separately to each of the various lists in hope that any ensuing discussions can be contained within the relevant group. Thanks, -- Skip Slone ------=_NextPart_000_002C_01C08085.331A4820 Content-Type: text/x-vcard; name="Chris Apple.vcf" Content-Disposition: attachment; filename="Chris Apple.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Apple;Chris FN:Chris Apple NICKNAME:capple ORG:eCal Corporation TEL;WORK;VOICE:215-627-5001, ext. 3839 TEL;CELL;VOICE:(267) 977-8333 TEL;WORK;FAX:215-627-0927 ADR;WORK:;;510 Walnut Street;Philadelphia;PA;19106;US LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:510 Walnut = Street=3D0D=3D0APhiladelphia, PA 19106=3D0D=3D0AUS URL: URL:http://www.ecal.com EMAIL;PREF;INTERNET:capple@ecal.com REV:20000725T173628Z END:VCARD ------=_NextPart_000_002C_01C08085.331A4820-- From owner-ietf-ldup@mail.imc.org Wed Jan 17 13:52:59 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24215 for ; Wed, 17 Jan 2001 13:52:58 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA20114 for ietf-ldup-bks; Wed, 17 Jan 2001 09:50:09 -0800 (PST) Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20108 for ; Wed, 17 Jan 2001 09:50:08 -0800 (PST) Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.8.8/8.8.8) with ESMTP id MAA01010 for ; Wed, 17 Jan 2001 12:55:46 -0500 (EST) Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38888) id <0G7B00201J28Y0@lmco.com> for ietf-ldup@imc.org; Wed, 17 Jan 2001 12:54:19 -0500 (EST) Received: from emss03i00.ems.lmco.com ([141.240.31.211]) by lmco.com (PMDF V5.2-32 #38888) with ESMTP id <0G7B00BTTJ1R4X@lmco.com> for ietf-ldup@imc.org; Wed, 17 Jan 2001 12:53:51 -0500 (EST) Received: by emss03i00.orl.lmco.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Jan 2001 12:54:59 -0500 Content-return: allowed Date: Wed, 17 Jan 2001 12:54:59 -0500 From: "Slone, Skip" Subject: LDAP/X.500 Alignment To: "LDUP Mailing List (E-mail)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT At the San Diego meeting, a new X.500-initiated work item on "maximizing alignment between LDAP and X.500" was briefly introduced to the ldapext WG. The philosophy behind this work is one of removing barriers -- barriers to LDAP/X.500 interoperability, and barriers to implemention resulting from X.500's OSI legacy. The goal of this work is to combine the collective talents of LDAP and X.500 experts in a way that facilitates the development of directory solutions that are both compelling and pragmatic. The document describing this work can be found at ftp://ftp.bull.com/pub/OSIdirectory/Orlando2000Output/LDAPalignmentWD.pdf. The document contains about four pages of real content, and the major section headers are as follows: - General Philosophy - Removal of Barriers - Distributed Operations - Related Entries - Name Resolution - Protocol / Presentation Interoperability - Schema - Replication and Metadirectory - Security - New Functionality I will be attending the X.500 group's upcoming meeting the week of January 29, and would welcome the perspective of members of this group. I invite interested parties to take a look at this document and to share your thoughts with me during the time remaining before the X.500 meeting. I also plan to attend the IETF meeting in Minneapolis, where I should be available to discuss the latest developments from the X.500 group's perspective. Because the topic list covers a wide range, the resulting work is likely to span multiple LDAP-related WGs. Accordingly, I am sending this initial message to several WG lists. However, to minimize cross-postings, I am sending the initial message separately to each of the various lists in hope that any ensuing discussions can be contained within the relevant group. Thanks, -- Skip Slone From owner-ietf-ldup@mail.imc.org Wed Jan 17 15:04:26 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25199 for ; Wed, 17 Jan 2001 15:04:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA24318 for ietf-ldup-bks; Wed, 17 Jan 2001 11:12:46 -0800 (PST) Received: from webserver.onlineevents.com.au ([203.111.80.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24298 for ; Wed, 17 Jan 2001 11:12:44 -0800 (PST) From: bk12bk27@yahoo.com Received: from max1-34.losangeles.corecomm.net by webserver.onlineevents.com.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1459.44) id C0CGL63A; Wed, 17 Jan 2001 14:54:42 +1100 DATE: 16 Jan 01 6:44:52 PM Message-ID: <2pD8g8NqEIdEMX> SUBJECT: RE; THANK YOU Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Friend and Partner, Think of all the things you could do if you had more free time and money wasn't an object What kind of car would you be driving? Where would you live? Where would you go on vacation? Now, for a limited time, 300+ money making and saving secrets can be yours for less than $10.00. Click here http://www.300moneysecrets.com/ and ORDER NOW!!!!!!!!!!!!!! Get information now, that could make you millions!!!! ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** To be removed from our mailing list, please email sandywho1212@yahoo.com All REMOVE requests AUTOMATICALLY honored upon receipt. PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list as it will be impossible to take anyone off the list if the remove instruction can not be received. From owner-ietf-ldup@mail.imc.org Wed Jan 17 20:32:35 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00919 for ; Wed, 17 Jan 2001 20:32:35 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA11379 for ietf-ldup-bks; Wed, 17 Jan 2001 16:48:59 -0800 (PST) Received: from webserver.onlineevents.com.au ([203.111.80.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA11360 for ; Wed, 17 Jan 2001 16:48:57 -0800 (PST) From: bk12bk27@yahoo.com Received: from max1-34.losangeles.corecomm.net by webserver.onlineevents.com.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1459.44) id C0CGL63A; Wed, 17 Jan 2001 14:54:42 +1100 DATE: 16 Jan 01 6:44:52 PM Message-ID: <2pD8g8NqEIdEMX> SUBJECT: RE; THANK YOU Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Friend and Partner, Think of all the things you could do if you had more free time and money wasn't an object What kind of car would you be driving? Where would you live? Where would you go on vacation? Now, for a limited time, 300+ money making and saving secrets can be yours for less than $10.00. Click here http://www.300moneysecrets.com/ and ORDER NOW!!!!!!!!!!!!!! Get information now, that could make you millions!!!! ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** To be removed from our mailing list, please email sandywho1212@yahoo.com All REMOVE requests AUTOMATICALLY honored upon receipt. PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list as it will be impossible to take anyone off the list if the remove instruction can not be received. From owner-ietf-ldup@mail.imc.org Wed Jan 17 22:26:31 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03302 for ; Wed, 17 Jan 2001 22:26:30 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA13955 for ietf-ldup-bks; Wed, 17 Jan 2001 18:39:02 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA13950 for ; Wed, 17 Jan 2001 18:39:00 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id VAA217148 for ; Wed, 17 Jan 2001 21:43:15 -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 VAA130522 for ; Wed, 17 Jan 2001 21:41:16 -0500 X-Priority: 3 (Normal) Importance: Normal Subject: Re: Revised work group charter for your review To: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Timothy Hahn" Date: Wed, 17 Jan 2001 21:38:57 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Release 5.0.6 |January 4, 2001) at 01/17/2001 09:44:09 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id SAA13951 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id SAA13955 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA03302 John, I put comments below - prefaced 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 "John Strassner" @mail.imc.org on 01/12/2001 06:34:56 PM Please respond to "John Strassner" Sent by: owner-ietf-ldup@mail.imc.org To: cc: , "Chris Apple" , Patrik Fältström Subject: Revised work group charter for your review Hi LDUPers, below is a revised charter for our workgroup. Chris and I need your comments asap, so that we can present our new charter to our AD. Please especially note the new dates for our delierables. I'd like this review closed as soon as possible. If anyone objects to review ending next Friday 19 January, please object soon. regards, John and Chris LDAP Duplication/Replication/Update Protocols (ldup) Chair(s): Chris Apple John C. Strassner Applications Area Director(s): Patrik Falstrom Ned Freed Applications Area Advisor: Patrik Falstrom Mailing Lists: General Discussion:ietf-ldup@imc.org To Subscribe: ietf-ldup-request@imc.org In Body: subscribe Archive: http://www.imc.org/ietf-ldup/ Description of Working Group: As LDAPv3 becomes more widely deployed, replication of data across servers running different implementations becomes an important part of providing a distributed directory service. However, the LDAPv3 community, to date, has focused on standardizing the client-server access protocol. Therefore, this group will standardize master-slave and multi-master LDAPv3 replication as defined below: o Multi-Master Replication - A replication model where entries can be written and updated on any of several replica copies, without - why state the following thing explicitly? In fact the current model in the architecture doesn't require communication with other masters before the update is performed requiring communication with other masters before the write or update is performed. o Master-Slave, or Single-Master Replication - A replication model that assumes only one server, the master, allows write access to the replicated data. Note that Master-Slave replication can be considered a proper subset of multi-master replication. The WG's approach is to first develop a set of requirements for LDAPv3 directory replication and write an applicability statement defining scenarios on which replication requirements are based. An engineering team was formed consisting of different vendors and the co-chairs in order to harmonize the existing approaches into a single standard approach. All of these have been accomplished during the pre-working group stage. It should be noted, however, that replication using heterogeneous servers is dependent on resolving access control issues, which are the domain of other working groups. editorial, "support" should be "supports" The new replication architecture support all forms of ^^^^^^^ replication mentioned above. Seven areas of working group focus have been identified through LDUP Engineering Team discussions, each leading to one or more documents to be published: o LDAPv3 Replication Architecture This documents a general-purpose LDAPv3 replication architecture, defines key components of this architecture, describes how these key components functionally behave, and describes how these components interact with each other when in various modes of operation o LDAPv3 Replication Information Model editorial - add the term "directory"? Defines the directory schema and semantics of information used to ^^^^^^^^^ operate, administer, maintain, and provision replication between LDAPv3 servers. Specifically, this document will contain common schema specifications intended to facilitate interoperable implementations with respect to: + replication agreements + consistency models + replication topologies + managing deleted objects and their states + administration and management is it still called "Replication Information Transport Protocol"? I thought it was just "Replication Transport Protocol" o LDAPv3 Replication Information Transport Protocol LDAPv3 extended operation and control specifications required to allow LDAPv3 to be used as the transport editorial - change: protocol for information being replicated to: protocol for replicating information between servers. o LDAPv3 Mandatory Replica Management Specifications required to allow administration, maintenance, and provisioning of replicas and replication agreements. These specifications may take the form of definitions for LDAPv3 extended operations, controls, and/or new schema elements. o LDAPv3 Update Reconciliation Procedures Procedures for detection and resolution of conflicts between editorial - change: the state of multiple replicas that contain information from to: the state of directory information held in multiple replicas which contain information from the same unit of replication. o LDAPv3 Profiles Including the LDAPv3 Replication Architecture, Information Model, Protocol Extensions, and Update Reconciliation Procedures for: + LDAPv3 Master-Slave Directory Replication + LDAPv3 Multi-Master Directory Replication o LDAPv3 Client Update A protocol that enables an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. The 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. Goals and Milestones: Done Submit I-D on LDAPv3 Directory Replication Requirements. Done Submit Internet-Draft on LDAPv3 Replication Information Model Done Submit I-D on LDAPv3 Update Reconciliation Procedures. Done Revise I-D on LDAPv3 Directory Replication Requirements. Done Revise I-D on LDAPv3 Replication Architecture. Done Revise I-D on LDAPv3 Replication Architecture. Done Submit I-D on LDAPv3 Replication Information Transport Protocol. Done Revise I-D on LDAPv3 Replication Information Model. Done Submit I-D on LDAPv3 Subentry Schema Done Submit I-D on LDAPv3 Client Update Protocol Done Submit I-D on Extended Operations for Framing LDAP Operations I assume that the 2-digit numbers below correspond to the year, i.e. "01" means "2001". Thus, "Jan 01" has not expired yet. Jan 01 LDAPv3 Directory Replication Requirements I-D goes to WG Last Call as Informational. How can this document go to last call before the architecture draft??? Jan 01 LDAPv3 Update Reconciliation Procedures I-D goes to WG Last Call as Proposed Standard. Mar 01 Submit I-D on LDAPv3 Mandatory Replica Management. Mar 01 Submit I-D on LDAPv3 Multi-Master Replication Profile. Mar 01 Submit I-D on LDAPv3 Master-Slave Replication Profile. Apr 01 LDAPv3 Replication Information Model I-D goes to WG Last Call as Proposed Standard. Why is this one only informational?? Apr 01 LDAPv3 Replication Architecture I-D goes to WG Last Call as Informational. Apr 01 LDAPv3 Subentry Schema goes to WG Last Call (joint with LDAPEXT) as Proposed Standard. Jun 01 LDAPv3 Replication Information Transport Protocol I-D goes to WG Last Call as Proposed Standard. Jun 01 LDAPv3 Client Update Protocol I-D goes to WG Last Call as Proposed Standard I don't recall seeing this topic in the list of topics above. Should something about "Framing" and "Grouping" be added to the write up above?? Aug 01 LDAPv3 Extended Operations for Framing I-D goes to WG Last Call as Proposed Standard. Dec 01 LDAPv3 Mandatory Replica Management I-D goes to WG Last Call as Proposed Standard. Dec 01 LDAPv3 Master-Slave Replication Profile I-D goes t WG Last Call as Proposed Standard. Dec 01 LDAPv3 Multi-Master Replication Profile I-D goes to WG Last Call as Proposed Standard. Dec 01 Reevaluate Charter and Milestones Current Internet-Drafts I believe that the -06 version of the replica reqs is now published. http://www.ietf.org/internet-drafts/draft-ietf-ldup-replica- req-05.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-urp-03.t xt http://www.ietf.org/internet-drafts/draft-ietf-ldup-model-05 .txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-infomod- 01.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-subentry -05.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-protocol -02.txt http://www.ietf.org/internet-drafts/draft-ietf-ldup-framing- 00.txt http://www.ietf.org/internet-drafts/draft-natkovich-ldap-lcu p-02.txt Current RFCs None From owner-ietf-ldup@mail.imc.org Mon Jan 22 21:31:28 2001 Received: from ns.secondary.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19255 for ; Mon, 22 Jan 2001 21:31:28 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA21657 for ietf-ldup-bks; Mon, 22 Jan 2001 16:47:37 -0800 (PST) Received: from cins.hanyang.ac.kr ([166.104.204.187]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA21626; Mon, 22 Jan 2001 16:47:24 -0800 (PST) From: emed22@libero.it Received: by cins.hanyang.ac.kr id JAA305538; Tue, 23 Jan 2001 09:27:53 +0900 (KST) Subject: Obtain Biotech IPOs! 13 Date: Mon, 22 Jan 2001 19:51:16 Message-Id: <53.644352.589899@unknown> Reply-To: emed22@libero.it Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cins.hanyang.ac.kr id JAA305538 Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable

Help Beta Test Our Site and Be Eligible to Purchase Shares= of=20 Future IPOs In Which We Participate**

eMedsecurities has selected you as a possible participant = to help=20 test our online stock-trading engine for knowledge-based investing = in the=20 life sciences.  For your cooperation, you will be eligible = to purchase=20 shares of future IPOs in which we participate, for as long as y= ou=20 maintain your account with us.  This is limited to only 50 = qualified=20 testers!  Request M= ore Information.**

eMedsecurities=85 The Cure for the Common Portfolio!

eMedsecurities provides you with a wealth of information, = all=20 compiled in a single, easy-to-use resource.  Learn about new r= esearch=20 and upcoming treatments for diabetes, glaucoma, cataract, obesity a= nd much more.  Obtain critical investment information about the=20 companies that are developing these treatments.  eMedsecuritie= s empowers=20 you to make more informed investment decisions.  Request More Information.**

Participation i= n eMedsecurities's Beta Test allows you:

  • Eligibility to purchase s= hares of IPOs in which=20 eMedsecurities participates for as long as you maintain your=20 account**

  • Valuable research of the = entire product=20 pipeline of companies, including stages of clinical development, = by=20 industry or specific disease

  • Useful information about = industry trends, recent=20 developments and upcoming IPOs

  • Commitment to customer se= rvice featuring=20 our Live Customer Service Online

  • Dedication to fast trade = executions at the best=20 possible price.

The following guideline= s will=20 explain what we expect from an eMedsecurities Beta Tester:

  • Open a funded eMedsecurities=20 account

  • Visit our online trading site onc= e=20 a week

  • Execute trades through our Web=20 site in accordance with your normal practice

  • Submit feedback to eMedsecurities= 's development team through a questionnaire sent via=20 email

  • Provide us with additional=20 feedback regarding the site as needed.

The test is limited to = only 50 Beta=20 Testers so sign up now to be considered!  Request More Information.**=20

Please note:<= /B> All applications for the Beta Test must be s= ubmitted by January 25, 2001 to be considered.=20

Please=20 be advised that your information will stay in our proprietary datab= ase and=20 will not be sold, traded, given or otherwise provided to outside ve= ndors.  We respect your privacy.=20

=20

By=20 submitting your information, you implicitly state that this is some= thing=20 that interests you and that you
agree to receive periodic emails from=20 eMedsecurities.=20

Research indicated= that you=20 might benefit from our offer.  To be removed instantly and per= manently from=20 our database, simply click here= .  We respect=20 all removal requests.

** R= estrictions=20 Apply:  Beta test not open t= o residents of HI, IL, MI, MN, NE, NH, TN, TX.  Initial Public=20 Offerings are considered speculative investments and as such may no= t be=20 appropriate for every investor. If an investor chooses to participa= te in=20 IPOs, there are certain restrictions that apply.   Flipping - The first time an invest= or sells their shares within the first 30 days the issue is trading in the=20 secondary market, that investor will not be allocated shares for th= e next=20 90 days following the sale.  The second time that investor =93= flips,"=20 they will not be allocated IPO shares for 180 days.  The third= time=20 that investor =93flips," they lose their IPO allocations perma= nently.  Transferring shares - If the=20 investor transfers IPO shares out of their account within the first= 30=20 days the issue is trading in the secondary market, they will perman= ently=20 lose their IPO allocations.  Beta investors will be chosen = from=20 all the applicants based on their income, net worth and investing=20 experience.  Beta Test open only to those 21 years of age= or older. IPO shares will only be allocated from transactions in=20 which eMedsecurities participates in the underwriting.  A0009-= 1-A2

eMedsecurities, Inc.   Member NASD  SIPC. 

From owner-ietf-ldup@mail.imc.org Mon Jan 29 18:57:05 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12311 for ; Mon, 29 Jan 2001 18:57:05 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA28209 for ietf-ldup-bks; Mon, 29 Jan 2001 15:05:10 -0800 (PST) Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28179; Mon, 29 Jan 2001 15:05:04 -0800 (PST) Received: from [129.250.38.62] (helo=dfw-mmp2.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 14NNRG-0003wb-00; Mon, 29 Jan 2001 23:10:22 +0000 Received: from [206.133.83.14] (helo=localhost) by dfw-mmp2.email.verio.net with esmtp id 14NNPk-0002Od-00; Mon, 29 Jan 2001 23:08:48 +0000 X-Sender: misterprivacy@hushmail.com From: Dave To: "customer" Date: Mon, 29 Jan 2001 14:25:17 -0500 Subject: I could go to JAIL for selling this CD! MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__10618077_51917.11" Message-Id: Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a Multipart MIME message. ------=_NextPart_000_001__10618077_51917.11 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__10618077_51917.11 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9u YWwvL2VuIj4NCjxodG1sPg0KPGhlYWQ+DQogICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50 LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCiAgIDxt ZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTW96aWxsYS80LjYxIFtlbl0gKFdpbjk4 OyBJKSBbTmV0c2NhcGVdIj4NCiAgIDx0aXRsZT5UaGUgQkFOTkVEIENEITwvdGl0bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxmb250IHNpemU9KzE+SGksPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0rMT5JIGhhdmUgYmVlbiByZWNpZXZpbmcgZW1haWxzIHNheWluZyB0aGF0IEknbSBjb250 cmlidXRpbmcNCnRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGhlICJtb3JhbCBkZWNh eSBvZiBzb2NpZXR5IiBieSBzZWxsaW5nIHRoZSBCYW5uZWQgQ0QuJm5ic3A7DQpUaGF0PC9m b250Pg0KPGJyPjxmb250IHNpemU9KzE+bWF5IGJlLCBidXQgSSBmZWVsIHN0cm9uZ2x5IHRo YXQgeW91IGhhdmUgYSByaWdodCB0bw0KYmVuZWZpdCBmcm9tPC9mb250Pg0KPGJyPjxmb250 IHNpemU9KzE+dGhpcyBoYXJkLXRvLWZpbmQgaW5mb3JtYXRpb24uPC9mb250Pg0KPHA+PGZv bnQgY29sb3I9IiNDQzAwMDAiPjxmb250IHNpemU9KzE+U28gSSBhbSBnaXZpbmcgeW91IE9O RSBMQVNUIENIQU5DRQ0KdG8gb3JkZXI8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9y PSIjQ0MwMDAwIj48Zm9udCBzaXplPSsxPnRoZSBCYW5uZWQgQ0QhPC9mb250PjwvZm9udD4N Cjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9MCBDT0xTPTIgV0lEVEg9Ijc1JSIgPg0KPHRy Pg0KPHRkIFdJRFRIPSIxJSI+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2lt YWdlcy9zcHkuanBnIiBoZWlnaHQ9MTI4IHdpZHRoPTg2PjwvdGQ+DQoNCjx0ZD48Zm9udCBz aXplPSsxPldpdGggdGhpcyBwb3dlcmZ1bCBDRCwgeW91IHdpbGwgYmUgYWJsZSB0byBpbnZl c3RpZ2F0ZQ0KeW91ciBmcmllbmRzLCBlbmVtaWVzIGFuZCBsb3ZlcnMgaW4ganVzdCBtaW51 dGVzIHVzaW5nIHRoZSBJbnRlcm5ldC4mbmJzcDsNCllvdSBjYW4gdHJhY2sgZG93biBvbGQg ZmxhbWVzIGZyb20gY29sbGVnZSwgb3IgeW91IGNhbiBkaWcgdXAgc29tZSBkaXJ0DQpvbiB5 b3VyIGJvc3MgdG8gbWFrZSBzdXJlIHlvdSBnZXQgdGhhdCBuZXh0IHByb21vdGlvbiE8L2Zv bnQ+PC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD48Zm9udCBzaXplPSsxPk9yIG1heWJl IHlvdSB3YW50IGEgZmFrZSBkaXBsb21hIHRvIGhhbmcgb24geW91ciBiZWRyb29tPC9mb250 Pg0KPGJyPjxmb250IHNpemU9KzE+d2FsbC4mbmJzcDsgWW91J2xsIGZpbmQgYWRkcmVzc2Vz IGZvciBjb21wYW5pZXMgdGhhdA0KbWFrZSB0aGVzZTwvZm9udD4NCjxicj48Zm9udCBzaXpl PSsxPmRpcGxvbWFzIG9uIHRoZSBCYW5uZWQgQ0QuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0r MT5OZWVkIHRvIGRpc2FwcGVhciBmYXN0IGFuZCBuZXZlciBsb29rIGJhY2s/Jm5ic3A7IE5v IHByb2JsZW0hPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+VXNpbmcgdGhlIEJhbm5lZCBD RCwgeW91IHdpbGwgbGVhcm4gaG93IHRvIGJ1aWxkIGEgY29tcGxldGVseTwvZm9udD4NCjxi cj48Zm9udCBzaXplPSsxPm5ldyBpZGVudGl0eS48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsx Pk9idmlvdXNseSwgdGhlIFBvd2VycyBUaGF0IEJlIGRvbid0IHdhbnQgeW91IHRvIGhhdmUg dGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+QmFubmVkIENELiZuYnNwOyBUaGV5IGhh dmUgdGhyZWF0ZW5lZCBtZSB3aXRoIGxhd3N1aXRzLA0KZmluZXMsPC9mb250Pg0KPGJyPjxm b250IHNpemU9KzE+YW5kIGV2ZW4gaW1wcmlzb25tZW50IHVubGVzcyBJIHN0b3Agc2VsbGlu ZyBpdCBpbW1lZGlhdGVseS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5CdXQgSSBmZWVs IHRoYXQgWU9VIGhhdmUgYSBDb25zdGl0dXRpb25hbCByaWdodCB0byBhY2Nlc3M8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0rMT50aGlzIHR5cGUgb2YgaW5mb3JtYXRpb24sIGFuZCBJIGNh bid0IGJlIGludGltaWRhdGVkLjwvZm9udD4NCjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9 MCBDT0xTPTIgV0lEVEg9IjUwJSIgPg0KPHRyPg0KPHRkIFdJRFRIPSIxMDAlIj48aT48Zm9u dCBjb2xvcj0iIzMzMzNGRiI+PGZvbnQgc2l6ZT0rMT5VbmNsZSBTYW0gYW5kIHlvdXINCmNy ZWRpdG9ycyBhcmUgaG9ycmlmaWVkIHRoYXQgSSBhbSBzdGlsbCBzZWxsaW5nIHRoaXMgcHJv ZHVjdCEmbmJzcDsgVGhlcmUNCm11c3QgYmUgYSBwcmljZSBvbiBteSBoZWFkITwvZm9udD48 L2ZvbnQ+PC9pPjwvdGQ+DQoNCjx0ZCBXSURUSD0iMSUiPjxpbWcgU1JDPSJodHRwOi8vY29t cHV6b25ldXNhLmNvbS9pbWFnZXMvb3V0bGF3LmpwZyIgaGVpZ2h0PTEyOCB3aWR0aD05Mz48 L3RkPg0KPC90cj4NCjwvdGFibGU+DQoNCjxwPjxmb250IHNpemU9KzE+V2h5IGFyZSB0aGV5 IHNvIHVwc2V0PyBCZWNhdXNlIHRoaXMgQ0QgZ2l2ZXMgeW91IGZyZWVkb20uPC9mb250Pg0K PGJyPjxmb250IHNpemU9KzE+QW5kIHlvdSBjYW4ndCBidXkgZnJlZWRvbSBhdCB5b3VyIGxv Y2FsIFdhbG1hcnQuJm5ic3A7DQpZb3Ugd2lsbDwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx PmhhdmUgdGhlIGZyZWVkb20gdG8gYXZvaWQgY3JlZGl0b3JzLCBqdWRnbWVudHMsIGxhd3N1 aXRzLA0KSVJTPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGF4IGNvbGxlY3RvcnMsIGNy aW1pbmFsIGluZGljdG1lbnRzLCB5b3VyIGdyZWVkeSBleC13aWZlDQpvcjwvZm9udD4NCjxi cj48Zm9udCBzaXplPSsxPmV4LWh1c2JhbmQsIGFuZCBNVUNIIG1vcmUhPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0rMT5KdXN0IGxvb2sgYXQgc29tZSBvZiB0aGUgdGhpbmdzIHlvdSBjYW4g ZG8gd2l0aCB0aGlzIENEDQouLi48L2ZvbnQ+DQo8dWw+DQo8bGk+DQo8Yj48Zm9udCBjb2xv cj0iIzAwMDA5OSI+U2F2ZSBodW5kcmVkcyBvciBldmVuIHRob3VzYW5kcyBvZiBkb2xsYXJz IG9uDQp5b3VyIHRheGVzIGJ5IHVzaW5nIHRoZSBzZWNyZXQgdGF4IHRpcHMgY29udGFpbmVk IGluIHRoaXMgcGFja2FnZS4mbmJzcDsNClRoZSBJUlMgZG9lcyBOT1Qgd2FudCB5b3UgdG8g a25vdyB0aGVzZSBsb29waG9sZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u dCBjb2xvcj0iIzAwMDA5OSI+VHJhY2sgZG93biBmcmllbmRzIGFuZCBvbGQgZmxhbWVzIGZy b20gdGhlIGNvbWZvcnQNCm9mIHlvdXIgb3duIGhvbWUgd2l0aCBvdXIgSW50ZXJuZXQgaW52 ZXN0aWdhdGlvbiByZXNvdXJjZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u dCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQgd2hlcmUgeW91ciBFWCBpcyBoaWRpbmcgdGhl aXIgbW9uZXkgdG8NCmF2b2lkIGFsaW1vbnksIGNoaWxkIHN1cHBvcnQsIG9yIGRpdm9yY2Ug c2V0dGxlbWVudHMuIFRoZW4gZ2V0IHlvdXIgaGFuZHMNCm9uIHRoYXQgbW9uZXkuJm5ic3A7 IEJsZWVkICdlbSBkcnkhJm5ic3A7IFByaXZhdGUgaW52ZXN0aWdhdG9ycyBjaGFyZ2UNCnRo b3VzYW5kcyBvZiBkb2xsYXJzIGZvciB0aGlzIHNlcnZpY2UsIGJ1dCB5b3UgY2FuIGRvIGl0 IHdpdGggYSBjb21wdXRlcg0KYW5kIGFuIGludGVybmV0IGNvbmVjdGlvbiB3aGVuIHlvdSBi dXkgdGhlIEJhbm5lZCBDRCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNv bG9yPSIjMDAwMDk5Ij5MZWFybiBob3cgdG8gdXNlIG9mZnNob3JlIG1vbmV5IGhhdmVucyBh bmQgYXNzZXQNCnByb3RlY3Rpb24gdHJ1c3RzIHRvIGF2b2lkIGxhd3N1aXRzLCBqdWRnbWVu dHMsIGFuZCBmb29sIHRoZSBtb3N0IGFnZ3Jlc3NpdmUNCnRheCBjb2xsZWN0b3IhJm5ic3A7 IElmIHlvdXIgbW9uZXkgaXMgc2l0dGluZyBpbiBhIFVTIGJhbmsgYWNjb3VudCwgeW91cg0K ZnVuZHMgY2FuIGJlIGxldmllZCBvciBmcm96ZW4gY29tcGxldGVseSBhdCBhbnkgdGltZS4m bmJzcDsgVGhlIFVTIGdvdmVybm1lbnQNCnVzZXMgImNpdmlsIGFzc2V0IGZvcmZlaXR1cmUi IHRvIHN0ZWFsIGJpbGxpb25zIG9mIGRvbGxhcnMgZWFjaCB5ZWFyIGZyb20NCmhhcmQtd29y a2luZywgbGF3IGFiaWRpbmcgY2l0aXplbnMuJm5ic3A7IEdldCB5b3VyIG1vbmV5IG91dCBv ZiB0aGUgY291bnRyeQ0KYmVmb3JlIFVuY2xlIFNhbSBzbmF0Y2hlcyBpdCBhbGwuPC9mb250 PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQg d2hlcmUgdG8gYnV5ICJmb3JiaWRkZW4gcHJvZHVjdHMiIG9uDQp0aGUgSW50ZXJuZXQuIEZ1 cnRoZXIgZWxhYm9yYXRpb24gc2hvdWxkIG5vdCBiZSBuZWNlc3Nhcnk7IGp1c3QgdXNlIHlv dXINCmltYWdpbmF0aW9uLjwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29s b3I9IiMwMDAwOTkiPkdldCBhIGJldHRlciBqb2IgYnkgcHVyY2hhc2luZyBhIGNvbGxlZ2Ug ZGVncmVlDQooaW5jbHVkaW5nIGEgUGhkISkgZm9yIGEgdmVyeSBsb3cgZmVlLiBObyBzdHVk eSByZXF1aXJlZCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNvbG9yPSIj MDAwMDk5Ij5JZiB5b3VyIEVYIGlzIGNvbWluZyBhZnRlciB5b3VyIG1vbmV5LCBzdGF5IG9u ZQ0Kc3RlcCBhaGVhZCBvZiB0aGUgbGF3eWVycyBhbmQga2VlcCB0aGVpciBncmVlZHkgaGFu ZHMgb2ZmIHlvdXIgbG9vdC4gRmluZA0Kb3V0IGhvdyB0byBoaWRlIHlvdXIgbW9uZXkgd2hl cmUgaXQgd2lsbCBuZXZlciBiZSBmb3VuZC48L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxi Pjxmb250IGNvbG9yPSIjMDAwMDk5Ij5Bdm9pZCBsZWdhbCBwcm9ibGVtcywganVkZ21lbnRz LCBjb252aWN0aW9ucywNCmFuZCBldmVuIHByaXNvbiBzZW50ZW5jZXMgYnkgb2J0YWluaW5n IGEgY29tcGxldGVseSBuZXcgaWRlbnRpdHkgYW5kIGRpc2FwcGVhcmluZw0Kd2l0aG91dCBh IHRyYWNlITwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29sb3I9IiMwMDAw OTkiPkVyYXNlIHlvdXIgY3JpbWluYWwgcmVjb3JkIGFuZCBvYnRhaW4gYSBjb3B5IG9mDQp5 b3VyIEZCSSBmaWxlIHVzaW5nIHRoZSBGcmVlZG9tIG9mIEluZm9ybWF0aW9uIEFjdC4mbmJz cDsgRmluZCBvdXQgaWYgdGhlDQpnb3Zlcm5tZW50IGlzIGludmVzdGlnYXRpbmcgeW91IE5P VyBiZWZvcmUgaXQncyB0b28gTEFURSE8L2ZvbnQ+PC9iPjwvbGk+DQo8L3VsPg0KPGZvbnQg c2l6ZT0rMT5JZiB5b3UgaGF2ZSBiZWVuIHB1dHRpbmcgb2ZmIGJ1eWluZyBUaGUgQmFubmVk IENELCB3aGF0IGFyZQ0KeW91PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+d2FpdGluZyBm b3I/Jm5ic3A7IEJpZyBCcm90aGVyIGlzIGFscmVhZHkgYnJlYXRoaW5nIGRvd24NCm15IG5l Y2ssIHNvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+SSBjYW4ndCBrZWVwIHNlbGxpbmcg aXQgZm9yZXZlci4mbmJzcDsgSWYgeW91IGtlZXAgd2FpdGluZw0KdG8gcGxhY2U8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0rMT55b3VyIG9yZGVyLCB5b3UgbWF5IG5ldmVyIGZpbmQgVGhl IEJhbm5lZCBDRCBhZ2Fpbi4mbmJzcDsNCkZvciBvbmx5PC9mb250Pg0KPGJyPjxmb250IHNp emU9KzE+JDE5Ljk5LCB5b3Ugd2lsbCBnYWluIHZhbHVhYmxlIHBlYWNlLW9mLW1pbmQga25v d2luZw0KaG93IHRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+c2FmZWd1YXJkIHlvdXJz ZWxmLCB5b3VyIGZhbWlseSwgYW5kIHlvdXIgbW9uZXkuJm5ic3A7DQpXaG8gY2FuIHB1dCBh PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+cHJpY2Ugb24gZnJlZWRvbT8hPC9mb250Pg0K PHA+PGk+PHU+PGZvbnQgc2l6ZT0rMT5IZXJlIGlzIGFub3RoZXIgbG9vayBhdCB0aGUgY29u dGVudHMgb2YgdGhlIEJBTk5FRA0KQ0Q6PC9mb250PjwvdT48L2k+DQo8cD48aW1nIFNSQz0i aHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3 aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgY29u ZmlkZW50aWFsIGluZm8gb24gYW55b25lIGluIDMwIG1pbnV0ZXMgb3I8L2ZvbnQ+PC9mb250 Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmxlc3Mgb24gdGhl IEludGVybmV0LiBZb3UnbGwgYmUNCmFibGUgdG8gdHJhY2sgZG93biB5b3VyPC9mb250Pjwv Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vbGQgZmxh bWUsIGZpbmQgb3V0IGhvdyBtdWNoIG1vbmV5DQp5b3VyIGV4IGlzIGhpZGluZzwvZm9udD48 L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW4gdGhl aXIgYmFuayBhY2NvdW50LCBvciBydW4gYQ0KYmFja2dyb3VuZCBjaGVjayBvbjwvZm9udD48 L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+cHJvZXNw ZWN0aXZlIGNsaWVudCBvciBlbXBsb3llZS4NCkV2ZW4gZ292ZXJubWVudDwvZm9udD48L2Zv bnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YWdlbmNpZXMg aGF2ZSB0cm91YmxlIG9idGFpbmluZw0KbXVjaCBvZiB0aGlzIGluZm9ybWF0aW9uLjwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+WW91 IHdpbGwgaGF2ZSBhbGwgdGhlIHJlc291cmNlcw0Kb2YgYW55IHByb2Zlc3Npb25hbDwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW52 ZXN0aWdhdG9yIHJpZ2h0IGF0IHlvdXIgZmluZ2VydGlwcw0KLSBvbiB5b3VyIGhvbWU8L2Zv bnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNv bXB1dGVyITwvZm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVz YS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xv cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkxpc3Qgb2YgY29tcGFuaWVzIHdobyB3aWxs IGlzc3VlIHlvdSBhIGNvbGxlZ2U8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIj NjY2NjY2Ij48Zm9udCBzaXplPSsxPmRlZ3JlZSAoaW5jbHVkaW5nIGEgUGhkLikgZm9yIGEN CmZlZS4gTm8gc3R1ZHkgcmVxdWlyZWQhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJo dHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdp ZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93 IHRvIGdldCBGUkVFIGNhYmxlIGFuZCBEU1MgY2hhbm5lbHMsPC9mb250PjwvZm9udD4NCjxi cj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5pbmNsdWRpbmcgdGhlIGFk dWx0IHN0YXRpb25zIGFuZA0KUGF5LVBlci1WaWV3ITwvZm9udD48L2ZvbnQ+DQo8cD48aW1n IFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdo dD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkhv dyB0byBPYnRhaW4gTWljcm9zb2Z0IFByb2R1Y3RzIGFic29sdXRlbHk8L2ZvbnQ+PC9mb250 Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPkZSRUUsIHRoZSBz YWZlIGFuZCBMRUdBTCB3YXkhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8v Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5 Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGlzdCBvZiBzdXBwbGll cnMgb2YgInF1ZXN0aW9uYWJsZSIgaXRlbXMsIHN1Y2g8L2ZvbnQ+PC9mb250Pg0KPGJyPjxm b250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmFzIGZjYyBiYW5uZWQgY29tbXVu aWNhdGlvbnMgZGV2aWNlcywNCnNjYW5uZXJzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQg Y29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+bmlnaHQgdmlzaW9uIGdvZ2dsZXMsIHBh c3Nwb3J0cywNCmZha2UgaWRlbnRpZmljYXRpb24sPC9mb250PjwvZm9udD4NCjxicj48Zm9u dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5hbmQgZXZlcnl0aGluZyBlbHNlIHRo YXQgeW91IHdvbid0DQpmaW5kIGluIHRoZSBiYWNrPC9mb250PjwvZm9udD4NCjxicj48Zm9u dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vZiBTb2xkaWVyIG9mIEZvcnR1bmUg bWFnYXppbmUhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KRmluZCBwcm9kdWN0cyB0byByZXNlbGwg b24gdGhlIEludGVybmV0IHdpdGggb3VyPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xv cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5XaG9sZXNhbGUgRGlyZWN0b3J5IGNvbnRhaW5p bmcNCm92ZXIgMSBtaWxsaW9uPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2 NjY2NiI+PGZvbnQgc2l6ZT0rMT4odGhhdCdzIHJpZ2h0LCBvbmUgbWlsbGlvbiEpIHdob2xl c2FsZQ0Kc291cmNlcyBmb3I8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2 NjY2Ij48Zm9udCBzaXplPSsxPmNvbXB1dGVycywgZWxlY3Ryb25pY3MsIGJlYW5pZXMsDQp0 cmVuZCBpdGVtcyw8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48 Zm9udCBzaXplPSsxPmpld2VscnksIGNhcnMsIGNvbGxlY3RpYmxlcywgYW5kDQpldmVyeXRo aW5nIGVsc2UhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KT3ZlciAyNSBtaWxsaW9uIGVtYWlsIGFk ZHJlc3NlcywgZnJlc2ggYW5kPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2 NjY2NiI+PGZvbnQgc2l6ZT0rMT50YXJnZXRlZCEgWW91IGNhbiB1c2UgdGhlc2UgdG8NCmNv bnRhY3QgdGhlIHBlb3BsZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2 NjYiPjxmb250IHNpemU9KzE+YW5kIHNlbmQgdGhlbSB5b3VyIGFkdmVydGlzZW1lbnRzLjwv Zm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1h Z2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2 NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgb3V0IGhvdyB0byBnZXQgYSBjb21wbGV0ZWx5IG5l dyBpZGVudGl0eS48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48 Zm9udCBzaXplPSsxPkRpc2FwcGVhciB3aXRob3V0IGEgdHJhY2UhPC9mb250PjwvZm9udD4N CjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdp ZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXpl PSsxPg0KRmluZCBvdXQgaG93IHRvIEVSQVNFIGJhZCBjcmVkaXQgYW5kIGV2ZW48L2ZvbnQ+ PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNyZWF0 ZSBhIHdob2xlIG5ldyBmaWxlIGluIHRoZQ0KY3JlZGl0IGJ1cmVhdSBjb21wdXRlcnMuPC9m b250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFn ZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2 Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93IHRvIGJlYXQgdGhlIElSUy4gVGF4IHRpcHMg Zm9yIHRoZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250 IHNpemU9KzE+cmVzdCBvZiB1cy48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6 Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9 MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpDb21wbGV0ZSBndWlk ZSBvbiBob3cgdG8gY2xhaW0gcHVibGljIGxhbmQ8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250 IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPm9mZmVyZWQgYnkgdGhlIEdvdmVybm1l bnQuIFlvdQ0KY2FuIGZpbmQgeW91cjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9 IiM2NjY2NjYiPjxmb250IHNpemU9KzE+ZHJlYW0gaG9tZSBmb3IgYSByaWRpY3Vsb3VzbHkg bG93DQpwcmljZSBvciBidXk8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2 NjY2Ij48Zm9udCBzaXplPSsxPnByb3BlcnRpZXMgdG8gcmVzZWxsIGZvciBhIGh1Z2UNCnBy b2ZpdCE8L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2Eu Y29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9 IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBY2NlcHQgY2hlY2tzIGZyb20geW91ciBjdXN0 b21lcnMgYnkgZmF4LDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYi Pjxmb250IHNpemU9KzE+cGhvbmUgYW5kIGVtYWlsIHdpdGggdGhlIGZ1bGwgd29ya2luZw0K dmVyc2lvbiBvZjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxm b250IHNpemU9KzE+Q2hlY2tlciBTb2Z0d2FyZSBpbmNsdWRlZCE8L2ZvbnQ+PC9mb250Pg0K PHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lm IiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9 KzE+DQpCdXNpbmVzcyBzb2Z0d2FyZSB0byBoZWxwIHlvdSBydW4geW91ciBzbWFsbDwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YnVz aW5lc3MsIGluY2x1ZGluZyBsYWJlbCBtYWtlcg0Kc29mdHdhcmUsIG1vbmV5PC9mb250Pjwv Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5tYW5hZ2Vt ZW50IHNvZnR3YXJlLCBJUlMgZm9yZ2l2ZW5lc3MNCnByb2dyYW0sPC9mb250PjwvZm9udD4N Cjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5kYXRhYmFzZSBzb2Z0 d2FyZSwgYW5kIG11Y2ggbW9yZS48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6 Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9 MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBIGh1Z2UgY29sbGVj dGlvbiBvZiBzY3JlZW5zYXZlcnMsIGdyYXBoaWNzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZv bnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+Y2xpcGFydCwgYW5kIGRlc2t0b3Ag dGhlbWVzIHRvDQpzcGljZSB1cCB5b3VyIGNvbXB1dGVyLjwvZm9udD48L2ZvbnQ+DQo8cD48 aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhl aWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4N Ck1VQ0gsIE1VQ0ggTU9SRSB0aGF0IHdlIGRvbid0IGhhdmUgcm9vbSB0byBsaXN0ITwvZm9u dD48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsxPldlIGFyZSBzbyBjb25maWRlbnQgdGhhdCB5 b3Ugd2lsbCBsb3ZlIHRoaXMgQ0QgdGhhdCB3ZTwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx Pm9mZmVyIGEgZnVsbCAzMC1kYXksIG5vIHF1ZXN0aW9ucyBhc2tlZCBtb25leS1iYWNrPC9m b250Pg0KPGJyPjxmb250IHNpemU9KzE+Z3VhcmFudGVlLiBUbyBvcmRlciB0aGUgIkJhbm5l ZCBDRCIgcmlnaHQgbm93IGZvciB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5zdXBl ciBsb3cgcHJpY2Ugb2Ygb25seSAkMTkuOTksIGp1c3QgY2xpY2sgb24gdGhlIGxpbms8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5iZWxvdyB0byBwYXkgd2l0aCBhIFZpc2Egb3IgTWFz dGVyY2FyZDo8L2ZvbnQ+DQo8YnI+Jm5ic3A7DQo8dGFibGUgQk9SREVSPTAgQ09MUz0yIFdJ RFRIPSI1MCUiID4NCjx0cj4NCjx0ZD48Zm9udCBzaXplPSsyPjxhIGhyZWY9Imh0dHA6Ly93 d3cuY29tcHV6b25ldXNhLmNvbS9jY3BheW1lbnQvYmFubmVkY2Q3Mi5odG0iPk9yZGVyDQpO b3chPC9hPjwvZm9udD48L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxpbWcgU1JDPSJodHRwOi8v Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvZ3VhcmFudGVlLmdpZiIgaGVpZ2h0PTk2IHdpZHRo PTk1PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD5PciB5b3UgbWF5 IHBheSB3aXRoIGNhc2gsIGNoZWNrIG9yIG1vbmV5IG9yZGVyIGJ5IHByaW50aW5nIHRoZSBv cmRlcg0KPGJyPmZvcm0gYmVsb3cgYW5kIHNlbmRpbmcgaXQgd2l0aCB5b3VyIHBheW1lbnQu DQo8cD48Yj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIENVVCBIRVJFIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPC9iPg0KPHA+UHJvZHVjdDogIlRoZSBCYW5uZWQgQ0QiDQo8YnI+UHJp Y2U6ICQxOS45OSArICQ0LjAxIHNoaXBwaW5nL2hhbmRsaW5nDQo8cD5IT1cgVE8gT1JERVIg QlkgTUFJTDogUHJpbnQgb3V0IHRoaXMgb3JkZXIgZm9ybSBhbmQgc2VuZCBjYXNoLA0KPGJy PnBlcnNvbmFsIGNoZWNrLCBtb25leSBvcmRlciBvciBjYXNoaWVyJ3MgY2hlY2sgdG8gdGhl IGFkZHJlc3MgbGlzdGVkDQpiZWxvdzoNCjxwPlF1aWtzaWx2ZXIgRW50ZXJwcmlzZXMgSW5j Lg0KPGJyPjM3OTIgQnJvYWR3YXkgIzM5OA0KPGJyPk5ldyBZb3JrLCBOWSAxMDAzMg0KPHA+ WW91ciBTaGlwcGluZyBJbmZvcm1hdGlvbjoNCjxwPllvdXIgTmFtZV9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQWRkcmVzc19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQ2l0eV9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPlN0YXRl IC8gWmlwX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJy PlBob25lICM6IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPGJyPihGb3IgcHJvYmxlbXMgd2l0aCB5b3VyIG9yZGVyIG9ubHkuIE5vIHNhbGVzbWVu IHdpbGwgY2FsbC4pDQo8cD5FbWFpbCBBZGRyZXNzX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPHA+UGxlYXNlIG5vdGUgdGhhdCBtYWlsLWluIG9yZGVycyBt YXkgYmUgZGVsYXllZCAyLTQgd2Vla3MuDQo8cD5bIF0gSSBhbSBlbmNsb3NpbmcgYSBjaGVj ayBvciBtb25leSBvcmRlciBmb3IgJDI0LjAwDQo8cD5bIF0gSSBhbSBtYWlsaW5nIG15IGNy ZWRpdCBjYXJkIG51bWJlci4gKE5vdGUgeW91ciBjYXJkIHdpbGwgYmUgY2hhcmdlZA0KZm9y ICQyNC4wMCkNCjxwPklmIHBheWluZyBieSBjcmVkaXQgY2FyZCwgcGxlYXNlIGZpbGwgaW4g dGhlIGluZm9ybWF0aW9uIGJlbG93Og0KPHA+Q3JlZGl0IENhcmQgTnVtYmVyOl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo8YnI+RXhwaXJhdGlvbiBEYXRlOl9fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPGJyPlNpZ25hdHVyZTpfX19fX19fX19fX19fX19fX19f X19fX19fDQo8YnI+RGF0ZTpfX19fX19fX19fX19fX19fX19fXw0KPHA+Tk9URTogVGhpcyBD RCBpcyBmb3IgaW5mb3JtYXRpb25hbCwgZWR1Y2F0aW9uYWwsIG9yDQo8YnI+ZW50ZXJ0YWlu bWVudCBwdXJwb3NlcyBvbmx5LiZuYnNwOyBTb21lIG9mIHRoZSBhY3Rpdml0aWVzDQo8YnI+ ZGVzY3JpYmVkIG9uIHRoaXMgQ0QgbWF5IGJlIGlsbGVnYWwgaWYgY2FycmllZCBvdXQuDQo8 YnI+VGhpcyBDRCBjb250YWlucyBsaW5rcyBhbmQgYWRkcmVzc2VzIG9mIGNvbXBhbmllcw0K PGJyPmFuZCBpbmRpdmlkdWFscyB3aGljaCBwcm9kdWNlIHZhcmlvdXMgcHJvZHVjdHMsIG9y DQo8YnI+b2ZmZXIgdmFyaW91cyBzZXJ2aWNlcywgd2hpY2ggbWF5IGJlIGlsbGVnYWwgaW4g eW91cg0KPGJyPmNvdW50cnksIHN0YXRlLCBvciBjaXR5LiZuYnNwOyBIb3dldmVyLCBpdCBp cyBwZXJmZWN0bHkNCjxicj5MRUdBTCB0byBwdXJjaGFzZSBhbmQgcG9zc2VzcyB0aGUgQmFu bmVkIENEIGluIHRoZQ0KPGJyPlVuaXRlZCBTdGF0ZXMgb2YgQW1lcmljYS4mbmJzcDsgQ29u dGFpbnMgYXBwcm94aW1hdGVseQ0KPGJyPjEwMCBtZWdzIG9mIGluZm9ybWF0aW9uLg0KPHA+ U2hpcHBpbmcgb3V0c2lkZSBVU0EgYWRkICQxMC4wMA0KPHA+KioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCjxicj5Zb3UgYXJl IHJlY2lldmluZyBhbiB1bnNvbGljaXRlZCBjb21tZXJjaWFsIGVtYWlsIGZyb20NCjxicj5R dWlrc2lsdmVyIEVudGVycHJpc2VzIEluYy4mbmJzcDsgV2UgcmVjb2duaXplIHRoYXQgeW91 IG1heQ0KPGJyPm5vdCB3aXNoIHRvIHJlY2lldmUgc3VjaCBlbWFpbHMgaW4gdGhlIGZ1dHVy ZSwgYW5kIHdlDQo8YnI+aGF2ZSBwcm92aWRlZCBhIGxpbmsgdG8gYXV0b21hdGljYWxseSBh bmQgaW5zdGFudGx5DQo8YnI+cmVtb3ZlIHlvdXJzZWxmOiA8YSBocmVmPSJodHRwOi8vd3d3 LmNvbXB1em9uZXVzYS5jb20vcmVtb3ZlLmh0bSI+UkVNT1ZFPC9hPg0KPGJyPlRoaXMgbWVz c2FnZSBpcyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGgNCjxicj5mZWRl cmFsIGd1aWRlbGluZXMgZ292ZXJuaW5nIHRoZSB0cmFuc21pc3Npb24gb2YNCjxicj51bnNv bGljaXRlZCBjb21tZXJjaWFsIGVtYWlsLCBpbmNsdWRpbmcgdGhlIHByb3Zpc2lvbiBvZg0K PGJyPmNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIG91ciBjb21wYW55IHdpdGhpbiB0aGlzIGVt YWlsLCBhDQo8YnI+dmFsaWQgcmV0dXJuIGVtYWlsIGFkZHJlc3MsIGFuZCBhIHdheSBmb3Ig Y3VzdG9tZXJzDQo8YnI+dG8gcmVtb3ZlIHRoZW1zZWx2ZXMuJm5ic3A7IFBsZWFzZSBub3Rl LCBob3dldmVyLCB0aGF0IG91cg0KPGJyPmVtYWlsIGFkZHJlc3Mgd2FzIHZhbGlkIGF0IHRo ZSB0aW1lIG9mIHNlbmRpbmcsIGJ1dCBtYXkNCjxicj5iZSBjYW5jZWxsZWQgYnkgdGhlIElT UCBzaG9ydGx5IHRoZXJlYWZ0ZXIgZHVlIHRvIG91cg0KPGJyPnVzZSBvZiB1bnNvbGljaXRl ZCBlbWFpbC4mbmJzcDsgWW91IGNhbiByZWFkIGFib3V0IHRoZSB2YXJpb3VzDQo8YnI+bGF3 cyBnb3Zlcm5pbmcgdW5zb2xpY2l0ZWQgZW1haWw6IGh0dHA6Ly9zcGFtbGF3cy5jb20NCjxi cj4iVW5zb2xpY2l0ZWQgY29tbWVyY2lhbCBlbGVjdHJvbmljIG1haWwgY2FuIGJlIGFuIGlt cG9ydGFudA0KPGJyPm1lY2hhbmlzbSB0aHJvdWdoIHdoaWNoIGJ1c2luZXNzZXMgYWR2ZXJ0 aXNlIGFuZCBhdHRyYWN0DQo8YnI+Y3VzdG9tZXJzIGluIHRoZSBvbmxpbmUgZW52aXJvbm1l bnQuIiZuYnNwOyAtLSBVLlMuIENvbmdyZXNzLA0KPGJyPkguUi4gMTA2dGggQ09OR1JFU1Mg MmQgU2Vzc2lvbiBILiBSLiAzMTEzIFNlYy4gMiAoYSkzIEp1bHkNCjxicj4xOSwgMjAwMCBo dHRwOi8vd3d3LnNwYW1sYXdzLmNvbS9mZWRlcmFsL2hyMzExMy5odG1sDQo8YnI+KioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN Cjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjwvYm9keT4NCjwvaHRtbD4NCg== ------=_NextPart_000_001__10618077_51917.11-- From owner-ietf-ldup@mail.imc.org Wed Jan 31 16:55:25 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26418 for ; Wed, 31 Jan 2001 16:55:24 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA26212 for ietf-ldup-bks; Wed, 31 Jan 2001 12:50:57 -0800 (PST) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA26206 for ; Wed, 31 Jan 2001 12:50:56 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 31 Jan 2001 13:57:05 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Wed, 31 Jan 2001 13:56:56 -0700 From: "Javed Khan" To: , Subject: LDAP Extensions for Managing Replication Context and Replicas Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_673C2831.7D1C331A" Sender: owner-ietf-ldup@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_673C2831.7D1C331A Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable A New Internet-Draft is available from the on-line Internet-Drafts = directories. Please send comments to: Javed Khan (jkhan@novell.com) Steve Sonntag (vtag@novell.com) Thanks =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Title : LDAP Extensions for Managing Replication Context and=20 Replicas Author(s) : J. Khan, S. Sonntag Filename : draft-khan-ldapext-replica-mgmt-00.txt Pages : 14 Date : 30-Jan-01 =20 Version 3 of the LDAP Protocol provides a mechanism for sending and receiving extended LDAP requests. This document describes twelve extended operations supported by Novell eDirectory Servers. A client application can use these extensions to manage directory replication contexts (partitions) and replicas. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-khan-ldapext-replica-mgmt-00.txt --=_673C2831.7D1C331A Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A New Internet-Draft is available from the on-line Internet-Drafts=20 directories.
 
Please send comments to:
 
Javed Khan (jkhan@novell.com)<= /DIV>
Steve Sonntag (vtag@novell.com)=
 
Thanks
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    Title        : = LDAP=20 Extensions for Managing Replication Context and=20
            = ;            &n= bsp;=20 Replicas
    Author(s)    : J. Khan, = S.=20 Sonntag
    Filename    :=20 draft-khan-ldapext-replica-mgmt-00.txt
   =20 Pages        : 14
   =20 Date        : 30-Jan-01
   = =20
Version 3 of the LDAP Protocol provides a mechanism for sending=20 and
receiving extended LDAP requests.  This document describes=20 twelve
extended operations supported by Novell eDirectory Servers.
A= =20 client application can use these extensions to manage directory
replicat= ion=20 contexts (partitions) and replicas.
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-khan-ldapext-replica-mgm= t-00.txt
 
 
 
 

 
--=_673C2831.7D1C331A--