idnits 2.17.1 draft-ietf-asid-replica-req-00.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-18) 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 52 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 73: '.... Both these models SHALL be sup-...' RFC 2119 keyword, line 86: '... SHALL be identical including al...' RFC 2119 keyword, line 88: '...Tree Replication SHALL be defined to a...' RFC 2119 keyword, line 109: '... 1. Replication SHALL only be allowed...' RFC 2119 keyword, line 113: '...hronization data MUST use secure trans...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '...ment is an I...' == Line 14 has weird spacing: '...cuments of t...' == Line 15 has weird spacing: '...ups may also ...' == Line 19 has weird spacing: '...ents at any...' == Line 20 has weird spacing: '...e. It is i...' == (47 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 (16 July 1997) is 9773 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 168 looks like a reference -- Missing reference section? 'Changelog' on line 175 looks like a reference -- Missing reference section? 'LDIF' on line 172 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 Expire in six months Ellen Stokes 5 IBM 6 16 July 1997 8 LDAP Replication Requirements 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet- Drafts. 18 Internet-Drafts are draft documents valid for a Maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or cite them other than as " work in progress." To learn 22 the current status of any Internet-Draft, please check the "lid- 23 abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 This document discusses some of the fundamental requirements for 31 replication and synchronization of the LDAPv3 [LDAPv3] protocol. It 32 is intended to be a gathering place for general replication 33 requirements needed to provide interoperability between informational 34 directories. 36 1. Introduction 37 The ability distribute directory information throughout the network 38 provides a two fold benefit to the network: (1) increasing the relia- 39 bililty of the directory through fault tolerance, and (2) brings the 40 directory content closer to the clients using the data. LDAPs accep- 41 tance as a access protocol for directory information is driving the 42 need to distribute LDAP directory content among servers within enter- 43 prise and Internet. Currently LDAP does not define a synchronization 44 mechanism and only generally mentions LDAP shadow servers see 46 [LDAPv3] and [Changelog] in passing. The requirements for replication 47 are critical to the successful deployment and acceptance of LDAP in 48 the market place. 50 2. Objectives 52 The major objectives are to provide a simple highly efficient and 53 preforming replica synchronization method for LDAP while also provid- 54 ing the appropriate flexibility to meet the needs of both the Inter- 55 net and enterprise environments. 57 Simple 58 Efficient 59 Reliable 60 Provides Interoperability between vendors 61 Flexibility 63 3. General Requirements 65 The following requirements are in no priority order. 67 The flexibility of a LDAP replication should be of the upmost impor- 68 tance due to the nature of the Internet and enterprise environments. 69 This generally leads to several general requirements that are dis- 70 cussed briefly below. 72 Therefore support for both multi-master and master/slave environments 73 should be a driving requirement. Both these models SHALL be sup- 74 ported. Note: The definition of a replica either as a Read-only 75 replica or Read/Write replica allowing administrators the choice of 76 centralized or distributed management of the directory. 78 Additionally synchronization of LDAP replicas should allow either a 79 master and or replica to initiate the replication process and allow 80 the initiator to determine whether it will become a consumer and or 81 supplier during the synchronization process. This would allow a 82 replica to be periodically connected and synchronized from remote 83 sites at the local administrator's discretion. 84 Another driving force or general requirement should be that all 85 information between the master database and its replica databases 86 SHALL be identical including all no user modify operational 87 attributes such as timestamps. 88 Support for SubTree Replication SHALL be defined to allow for greater 89 flexibility replication toplologies of the DIT as discussed in X.525 90 section 7.2 [X.525]. 91 Along with the above is the need for replication policies that govern 92 the behavior of the replicas and the synchronization process and are 93 briefly discussed below in sections 3.1. 95 3.1. Replication policy definitions 97 Policies for the LDAP replication/synchronization shall be defined in 98 such a manner as to allow programmatic representation; these policies 99 shall be kept as replica attributes or as entries of the predeter- 100 mined agreement discussed in section 3.2 to be propagated during 101 replication. 103 3.1.1. Propagation behavior 105 Propagation behavior defines the general behavior of the actual syn- 106 chronization process between a consumer and a provider of replication 107 information. 109 1. Replication SHALL only be allowed after the proper authentication 110 and verification of authorization of both the replica and the source 111 directory. 113 2. The transport of LDAP synchronization data MUST use secure trans- 114 ports. 116 3. The replica synchronization SHALL be handled in such a manner as 117 to not saturate network with repetitive entry replication from multi- 118 ple synchronization providers points. 120 4. Full copy replication SHOULD be supported for reset and initial 121 loading of a replica using the LDIF [LDIF]. 123 5. The normal means of synchronizing replicas SHALL be performed 124 through incremental synchronization and in accordance with the 125 scheduling policies of section 3.1.2. 127 6. Multiple LDAP changes SHOULD to be allowed to be treated as single 128 atomic transactions propagated during replication. 130 7. ChangeLog [Changelog] information shall be purged upon completion 131 of a synchronization cycle where all replica members have been syn- 132 chronized with the master(s). 134 3.1.2. Scheduling policies 136 The scheduling policies allow administration and tuning of the con- 137 vergence of replicas. 139 1. A propagation schedule SHALL be defined and SHOULD be tunable such 140 that every X hours and or N changes will automatically begin a repli- 141 cation cycle. 143 2. Immediate replication of critical values in secs/mins such as user 144 password changed SHALL be supported. 146 3. Allowance for non scheduled replication of replica upon request 147 such that the server has been down or unconnected for a period of 148 time. 150 3.2. Predetermined Replication Agreements 152 The use of predetermined replication agreements between the master 153 directories and replica directories MUST be addressed to provide 154 proper knowledge of access requirements and credentials between the 155 synchronizing directories. 157 Currently X.525 DISP [X.525] discusses this as a shadowing agreement 158 including such information as unit of replication, update mode, and 159 access point defining many of the policies between the master and a 160 replica. 162 4. Acknowledgements 163 This document is based on input from IETF members interested in LDAP 164 replication 166 5. Bibliography 168 [LDAPv3] - M. Wahl, T. Howes, S. Kille "Lightweight Directory Access 169 Protocol (v3), Internet Draft, draft-ietf-asid-ldapv3-04.txt March 170 1997. 172 [LDIF] -_ Gordon Good, "The LDAP Data Interchange Format (LDIF)", 173 Internet draft, draft-ietf-asid-ldif-00.txt, November 1996. 175 [Changelog] - Gordon Good, "Definitions of an Object Class to Hold 176 LDAP Change records", Internet Draft, draft-ietf-asid- 177 changelog-00.txt, November 1996. 179 [X.525] - "Information Technology - Open Systems Interconnection- The 180 Directory: Replication", ITU-T Recommendation X.525 and ISO/IEC 181 International Standard 9594-9, November 1993. 183 6. Author(s) Addres 185 Russel F. Weiser 186 Novell Inc. 187 122 East 1700 South 188 Provo, Utah 84606 189 USA 191 E-mail: Rweiser@novell.com 192 Telephone: +1-801-861-7808 193 Fax +1-801-861-7808 195 Ellen J. Stokes 196 IBM 197 11400 Burnet Rd. 198 Austin, Texas 78758 199 USA 201 E-mail: stokes@austin.ibm.com 202 Telephone: +1-512-838-3725 203 Fax: +1-512-838-0156 204 Table of Contents 206 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1 207 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 208 3. General Requirements . . . . . . . . . . . . . . . . . . . . . . 2 209 3.1. Replication policy definitions . . . . . . . . . . . . . . . . 3 210 3.1.1. Propagation behavior . . . . . . . . . . . . . . . . . . . . 3 211 3.1.2. Scheduling policies . . . . . . . . . . . . . . . . . . . . 3 212 3.2. Predetermined Replication Agreements . . . . . . . . . . . . 4 213 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 4 214 5. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . 4 215 6. Author(s) Address . . . . . . . . . . . . . . . . . . . . . . . 5