idnits 2.17.1 draft-zeilenga-ldap-noop-06.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 3667, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 228. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 241. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 247), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (10 February 2005) is 7014 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: 'U12' is mentioned on line 78, but not defined == Missing Reference: 'RFC3383' is mentioned on line 150, but not defined ** Obsolete undefined reference: RFC 3383 (Obsoleted by RFC 4520) -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Models' -- No information found for draft-ietf-ldapbis-bcp64-xx - is the name correct? Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires in six months 10 February 2005 6 The LDAP No-Op Control 7 9 Status of this Memo 11 This document is intended to be, after appropriate review and 12 revision, submitted to the IESG for consideration as a Standard Track 13 document. Distribution of this memo is unlimited. Technical 14 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, I accept the provisions of Section 19 4 of RFC 3667. By submitting this Internet-Draft, I certify that any 20 applicable patent or other IPR claims of which I am aware have been 21 disclosed, or will be disclosed, and any of which I become aware will 22 be disclosed, in accordance with RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering Task 25 Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference material 31 or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Please see the Full Copyright section near the end of this document 42 for more information. 44 Abstract 46 This document defines the Lightweight Directory Access Protocol (LDAP) 47 No-Op control which can be used to disable the normal effect of an 48 operation. The control can be used to discover how a server might 49 react to a particular update request without updating the directory. 51 1. Overview 53 It is often desirable to be able to determine if a directory operation 54 [Protocol] would successful complete or not without having the normal 55 effect of the operation take place. For example, an administrative 56 client might want to verify that new user could update their entry 57 (and not other entries) without the directory actually being updated. 58 The mechanism could be used to build more sophisticated security 59 auditing tools. 61 This document defines the Lightweight Directory Access Protocol (LDAP) 62 [Roadmap] No-Op control extension. The presence of the No-Op control 63 in an operation request message disables its normal effect upon the 64 directory which operation would otherwise have. Instead of updating 65 the directory and return the normal indication of success, the server 66 does not update the directory and indicates so by returning the 67 noOperation resultCode (introduced below). 69 For example, when the No-Op control is present in a LDAP modify 70 operation [Protocol], the server is do all processing necessary to 71 perform the operation without actually updating the directory. If it 72 detects an error during this processing, it returns a non-success 73 (other than noOperation) resultCode as it normally would. Otherwise, 74 it returns the noOperation. In either case, the directory is left 75 unchanged. 77 This No-Op control is not intended to be to an "effective access" 78 mechanism [RFC2820, U12]. 80 1.1. Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in BCP 14 [RFC2119]. 86 DN stands for Distinguished Name. 87 DSA stands for Directory System Agent. 88 DSE stands for DSA-specific entry. 90 2. No-Op Control 92 The No-Op control is an LDAP Control [Protocol] whose controlType is 93 IANA-ASSIGNED-OID and controlValue is absent. Clients MUST provide a 94 criticality value of TRUE to prevent unintended modification of the 95 directory. 97 The control is appropriate for request messages of LDAP Add, Delete, 98 Modify and ModifyDN operations [Protocol]. The control is also 99 appropriate for requests of extended operations which update the 100 directory (or other data stores), such as Password Modify Extended 101 Operation [RFC3062]. There is no corresponding response control. 103 When the control is attached to an LDAP request, the server does all 104 normal processing possible for the operation without modification of 105 the directory. That is, when the control is attached to an LDAP 106 request, the directory SHALL NOT be updated and the response SHALL NOT 107 have a resultCode of success (0). 109 A result code other than noOperation (IANA-ASSIGNED-CODE) means that 110 the server is unable or unwilling to complete the processing for the 111 reason indicated by the result code. A result code of noOperation 112 (IANA-ASSIGNED-CODE) indicates that the server discovered no reason 113 why the operation would fail if submitted without the No-Op control. 115 Servers SHOULD indicate their support for this control by providing 116 IANA-ASSIGNED-OID as a value of the 'supportedControl' attribute type 117 [Models] in their root DSE entry. A server MAY choose to advertise 118 this extension only when the client is authorized to use this 119 operation. 121 3. Security Considerations 123 The No-Op control mechanism allows directory administrators and users 124 to verify that access control and other administrative policy controls 125 are properly configured. The mechanism may also lead to the 126 development (and deployment) of more effective security auditing 127 tools. 129 Implementors of this LDAP extension should be familiar with security 130 considerations applicable to the LDAP operations [Protocol] extended 131 by this control, as well as general LDAP security considerations 132 [Roadmap]. 134 4. IANA Considerations 135 4.1. Object Identifier 137 It is requested that IANA assign an LDAP Object Identifier [BCP64bis] 138 to identify the LDAP No-Op Control defined in this document. 140 Subject: Request for LDAP Object Identifier Registration 141 Person & email address to contact for further information: 142 Kurt Zeilenga 143 Specification: RFC XXXX 144 Author/Change Controller: IESG 145 Comments: 146 Identifies the LDAP No-Op Control 148 4.2 LDAP Protocol Mechanism 150 Registration of this protocol mechanism is requested [RFC3383]. 152 Subject: Request for LDAP Protocol Mechanism Registration 153 Object Identifier: IANA-ASSIGNED-OID 154 Description: No-Op Control 155 Person & email address to contact for further information: 156 Kurt Zeilenga 157 Usage: Control 158 Specification: RFC XXXX 159 Author/Change Controller: IESG 160 Comments: none 162 4.3 LDAP Result Code 164 Assignment of an LDAP Result Code called 'noOperation' is requested. 166 Subject: LDAP Result Code Registration 167 Person & email address to contact for further information: 168 Kurt Zeilenga 169 Result Code Name: noOperation 170 Specification: RFC XXXX 171 Author/Change Controller: IESG 172 Comments: none 174 5. Author's Address 176 Kurt D. Zeilenga 177 OpenLDAP Foundation 179 Email: Kurt@OpenLDAP.org 181 6. References 183 [[Note to the RFC Editor: please replace the citation tags used in 184 referencing Internet-Drafts with tags of the form RFCnnnn where 185 possible.]] 187 6.1. Normative References 189 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 190 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 192 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 193 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 195 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 196 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 197 progress. 199 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 200 Models", draft-ietf-ldapbis-models-xx.txt, a work in 201 progress. 203 6.2. Informative References 205 [X.500] International Telecommunication Union - 206 Telecommunication Standardization Sector, "The Directory 207 -- Overview of concepts, models and services," 208 X.500(1993) (also ISO/IEC 9594-1:1994). 210 [RFC2820] Stokes, E., et. al., "Access Control Requirements for 211 LDAP", RFC 2820, May 2000. 213 [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", 214 RFC 3062, February 2000. 216 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", 217 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. 219 Intellectual Property Rights 221 The IETF takes no position regarding the validity or scope of any 222 Intellectual Property Rights or other rights that might be claimed to 223 pertain to the implementation or use of the technology described in 224 this document or the extent to which any license under such rights 225 might or might not be available; nor does it represent that it has 226 made any independent effort to identify any such rights. Information 227 on the procedures with respect to rights in RFC documents can be found 228 in BCP 78 and BCP 79. 230 Copies of IPR disclosures made to the IETF Secretariat and any 231 assurances of licenses to be made available, or the result of an 232 attempt made to obtain a general license or permission for the use of 233 such proprietary rights by implementers or users of this specification 234 can be obtained from the IETF on-line IPR repository at 235 http://www.ietf.org/ipr. 237 The IETF invites any interested party to bring to its attention any 238 copyrights, patents or patent applications, or other proprietary 239 rights that may cover technology that may be required to implement 240 this standard. Please address the information to the IETF at 241 ietf-ipr@ietf.org. 243 Full Copyright 245 Copyright (C) The Internet Society (2005). This document is subject 246 to the rights, licenses and restrictions contained in BCP 78, and 247 except as set forth therein, the authors retain all their rights. 249 This document and the information contained herein are provided on an 250 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 251 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 252 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 253 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 254 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 255 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.