idnits 2.17.1 draft-liang-iana-pen-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 13, 2014) is 3668 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 397, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 1065 (Obsoleted by RFC 1155) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Liang 3 Internet-Draft ICANN 4 Intended status: Informational A. Melnikov 5 Expires: September 14, 2014 Isode Ltd 6 D. Conrad 8 March 13, 2014 10 Private Enterprise Number (PEN) practices and Internet Assigned Numbers 11 Authority (IANA) registration considerations 12 draft-liang-iana-pen-03 14 Abstract 16 Private Enterprise Numbers (PENs) are a technical protocol parameter 17 frequently assigned for use in the management of network connected 18 equipment or software via SNMP-based network management systems, 19 LDAP, DIAMETER or GSS-API. This document discusses what a Private 20 Enterprise Number (PEN) is, common uses of PENs, and registration 21 procedures for IANA Considerations. The registration procedures 22 include instructions and requirements for obtaining a new Private 23 Enterprise Number, modifying existing numbers, and the removal of 24 existing numbers. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 14, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Example of use for Private Enterprise Numbers . . . . . . . . 3 62 3. Who can get a Private Enterprise Number? . . . . . . . . . . 3 63 4. Other useful things to know . . . . . . . . . . . . . . . . . 4 64 5. Syntax for Private Enterprise Numbers . . . . . . . . . . . . 5 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 7.1. New Private Enterprise Numbers . . . . . . . . . . . . . 5 68 7.2. Modification of Private Enterprise Numbers . . . . . . . 7 69 7.3. Removals of Private Enterprise Numbers . . . . . . . . . 8 70 7.4. Historical Assignments . . . . . . . . . . . . . . . . . 8 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 9.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 A Private Enterprise Number (also known as a "PEN"), is a subtree of 80 Object Identifiers (OIDs ) with prefix 81 iso.org.dod.internet.private.enterprise (1.3.6.1.4.1)). The Private 82 Enterprise Number OID was originally defined in [RFC1065]. A PEN is 83 a non-negative integer, unique within the 84 iso.org.dod.internet.private.enterprise subtree, that can be used to 85 reference an organization ("enterprise") in protocols that require 86 numeric values instead of a human readable organization name. 88 Currently, procedures for assignment of new PENs and the modification 89 of existing PENs are not clearly documented. Private Enterprise 90 Numbers are referenced in RFCs [RFC1157] [RFC1213] and [RFC2578]. 91 These documents mostly define Simple Network Management Protocol 92 (SNMP), Management Information Base (MIB) and Structure of Management 93 Information (SMI) structures. However, none of these RFCs clearly 94 describe PENs and define their registration procedures. 96 Additionally, updates to existing Private Enterprise Numbers can be 97 challenging due to the lack of clear registration requirements and 98 difficulties in validation, particuarly in cases such as organization 99 name or legal ownership changes, changes in email addresses of the 100 registered PEN owner, etc. 102 This purpose of this document is to describe the basics of PENs, how 103 they are most commonly used, and to define PEN registration and 104 update procedures. 106 2. Example of use for Private Enterprise Numbers 108 PENs are frequently embedded in OIDs (Object Identifiers) , which are 109 most often used in Simple Network Management Protocol (SNMP) 110 Management Information Base (MIB) configurations. However, PENs are 111 not designed to be used exclusively for SNMP purposes, but rather 112 they can be and are used by a variety protocols and Data Manipulation 113 Languagess. These other uses include: 115 Distinguished Names and other components in X.509 certificates; 117 Various schema elements in X.500/LDAP directories; 119 GSS-API 121 extensions to DIAMETER 123 PA-TNC [RFC5792] and PB-TNC [RFC5793] 125 Various healthcare related standards, including HL7. 127 3. Who can get a Private Enterprise Number? 129 PENs are assigned through a "First Come First Served" registration 130 policy as described in [RFC5226]. A new request can be submitted to 131 IANA by individuals or organizations in order to obtain a unique 132 value for their "enterprise". In order to facilitate appropriate 133 registration, a small amount of information is required including the 134 requesting organization (or individual's) name, the name of the 135 contact person for the PEN, and an e-mail address of the contact. In 136 some cases, users submit a program name, product, project, and random 137 abbreviation as the organization name to apply for a new 138 registration. However this should be discouraged since the program 139 name is not and should not be considered the name of the Registrant 140 (Company/Organization) as described in Section 7. 142 In other cases, applicants that already have a PEN make requests for 143 new PENs for subsidiaries claiming the subsidiaries are completely 144 independent of the parent organization, the subsidiaries are located 145 in different locations, or other reasons why the subsidiaries cannot 146 use existing the existing PEN allocation. However, this does not 147 justify new allocations as the parent company is able to create sub- 148 trees and allocate the sub-numbers themselves. IANA does not 149 allocate new numbers to companies that are subsidiaries of existing 150 registrations. 152 However, joint ventures of business enterprises may request new 153 allocations if the joint venture is considered a new legal body. In 154 addition, open resource forums and individuals may request new 155 allocations under the registration requirement as describe in 156 Section 7. 158 4. Other useful things to know 160 As some examples documented on Wikipedia, the most common OIDs seen 161 "in the wild" usually belong to the private enterprise numbers 162 allocated by IANA under the 1.3.6.1.4.1 163 (iso.org.dod.internet.private.enterprise) tree. However, 164 increasingly, an OID with health care and public health informatics 165 in the United States is being used. Health Level Seven (HL7), a 166 standards-developing organization in the area of electronic health 167 care data exchange is an assigning authority at the 2.16.840.1.113883 168 (joint-iso-itu-t.country.us.organization.hl7) tree. 170 It is important to note that PENs do not always represent a 171 manufacturer or Vendor ID. 173 The registrant of a Private Enterprise Number can create sub-trees by 174 appending a "." along with unique numbers at the end of their PEN, 175 i.e. to perform its own sub-allocations. For example, for LDAP, the 176 registrant of PEN can use: 178 iso.org.dod.internet.private.enterprise..1 for LDAP Object 179 Classes 181 iso.org.dod.internet.private.enterprise..2 for LDAP attribute 182 types 184 iso.org.dod.internet.private.enterprise..3 for LDAP syntaxes 186 A particular Object class can have OID: 188 iso.org.dod.internet.private.enterprise..1.100 190 iso.org.dod.internet.private.enterprise..1.200 for subsidiaries 191 an/or divisions 192 In general any number of additional levels are permitted, for 193 example: 195 iso.org.dod.internet.private.enterprise..1.1 can be used as a 196 parent OID for all email related object classes, and 198 iso.org.dod.internet.private.enterprise..1.2 can be used for web 199 related object classes, etc. 201 5. Syntax for Private Enterprise Numbers 203 Valid information for the Registrant (Company/Organization) Name for 204 PEN registrations are normatively defined as follows: 206 o Maximum value for PENs is hereby defined within 2**32-1 with 0 and 207 0xFFFFFF (in hex) marked as Reserved. 209 o TBD: Subset of ASCII character (at least ALPHA, DIGIT and "-", SP) 211 o TBD: Special characters (Use LetterDigits from draft-ietf-precis- 212 framework?) 214 o MUST NOT begin or end with a hyphen 216 o Values "Reserved" MUST NOT be allocated 218 o Value "Unassigned" SHOULD NOT be re-assigned unless specified 219 otherwise, i.e. when the available pool of PENs runs out. 221 6. Acknowledgements 223 The authors would like to thank Dan Romascanu, Michelle Cotton, and 224 Bert Wijnen for their contributions to this document. 226 7. IANA Considerations 228 7.1. New Private Enterprise Numbers 230 New Private Enterprise Numbers are assigned on a First Come First 231 Served basis [RFC5226] and are assigned sequentially. There is no 232 opportunity to request a particular private enterprise number. The 233 requester can submit an online application form. Information to be 234 included: 236 Registrant (Company/Organization) Name (REQUIRED) 238 Registrant (Company/Organization) E-mail Address (REQUIRED) 239 Registrant Postal Address (REQUIRED) 241 Registrant Phone Number (Optional) 243 Registrant Fax Number (OPTIONAL) 245 Contact Name (REQUIRED) 247 Contact E-mail Address (REQUIRED) 249 Contact Postal Address (OPTIONAL) 251 Contact Phone Number (OPTIONAL) 253 Reference (OPTIONAL) 255 Registrant (Company/Organization) Name: The name of the organization 256 or individual responsible for the registration of Private Enterprise 257 Number. If the organization is a company, it should be the full 258 legal name including "Inc.", "Ltd.", etc. 260 Registrant (Company/Organization) E-mail Address: The e-mail address 261 of the organization that requests the PEN. This e-mail address will 262 be publicly available in the IANA PEN Registry. The E-mail address 263 should be a valid email address and can be a role account e-mail 264 address. 266 Registrant Postal Address: The full postal address of the 267 organization/individual requesting the PEN, including state/province, 268 zip/postal code, country, etc. 270 Registrant Phone: The main telephone number of the organization/ 271 individual requesting the PEN, including the country code. 273 Registrant Fax Number: The facsimile number of the organization/ 274 individual responsible for the PEN, including the country code. 276 Contact Name: The full name of the individual who will be responsible 277 for the PEN on behalf of the company. 279 Contact Postal Address: The full postal address of the individual 280 responsible the PEN, including state/province, zip/postal code, 281 country, etc. 283 Contact Phone: The telephone number (with extension where 284 appropriate) of the individual responsible for the PEN, including 285 country code. 287 Contact E-Mail Address: The e-mail address of the individual 288 responsible for the PEN. The e-mail address must be one the Contact 289 person can email confirmation from. This e-mail address will be 290 publicly available in the IANA PEN Registry. The Contact E-mail 291 Address can be the same one as the Registrant's E-mail address. 293 Reference: A document associated with the implementation of the OID 294 can be referenced with the registration. 296 It is recommended that a single PEN is granted per organization. 297 IANA does not expect to allocate additional PENs to the same 298 Registrants (Companies/Organizations) that have existing PEN records 299 listed in the IANA PEN registry. 301 7.2. Modification of Private Enterprise Numbers 303 Modification of existing Private Enterprise Numbers: 305 Registrant (Company/Organization) Name can be modified with 306 verification. When a Company/Organization has been merged or 307 acquired by another enterprise, the Registrant (Company/Organization) 308 Name can be annotated in the registry with the new owner. Note that 309 such annotations would require emails from the both existing Contact 310 and proposed Contact, and, if it deems to be necessary, official 311 letters from the existing owner (if applicable) to provide proofs of 312 the changes to IANA. If either the existing owner or Contact is 313 obsoleted, an official letter from the proposed Registrant (Company/ 314 Organization) Name will be required and be supplied to IANA for 315 verifications. Additional documentations will be required subject to 316 the conditions of the changes of the numbers in questions. It is not 317 guarantee that the request will be granted if IANA does not have 318 sufficient information to verify the changes, or if there is legacy 319 use of the PEN out in the wild. 321 All information associated with existing PEN records, excluding the 322 Registrant (Company/Organization) Name, shall be updated if the 323 information is obsoleted. (See the preceding section to update the 324 Registrant (Company/Organization) Name.) A request to update Contact 325 information associated with an existing PEN record shall be submitted 326 to IANA using an online submission. Requests can only be fulfilled 327 upon verification by IANA and/or subject matter experts. Additional 328 documentations will be required if it deems to be necessary to 329 validate the request. 331 A change to the Contact Name of existing PEN records can be made to 332 IANA in case of personnel changes, change of employment, 333 acquisitions, etc. It would be ideal that new requests shall be 334 completed by the existing Contacts for the PEN records. E-mail 335 verifications of the requested changes are required. Alternatively, 336 supplemental documentations and/or letters issued by the Company/ 337 Organization (Registrant Name) will be required if E-mail 338 verifications cannot be fulfilled and if it deems to be necessary. 340 Letters and documentations can be in forms of e-documents, PDF, fax 341 however feasible to the applicants. The documents can be supplied to 342 IANA via an email message or in facsimile. 344 Requests can only be fulfilled upon verification by IANA and/or 345 subject matter experts if it deems to be necessary. 347 7.3. Removals of Private Enterprise Numbers 349 Such request does not happen often and regularly. 351 Considering the fact that there might be legacy uses by an existing 352 allocation, it is NOT recommended to remove the registration. 354 A Contact Name can request to remove the corresponding Contact 355 information if the company is no longer in operation, the Contact 356 does not wish to be listed in the IANA PEN registry and if the PEN is 357 no longer believed to be in use. The Modification procedure 358 described above SHOULD be followed. 360 Requests can only be fulfilled upon verification by IANA and/or 361 subject matter experts if it deems to be necessary. 363 IF the removal request is honoured, the entry is marked as "Reserved" 364 and annotated as "returned on yyyy-mm-dd by xxxxxxx". A future 365 update to this document can allow IANA to reallocate such returned 366 PEN, however this document doesn't allow for that. 368 7.4. Historical Assignments 370 This document will correct the missing historical assignments that 371 predates ICANN's management of the existing registry. These entries 372 will be marked as "Reserved" and annotated as "Returned on yyyy-mm- 373 dd". These numbers MAY be re-assigned when the available pool of 374 PENs runs out. 376 2187, 2188, 3513, 4164, 4565, 4600, 4913, 4999, 5099, 5144, 5201, 377 5683, 5777, 6260, 6619, 14827, 16739, 26975 379 The range from 11670 to 11769 381 8. Security Considerations 383 See the Security Considerations section in BCP 26 [RFC5226], and note 384 that improper definition and application of IANA registration 385 policies can introduce both interoperability and security issues. It 386 is critical that registration policies be considered carefully and 387 separately for each registry. Overly restrictive policies can result 388 in the lack of registration of code points and parameters that need 389 to be registered, while overly permissive policies can result in 390 inappropriate registrations. Striking the right balance is an 391 important part of document development. 393 9. References 395 9.1. Normative References 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997. 400 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 401 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 402 May 2008. 404 9.2. Informative References 406 [RFC1065] Rose, M. and K. McCloghrie, "Structure and identification 407 of management information for TCP/IP-based internets", RFC 408 1065, August 1988. 410 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 411 "Simple Network Management Protocol (SNMP)", STD 15, RFC 412 1157, May 1990. 414 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 415 for Network Management of TCP/IP-based internets:MIB-II", 416 STD 17, RFC 1213, March 1991. 418 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 419 Schoenwaelder, Ed., "Structure of Management Information 420 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 422 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 423 (PA) Protocol Compatible with Trusted Network Connect 424 (TNC)", RFC 5792, March 2010. 426 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 427 A Posture Broker (PB) Protocol Compatible with Trusted 428 Network Connect (TNC)", RFC 5793, March 2010. 430 Authors' Addresses 432 Pearl Liang 433 ICANN 434 12025 Waterfront Drive, Suite 300 435 Los Angeles, CA 90094 436 USA 438 Email: pearl.liang@icann.org 440 Alexey Melnikov 441 Isode Ltd 442 5 Castle Business Village 443 36 Station Road 444 Hampton, Middlesex TW12 2BX 445 UK 447 Email: Alexey.Melnikov@isode.com 449 David Conrad 450 CA 451 US 453 Email: drc@virtualized.org