idnits 2.17.1 draft-zeilenga-ldap-incr-01.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 261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 234. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 241. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 247. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 253), 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 7009 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC3674' is mentioned on line 93, but not defined ** Obsolete undefined reference: RFC 3674 (Obsoleted by RFC 4512) == Unused Reference: 'Features' is defined on line 197, but no explicit reference was found in the text == Unused Reference: 'ASSIGN' is defined on line 219, but no explicit reference was found in the text == Unused Reference: 'PRIVATE' is defined on line 222, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3674 (ref. 'Features') (Obsoleted by RFC 4512) -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- No information found for draft-ietf-ldapbis-protocol-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-readentry-xx - is the name correct? -- No information found for draft-zeilenga-ldap-assert-xx - is the name correct? Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 13 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 10 February 2005 6 LDAP Modify-Increment Extension 7 9 Status of this Memo 11 This document is intended to be, after appropriate review and 12 revision, submitted to the RFC Editor as an Experimental document. 13 Distribution of this memo is unlimited. Technical discussion of this 14 document will take place on the IETF LDAP Extensions mailing list 15 . Please send editorial comments directly to the 16 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 describes an extension to the Lightweight Directory 47 Access Protocol (LDAP) Modify operation to support an increment 48 capability. This extension is useful in provisioning applications, 49 especially when combined with the assertion control and/or the 50 pre-read or post-read control extension. 52 1. Background and Intended Use 54 The Lightweight Directory Access Protocol [Roadmap] does not currently 55 provide an operation to increment values of an attribute. A client 56 must read the values of the attribute, then modify those values to 57 increment them by the desired amount. As the values may be updated by 58 other clients between this add and modify, the client must be careful 59 to construct the modify request so that it fails in this case, and 60 upon failure, re-read the values and construct a new modify request. 62 This document extends the LDAP Modify Operation [Protocol] to support 63 an increment values capability. This feature is intended to be used 64 with either the LDAP pre-read or post-read control extension 65 [ReadEntry]. This feature may also be used with the LDAP assertion 66 control [Assertion] to provide test-and-increment functionality. 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in BCP 14 [RFC2119]. 72 2. The Modify-Increment Extension 74 This document extends the LDAP Modify request to support a increment 75 values capability. Implementations of this extension SHALL support an 76 additional ModifyRequest operation enumeration value increment (IANA- 77 ASSIGNED-TYPE) as described herein. Implementations not supporting 78 this extension will treat this value as they would an unlisted value, 79 e.g., as a protocol error. 81 The increment (IANA-ASSIGNED-TYPE) operation value specifies that an 82 increment values modification is requested. All existing values of 83 the modification attribute are to be incremented by the listed value. 84 The modification attribute must be appropriate for request, e.g., must 85 have INTEGER or other increment-able values, and the modification must 86 provide one and only value. If the attribute is not appropriate for 87 the request, a constraintViolation or other appropriate error is to be 88 returned. If multiple values are provided, a protocolError is to be 89 returned. 91 Servers supporting this feature SHOULD publish the object identifier 92 (OID) IANA-ASSIGNED-OID as a value of the 'supportedFeatures' 93 [RFC3674] attribute in the root DSE. Clients supporting this feature 94 SHOULD NOT use the feature unless they have knowledge the server 95 supports it. 97 3. LDIF Support 99 To represent Modify-Increment requests in LDAP Data Interchange Format 100 [RFC2849], the ABNF [RFC2234] production is extended as 101 follows: 103 mod-spec /= "increment:" FILL AttributeDescription SEP 104 attrval-spec "-" SEP 106 For example, 108 # Increment uidNumber 109 dn: cn=max-assigned uidNumber,dc=example,dc=com 110 changetype: modify 111 increment: uidNumber 112 uidNumber: 1 113 - 115 This LDIF fragment represents a Modify request to increment the 116 value(s) of uidNumber by 1. 118 4. Security Considerations 120 General LDAP security considerations [Roadmap], as well as those 121 specific to the LDAP Modify [Protocol], apply to this Modify-Increment 122 extension. Beyond these considerations, it is noted that introduction 123 of this extension should reduce application complexity (by provide one 124 operation what presently requires multiple operation) and, hence, may 125 aide in the production of correct and secure implementations. 127 5. IANA Considerations 129 Registration of the following values [BCP64bis] is requested. 131 5.1. Object Identifier 133 It is requested that IANA assign an LDAP Object Identifier to identify 134 the LDAP Modify-Increment feature as defined in this document. 136 Subject: Request for LDAP Object Identifier Registration 137 Person & email address to contact for further information: 138 Kurt Zeilenga 139 Specification: RFC XXXX 140 Author/Change Controller: Author 141 Comments: 142 Identifies the LDAP Modify-Increment feature 144 5.2. LDAP Protocol Mechanism 146 It is requested that the following LDAP Protocol Mechanism be 147 registered. 149 Subject: Request for LDAP Protocol Mechanism Registration 150 Object Identifier: IANA-ASSIGNED-OID 151 Description: Modify-Increment 152 Person & email address to contact for further information: 153 Kurt Zeilenga 154 Usage: Feature 155 Specification: RFC XXXX 156 Author/Change Controller: Kurt Zeilenga 157 Comments: none 159 5.3. LDAP Protocol Mechanism 161 It is requested that IANA assign an LDAP ModifyRequest Operation Type 162 [BCP64bis] for use in this document. 164 Subject: Request for LDAP Protocol Mechanism Registration 165 ModifyRequest Operation Name: increment 166 Description: Modify-Increment 167 Person & email address to contact for further information: 168 Kurt Zeilenga 169 Usage: Feature 170 Specification: RFC XXXX 171 Author/Change Controller: Kurt Zeilenga 172 Comments: none 174 6. Author's Address 176 Kurt D. Zeilenga 177 OpenLDAP Foundation 178 180 7. References 182 [[Note to the RFC Editor: please replace the citation tags used in 183 referencing Internet-Drafts with tags of the form RFCnnnn where 184 possible.]] 186 7.1. Normative References 188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 189 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 191 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 192 Specifications: ABNF", RFC 2234, November 1997. 194 [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - 195 Technical Specification", RFC 2849, June 2000. 197 [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674, 198 December 2003. 200 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 201 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 202 progress. 204 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 205 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 207 7.2. Informative References 209 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", 210 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. 212 [ReadEntry] Zeilenga, K., "LDAP Read Entry Controls", 213 draft-zeilenga-ldap-readentry-xx.txt, a work in 214 progress. 216 [Assertion] Zeilenga, K., "LDAP Assertion Control", 217 draft-zeilenga-ldap-assert-xx.txt, a work in progress. 219 [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", 220 http://www.openldap.org/foundation/oid-delegate.txt. 222 [PRIVATE] IANA, "Private Enterprise Numbers", 223 http://www.iana.org/assignments/enterprise-numbers. 225 Intellectual Property Rights 227 The IETF takes no position regarding the validity or scope of any 228 Intellectual Property Rights or other rights that might be claimed to 229 pertain to the implementation or use of the technology described in 230 this document or the extent to which any license under such rights 231 might or might not be available; nor does it represent that it has 232 made any independent effort to identify any such rights. Information 233 on the procedures with respect to rights in RFC documents can be found 234 in BCP 78 and BCP 79. 236 Copies of IPR disclosures made to the IETF Secretariat and any 237 assurances of licenses to be made available, or the result of an 238 attempt made to obtain a general license or permission for the use of 239 such proprietary rights by implementers or users of this specification 240 can be obtained from the IETF on-line IPR repository at 241 http://www.ietf.org/ipr. 243 The IETF invites any interested party to bring to its attention any 244 copyrights, patents or patent applications, or other proprietary 245 rights that may cover technology that may be required to implement 246 this standard. Please address the information to the IETF at 247 ietf-ipr@ietf.org. 249 Full Copyright 251 Copyright (C) The Internet Society (2005). This document is subject 252 to the rights, licenses and restrictions contained in BCP 78, and 253 except as set forth therein, the authors retain all their rights. 255 This document and the information contained herein are provided on an 256 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 257 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 258 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 259 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 260 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 261 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.