idnits 2.17.1 draft-zeilenga-ldap-managedit-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 503. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 487. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 491), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (27 February 2006) is 6626 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Protocol' is mentioned on line 394, but not defined == Missing Reference: 'EntryDN' is mentioned on line 237, but not defined == Missing Reference: 'RFC3671' is mentioned on line 238, but not defined == Unused Reference: 'EntryUUID' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'RFC2849' is defined on line 462, but no explicit reference was found in the text -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- No information found for draft-ietf-ldapbis-bcp64-xx - is the name correct? -- No information found for draft-zeilenga-ldap-uuid-xx - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Experimental OpenLDAP Foundation 4 Expires in six months 27 February 2006 6 The LDAP Manage Directory Information Tree Control 7 9 Status of this Memo 11 This document is intended to be, after appropriate review and 12 revision, submitted to the RFC Editor for publication as an 13 Experimental document. Distribution of this memo is unlimited. 14 Technical discussion of this document will take place on the IETF LDAP 15 Extensions mailing list . Please send editorial 16 comments directly to the author . 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware have 20 been or will be disclosed, and any of which he or she becomes aware 21 will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference material 30 or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright (C) The Internet Society (2006). All Rights Reserved. 40 Please see the Full Copyright section near the end of this document 41 for more information. 43 Abstract 45 This document defines the Lightweight Directory Access Protocol (LDAP) 46 Manage Directory Information Tree (DIT) Control which allows a 47 directory user agent (a client) to request the directory service 48 temporarily relax enforcement of constraints of the X.500 models. 50 1. Background and Intended Use 52 Directory servers accessible via Lightweight Directory Access Protocol 53 (LDAP) [Roadmap] are expected to act in accordance with the X.500 54 series of ITU-T Recommendations. In particular, servers are expected 55 to ensure the X.500 data and service models are not violated. 57 An LDAP server is expected to prevent modification of the structural 58 object class of an object [Models]. That is, the X.500 models do not 59 allow a 'person' object to be transformed into an 60 'organizationalPerson' object through modification of the object. 61 Instead, the 'person' object must be deleted and then a new 62 'organizationalPerson' object created in its place. This approach, 63 aside from being inconvient, is problematic for a number reasons. 64 First, as LDAP does not have a standardized method for performing the 65 two operations in a single transaction, the intermediate directory 66 state (after the delete, before the add) is visible to other clients, 67 which may lead to undesirable client behavior. Second, attributes 68 such as entryUUID [entryUUID] will reflect the object was replaced, 69 not transformed. 71 An LDAP server is expected to prevent clients from modifying values of 72 NO-USER-MODIFICATION attributes [Models]. For instance, an entry is 73 not allowed to assign or modify the value of the entryUUID attribute. 74 However, where an administrator is restoring a previously existing 75 object, for instance when repartitioning data between directory 76 servers or when migrating from one vendor server product to another, 77 it may be desirable to allow the client to assign or modify the value 78 of the entryUUID attribute. 80 This document specifies the Manage Directory Information Tree (DIT) 81 control. The Manage DIT control may be attached to LDAP requests to 82 update the DIT to request DIT restrictions be temporarily relaxed 83 during the performance of the requested DIT update. The server is 84 however to ensure the resulting directory state is valid. 86 Use of this control is expected that use of this extension will be 87 restricted by administrative and/or access controls. It is intended 88 to be used by directory administrators. 90 This extension is considered experimental as it is not yet clear 91 whether it adequately addresses directory administrators' needs for 92 flexible mechanisms for managing directory objects. It is hoped that 93 after suitable amount of time, either this extension or a suitable 94 replacement will be standardization. 96 1.1. Terminology 98 Protocol elements are described using ASN.1 [X.680] with implicit 99 tags. The term "BER-encoded" means the element is to be encoded using 100 the Basic Encoding Rules [X.690] under the restrictions detailed in 101 Section 5.2 of [Protocol]. 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in BCP 14 [RFC2119]. 107 DSA stands for Directory System Agent, a server. DSE stands for DSA- 108 specific Entry. 110 2. The Manage DIT Control 112 The Manage DIT control is an LDAP Control [Protocol] whose controlType 113 is IANA-ASSIGNED-OID, controlValue is empty, and the criticality of 114 TRUE. 116 There is no corresponding response control. 118 The control is appropriate for all LDAP update requests, including 119 add, delete, modify, and modifyDN (rename) [Protocol]. 121 The presence of the Manage DIT control in an LDAP update request 122 indicates the server temporarily relax X.500 model contraints during 123 performance of the directory update. 125 The server may restrict use of this control and/or limit the extent of 126 the relaxation provided based upon local policy or factors. 128 The server is obligated to ensure the resulting directory state is 129 consistent with the X.500 models. For instance, the server ensure 130 that values of attributes conform to the value syntax. 132 It is noted that while this extension may be used to add or modify 133 objects in a manner which violate the controlling subschema, the 134 presence of objects in the DIT is not inconsistent with the X.500 135 models. For instance, an object created prior to establshment of a 136 DIT content rule may contain an attribute now precluded by the current 137 controlling DIT Content Rule. 139 Servers implementing this technical specification SHOULD publish the 140 object identifier IANA-ASSIGNED-OID as a value of the 141 'supportedControl' attribute [Models] in their root DSE. A server MAY 142 choose to advertise this extension only when the client is authorized 143 to use it. 145 3. Use Cases 147 3.1. Object metamorphism 149 In absence of this control, an attempt to modify an object's 150 'objectClass' in a manner which cause a change in the structural 151 object class of the object would normally lead to an 152 objectClassModsProhibited error [Protocol]. The presence of the 153 Manage DIT control in the modify request requests the change be 154 allowed. If the server is willing and able to allow the change in the 155 structural object class of the object. 157 For instance, to change an 'organization' object into an 158 'organizationalUnit' object, a client could issue the following LDAP 159 request: 161 dn: o=Unit,dc=example,dc=net 162 control: IANA-ASSIGNED-OID 163 changetype: modify 164 delete: objectClass 165 objectClass: organization 166 - 167 add: objectClass 168 objectClass: organizationalUnit 169 - 171 In this case, the server is expected to either effect the requested 172 change in the structural object class, including updating of the value 173 of the structural object class, or fail the operation. 175 3.2. Inactive Attribute Types 177 In absence of the Manage DIT control, an attempt to add or modify 178 values to an attribute whose type has been marked inactive in the 179 controlling subschema (its attribute type description contains the 180 OBSOLETE field) [Models] normally results in a failure. 182 In the presence of the Manage DIT control, the server performs the 183 update operation as if the attribute's type is marked active in the 184 controlling subschema (its attribute type description does not contain 185 the OBSOLETE field). 187 3.3. DIT Content Rules 189 In absence of the Manage DIT control, an attempt to include the name 190 (or OID) of an auxiliary class to an object's 'objectClass' which is 191 not allowed by the controlling DIT Content Rule would be disallowed 192 [Models]. Additionally, an attempt to add values of an attribute not 193 allowed (or explicitly precluded) by the DIT Content Rule would fail. 195 In presence of the Manage DIT control, the server performs the update 196 operation as if the controlling DIT Content Rule allowed any and all 197 known auxiliary classses to be present and allowed any and all known 198 attributes to be present (and precluded no attributes). 200 3.4. DIT Structure Rules and Name Forms 202 In absence of the Manage DIT control, the service enforces DIT 203 structure rules and name form requirements of the controlling 204 subschema [Models]. 206 In the presence of the Manage DIT control, the server performs the 207 update operation ignoring all DIT structure rules and name forms in 208 the controlling subschema. 210 3.5. Modification of Nonconformant Objects 212 It is also noted that in absense of this control, modification of an 213 object which presently violates the controlling subschema will fail 214 unless the modification would result in the object conforming to the 215 controlling subschema. That is, modifications of an non-conformant 216 object should result in a conformant object. 218 In the presence of this control, modifications of a non-conformant 219 object need not result in a conformant object. 221 3.6. NO-USER-MODIFICATION attribute modification 223 In absence of this control, an attempt to modify values of a 224 NO-USER-MODIFICATION attribute would normally lead to a 225 constraintViolation or other appropriate error [Protocol]. In the 226 presence of the Manage DIT control in the update request requests the 227 modification be allowed. 229 Relaxation of the NO-USER-MODIFICATION constraint is not appropriate 230 for some operational attribute types. For instance, as the value of 231 the 'structuralObjectClass' is derived by the values of the 232 'objectClass' attribute, the 'structuralObjectClass' attribute type's 233 NO-USER-MODIFICATION contraint MUST NOT be relaxed. To effect a 234 change in the structuralObjectClass class, values of objectClass 235 should be changed as discussed in Section 3.1. Other attributes for 236 which the NO-USER-MODIFICATION constraint should not be relaxed 237 include 'entryDN' [EntryDN], 'subschemaSubentry' [Models], and 238 'collectiveAttributeSubentries' [RFC3671]. 240 The subsections of this section discuss modification of various 241 operational attributes where their NO-USER-MODIFICATION constraint may 242 be relaxed. Future documents may specify where NO-USER-MODIFICATION 243 constraints on other operational attribute may be relaxed. In absence 244 of a document detailing that the NO-USER-MODIFICATION constraint on a 245 particular operational attribute may be relaxed, implementors SHOULD 246 assume relaxation of the constraint is not appropriate for that 247 attribute. 249 3.1.1. entryUUID 251 To provide a value for the 'entryUUID' attribute on entry creation, 252 the client should issue an LDAP Add request with a Manage DIT control 253 providing the desired value. For instance: 255 dn: ou=Unit,dc=example,dc=net 256 control: IANA-ASSIGNED-OID 257 changetype: add 258 objectClass: organizationalUnit 259 ou: Unit 260 entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14 262 In this case, the server is either to add the entry using the 263 provided 'entryUUID' value or fail the request. 265 To provide a replacement value for the 'entryUUID' after entry 266 creation, the client should issue an LDAP Modify request with a 267 Manage DIT control including an approrpiate change. For instance: 269 dn: ou=Unit,dc=example,dc=net 270 control: IANA-ASSIGNED-OID 271 changetype: modify 272 replace: entryUUID 273 entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14 274 - 276 In this case, the server is either to replace the 'entryUUID' value 277 as requested or fail the request. 279 3.2.2. createTimestamp 281 To provide a value for the 'createTimestamp' attribute on entry 282 creation, the client should issue an LDAP Add request with a Manage 283 DIT control providing the desired 'createTimestamp' value. For 284 instance: 286 dn: ou=Unit,dc=example,dc=net 287 control: IANA-ASSIGNED-OID 288 changetype: add 289 objectClass: organizationalUnit 290 ou: Unit 291 createTimestamp: 20060101000000Z 293 In this case, the server is either to add the entry using the 294 provided 'createTimestamp' value or fail the request. 296 To provide a replacement value for the 'createTimestamp' after 297 entry creation, the client should issue an LDAP Modify request with 298 a Manage DIT control including an approrpiate change. For instance: 300 dn: ou=Unit,dc=example,dc=net 301 control: IANA-ASSIGNED-OID 302 changetype: modify 303 replace: createTimestamp 304 createTimestamp: 20060101000000Z 305 - 307 In this case, the server is either to replace the 'createTimestamp' 308 value as requested or fail the request. 310 The server should ensure the requested 'createTimestamp' value is 311 appropriate. In particular, it should fail the request if the 312 requested 'createTimestamp' value is in the future or is greater 313 than the value of the 'modifyTimestamp' attribute. 315 3.2.3. modifyTimestamp 317 To provide a value for the 'modifyTimestamp' attribute on entry 318 creation, the client should issue an LDAP Add request with a Manage 319 DIT control providing the desired 'modifyTimestamp' value. For 320 instance: 322 dn: ou=Unit,dc=example,dc=net 323 control: IANA-ASSIGNED-OID 324 changetype: add 325 objectClass: organizationalUnit 326 ou: Unit 327 modifyTimestamp: 20060101000000Z 329 In this case, the server is either to add the entry using 330 the provided 'modifyTimestamp' value or fail the request. 332 To provide a replacement value for the 'modifyTimestamp' after 333 entry creation, the client should issue an LDAP Modify 334 request with a Manage DIT control including an approrpiate 335 change. For instance: 337 dn: ou=Unit,dc=example,dc=net 338 control: IANA-ASSIGNED-OID 339 changetype: modify 340 replace: modifyTimestamp 341 modifyTimestamp: 20060101000000Z 342 - 344 In this case, the server is either to replace the 'modifyTimestamp' 345 value as requested or fail the request. 347 The server should ensure the requested 'modifyTimestamp' value is 348 appropriate. In particular, it should fail the request if the 349 requested 'modifyTimestamp' value is in the future or is less than 350 the value of the 'createTimestamp' attribute. 352 3.2.3. creatorsName and modifiersName 354 To provide a value for the 'creatorsName' and/or 'modifiersName' 355 attribute on entry creation, the client should issue an LDAP Add 356 request with a Manage DIT control providing the desired values. 357 For instance: 359 dn: ou=Unit,dc=example,dc=net 360 control: IANA-ASSIGNED-OID 361 changetype: add 362 objectClass: organizationalUnit 363 ou: Unit 364 creatorsName: cn=Jane Doe,dc=example,net 365 modifiersName: cn=Jane Doe,dc=example,net 367 In this case, the server is either to add the entry using 368 the provided values or fail the request. 370 To provide a replacement values after entry creation for either of 371 the 'creatorsName' or 'modifiersName' attributes or both, the 372 client should issue an LDAP Modify request with a Manage DIT control 373 including the approrpiate changes. For instance: 375 dn: ou=Unit,dc=example,dc=net 376 control: IANA-ASSIGNED-OID 377 changetype: modify 378 replace: creatorsName 379 creatorsName: cn=Jane Doe,dc=example,net 380 - 381 replace: modifiersName 382 modifiersName: cn=Jane Doe,dc=example,net 383 - 385 In this case, the server is either to replace the provided 386 values as requested or fail the request. 388 4. Security Considerations 390 Use of this extension should be subject to appropriate administrative 391 and access controls. Use of this mechanism is intended to be 392 restricted to directory administrators. 394 Security considerations for the base operations [Protocol] extended 395 by this control, as well as general LDAP security considerations 396 [Roadmap], generally apply to implementation and use of this 397 extension. 399 5. IANA Considerations 401 5.1. Object Identifier 403 It is requested that IANA assign a LDAP Object Identifier [BCP64bis] 404 to identify the LDAP Assertion Control defined in this document. 406 Subject: Request for LDAP Object Identifier Registration 407 Person & email address to contact for further information: 408 Kurt Zeilenga 409 Specification: RFC XXXX 410 Author/Change Controller: Kurt Zeilenga 411 Comments: Identifies the LDAP Manage DIT Control 413 5.2 LDAP Protocol Mechanism 415 Registration of this protocol mechanism [BCP64bis] is requested. 417 Subject: Request for LDAP Protocol Mechanism Registration 418 Object Identifier: IANA-ASSIGNED-OID 419 Description: Manage DIT Control 420 Person & email address to contact for further information: 421 Kurt Zeilenga 422 Usage: Control 423 Specification: RFC XXXX 424 Author/Change Controller: Kurt Zeilenga 425 Comments: none 427 6. Author's Address 429 Kurt D. Zeilenga 430 OpenLDAP Foundation 432 Email: Kurt@OpenLDAP.org 434 7. References 436 [[Note to the RFC Editor: please replace the citation tags used in 437 referencing Internet-Drafts with tags of the form RFCnnnn where 438 possible.]] 440 7.1. Normative References 442 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 443 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 445 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 446 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 447 progress. 449 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 450 Models", draft-ietf-ldapbis-models-xx.txt, a work in 451 progress. 453 7.2. Informative References 455 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", 456 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. 458 [EntryUUID] Zeilenga, K., "The LDAP EntryUUID Operational 459 Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in 460 progress. 462 [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - 463 Technical Specification", RFC 2849, June 2000. 465 Intellectual Property Rights 467 The IETF takes no position regarding the validity or scope of any 468 Intellectual Property Rights or other rights that might be claimed to 469 pertain to the implementation or use of the technology described in 470 this document or the extent to which any license under such rights 471 might or might not be available; nor does it represent that it has 472 made any independent effort to identify any such rights. Information 473 on the procedures with respect to rights in RFC documents can be found 474 in BCP 78 and BCP 79. 476 Copies of IPR disclosures made to the IETF Secretariat and any 477 assurances of licenses to be made available, or the result of an 478 attempt made to obtain a general license or permission for the use of 479 such proprietary rights by implementers or users of this specification 480 can be obtained from the IETF on-line IPR repository at 481 http://www.ietf.org/ipr. 483 The IETF invites any interested party to bring to its attention any 484 copyrights, patents or patent applications, or other proprietary 485 rights that may cover technology that may be required to implement 486 this standard. Please address the information to the IETF at 487 ietf-ipr@ietf.org. 489 Full Copyright 491 Copyright (C) The Internet Society (2006). 493 This document is subject to the rights, licenses and restrictions 494 contained in BCP 78, and except as set forth therein, the authors 495 retain all their rights. 497 This document and the information contained herein are provided on an 498 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 499 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 500 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 501 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 502 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 503 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.