idnits 2.17.1 draft-liang-iana-pen-04.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 10 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 (July 4, 2014) is 3577 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 409, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-precis-nickname-09 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 1065 (Obsoleted by RFC 1155) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 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: January 5, 2015 Isode Ltd 6 D. Conrad 8 July 4, 2014 10 Private Enterprise Number (PEN) practices and Internet Assigned Numbers 11 Authority (IANA) registration considerations 12 draft-liang-iana-pen-04 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 January 5, 2015. 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 . . . . . . . . . . . . . . . . . . . . . 6 67 7.1. New Private Enterprise Numbers . . . . . . . . . . . . . 6 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 despite the name PENs do not necessarily 171 represent a manufacturer or Vendor ID. For example they can 172 represent organizations and even independent developers. 174 The registrant of a Private Enterprise Number can create sub-trees by 175 appending a "." along with unique numbers at the end of their PEN, 176 i.e. to perform its own sub-allocations. For example, for LDAP, the 177 registrant of PEN can use: 179 iso.org.dod.internet.private.enterprise..1 for LDAP Object 180 Classes 182 iso.org.dod.internet.private.enterprise..2 for LDAP attribute 183 types 185 iso.org.dod.internet.private.enterprise..3 for LDAP syntaxes 187 A particular Object class can have OID: 189 iso.org.dod.internet.private.enterprise..1.100 190 iso.org.dod.internet.private.enterprise..1.200 for subsidiaries 191 an/or divisions 193 In general any number of additional levels are permitted, for 194 example: 196 iso.org.dod.internet.private.enterprise..1.1 can be used as a 197 parent OID for all email related object classes, and 199 iso.org.dod.internet.private.enterprise..1.2 can be used for web 200 related object classes. 202 iso.org.dod.internet.private.enterprise..1.3 can be used for 203 instant messaging related object classes, etc. 205 5. Syntax for Private Enterprise Numbers 207 Valid information for the Registrant (Company/Organization) Name for 208 PEN registrations are normatively defined as follows: 210 o Names of Private Enterprises MUST satisfy the requirements of the 211 NicknameFreeformClass [I-D.ietf-precis-nickname]. ( Basically, this 212 means that all ASCII letters, ASCII digits, ASCII punctuation 213 characters, Unicode symbols are allowed.) 215 o Names of Private Enterprises MUST NOT begin or end with a hyphen 217 o Maximum value for PENs is hereby defined within 2**32-1 with 0 and 218 0xFFFFFF (in hex) marked as Reserved. (Note that the upper bound is 219 selected, because some protocol make assumptions about how big PENs 220 can be. For example, DIAMETER [RFC3588] assumes that this value is 221 no bigger than 2**32-1.) 223 o Values marked as "Reserved" excluding value zero in the registry 224 MUST NOT be allocated. IESG expert(s) shall be consulted to re- 225 assign the "Reserved" number to a new company or individual. 226 Reserved entries mark entries with unclear ownership. 228 o Value "Unassigned" SHOULD NOT be re-assigned unless specified 229 otherwise, i.e. when the available pool of PENs runs out. 231 6. Acknowledgements 233 The authors would like to thank Dan Romascanu, Michelle Cotton, and 234 Bert Wijnen for their contributions to this document. 236 7. IANA Considerations 238 7.1. New Private Enterprise Numbers 240 New Private Enterprise Numbers are assigned on a First Come First 241 Served basis [RFC5226] and are assigned sequentially. There is no 242 opportunity to request a particular private enterprise number. The 243 requester can submit an online application form. Information to be 244 included: 246 Registrant (Company/Organization) Name (REQUIRED) 248 Registrant (Company/Organization) E-mail Address (REQUIRED) 250 Registrant Postal Address (REQUIRED) 252 Registrant Phone Number (Optional) 254 Registrant Fax Number (OPTIONAL) 256 Contact Name (REQUIRED) 258 Contact E-mail Address (REQUIRED) 260 Contact Postal Address (OPTIONAL) 262 Contact Phone Number (OPTIONAL) 264 Reference (OPTIONAL) 266 Registrant (Company/Organization) Name: The name of the organization 267 or individual responsible for the registration of Private Enterprise 268 Number. If the organization is a company, it should be the full 269 legal name including "Inc.", "Ltd.", etc. 271 Registrant (Company/Organization) E-mail Address: The e-mail address 272 of the organization that requests the PEN. This e-mail address will 273 be publicly available in the IANA PEN Registry. The E-mail address 274 should be a valid email address and can be a role account e-mail 275 address. 277 Registrant Postal Address: The full postal address of the 278 organization/individual requesting the PEN, including state/province, 279 zip/postal code, country, etc. 281 Registrant Phone: The main telephone number of the organization/ 282 individual requesting the PEN, including the country code. 284 Registrant Fax Number: The facsimile number of the organization/ 285 individual responsible for the PEN, including the country code. 287 Contact Name: The full name of the individual who will be responsible 288 for the PEN on behalf of the company. 290 Contact Postal Address: The full postal address of the individual 291 responsible the PEN, including state/province, zip/postal code, 292 country, etc. 294 Contact Phone: The telephone number (with extension where 295 appropriate) of the individual responsible for the PEN, including 296 country code. 298 Contact E-Mail Address: The e-mail address of the individual 299 responsible for the PEN. The e-mail address must be one the Contact 300 person can email confirmation from. This e-mail address will be 301 publicly available in the IANA PEN Registry. The Contact E-mail 302 Address can be the same one as the Registrant's E-mail address. 304 Reference: A document associated with the implementation of the OID 305 can be referenced with the registration. 307 It is recommended that a single PEN is granted per organization. 308 IANA does not expect to allocate additional PENs to the same 309 Registrants (Companies/Organizations) that have existing PEN records 310 listed in the IANA PEN registry. 312 7.2. Modification of Private Enterprise Numbers 314 Modification of existing Private Enterprise Numbers: 316 Registrant (Company/Organization) Name can be modified with 317 verification. When a Company/Organization has been merged or 318 acquired by another enterprise, the Registrant (Company/Organization) 319 Name can be annotated in the registry with the new owner. Note that 320 such annotations would require emails from the both existing Contact 321 and proposed Contact, and, if it deems to be necessary, official 322 letters from the existing owner (if applicable) to provide proofs of 323 the changes to IANA. If either the existing owner or Contact is 324 obsoleted, an official letter from the proposed Registrant (Company/ 325 Organization) Name will be required and be supplied to IANA for 326 verifications. Additional documentations will be required subject to 327 the conditions of the changes of the numbers in questions. It is not 328 guarantee that the request will be granted if IANA does not have 329 sufficient information to verify the changes, or if there is legacy 330 use of the PEN out in the wild. 332 All information associated with existing PEN records, excluding the 333 Registrant (Company/Organization) Name, shall be updated if the 334 information is obsoleted. (See the preceding section to update the 335 Registrant (Company/Organization) Name.) A request to update Contact 336 information associated with an existing PEN record shall be submitted 337 to IANA using an online submission. Requests can only be fulfilled 338 upon verification by IANA and/or subject matter experts. Additional 339 documentations will be required if it deems to be necessary to 340 validate the request. 342 A change to the Contact Name of existing PEN records can be made to 343 IANA in case of personnel changes, change of employment, 344 acquisitions, etc. It would be ideal that new requests shall be 345 completed by the existing Contacts for the PEN records. E-mail 346 verifications of the requested changes are required. Alternatively, 347 supplemental documentations and/or letters issued by the Company/ 348 Organization (Registrant Name) will be required if E-mail 349 verifications cannot be fulfilled and if it deems to be necessary. 351 Requests can only be fulfilled upon verification by IANA and/or 352 subject matter experts if it deems to be necessary. 354 7.3. Removals of Private Enterprise Numbers 356 Such request does not happen often and regularly. 358 Considering the fact that there might be legacy uses by an existing 359 allocation, it is NOT recommended to remove the registration. 361 A Contact Name can request to remove the corresponding Contact 362 information if the company is no longer in operation, the Contact 363 does not wish to be listed in the IANA PEN registry and if the PEN is 364 no longer believed to be in use. The Modification procedure 365 described above SHOULD be followed. 367 Requests can only be fulfilled upon verification by IANA and/or 368 subject matter experts if it deems to be necessary. 370 IF the removal request is honoured, the entry is marked as 371 "Unassigned" and annotated as "returned on yyyy-mm-dd by xxxxxxx". A 372 future update to this document can allow IANA to reallocate such 373 returned PEN, however this document doesn't allow for that. 375 7.4. Historical Assignments 377 This document will correct the missing historical assignments that 378 predates ICANN's management of the existing registry. These entries 379 will be marked as "Reserved" and annotated as "Returned on yyyy-mm- 380 dd". These numbers MAY be re-assigned when the available pool of 381 PENs runs out. 383 2187, 2188, 3513, 4164, 4565, 4600, 4913, 4999, 5099, 5144, 5201, 384 5683, 5777, 6260, 6619, 14827, 16739, 26975 386 The range from 11670 to 11769 388 8. Security Considerations 390 See the Security Considerations section in BCP 26 [RFC5226], and note 391 that improper definition and application of IANA registration 392 policies can introduce both interoperability and security issues. It 393 is critical that registration policies be considered carefully and 394 separately for each registry. Overly restrictive policies can result 395 in the lack of registration of code points and parameters that need 396 to be registered, while overly permissive policies can result in 397 inappropriate registrations. Striking the right balance is an 398 important part of document development. 400 9. References 402 9.1. Normative References 404 [I-D.ietf-precis-nickname] 405 Saint-Andre, P., "Preparation and Comparison of 406 Nicknames", draft-ietf-precis-nickname-09 (work in 407 progress), January 2014. 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 413 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 414 May 2008. 416 9.2. Informative References 418 [RFC1065] Rose, M. and K. McCloghrie, "Structure and identification 419 of management information for TCP/IP-based internets", RFC 420 1065, August 1988. 422 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 423 "Simple Network Management Protocol (SNMP)", STD 15, RFC 424 1157, May 1990. 426 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 427 for Network Management of TCP/IP-based internets:MIB-II", 428 STD 17, RFC 1213, March 1991. 430 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 431 Schoenwaelder, Ed., "Structure of Management Information 432 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 434 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 435 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 437 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 438 (PA) Protocol Compatible with Trusted Network Connect 439 (TNC)", RFC 5792, March 2010. 441 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 442 A Posture Broker (PB) Protocol Compatible with Trusted 443 Network Connect (TNC)", RFC 5793, March 2010. 445 Authors' Addresses 447 Pearl Liang 448 ICANN 449 12025 Waterfront Drive, Suite 300 450 Los Angeles, CA 90094 451 USA 453 Email: pearl.liang@icann.org 455 Alexey Melnikov 456 Isode Ltd 457 5 Castle Business Village 458 36 Station Road 459 Hampton, Middlesex TW12 2BX 460 UK 462 Email: Alexey.Melnikov@isode.com 464 David Conrad 465 CA 466 US 468 Email: drc@virtualized.org