idnits 2.17.1 draft-ietf-ldup-subentry-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (March 1, 2001) is 8457 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) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 3 draft-ietf-ldup-subentry-07.txt 4 Ed Reed 5 Reed-Matthews, Inc. 6 March 1, 2001 8 LDAP Subentry Schema 10 1 Status of this Memo 12 This document is an Internet-Draft and is in full 13 conformance with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet 16 Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by 22 other documents at any time. It is inappropriate to use 23 Internet-Drafts as reference material or to cite them other 24 than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be 30 accessed at http://www.ietf.org/shadow.html. 32 This Internet-Draft expires on September 1, 2001. 34 2 Abstract / Description 36 This document describes two object classes called 37 ldapSubEntry and inheritableLDAPSubEntry, and a control, 38 ldapSubentriesControl (to control the visibility of entries 39 of type ldapSubEntry) which MUST be used by directory 40 servers claiming support for the features of this document 41 to indicate operations and management related entries in 42 the directory, called LDAP Subentries. Scope rules are 43 defined for LDAP Subentries. 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 46 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 47 and "OPTIONAL" in this document are to be interpreted as 48 LDAP Subentry Schema 50 described in [RFC2119]. The sections below reiterate these 51 definitions and include some additional ones. 53 3 Table of Contents 55 1 Status of this Memo 1 56 2 Abstract / Description 1 57 3 Table of Contents 2 58 4 Object Class Definitions 2 59 4.1 ldapSubEntry Class 2 60 4.1.1 Scope Rules 3 61 4.2 InheritableLDAPSubentry Class 4 62 4.2.1 Illustration 5 63 5 Attribute Definitions 6 64 5.1 inheritable Attribute 6 65 5.2 blockInheritance Attribute 6 66 6 Visibility Controls 7 67 6.1 ldapSubentriesControl 7 68 6.1.1 LDAP Search with scope other than baseObject 7 69 6.1.2 LDAP Search with scope of baseObject 7 70 6.1.3 Other LDAP operations 8 71 6.1.4 Correspondence to X.500 [X.511] 8 72 7 Security Considerations 8 73 8 References 9 74 9 Copyright Notice 9 75 10 Acknowledgements 10 76 11 Author's Address 11 78 4 Object Class Definitions 80 4.1 ldapSubEntry Class 82 ( 2.16.840.1.113719.2.142.6.1.1 NAME 'ldapSubEntry' 83 DESC 'LDAP Subentry class, version 1' 84 SUP top STRUCTURAL 85 MAY ( cn ) ) 87 The class ldapSubEntry is intended to be used as a super- 88 class when defining other structural classes to be used 89 as LDAP Subentries, and as the structural class to which 90 Auxiliary classes may be added for application specific 91 subentry information. Where possible, the use of Auxiliary 92 classes to extend LDAP Subentries is strongly preferred. 94 Expires September 1, 2001 95 LDAP Subentry Schema 97 The presence of ldapSubEntry in the list of super-classes 98 of an entry in the directory makes that entry an LDAP 99 Subentry. Object classes derived from ldapSubEntry are 100 themselves considered ldapSubEntry classes, for the purpose 101 of this discussion. 103 LDAP Subentries MAY be named by their commonName attribute 104 [RFC2251]. Other naming attributes are also permitted. 106 LDAP Subentries MAY be containers, unlike their [X.501] 107 counterparts. 109 LDAP Subentries MAY be contained by, and will usually be 110 located in the directory information tree immediately 111 subordinate to, administrative points. Further (unlike 112 X.500 subentries), LDAP Subentries MAY be contained by 113 other LDAP Subentries (the way organizational units may be 114 contained by other organizational units). Deep nesting of 115 LDAP Subentries are discouraged, but not prohibited. 116 Developers are warned that deep nesting of LDAP Subentries 117 may not be supported by all (or indeed, by any) LDAP server 118 implementations. 120 4.1.1Scope Rules 122 The default scope of an LDAP Subentry is limited to the 123 administrative area in which it is defined. Specifically, 124 the subtree of the directory namespace based at the 125 administrative point most immediately superior to the LDAP 126 Subentry, down to but not including any subordinate 127 administrative points or areas. Policy defined in an LDAP 128 Subentry is not inheritable, unless such inheritance is 129 explicitly defined (see the object class definition for 130 InheritableLDAPSubEntry, below, for such an example). 132 If an LDAP Subentry is subordinate to another LDAP 133 Subentry, it takes the same default scope as the parent 134 LDAP Subentry. 136 Applications MAY define alternative scope semantics for 137 classes they define which are derived from the ldapSubEntry 138 class. This means that an application can derive a new 139 class from the ldapSubEntry class and add an attribute, 140 like subtreeSpecification [X.501] or inheritance controls 141 (see below), to define a new scope rule for that 142 application to use. 144 Expires September 1, 2001 145 LDAP Subentry Schema 147 Applications MUST NOT define alternative scope rules for 148 auxiliary classes used to decorate entries of the 149 ldapSubEntry class. This restriction is required to avoid 150 having conflicting or contradictory scope definitions 151 applied by different applications to the same LDAP 152 Subentry. 154 4.2 InheritableLDAPSubEntry Class 156 ( 1.3.6.1.4.1.7628.5.6.1.1 NAME 'inheritableLDAPSubEntry' 157 DESC 'Inheritable LDAP Subentry class, version 1' 158 SUP ldapSubEntry STRUCTURAL 159 MUST ( inheritable ) 160 MAY ( blockInheritance ) 162 The InheritableLDAPSubentry class is derived from the 163 ldapSubEntry class and provides modified scope semantics to 164 permit and control inheritance from one administrative area 165 to one or more subordinate administrative areas. 167 If the 'inheritable' attribute is TRUE (1), then the policy 168 information contained in the InheritableLDAPSubEntry is 169 intended to apply to any (and all) subordinate 170 administrative areas. Subordinate administrative areas 171 MUST include Inheritable LDAP Subentries from their 172 immediately superior administrative area (unless blocked, 173 see below). The means of such inclusion (that is, whether 174 via replication, caching, or explicitly walking the tree to 175 locate and "include" them, are left to the application that 176 consumes the inheritable policy information contained on 177 the inheritableLDAPSubEntry. 179 If the 'inheritable' attribute is FALSE (0), the policy is 180 NOT inheritable, and subordinate administrative areas MUST 181 treat the associated policy information as UNDEFINED (that 182 is, absent) unless explicitly defined within their own 183 administrative area. 185 If a subordinate administrative area defines an Inheritable 186 LDAP Subentry for an application with the same name as one 187 defined in a superior administrative area, and if the 188 subordinate�s Inheritable LDAP Subentry has the attribute 189 'blockInheritance' with the value TRUE, then inheritance is 190 blocked from the superior administrative area to that 191 subordinate administrative area, and the effect is the same 192 as if the superior Inheritable LDAP Subentry contained the 193 'inheritable' attribute set to FALSE. 195 Expires September 1, 2001 196 LDAP Subentry Schema 198 The value of the 'blockInheritance' attribute in a superior 199 administrative area Inheritable LDAP Subentry is irrelevant 200 to a subordinate administrative area for this object class. 202 No mechanism is defined (at this time) to signal to 203 subordinate administrative areas that they may not block 204 inheritable policy from superior administrative areas. 206 4.2.1Illustration 208 An illustration may help clarify the use of the class and 209 these attributes. 211 Suppose the administrative area based at 'dc=com' has an 212 Inheritable LDAP Subentry for an application defined with 213 the 'inheritable' attribute set to TRUE. Subordinate 214 administrative areas, for instance 'dc=widget, dc=com' 215 might or might not want to accept the inherited policy from 216 the 'dc=com' administrative area. 218 If the administrator of the 'dc=widget, dc=com' 219 administrative area creates an Inheritable LDAP Subentry 220 (say, 'cn=example, dc=widget, dc=com') with the same 221 relative distinguished name as used in the 'dc=com' 222 administrative area (that is, 'cn=example, dc=com') setting 223 the 'blockInheritance' attribute set to TRUE, then the 224 inheritance of the policy defined (on 'cn=example, dc=com') 225 is effectively blocked from affecting the 'dc=widget, 226 dc=com' administrative area. We�ll call this a blocking 227 subentry for our discussion here. 229 If the administrator of the 'dc=widget, dc=com' 230 administrative area creates a blocking subentry (as above) 231 with some locally defined policy information, that policy 232 information effectively replaces the policy information 233 defined by the superior administrative area. We�ll call 234 this an over-riding subentry for our discussion here. 236 An over-riding subentry MAY itself be inheritable, in which 237 case the 'inheritable' attribute on the locally defined 238 Inheritable LDAP Subentry MAY be set to TRUE or FALSE, at 239 the discretion of the local administrative authority, with 240 appropriate implications for inheritance of the new, 241 locally defined policy, on any other subordinate 242 administrative areas. In this way, the 'dc=widget, dc=com' 243 administrator can set inheritable policy for organizational 244 units (like 'ou=eng, dc=widget, dc=com') for an application 246 Expires September 1, 2001 247 LDAP Subentry Schema 249 while over-riding inheritable policy from the superior 250 'dc=com' administrative area. 252 5 Attribute Definitions 254 5.1 inheritable Attribute 256 ( 1.3.6.1.4.1.7628.5.4.1 NAME 'inheritable' 257 SYNTAX BOOLEAN 258 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) 260 Used to signal whether an inheritableLDAPSubEntry is 261 intended to be inherited by subordinate administrative 262 areas, or not. TRUE indicates that the subentry and the 263 policy it contains is inheritable. 265 FALSE indicates that information from the 266 inheritableLDAPSubEntry is not to be inherited by 267 subordinate administrative areas. 269 5.2 blockInheritance Attribute 271 ( 1.3.6.1.4.1.7628.5.4.2 NAME 'blockInheritance' 272 SYNTAX BOOLEAN 273 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) 275 Used by administrators of subordinate administrative areas 276 to over-ride, or block, the inheritance of 277 inheritableLDAPSubEntry policy from superior administrative 278 areas. 280 A value of TRUE indicates that inheritance is to be 281 blocked. 283 A value of FALSE is implies that inheritance is not to be 284 blocked, but specific semantic interpretation is left to 285 applications (who may specify any of a variety of policy 286 aggregation mechanisms to define how inherited policy is to 287 be mixed with locally defined policy, which mechanisms are 288 explicitly outside the scope of this specification). 290 Expires September 1, 2001 291 LDAP Subentry Schema 293 6 Visibility Controls 295 6.1 ldapSubentriesControl 297 This control is included in the searchRequest message as 298 part of the controls field of the LDAPMessage, as defined 299 in Section 4.1.12 of [RFC2251]. 301 The controlType is set to "1.3.6.1.4.1.7628.5.101.1". The 302 criticality MAY be set to either TRUE or FALSE. The 303 controlValue is absent. 305 There is no corresponding response control defined. 307 LDAP servers that support this control MUST treat LDAP 308 Subentries as "operational objects" in much the same way 309 that "operational attributes" are not returned in search 310 results and [X.511] read operations when only user 311 attributes are requested. 313 Entries which are not LDAP Subentries may still be 314 referenced in the base object of search operations where 315 the ldapSubentriesControl is present in the request. 317 6.1.1LDAP Search with scope other than baseObject 319 The ldapSubentriesControl is defined for LDAP to signal to 320 LDAP Search operations that ONLY LDAP Subentries are to be 321 included in the return set of entries for the Search, 322 provided other Search criteria (such as scope and filter) 323 are satisfied. When ldapSubentriesControl is NOT included 324 in a Search request on a server that supports the control, 325 LDAP Subentries MUST be omitted from the return set (with 326 the single exception described in Search Filter Visibility, 327 below). 329 6.1.2LDAP Search with scope of baseObject 331 For Search operations with a scope value of baseObject, the 332 presence or absence of the ldapSubentriesControl MUST be 333 ignored. Specifically, baseObject searches applied to 334 ldapSubEntry entries MUST be evaluated by Search as if the 335 ldapSubentriesControl is present, even if it is absent. 337 Expires September 1, 2001 338 LDAP Subentry Schema 340 This provision is intended to preserve the behavior of 341 [X.511] Read operations, which are not affected by the 342 [X.511] subentries control (see Correspondence to X.500, 343 below), and because it would seem silly to behave 344 otherwise. 346 6.1.3Other LDAP operations 348 The ldapSubentriesControl is not defined for any LDAP 349 operation other than Search. However, an LDAPv3 Extension 350 MAY define a use of this control with that extension as 351 long as such use is consistent with this specification. 353 6.1.4Correspondence to X.500 [X.511] 355 In [X.511] a ServiceControl option is used to govern the 356 visibility of [X.501] subentries. The subentry 357 ServiceControl option is a specific bit of a bitstring 358 that, when set to TRUE in the common arguments of an X.500 359 Search or List operation, indicates that the operation is 360 to access ONLY the subentries found in the context of the 361 list or search. In fact, normal entries are explicitly NOT 362 returned in the result of a list or search operation when 363 the X.500 subentries ServiceControl is set. 365 Entries which are not subentries may still be referenced in 366 the base object of list and search operations where the 367 subentries control is set. 369 The [X.511] subentries ServiceControl has no meaning for 370 operations other than Search and List (i.e., Read, Modify, 371 Delete, etc.). 373 In [X.501], the scope of a subentry is a subtree or subtree 374 refinement. The ldapSubEntry class defined in this 375 document provides no mechanism to define a subtree 376 refinement. 378 7 Security Considerations 380 LDAP Subentries will frequently be used to hold data which 381 reflects either the actual or intended behavior of the 382 directory service. As such, permission to read such 383 entries MAY need to be restricted to authorized users. 385 Expires September 1, 2001 386 LDAP Subentry Schema 388 More importantly, IF a directory service treats the 389 information in an LDAP Subentry as the authoritative source 390 of policy to be used to control the behavior of the 391 directory, then permission to create, modify, or delete 392 such entries MUST be carefully restricted to authorized 393 administrators. 395 This specification defines a policy inheritance model that 396 allows subordinate administrators to over-ride policy 397 defined by administrators of administrative areas superior 398 to the local administrative area. No mechanism is defined 399 here to keep local administrators from over-riding such 400 inherited policy. Implementations that intend to provide 401 such control over the actions of subordinate administrators 402 will require additional semantics (and possibly syntax). 404 8 References 406 [RFC2119] S. Bradner, "Key words for use in RFCs to 407 Indicate Requirement Levels", RFC 2119, March 1997 409 [RFC2251] S. Kille, M. Wahl, and T. Howes, "Lightweight 410 Directory Access Protocol (v3)", RFC 2251, December 1997 412 [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993 and 413 subsequent versions 415 [X.511] ITU-T Rec. X.501, "The Directory: Abstract Service 416 Definition", 1993 and subsequent versions 418 9 Copyright Notice 420 Copyright (C) The Internet Society (2000). All Rights 421 Reserved. 423 This document and translations of it may be copied and 424 furnished to others, and derivative works that comment on 425 or otherwise explain it or assist in its implementation may 426 be prepared, copied, published and distributed, in whole or 427 in part, without restriction of any kind, provided that the 428 above copyright notice and this paragraph are included on 429 all such copies and derivative works. However, this 431 Expires September 1, 2001 432 LDAP Subentry Schema 434 document itself may not be modified in any way, such as by 435 removing the copyright notice or references to the Internet 436 Society or other Internet organizations, except as needed 437 for the purpose of developing Internet standards in which 438 case the procedures for copyrights defined in the Internet 439 Standards process must be followed, or as required to 440 translate it into languages other than English. 442 The limited permissions granted above are perpetual and 443 will not be revoked by the Internet Society or its 444 successors or assigns. 446 This document and the information contained herein is 447 provided on an "AS IS" basis and THE INTERNET SOCIETY AND 448 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 449 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 450 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 451 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 452 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 454 10 Acknowledgements 456 The utility of subEntry object class was originally 457 suggested as a means to store Replica and Replication 458 Agreement information with a the lucid explanation by Mark 459 Wahl, (then of Innosoft), of how they could be used and 460 extended. 462 The IETF takes no position regarding the validity or scope 463 of any intellectual property or other rights that might be 464 claimed to pertain to the implementation or use of the 465 technology described in this document or the extent to 466 which any license under such rights might or might not be 467 available; neither does it represent that it has made any 468 effort to identify any such rights. Information on the 469 IETF's procedures with respect to rights in standards-track 470 and standards-related documentation can be found in BCP-11. 471 Copies of claims of rights made available for publication 472 and any assurances of licenses to be made available, or the 473 result of an attempt made to obtain a general license or 474 permission for the use of such proprietary rights by 475 implementers or users of this specification can be obtained 476 from the IETF Secretariat. 478 The IETF invites any interested party to bring to its 479 attention any copyrights, patents or patent applications, 480 or other proprietary rights which may cover technology that 482 Expires September 1, 2001 483 LDAP Subentry Schema 485 may be required to practice this standard. Please address 486 the information to the IETF Executive Director. 488 11 Author's Address 490 Edwards E. Reed 491 Reed-Matthews, Inc. 492 1064 E 140 North 493 Lindon, UT 84042 494 USA 495 E-mail: eer@oncalldba.com 497 LDUP Mailing List: ietf-ldup@imc.org 498 LDAPEXT Mailing List: ietf-ldapext@netscape.com 500 Expires September 1, 2001