idnits 2.17.1 draft-ietf-kitten-gssapi-extensions-iana-02.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 304. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 310. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (February 25, 2008) is 5905 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) == Unused Reference: 'RFC2743' is defined on line 256, but no explicit reference was found in the text == Unused Reference: 'RFC2744' is defined on line 259, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 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: August 28, 2008 February 25, 2008 6 Namespace Considerations and Registries for GSS-API Extensions 7 draft-ietf-kitten-gssapi-extensions-iana-02.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 19 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 August 28, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 55 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 56 11. Normative References . . . . . . . . . . . . . . . . . . . . . 7 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 58 Intellectual Property and Copyright Statements . . . . . . . . 8 60 1. Conventions used in this document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119]. 66 2. Introduction 68 There is a need for generic and mechanism-specific extensions to the 69 Generic Security Services Application Programming Interface (GSS- 70 API). As such extensions are designed and standardized, both at the 71 IETF and elsewhere, there is a non-trivial risk of namespace 72 pollution and conflicts. To avoid this we set out guidelines for 73 extending the GSS-API and create IANA registries of GSS-API 74 namespaces. 76 Registrations of individual items and sub-namespaces are allowed. 77 Each sub-namespace may provide different rules for registration, 78 e.g., for mechanism-specific and private-use extensions. All 79 Standards-Track uses of the GSS-API namespaces will be registered 80 directly with the IANA subsequent to the create of the registries or 81 when the document is published. 83 3. Extensions to the GSS-API 85 Extensions to the GSS-API can be categorized as follows: 86 o Abstract API extensions 87 o Implementation-specific 88 o Mechanism-specific 89 o Language binding-specific 91 Extensions to the GSS-API may be purely semantic, without effect on 92 the GSS-API's namespaces. Or they may introduce new functions, 93 constants, types, etc...; these clearly affect the GSS-API 94 namespaces. 96 Extensions that affect the GSS-API namespaces should be registered 97 with the IANA as described herein. 99 4. Generic GSS-API Namespaces 101 The abstract API namespaces for the GSS-API are: 102 o Type names 103 o Function names 104 o Constant names for each type 105 o Constant values for each type 106 o Name types (OID, type name and syntaxes) 108 Additionally we have namespaces associates with the OBJECT IDENTIFIER 109 (OID) type: 110 o Mechanism OIDs 111 o Name Type OIDs 113 5. Language Binding-Specific GSS-API Namespaces 115 Language binding specific namespaces include: 116 o Header/interface module names 117 o Object classes and/or types 118 o Methods and/or functions 119 o Constant names 120 o Constant values 122 6. Extension-Specific GSS-API Namespaces 124 Extensions to the GSS-API may create additional namespaces. 125 Instructions to the IANA should included for the handling of such 126 namespaces. 128 7. Registration Form(s) 130 Registrations for GSS-API namespaces SHALL take the following form: 132 +----------------+----------------------------+---------------------+ 133 | Registration | Possible Values | Description | 134 | Field | | | 135 +----------------+----------------------------+---------------------+ 136 | Registration | 'Instance', | Indicates whether | 137 | type | 'Sub-Namespace' | this entry reserves | 138 | | | a given symbol name | 139 | | | or constant value | 140 | | | or whether it | 141 | | | reserves an entire | 142 | | | sub-namespace (the | 143 | | | name is a "prefix") | 144 | | | or constant value | 145 | | | range. | 146 +----------------+----------------------------+---------------------+ 147 | Bindings | 'Generic', 'C-bindings', | Indicates the | 148 | | 'Java', 'C#', | that this | 150 | | | registration is | 151 | | | for, or, if | 152 | | | 'Generic', that | 153 | | | this is an entry | 154 | | | for the generic | 155 | | | GSS-API, not | 156 | | | specific to any | 157 | | | programming | 158 | | | language. | 159 +----------------+----------------------------+---------------------+ 160 | Object Type | 'Data-Type', 'Function', | Indicates the type | 161 | | 'Method', 'Integer', | of the object(s) | 162 | | 'String', 'OID', 'Context | whose symbolic name | 163 | | Flag', 'Name Type' | or constant value | 164 | | | this entry | 165 | | | registers. | 166 +----------------+----------------------------+---------------------+ 167 | Symbol | | symbols or values | 169 | | | being registered. | 170 +----------------+----------------------------+---------------------+ 171 | Binding of | | language binding of | 174 | | | the GSS-API, then | 175 | | | this names the | 176 | | | abstract API | 177 | | | element of which it | 178 | | | is a binding | 179 | | | (OPTIONAL). | 180 +----------------+----------------------------+---------------------+ 181 | Constant | or | The value(s) | 182 | Value/Range(s) | | registered | 183 | | | (OPTIONAL). | 184 +----------------+----------------------------+---------------------+ 185 | Description | | Description of | 186 | | | object(s) being | 187 | | | registered. | 188 +----------------+----------------------------+---------------------+ 189 | Registration | 'Protocol Action', 'Expert | Describes the rules | 190 | Rules | Review', | for allocation of | 191 | | 'First-Come-First-Served', | items that fall in | 192 | | 'Closed-For-Registrations' | this sub-namespace, | 193 | | | if this entry is | 194 | | | for a sub-namespace | 195 | | | (OPTIONAL). | 196 +----------------+----------------------------+---------------------+ 197 | Reference | | Reference to | 198 | | | document that | 199 | | | describes the | 200 | | | object(s) being | 201 | | | registered. | 202 +----------------+----------------------------+---------------------+ 203 | Expert | | | 205 +----------------+----------------------------+---------------------+ 206 | Status | 'Standards-Track', | Status of the | 207 | | 'Informational', | registration. | 208 | | 'Experimental', | | 209 | | 'Obsolete', 'Other' | | 210 +----------------+----------------------------+---------------------+ 212 The IANA should create a single GSS-API namespace registry, or 213 multiple registries, one for symbolic names and one for constant 214 values, or it may create a registry per-programming language, at its 215 convenience. 217 Entries in these registries should consist of all the fields from 218 their corresponding registration entries. 220 Entries should be sorted by object type, progamming language, symbol 221 name. 223 230 8. Initial Namespace Registrations 232 235 238 9. IANA Considerations 240 This document deals with IANA considerations throughout. 241 Specifically it creates a single registry of various kinds of things, 242 thought the IANA may instead create multiple registries each for one 243 of those kinds of things. Of particular interest may be that IANA 244 will now be the registration authority for the GSS-API name type OID 245 space. 247 10. Security Considerations 249 This document has no security considerations. 251 11. Normative References 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, March 1997. 256 [RFC2743] Linn, J., "Generic Security Service Application Program 257 Interface Version 2, Update 1", RFC 2743, January 2000. 259 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 260 C-bindings", RFC 2744, January 2000. 262 Author's Address 264 Nicolas Williams 265 Sun Microsystems 266 5300 Riata Trace Ct 267 Austin, TX 78727 268 US 270 Email: Nicolas.Williams@sun.com 272 Full Copyright Statement 274 Copyright (C) The IETF Trust (2008). 276 This document is subject to the rights, licenses and restrictions 277 contained in BCP 78, and except as set forth therein, the authors 278 retain all their rights. 280 This document and the information contained herein are provided on an 281 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 282 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 283 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 284 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 285 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 286 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 288 Intellectual Property 290 The IETF takes no position regarding the validity or scope of any 291 Intellectual Property Rights or other rights that might be claimed to 292 pertain to the implementation or use of the technology described in 293 this document or the extent to which any license under such rights 294 might or might not be available; nor does it represent that it has 295 made any independent effort to identify any such rights. Information 296 on the procedures with respect to rights in RFC documents can be 297 found in BCP 78 and BCP 79. 299 Copies of IPR disclosures made to the IETF Secretariat and any 300 assurances of licenses to be made available, or the result of an 301 attempt made to obtain a general license or permission for the use of 302 such proprietary rights by implementers or users of this 303 specification can be obtained from the IETF on-line IPR repository at 304 http://www.ietf.org/ipr. 306 The IETF invites any interested party to bring to its attention any 307 copyrights, patents or patent applications, or other proprietary 308 rights that may cover technology that may be required to implement 309 this standard. Please address the information to the IETF at 310 ietf-ipr@ietf.org. 312 Acknowledgment 314 Funding for the RFC Editor function is provided by the IETF 315 Administrative Support Activity (IASA).