idnits 2.17.1 draft-ietf-kitten-gssapi-extensions-iana-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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 277. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 254. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 267. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 283), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** 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 '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 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.) 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 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 (January 2005) is 7040 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? 'RFC2119' on line 226 looks like a reference -- Missing reference section? 'EXTENDED-INQUIRY' on line 220 looks like a reference -- Missing reference section? 'RFC2743' on line 229 looks like a reference -- Missing reference section? 'RFC2744' on line 232 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP N. Williams 3 Internet-Draft Sun 4 Expires: July 2, 2005 January 2005 6 Namespace Considerations and Registries for GSS-API Extensions 7 draft-ietf-kitten-gssapi-extensions-iana-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other 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 accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 2, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). All Rights Reserved. 38 Abstract 40 This document describes the ways in which the GSS-API may be extended 41 and directs the creation of IANA registries for various GSS-API 42 namespaces. 44 Table of Contents 46 1. Conventions used in this document . . . . . . . . . . . . . . 3 47 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. Extensions to the GSS-API . . . . . . . . . . . . . . . . . . 3 49 4. Generic GSS-API Namespaces . . . . . . . . . . . . . . . . . . 3 50 5. Language Binding-Specific GSS-API Namespaces . . . . . . . . . 4 51 6. Extension-Specific GSS-API Namespaces . . . . . . . . . . . . 4 52 7. Registration Form(s) . . . . . . . . . . . . . . . . . . . . . 4 53 8. Initial Namespace Registrations . . . . . . . . . . . . . . . 6 54 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 55 10. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 57 Intellectual Property and Copyright Statements . . . . . . . . 7 59 1. Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 2. Introduction 67 There is a need for generic and mechanism-specific extensions to the 68 Generic Security Services Application Programming Interface 69 (GSS-API). As such extensions are designed and standardized, both at 70 the IETF and elsewhere, there is a non-trivial risk of namespace 71 pollution and conflicts. To avoid this we set out guidelines for 72 extending the GSS-API and create IANA registries of GSS-API 73 namespaces. 75 The registration of name prefixes and constant value ranges is 76 allowed so as to save the IANA the trouble of registering every 77 GSS-API name and constant, and to allow for reservation of portions 78 of some GSS namespaces for private extensions or extensions which 79 lack IETF Standards-Track extensions. 81 3. Extensions to the GSS-API 83 Extensions to the GSS-API can be categorized as follows: 84 o Generic 85 o Implementation-specific 86 o Mechanism-specific 87 o Language binding-specific 88 o Any combination of two or all three of the last three 90 Extensions to the GSS-API may be purely semantic, without effect on 91 the GSS-API's namespaces. Or they may introduce new functions, 92 constants, types, etc...; these clearly affect the GSS-API 93 namespaces. 95 Extensions that affect the GSS-API namespaces should be registered 96 with the IANA. 98 4. Generic GSS-API Namespaces 100 All the function, constant and type names, as well as all the 101 constant values specified in the base GSS-API specification for the 102 basic generic GSS-API namespace. 104 The generic GSS-API namespaces are: 105 o Type names 106 o Function names 107 o Constant names for each type 108 o Constant values for each type 109 o Mechanism OIDs 110 o Name Type OIDs 111 o Mechanism Attribute OIDs (see [EXTENDED-INQUIRY]) 113 5. Language Binding-Specific GSS-API Namespaces 115 119 6. Extension-Specific GSS-API Namespaces 121 Extensions to the GSS-API may create additional namespaces. 122 Instructions to the IANA should included for the handling of such 123 namespaces. 125 7. Registration Form(s) 127 Registrations for GSS-API namespaces SHALL take the following form: 129 +----------------------+----------------------+---------------------+ 130 | Registration Field | Possible Values | Description | 131 +----------------------+----------------------+---------------------+ 132 | Registration type | 'Individual', | Indicates whether | 133 | | 'Prefix', 'Range' | this entry reserves | 134 | | | a given symbol name | 135 | | | or constant value | 136 | | | or whether it | 137 | | | reserves an entire | 138 | | | sub-namespace (the | 139 | | | name is a "prefix") | 140 | | | or constant value | 141 | | | range. | 142 | Bindings | 'Generic', | Indicates the | 143 | | 'C-bindings', | language bindings | 144 | | 'Java', 'C#', etc... | that this | 145 | | | registration is | 146 | | | for, or, if | 147 | | | 'Generic', that | 148 | | | this is an entry | 149 | | | for the generic | 150 | | | GSS-API, not | 151 | | | specific to any | 152 | | | programming | 153 | | | language. | 154 | Object Type | 'Symbol', | Indicates whether | 155 | | 'Constant-Value' | this registration | 156 | | | is for a symbol | 157 | | | (e.g., function, | 158 | | | constant name(s)) | 159 | | | or constant value. | 160 | Object Programming | 'Data-Type', | Indicates the type | 161 | Type | 'Function', | of the object(s) | 162 | | 'Method', 'Integer', | whose symbolic name | 163 | | 'String', 'OID' | or constant value | 164 | | | is this entry | 165 | | | registers. | 166 | Object Name | | symbols or values | 168 | | | being registered. | 169 | Object Value | or | [Only for | 170 | | | registrations.] The | 172 | | | value(s) | 173 | | | registered. | 174 | Description | | Description of | 175 | | | object(s) being | 176 | | | registered. | 177 | Reference | | Reference to | 178 | | | document that | 179 | | | describes the | 180 | | | object(s) being | 181 | | | registered. | 182 | Status | 'Standards-Track', | | 183 | | 'Informational', | | 184 | | 'Experimental', | | 185 | | 'Obsolete' | | 186 +----------------------+----------------------+---------------------+ 188 The IANA should create a single GSS-API namespace registry, or 189 multiple registries, one for symbolic names and one for constant 190 values, or it may create a registry per-programming language, at its 191 convenience. 193 Entries in these registries should consist of all the fields from 194 their corresponding registration entries. 196 Entries SHOULD be sorted by object type, proggamming language, symbol 197 name. 199 206 8. Initial Namespace Registrations 208 211 214 9. Security Considerations 216 This document has no security considerations. 218 10 Normative 220 [EXTENDED-INQUIRY] 221 Williams, N., "Extended Generic Security Service Mechanism 222 Inquiry APIs", 223 draft-ietf-kitten-extended-mech-inquiry-00.txt (work in 224 progress). 226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, March 1997. 229 [RFC2743] Linn, J., "Generic Security Service Application Program 230 Interface Version 2, Update 1", RFC 2743, January 2000. 232 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 233 C-bindings", RFC 2744, January 2000. 235 Author's Address 237 Nicolas Williams 238 Sun Microsystems 239 5300 Riata Trace Ct 240 Austin, TX 78727 241 US 243 EMail: Nicolas.Williams@sun.com 245 Intellectual Property Statement 247 The IETF takes no position regarding the validity or scope of any 248 Intellectual Property Rights or other rights that might be claimed to 249 pertain to the implementation or use of the technology described in 250 this document or the extent to which any license under such rights 251 might or might not be available; nor does it represent that it has 252 made any independent effort to identify any such rights. Information 253 on the procedures with respect to rights in RFC documents can be 254 found in BCP 78 and BCP 79. 256 Copies of IPR disclosures made to the IETF Secretariat and any 257 assurances of licenses to be made available, or the result of an 258 attempt made to obtain a general license or permission for the use of 259 such proprietary rights by implementers or users of this 260 specification can be obtained from the IETF on-line IPR repository at 261 http://www.ietf.org/ipr. 263 The IETF invites any interested party to bring to its attention any 264 copyrights, patents or patent applications, or other proprietary 265 rights that may cover technology that may be required to implement 266 this standard. Please address the information to the IETF at 267 ietf-ipr@ietf.org. 269 Disclaimer of Validity 271 This document and the information contained herein are provided on an 272 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 273 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 274 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 275 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 276 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 277 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 279 Copyright Statement 281 Copyright (C) The Internet Society (2005). This document is subject 282 to the rights, licenses and restrictions contained in BCP 78, and 283 except as set forth therein, the authors retain all their rights. 285 Acknowledgment 287 Funding for the RFC Editor function is currently provided by the 288 Internet Society.