idnits 2.17.1 draft-ietf-asid-ldap-repl-info-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-24) 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 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 an Abstract section. ** The document seems to lack an Introduction section. ** 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 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 243: '...bind credentials MUST NOT be stored in...' RFC 2119 keyword, line 422: '...hese credentials MUST be adequately pr...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 123 has weird spacing: '...enforce rep-...' == Line 128 has weird spacing: '...reement based...' -- 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 (July 1997) is 9780 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? '4' on line 443 looks like a reference -- Missing reference section? '6' on line 454 looks like a reference -- Missing reference section? '5' on line 448 looks like a reference -- Missing reference section? '1' on line 427 looks like a reference -- Missing reference section? '2' on line 432 looks like a reference -- Missing reference section? '3' on line 437 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF ASID Working Group Sanjay Jain 2 Internet Draft Oracle Corporation 3 Uppili Srinivasan 4 Oracle Corporation 5 Gordon Good 6 Netscape Communications Corporation 7 July 1997 9 Schema for Replication Information 10 12 I. Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working docume- 15 nts of the Internet Engineering Task Force (IETF), its areas, and its 16 working groups. Note that other groups may also distribute working doc- 17 uments as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference material 22 or to cite them other than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 26 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 27 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 29 Distribution of this memo is unlimited. Editorial comments should be 30 sent to skjain@us.oracle.com. Technical discussion should take place on 31 the IETF ASID mailing list (ietf-asid@umich.edu). 33 This Internet Draft expires February 1st, 1998. 35 II. Abstract 37 This document defines a new attribute syntax and an operational attribu- 38 te type to store replication agreements within the directory. In addit- 39 ion it defines a framework to detect whether an entry is a master or 40 replica. 42 The replication agreement structure defined here includes a placeholder 43 to specify the replication protocol associated with an agreement. This 44 document itself does not define any replication protocol. Replication 45 protocols and replication agreements are seen as orthogonal issues. 47 III. Definition Of Terms 49 Consumer An LDAP server which receives replica updates. 51 Master An LDAP server holding a master copy of an entry. 53 Master Entry The copy of an entry where all direct LDAP 54 modifications are performed. In a multi-master 55 environment, there could exist multiple master copies 56 for an entry. 58 Replication Agreement 59 An agreement between a supplier and a consumer 60 regarding replication of a full/partial naming 61 context. The main components of a replication 62 agreement are: 63 . Reference to the supplier 64 . Reference to the consumer 65 . Specification of the directory information to 66 be replicated. 67 . Schedule for updating the replicas. 69 Replica A copy of an entry where modifications are allowed 70 only through replication updates. I.e. direct LDAP 71 modifications are not allowed on a replica of an 72 entry. A replica will typically issue a referral to a 73 supplier if a client attempts an update operation. 75 Supplier An LDAP server which supplies replica updates. 77 IV. Introduction 79 The broadening of interest in LDAP directories beyond their use as front 80 ends to X.500 and proliferation of stand alone LDAP implementations has 81 created a need to define standards that would facilitate deployment of 82 distributed and replicated directory involving multi-vendor implementat- 83 ions. 85 The "referrals" draft (Ref[4]) defines ways to create and use knowledge 86 references. It lays the foundation for distributed directories by defi- 87 ning mechanisms that can be used to "glue" the parts of directory infor- 88 mation tree (DIT) together. The framework defined here is a step in the 89 direction to standardize the directory replication process. Together, 90 these proposals establish the infrastructure to distribute and replicate 91 the directory information. 93 This document defines a new attribute syntax and an operational attribu- 94 te type to store replication agreements within the directory. The attr- 95 ibute is a root DSE attribute. 97 A replication agreement is established between a consumer and a 98 supplier. Establishment of an agreement is expected to precede any rep- 99 lication. An agreement specifies, among other things, the replication 100 area and the update frequency. It also identifies the replication prot- 101 ocol and the parameters that are specific to that protocol. 103 While it is desirable for a single LDAP replication protocol to be defi- 104 ned and standardized, this draft accommodates the possibility of variat- 105 ions and versions to be specified in the agreement through a replication 106 protocol identifier (oid) and associated parameters. Some of the possi- 107 ble variations include characteristics such as supplier initiated (push) 108 , consumer initiated (pull) etc. 110 Proprietary replication protocols already exist and LDAP directories 111 will be rolled out into these environments. Replication protocol oids 112 can be registered for such protocols as well. The intent is not to pro- 113 mote proprietary protocols, but to facilitate painless roll-out of stan- 114 dards based implementations within pre-existing directory environments. 115 It is believed that this accommodation in the replication agreements 116 would ease adoption of the standards. 118 V. Replication Agreement Establishment and Usage Model 120 Creation of a replication agreement would either be initiated by a human 121 administrator or by a consumer. Identical copies of an agreement would 122 exist on the supplier and the consumer. A replication agreement has to 123 exist before replication can take place. The servers will enforce rep- 124 lication exchanges per the terms of an agreement. 126 The replication agreements should be added, deleted or modified using 127 LDAP "modify" operation on the root DSE. The server should check the 128 consistency and acceptability of an agreement based on local administr- 129 ative policies. An agreement is considered to be in effect when both the 130 supplier and consumer have identical copies of the agreement in their 131 root DSEs. Two agreements are deemed identical when they match according 132 to the replBindingMatch matching rule defined in this document. 134 It is possible to achieve the effect of the above administrative actions 135 (creation of replication agreements) through protocol exchanges between 136 servers, equivalent of the X.500 DOP. Such protocols may get standardi- 137 zed in the future. This draft does not define such a protocol. It only 138 defines a standard for the structure and semantics of resulting replica- 139 tion agreement information. 141 A supplier can maintain different replication agreements with different 142 consumer servers for a single naming context. It is also possible for a 143 consumer to have multiple agreements with one or more suppliers for same 144 or different naming contexts. 146 VI. Attribute Definitions 148 A. replAgreement 150 ( < ora_onldap_replica_oid1> NAME 'replAgreement' DESC 'describes a rep- 151 lication agreement between 2 servers' EQUALITY replBindingMatch SYNTAX 152 'replBinding' USAGE distributedOperation ) 154 'replAgreement' attribute stores the information about a replication 155 agreement reached between two servers (consumer and supplier). It is a 156 multi-valued attribute. It is a root DSE attribute. 158 A replication agreement specifies, among other details, the user entries 159 and attributes to be replicated from the supplier LDAP server to the 160 consumer LDAP server. Normally, the administrative information (Schema, 161 ACLs etc.), associated with the selected user entries, would also be re- 162 plicated along with the user entries. 164 B. supportedReplProtocols 166 ( < ora_onldap_replica_oid2> NAME 'supportedReplProtocols' DESC 'Stores 167 the OIDS of the supported replication protocols" SYNTAX 'OID' USAGE dis- 168 tributedOperation) 170 'supportedReplProtocols' attribute stores the OIDS of the supported rep- 171 lication protocols. It is a multi-valued attribute. It is a root DSE 172 attribute. 174 C. myRef 176 ( < ora_onldap_replica_oid3> NAME 'myRef' DESC 'LDAP URI without any DN 177 part. Reference to self.' EQUALITY caseExactIA5Match SYNTAX 'IA5String' 178 SINGLE_VALUE USAGE dSAOperation ) 180 'myRef' is a root DSE attribute . It is a single valued attribute. It 181 contains the LDAP reference (without the DN part) to the server itself. 183 D. masterRef 185 ( < ora_onldap_replica_oid4> NAME 'masterRef' DESC 'LDAP URI without any 186 DN part' EQUALITY caseExactIA5Match SYNTAX 'IA5String' USAGE dSAOperati- 187 on ) 189 'masterRef' is an operational attribute for every entry (except the DSE 190 root entry) in the LDAP directory. It is a multi-valued attribute. The 191 values of this attribute refer to the servers which master this entry. 193 By comparing 'myRef' attribute value and the 'masterRef' attribute valu- 194 es for an entry, a server and a directory user can determine whether 195 the particular copy is a master copy or a replica. When an LDAP client 196 tries a modify operation on a replica then the server by looking at the 197 'masterRef' attribute can return a referral to the master LDAP server. 199 VII. replBinding Syntax 201 ( < ora_onldap_replica_oid5> DESC 'Replication Agreement Syntax' ) 203 Attribute values with 'replBinding' syntax are written according to 204 following BNF: 206 ::= "(" 207 "AGREEMENTID" 208 "NAMINGCONTEXT" 209 "SUPPLIER_REFERENCE" 210 "CONSUMER_REFERENCE" 211 ["SUPPLIER_IDENTITY" ] 212 ["CONSUMER_IDENTITY" ] 213 ["BASEDN" ] 214 ["FILTER" ] 215 ["SCOPE" <0|1|2>] 216 ["ATTRIBUTE_SELECTION ] 217 "UPDATE_SCHEDULE" 218 ["REPLICATION_PROTOCOL" ] 219 ")" 221 AGREEMENTID is local to the supplier. The server must verify that the 222 combination of AGREEMENTID and SUPPLIER_REFERENCE is unique. Otherwise 223 the LDAP "modify" operation to enter an agreement should fail with an 224 LDAP_CONSTRAINT_VIOLATION (0x13) LDAP error. 226 NAMINGCONTEXT is the DN of the root of the naming context with which the 227 replication agreement is associated. 229 SUPPLIER_REFERENCE is an LDAP URI [6] (without the DN part) to the supp- 230 lier. 232 CONSUMER_REFERENCE is an LDAP URI [6] (without the DN part) to the cons- 233 umer. 235 SUPPLIER_IDENTITY is the identity which the supplier must use to authen- 236 ticate itself to the consumer for replica update exchanges. This param- 237 eter would be most useful in the push model. 239 CONSUMER_IDENTITY is the identity which the consumer must use to authen- 240 ticate itself to the supplier for replica update exchanges. This param- 241 eter would be most useful in the pull model. 243 Note: For security reasons, bind credentials MUST NOT be stored in the 244 replication agreement attribute. 246 SUPPLIER_IDENTITY, CONSUMER_IDENTITY and associated credentials may not 247 actually exist in the directory. When binding for sending/receiving 248 replication updates, the target server would recognize the 249 SUPPLIER_IDENTITY /CONSUMER_IDENTITY and adjust its semantics appropria- 250 tely. 252 SUPPLIER_IDENTITY and CONSUMER_IDENTITY are both optional parameters of 253 a replication agreement. 255 BASEDN, FILTER and SCOPE have same semantics as in a LDAP search request 256 . Default value for BASEDN is the root of the naming context. Default 257 value for SCOPE is 2 (whole subtree). 259 Through ATTRIBUTE_SELECTION one can specify the list of attributes of a 260 particular object class which should be included/excluded in the replic- 261 ation. 263 AttributeSelectionList ::= | 264 '('')' 266 AttributeSelectionList ::= '$' 267 | 268 270 AttributeSelection ::= "(" [] 271 [] 272 ")" 274 ::= An LDAP filter as described in [5] 276 If the filter is absent, then the attribute list selection applies to 277 all replicated entries. 279 ::= | 280 282 ::= "INCLUDE" 284 ::= "EXCLUDE" 285 ::= | 286 '(' ')' 288 ::= '$' 289 | 290 292 UPDATE_SCHEDULE specifies the schedule for updating the replica. 294 ::= 296 ::= | 297 '('')' 299 ::= < ScheduleList> '$' 300 | 301 303 ::= 304 306 has UNIX crontab style syntax and semantics. The schedu- 307 le is specified using five fields separated by spaces. The fields are 308 integer patterns that specify the following: 310 minute (0-59) 311 hour (0-23) 312 day of the month (1-31) 313 month of the year (1-12) 314 day of the week (0-6 with 0=Sunday) 315 Each of these five patterns may be either an asterisk (meaning all legal 316 values) or a list of elements separated by commas. An element is either 317 a number or two numbers separated by a minus sign (meaning an inclusive 318 range). Note that the specification of days may be made by two fields 319 (day of the month and day of the week). Both are adhered to if specifi- 320 ed as a list of elements. Times are always interpreted as Greenwich 321 Mean Time. 323 Examples: 325 1.Always keep replicas updated immediately: 326 UPDATE_SCHEDULE * * * * * 328 2. Update replicas at 1 am every day: 329 UPDATE_SCHEDULE * 1 * * * 331 3. Update replicas every hour between 8am and 5 pm on weekdays, and at 332 1am on weekends: 333 UPDATE_SCHEDULE (* 8-17 * * 1-5 $ * 1 * * 0, 6) 334 4. Update replicas every 30 minutes: 335 UPDATE_SCHEDULE 0,30 * * * * 337 5. Update replicas on first and fifteenth of each month as well as on 338 every Monday (Example of using two fields for the specification of days) 339 UPDATE_SCHEDULE * * 1,15 * 1 341 REPLICATION_PROTOCOL is the protocol to be used to exchange replica upd- 342 ates. 344 ReplProtocol ::= "(" 345 "OID" 346 ["PROTOCOL_SPECIFIC" ] 347 ")" 349 VIII. replBindingMatch definition 351 ( < ora_onldap_shadow_oid6> NAME ' replBindingMatch' SYNTAX 'replBinding 352 ' ) 354 Two replication agreements are equal if and only if the AGREEMENTID and 355 SUPPLIER_REFERENCE match for equality, as determined by the NumericStri- 356 ngMatch and CaseExactIA5Match matching rules defined in X.520 (1993). 358 IX. Relationship To X.500 Shadowing Agreements 360 LDAP replication agreements are independent of X.500 shadowing agreemen- 361 ts, although terminology has been borrowed from X.500 and, in general, 362 the meaning of these terms is equivalent. 364 It is anticipated that LDAP servers which front-end and X.500 server 365 will advertise the fact that they support X.500 DISP by placing in the 366 'supportedReplProtocols' attribute of the root DSE the OID which repres- 367 ents X.500 DISP (this OID has not been defined at this time). 369 X. Examples 371 Following are examples of attribute values for replAgreement attribute: 373 1. This is an example of a replication agreement between two cooperati- 374 ng organizations, "ABC Inc." and "XYZ AG". ABC's LDAP server runs on 375 the host "ldap.abc.com" while XYZ's LDAP server runs on the host 376 "ldap.mch.xyz.de". The objective is for both organizations to have a 377 copy of the subtree "ou=Sales, o=ABC, c=US". The server "ldap.mch.xyz.de 378 ", then, is a consumer for the subtree "ou=Sales, o=ABC, c=US", which is 379 part of the "c=US" naming context held by the supplier. The server "ldap 380 .abc.com" is the supplier for that subtree. The replica is updated by 381 the supplier (since only supplier identity isthere in the agreement) 382 continuously, using the replication protocol identified by the OID '1.2. 383 3'. When connecting to the consumer, the supplier will bind as "cn=rep- 384 lAdmin,dc=replTree,dc=ldap,dc=mch,dc=xyz,dc=de". The following replAgr- 385 eement attribute describes this agreement: 387 ( AGREEMENTID 123456 NAMINGCONTEXT 'c=us' SUPPLIER_REFERENCE 388 'ldap://ldap.abc.com' CONSUMER_REFERENCE 389 'ldap://ldap.mch.xyz.de' SUPPLIER_IDENTITY 390 'cn=replAdmin,dc=replTree,dc=ldap,dc=mch,dc=xyz,dc=de' 391 BASEDN 'ou=Sales, o=ABC, c=US' SCOPE 2 UPDATE_SCHEDULE * * * 392 * * REPLICATION_PROTOCOL 1.2.3 ) 394 2. This example is a refinement of the above agreement. In addition to 395 the parameters described above, entries are only replicated if they 396 match the filter "(objetclass=person)". Furthermore, only the attribut- 397 es cn, sn, telephoneNumber, and mail are replicated, and replication may 398 only occur between 1 am and 2 am GMT. 400 ( AGREEMENTID 123456 NAMINGCONTEXT 'c=us' SUPPLIER_REFERENCE 401 'ldap://ldap.abc.com' CONSUMER_REFERENCE 402 'ldap://ldap.mch.xyz.de' SUPPLIER_IDENTITY 403 'cn=replAdmin,dc=replTree,dc=ldap,dc=mch,dc=xyz,dc=de' 404 BASEDN 'ou=Sales, o=ABC, c=US' FILTER '(objectlass=person)' 405 ATTRIBUTE_SELECTION '(objectclass=*) INCLUDE cn $ sn $ 406 telephoneNumber $ mail)' SCOPE 2 UPDATE_SCHEDULE * 1-2 * * * 407 REPLICATION_PROTOCOL 1.2.3 ) 409 XI. Security Considerations 411 This document defines a mechanism that can be used to describe the repl- 412 ication agreements between suppliers and consumers. The replication pr- 413 ocess would rely on this information to schedule and control the replica 414 updates. Hence the replication agreement attribute should be protected 415 from unauthorized access. If the identity of consumers and/or the natu- 416 re of their subscription to directory information is not public informa- 417 tion, the relevant directory information should be protected from unaut- 418 horized access as well. 420 Servers will generally need to persistently store authentication creden- 421 tials used to bind to consumer or supplier servers when performing repl- 422 ica updates. These credentials MUST be adequately protected from unaut- 423 horized access. 425 XII. References 427 [1] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Spe- 428 cification", INTERNET-DRAFT draft-ietf-asid-ldif-01.txt, Netscape Commu- 429 nications Corp., 430 432 [2] Good, G., "Definition of an Object Class to Hold LDAP Change Recor- 433 ds", INTERNET-DRAFT draft-ietf-asid-changelog-01.txt, Netscape Communic- 434 ations Corp., 435 437 [3] C. Weider, J. Strassner, "LDAP Multi-master Replication Protocol", 438 INTERNET-DRAFT draft-ietf-asid-ldap-mult-mast-rep-00.txt, Microsoft Cor- 439 poration, Cisco Systems Corporation, 440 443 [4] T. Howes, M. Wahl, "Referrals and Knowledge References in LDAP Dir- 444 ectories", INTERNET-DRAFT draft-ietf-asid-ldapv3-referral-00.txt, 445 Netscape Communications Corp., Critical-Angle, Inc., 448 [5] T. Howes, "The String Representation of LDAP Search Filters", 449 INTERNET-DRAFT draft-ietf-asid-ldapv3-filter-02.txt, Netscape Communica- 450 tions Corp., 451 454 [6] T. Howes, M. Smith, "The LDAP URL Format", INTERNET-DRAFT 455 draft-ietf-asid-ldapv3-url-03.txt, Netscape Communications Corp., 456 458 XIII. Authors' Addresses 460 Sanjay Jain 461 Oracle Corporation 462 200 Oracle Parkway 463 Box 659210 464 Redwood Shores, CA 94065 465 USA 466 Phone: +1 415-506-9325 467 E-mail: skjain@us.oracle.com 468 Uppili Srinivasan 469 Oracle Corporation 470 200 Oracle Parkway 471 Box 659210 472 Redwood Shores, CA 94065 473 USA 474 Phone: +1 415-506-3039 475 E-mail: usriniva@us.oracle.com 477 Gordon Good 478 Netscape Communications Corporation 479 501 E. Middlefield Rd. 480 Mail Stop MV068 481 Mountain View, CA 94043 482 USA 483 Phone: +1 415 937 3825 484 E-mail: ggood@netscape.com