idnits 2.17.1 draft-ietf-asid-replica-req-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 92 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([LDAPv3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 86: '...le - Replication MUST be simple to con...' RFC 2119 keyword, line 88: '...t of replication MUST have minimal imp...' RFC 2119 keyword, line 90: '...ency, replication policies SHALL allow...' RFC 2119 keyword, line 94: '...eplicated copies MUST eventually be up...' RFC 2119 keyword, line 97: '...ty between vendors - Replicas MUST be...' (26 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 15 has weird spacing: '...ment is an I...' == Line 16 has weird spacing: '...cuments of t...' == Line 17 has weird spacing: '...ups may also ...' == Line 21 has weird spacing: '...ents at any...' == Line 22 has weird spacing: '...e. It is i...' == (87 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (17 Nov 1997) is 9650 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'LDAPv3' on line 309 looks like a reference -- Missing reference section? 'Changelog' on line 316 looks like a reference -- Missing reference section? 'LDIF' on line 313 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF-ASID Russel Weiser 3 Informational Draft Novell Inc. 4 Ellen Stokes 5 IBM 6 Bob Huston 7 Iris Assoc. 8 17 Nov 1997 10 LDAP Replication Requirements 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet- Drafts. 20 Internet-Drafts are draft documents valid for a Maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or cite them other than as " work in progress." To learn 24 the current status of any Internet-Draft, please check the "lid- 25 abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 This document discusses the fundamental requirements for replication 33 of the LDAPv3 [LDAPv3] protocol. It is intended to be a gathering 34 place for general replication requirements needed to provide 35 interoperability between informational directories. 37 1. Introduction 39 The ability to distribute directory information throughout the net- 40 work provides a two fold benefit to the network: (1) increasing the 41 reliabililty of the directory through fault tolerance, and (2) brings 42 the directory content closer to the clients using the data. LDAPs 43 acceptance as a access protocol for directory information is driving 44 the need to distribute LDAP directory content among servers within 45 enterprise and Internet. Currently LDAP does not define a replica- 46 tion mechanism and only generally mentions LDAP shadow servers (see 47 [LDAPv3] and [Changelog]) in passing. The requirements for replica- 48 tion are critical to the successful deployment and acceptance of LDAP 49 in the market place. 51 2. Objectives 53 For the purposes of this document, the following definitions are 54 used: 56 Replication - The process of copying portions of naming context 57 information and content, between multiple LDAP servers, such that 58 certain, predefined portions of the information are available from 59 many geographic locations. 61 Synchronization - The harmonization of dissimilar directories and 62 namespaces, whereby it is guarenteed that at all times, all copies of 63 the information will be identicle. 65 Incremental Update - The process of updating a replica, or copy, of a 66 naming context, by updating only those fields or objects which have 67 changed. 69 Master Replica - A writeable copy of the replicated information. 71 Slave Replica - A read-only copy of the replicated information. 73 Multi-Master Replication - A replication model where entries can be 74 written and updated on any of several replica copies. 76 Master Slave, or Single Master Replication - Replication model that 77 assumes only one server, the master, allows write access to the 78 replicated data. Note that Master-Slave replication can be considered 79 a proper subset of multi-master replication. 81 The major objectives are to provide a simple, highly efficient and 82 high performing replication method for LDAP while also providing the 83 appropriate flexibility to meet the needs of both the Internet and 84 enterprise environments. 86 Simple - Replication MUST be simple to configure and maintain. 88 Efficient - The act of replication MUST have minimal impact on 89 both the system and network performance and throughput. In order 90 to achieve this efficiency, replication policies SHALL allow 91 replication of changed information to be postponed to a more 92 conveniant period, or done at user request. 94 Reliable - All replicated copies MUST eventually be updated with 95 the changed information, specified by the replication policy. 97 Provides Interoperability between vendors - Replicas MUST be 98 allowed to span different vendors directory services. Without such 99 vendor interoperability, internet based directory services will 100 not be feasible. 102 Security of data, connections and replication process - Replicated 103 data MUST be transferred in a secure manner, where both endpoints 104 in the communication have identified and authenticated themselves 105 to the other server. 107 Robustness - The ability to deal with differences in directory 108 services schemas in a cross vendor enterprise. The ability to 109 recover when a replica server is unavailable during replication. 111 Location independant manageability - A replica administrator MUST 112 be allowed access to the replication policies, regardless of 113 network location. 115 Auditability - Each copy of a replica MUST maintain a history of 116 who it has replicated with and who has replicated with it. 118 Ability to Set Change Metrics - Replication schedules MUST be 119 dynamic to allow for periodic replication, with the replication 120 period determined by administrator of the replicated system. In 121 addition, replication policy must be globally available to any 122 authorized administrator from anyplace on the network. 124 Replication Policy Mechanisms - Policies to allow both schedule 125 and content of replicated information MUST be allowed. Policies 126 SHALL allow replication to be schedule both on a periodic basis, 127 as well as on a number of changes basis. 129 3. General Requirements 131 The following requirements are in no priority order. 133 Simple - Replication MUST be simple to configure and maintain. 135 Due to the nature of the Internet and enterprise environments, the 136 flexibility of a LDAP replication should be of the upmost importance 137 Replication must allow for both total and incremental update of 138 objects. In addition, updates MUST be allowed to multiple replicas to 139 enhance distributed performance. 141 Support for both multi-master and master/slave environments should be 142 a driving requirement. Since master/slave is considered a proper sub- 143 set of multi-master, both these models SHALL be supported. 145 Additionally synchronization of LDAP replicas should allow either a 146 master and or replica to initiate the replication process and allow 147 the initiator to determine whether it will become a consumer and or 148 supplier during the synchronization process. This would allow a 149 replica to be periodically connected and synchronized from remote 150 sites at the local administrator's discretion. 151 Another driving force or general requirement should be that all 152 replicated information between the master database and its replica 153 databases SHALL be identical including all no user modify operational 154 attributes such as timestamps. 155 It is not required to have all replica copies on the network avail- 156 able at replication time. In a distributed enterprise environment, it 157 is unrealistic to assume that all copies of a replica will be avail- 158 able for update at all times. Under this circumstance, when a previ- 159 ously unavailable replica copy comes on line, it SHOULD initiate 160 replication with another replicated copy such that its local repli- 161 cated information is brought up to date. 162 In addition, in a distributed multi-vendor environment, LDAP replica- 163 tion SHALL NOT ensure all copies of the replicated information be 164 complete copies of the replicated object. It is not realistic to 165 assume that all vendors have cooperating schemas, but it is required 166 that different vendors schemas allow replication from diverse 167 schemas. LDAP replication SHALL encompass common schema objects and 168 attributes, and MAY define a model whereby divergent schemas can 169 replicate non-common or extended attributes for common LDAP objects. 170 Support for SubTree Replication SHALL be defined to allow for greater 171 flexibility replication toplologies of the DIT as discussed in X.525 172 section 7.2 [X.525]. 173 Along with the above is the need for replication policies that govern 174 the behavior of the replicas and the synchronization process and are 175 briefly discussed below in sections 3.1. 177 3.1. Replication policy definitions 179 Policies for the LDAP replication shall be defined in such a manner 180 as to allow programmatic representation; these policies shall be kept 181 as replica attributes or as entries of the predeter- mined agreement 182 discussed in section 3.2 to be propagated during replication. 184 3.1.1. Propagation behavior 186 Propagation behavior defines the general behavior of the actual syn- 187 chronization process between a consumer and a provider of replication 188 information. 190 1. Replication SHALL only be allowed after the proper authentication 191 and verification of authorization of both the replica and the source 192 directory. 194 2. The transport for LDAP synchronization MUST allow for the 195 integrity and confidentiality of each replicated server. 197 3. The replica synchronization MUST be handled in such a manner as to 198 not saturate network with repetitive entry replication from multiple 199 synchronization providers points. 201 4. Full copy replication SHOULD be supported for reset and initial 202 loading of a replica using the LDIF [LDIF]. 204 5. The normal means of synchronizing replicas SHALL be performed 205 through incremental synchronization and in accordance with the 206 scheduling policies of section 3.1.2. 208 6. Multiple LDAP changes, to a single server, SHOULD be allowed to be 209 treated as single atomic unit of work propagated during replication. 211 7. Entry change information shall be purged upon completion of a syn- 212 chronization cycle where all replica members have been syn- chronized 213 with the master(s). 215 8. Replication policies SHOULD contain clauses to account for the 216 instance of a replica being unavailable at the scheduled update time. 218 3.1.2. Scheduling policies 220 The scheduling policies allow administration and tuning of the con- 221 vergence of replicas. These administrator controlled policies give 222 replication the flexibility to be adapted to the local environment. 224 1. A propagation schedule SHALL be defined and SHOULD be tunable such 225 that every X hours and or N changes will automatically begin a repli- 226 cation cycle. 228 2. Immediate replication of critical values in secs/mins such as user 229 password changed SHALL be supported. 231 3. Allowance for non scheduled replication of replica upon request 232 such that the replica server has been down or unconnected for a 233 period of time. 235 3.2. Predetermined Replication Agreements 237 The use of predetermined replication agreements between the master 238 directories and replica directories MUST be addressed to provide 239 proper knowledge of access requirements and credentials between the 240 synchronizing directories. 242 Currently X.525 DISP [X.525] discusses this as a shadowing agreement 243 including such information as unit of replication, update mode, and 244 access point defining many of the policies between the master and a 245 replica. 247 Replication agreements SHOULD be accessible, via LDAP, to all servers 248 containing replicated information. 250 3.3. Scalability 252 In order to support both enterprise and internet environments, repli- 253 cation must be scalable. Scalability is comprised of the following 254 factors. 256 1. Real time Vs. non-real-time operations. 258 2. Large amounts of replicated data. The unit of replication is 259 defined to be the naming context. This naming context may consist of 260 large amounts of data, all or which may be replicated. The replica- 261 tion mechanism must account for any amount of data to be replicated. 262 Incremental replication must be allowed to attempt to keep the amount 263 of data replicated to a minimum. 265 3. Large amounts transactions per second. 267 4. Scale to global internet, or not. Due to the acceptance and usage 268 of the internet, and the requirement that LDAP replication be avail- 269 able across disparate vendors directory services, LDAP replication 270 must scale to the internet level, but also must function at the 271 enterprise level. 273 5. Large numbers of replicas, ie distributivity. A policy must be 274 defined to account for simultaneous updates to multiple master 275 replicas, where simultaneous is defined to be a period between repli- 276 cations. 278 6. Arbitrary replication topology 280 7. Arbitrary Management topologies 282 3.4. LDAP Access 284 Access to replication topologies and policies, via LDAP is a must. In 285 order to replicate across different vendors directory services, each 286 naming contexts replication policies must be available via LDAP. 288 3.5. Administration Utility Requirements 290 Administration of replicated servers shall be defined in such a man- 291 ner to include: 293 1. The capability to check the differences between two replicas of 294 the same information. 296 2. The capability to view the replication topology from a single 297 server in the topology. 299 3. The capability to view the current state and replication history 300 of each replicated copy in the replication topology, from a single 301 server in the topology. 303 4. Acknowledgements 304 This document is based on input from IETF members interested in LDAP 305 replication 307 5. Bibliography 309 [LDAPv3] - M. Wahl, T. Howes, S. Kille "Lightweight Directory Access 310 Protocol (v3), Internet Draft, draft-ietf-asid-ldapv3-04.txt March 311 1997. 313 [LDIF] -_ Gordon Good, "The LDAP Data Interchange Format (LDIF)", 314 Internet draft, draft-ietf-asid-ldif-00.txt, November 1996. 316 [Changelog] - Gordon Good, "Definitions of an Object Class to Hold 317 LDAP Change records", Internet Draft, draft-ietf-asid- 318 changelog-00.txt, November 1996. 320 [X.525] - "Information Technology - Open Systems Interconnection- The 321 Directory: Replication", ITU-T Recommendation X.525 and ISO/IEC 322 International Standard 9594-9, November 1993. 324 6. Author(s) Addres 326 Russel F. Weiser 327 Novell Inc. 328 122 East 1700 South 329 Provo, Utah 84606 330 USA 332 E-mail: Rweiser@novell.com 333 Telephone: +1-801-861-7808 334 Fax +1-801-861-7808 336 Ellen J. Stokes 337 IBM 338 11400 Burnet Rd. 339 Austin, Texas 78758 340 USA 342 E-mail: stokes@austin.ibm.com 343 Telephone: +1-512-838-3725 344 Fax: +1-512-838-0156 346 Bob Huston 347 Iris Associates 348 5 Technology Park. 349 Westford, MA 01886 350 USA 352 E-mail: bhuston@iris.com 353 Telephone: +1-978-392-5203 354 Fax: +1-978-692-7365 355 Table of Contents 357 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1 358 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 359 3. General Requirements . . . . . . . . . . . . . . . . . . . . . . 3 360 3.1. Replication policy . . . . . . . . . . . . . . . . . . . . . . 4 361 3.1.1. Propagation behavior . . . . . . . . . . . . . . . . . . . . 4 362 3.1.2. Scheduling policies . . . . . . . . . . . . . . . . . . . . 5 363 3.2. Predetermined Replication Agreements . . . . . . . . . . . . 6 364 3.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 6 365 3.5. LDAP access . . . . . . . . . . . . . . . . . . . . . . . . . 7 366 3.5. Administration Utility Requirements . . . . . . . . . . . . . 7 367 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 368 5. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . 7 369 6. Author(s) Address . . . . . . . . . . . . . . . . . . . . . . . 8