idnits 2.17.1 draft-liang-iana-pen-05.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 (March 7, 2015) is 3330 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 427, 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: September 8, 2015 Isode Ltd 6 D. Conrad 7 ICANN 8 March 7, 2015 10 Private Enterprise Number (PEN) practices and Internet Assigned Numbers 11 Authority (IANA) registration considerations 12 draft-liang-iana-pen-05 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 8, 2015. 43 Copyright Notice 45 Copyright (c) 2015 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 Names and PENs . . . . . . . . 5 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . 9 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 9.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 A Private Enterprise Number (also known as a "PEN"), is a non- 80 negative integer, unique within the 81 iso.org.dod.internet.private.enterprise (1.3.6.1.4.1) Object 82 Identifiers (OIDs ) subtree, that can be used to reference an 83 organization ("enterprise") in protocols that require numeric values 84 instead of a human readable organization name. The 85 iso.org.dod.internet.private.enterprise OID is known as the Private 86 Enterprise Number OID. The Private Enterprise Number OID was 87 originally defined in [RFC1065]. 89 Currently, procedures for assignment of new PENs and the modification 90 of existing PENs are not clearly documented. Private Enterprise 91 Numbers are referenced in RFCs [RFC1157] [RFC1213] and [RFC2578]. 92 These documents mostly define Simple Network Management Protocol 93 (SNMP), Management Information Base (MIB) and Structure of Management 94 Information (SMI) structures. However, none of these RFCs clearly 95 describe PENs and define their registration procedures. 97 Additionally, updates to existing Private Enterprise Numbers can be 98 challenging due to the lack of clear registration requirements and 99 difficulties in validation, particularly in cases such as 100 organization name or legal ownership changes, changes in email 101 addresses of the registered PEN owner, etc. 103 This purpose of this document is to describe the basics of PENs, how 104 they are most commonly used, and to define PEN registration and 105 update procedures. 107 2. Example of use for Private Enterprise Numbers 109 PENs are frequently embedded in OIDs (Object Identifiers) , which are 110 most often used in Simple Network Management Protocol (SNMP) 111 Management Information Base (MIB) configurations. However, PENs are 112 not designed to be used exclusively for SNMP purposes, but rather 113 they can be and are used by a variety protocols and Data Manipulation 114 Languages. Examples of other uses include: 116 Distinguished Names and other components in X.509 certificates; 118 Various schema elements in X.500/LDAP directories; 120 GSS-API 122 extensions to DIAMETER 124 PA-TNC [RFC5792] and PB-TNC [RFC5793] 126 Various health-care related standards, including HL7. 128 3. Who can get a Private Enterprise Number? 130 PENs are assigned through a "First Come First Served" registration 131 policy as described in [RFC5226]. A new request can be submitted to 132 IANA by individuals or organizations in order to obtain a unique 133 value for their "enterprise". In order to facilitate appropriate 134 registration, a small amount of information is required including the 135 requesting organization (or individual's) name, the name of the 136 contact person for the PEN, and an e-mail address of the contact. In 137 some cases, users submit a program name, product, project, and random 138 abbreviation as the organization name to apply for a new 139 registration. However this should be discouraged since the program 140 name is not and should not be considered the name of the Registrant 141 (Company/Organization) as described in Section 7. 143 In other cases, applicants that already have a PEN make requests for 144 new PENs for subsidiaries claiming the subsidiaries are completely 145 independent of the parent organization, the subsidiaries are located 146 in different locations, the listed Contact person(s) are unknown or 147 unreachable, or other reasons why the subsidiaries cannot use 148 existing the existing PEN allocation. However, this does not justify 149 new allocations as the parent company is able to create sub-trees and 150 allocate the sub-numbers themselves. Before requesting additional 151 OID, IANA encourages companies to coordinate implementations of 152 multiple projects within the organization and identify the existing 153 OID assignment(s) whether those numbers have been properly 154 maintained. Nevertheless, this registry allows for large number of 155 allocations and, as of now (this version), there are approximately 156 45,000 allocations. IANA may allocate new numbers to companies that 157 are subsidiaries of existing registrations if justfication for 158 multiple allocations is provided. 160 However, joint ventures of business enterprises may request new 161 allocations if the joint venture is considered a new legal body. In 162 addition, open resource forums and individuals may request new 163 allocations under the registration requirement as describe in 164 Section 7. 166 4. Other useful things to know 168 As some examples documented on Wikipedia, the most common OIDs seen 169 "in the wild" usually belong to the private enterprise numbers 170 allocated by IANA under the 1.3.6.1.4.1 171 (iso.org.dod.internet.private.enterprise) tree. However, 172 increasingly, an OID with health care and public health informatics 173 in the United States is being used. Health Level Seven (HL7), a 174 standards-developing organization in the area of electronic health 175 care data exchange is an assigning authority at the 2.16.840.1.113883 176 (joint-iso-itu-t.country.us.organization.hl7) tree. 178 It is important to note that despite the name PENs do not necessarily 179 represent a manufacturer or Vendor ID. For example they can 180 represent organizations and even independent developers. 182 The registrant of a Private Enterprise Number can create sub-trees by 183 appending a "." along with unique numbers at the end of their PEN, 184 i.e. to perform its own sub-allocations. For example, for LDAP, the 185 registrant of PEN can use: 187 iso.org.dod.internet.private.enterprise..1 for LDAP Object 188 Classes 190 iso.org.dod.internet.private.enterprise..2 for LDAP attribute 191 types 192 iso.org.dod.internet.private.enterprise..3 for LDAP syntaxes 194 A particular Object class can have OID: 196 iso.org.dod.internet.private.enterprise..1.100 198 iso.org.dod.internet.private.enterprise..1.200 for subsidiaries 199 an/or divisions 201 In general any number of additional levels are permitted, for 202 example: 204 iso.org.dod.internet.private.enterprise..1.1 can be used as a 205 parent OID for all email related object classes, and 207 iso.org.dod.internet.private.enterprise..1.2 can be used for web 208 related object classes. 210 iso.org.dod.internet.private.enterprise..1.3 can be used for 211 instant messaging related object classes, etc. 213 5. Syntax for Private Enterprise Names and PENs 215 Valid information for the Registrant (Company/Organization) Name for 216 PEN registrations are normatively defined as follows: 218 o Names of Private Enterprises MUST satisfy the requirements of the 219 NicknameFreeformClass [I-D.ietf-precis-nickname]. ( Basically, this 220 means that all ASCII letters, ASCII digits, ASCII punctuation 221 characters, Unicode symbols are allowed.) 223 o Names of Private Enterprises MUST NOT begin or end with a hyphen 225 o Maximum value for PENs is hereby defined within 2**32-1 with 0 and 226 0xFFFFFF (in hex) marked as Reserved. (Note that while the original 227 PEN definition has no upper bound, this document defines the upper 228 bound, because some protocol make assumptions about how big PENs can 229 be. For example, DIAMETER [RFC3588] assumes that this value is no 230 bigger than 2**32-1.) 232 o Values marked as "Reserved" (excluding value zero) in the registry 233 can not be reassigned to a new company or individual without 234 consulting IESG assigned expert(s). Reserved entries mark entries 235 with unclear ownership. 237 o Value "Unassigned" SHOULD NOT be re-assigned unless specified 238 otherwise, i.e. when the available pool of PENs runs out. 240 6. Acknowledgements 242 The authors would like to thank Dan Romascanu, Michelle Cotton, and 243 Bert Wijnen for their contributions to this document. 245 7. IANA Considerations 247 7.1. New Private Enterprise Numbers 249 New Private Enterprise Numbers are assigned on a First Come First 250 Served basis [RFC5226] and are assigned sequentially. There is no 251 opportunity to request a particular private enterprise number. 252 (Suspected allocation requests coming from the same organization/ 253 person that try to allocate a range of PENs up to a desired number 254 will be reported to IESG.) The requester can submit an online 255 application form. Information to be included: 257 Registrant (Company/Organization) Name (REQUIRED) 259 Registrant (Company/Organization) E-mail Address (REQUIRED) 261 Registrant Postal Address (REQUIRED) 263 Registrant Phone Number (OPTIONAL) 265 Registrant Fax Number (OPTIONAL) 267 Contact Name (REQUIRED) 269 Contact E-mail Address (REQUIRED) 271 Contact Postal Address (OPTIONAL) 273 Contact Phone Number (OPTIONAL) 275 Reference (OPTIONAL) 277 Comments (OPTIONAL) 279 Registrant (Company/Organization) Name: The name of the organization 280 or individual responsible for the registration of Private Enterprise 281 Number. If the organization is a company, it should be the full 282 legal name including "Inc.", "Ltd.", etc. 284 Registrant (Company/Organization) E-mail Address: An e-mail address 285 belonging to the organization that requests the PEN. This e-mail 286 address will be publicly available in the IANA PEN Registry. The 287 E-mail address should be a valid email address and can be a role 288 account e-mail address. 290 Registrant Postal Address: The postal address/location of the 291 organization/individual requesting the PEN. This information is only 292 used by IANA for verification and will be kept private. 294 Registrant Phone: The main telephone number of the organization/ 295 individual requesting the PEN, including the country code. 297 Registrant Fax Number: The facsimile number of the organization/ 298 individual responsible for the PEN, including the country code. 300 Contact Name: Name of the individual who will be responsible for the 301 PEN on behalf of the company. This Contact person is authorized to 302 submit changes on behalf of the Registrant (Company/Organization) 303 described above. 305 Contact Postal Address: The full postal address of the individual 306 responsible the PEN, including state/province, zip/postal code, 307 country, etc. 309 Contact Phone: The telephone number (with extension where 310 appropriate) of the individual responsible for the PEN, including 311 country code. 313 Contact E-Mail Address: The e-mail address of the individual 314 responsible for the PEN. The e-mail address must be one the Contact 315 person can email confirmation from. This e-mail address will be 316 publicly available in the IANA PEN Registry. The Contact E-mail 317 Address can be the same one as the Registrant's E-mail address. 319 Reference: A document associated with the implementation of the OID 320 can be referenced with the registration. 322 Comments: Initially empty. This field can be updated upon request to 323 modify Registrant Name associated with a PEN (see Section 7.2). 325 It is recommended that a single PEN is granted per organization. 326 IANA does not expect to allocate additional PENs to the same 327 Registrants (Companies/Organizations) that have existing PEN records 328 listed in the IANA PEN registry. 330 7.2. Modification of Private Enterprise Numbers 332 Modification of existing Private Enterprise Numbers: 334 When a Company/Organization has been merged or acquired by another 335 enterprise, the Registrant (Company/Organization) Name can be 336 annotated in the registry with the new owner/name in the Comments 337 field. This requires verification in the form of emails from the 338 both existing Contact and proposed Contact, and, if it deems to be 339 necessary, official letters from the existing owner (if applicable) 340 to provide proofs of the changes to IANA. If either the existing 341 owner or Contact is obsoleted, an official letter from the proposed 342 Registrant (Company/ Organization) Name will be required and be 343 supplied to IANA for verification. Additional documentations will be 344 required subject to the conditions of the changes of the numbers in 345 questions. It is not guarantee that the request will be granted if 346 IANA does not have sufficient information to verify the changes, or 347 if there is legacy use of the PEN out in the wild. 349 All information associated with existing PEN records, excluding the 350 Registrant (Company/Organization) Name, shall be updated if the 351 information is obsoleted. (See the preceding section to update the 352 Registrant (Company/Organization) Name.) A request to update Contact 353 information associated with an existing PEN record shall be submitted 354 to IANA using an online submission. Requests can only be fulfilled 355 upon verification by IANA and/or subject matter experts. Additional 356 documentations will be required if it deems to be necessary to 357 validate the request. 359 A change to the Contact Name of existing PEN records can be made to 360 IANA in case of personnel changes, change of employment, 361 acquisitions, etc. It would be ideal that new requests shall be 362 completed by the existing Contacts for the PEN records. E-mail 363 verifications of the requested changes are required. Alternatively, 364 supplemental documentations and/or letters issued by the Company/ 365 Organization (Registrant Name) will be required if E-mail 366 verifications cannot be fulfilled and if it deems to be necessary. 368 Requests can only be fulfilled upon verification by IANA and/or 369 subject matter experts if it deems to be necessary. 371 7.3. Removals of Private Enterprise Numbers 373 Such request does not happen often and regularly. 375 Considering the fact that there might be legacy uses of any existing 376 allocation, registrations SHOULD NOT be removed. 378 A Contact Name can request to remove the corresponding Contact 379 information if the company is no longer in operation, the Contact 380 does not wish to be listed in the IANA PEN registry and if the PEN is 381 no longer believed to be in use. The Modification procedure 382 described above SHOULD be followed. 384 Requests can only be fulfilled upon verification by IANA and/or 385 subject matter experts if it deems to be necessary. 387 IF the removal request is honoured, the entry is marked as 388 "Unassigned" and annotated as "returned on yyyy-mm-dd by xxxxxxx". A 389 future update to this document can allow IANA to reallocate such 390 returned PEN, however this document doesn't allow for that. 392 7.4. Historical Assignments 394 This document will correct the missing historical assignments that 395 predates ICANN's management of the existing registry. These entries 396 will be marked as "Reserved" and annotated as "Returned on yyyy-mm- 397 dd". These numbers MAY be re-assigned when the available pool of 398 PENs runs out upon instructions from IESG (or IESG assigned 399 expert(s)). 401 2187, 2188, 3513, 4164, 4565, 4600, 4913, 4999, 5099, 5144, 5201, 402 5683, 5777, 6260, 6619, 14827, 16739, 26975 404 The range from 11670 to 11769 406 8. Security Considerations 408 See the Security Considerations section in BCP 26 [RFC5226], and note 409 that improper definition and application of IANA registration 410 policies can introduce both interoperability and security issues. It 411 is critical that registration policies be considered carefully and 412 separately for each registry. Overly restrictive policies can result 413 in the lack of registration of code points and parameters that need 414 to be registered, while overly permissive policies can result in 415 inappropriate registrations. Striking the right balance is an 416 important part of document development. 418 9. References 420 9.1. Normative References 422 [I-D.ietf-precis-nickname] 423 Saint-Andre, P., "Preparation and Comparison of 424 Nicknames", draft-ietf-precis-nickname-09 (work in 425 progress), January 2014. 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, March 1997. 430 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 431 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 432 May 2008. 434 9.2. Informative References 436 [RFC1065] Rose, M. and K. McCloghrie, "Structure and identification 437 of management information for TCP/IP-based internets", RFC 438 1065, August 1988. 440 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 441 "Simple Network Management Protocol (SNMP)", STD 15, RFC 442 1157, May 1990. 444 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 445 for Network Management of TCP/IP-based internets:MIB-II", 446 STD 17, RFC 1213, March 1991. 448 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 449 Schoenwaelder, Ed., "Structure of Management Information 450 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 452 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 453 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 455 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 456 (PA) Protocol Compatible with Trusted Network Connect 457 (TNC)", RFC 5792, March 2010. 459 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 460 A Posture Broker (PB) Protocol Compatible with Trusted 461 Network Connect (TNC)", RFC 5793, March 2010. 463 Authors' Addresses 465 Pearl Liang 466 ICANN 467 12025 Waterfront Drive, Suite 300 468 Los Angeles, CA 90094 469 USA 471 Email: pearl.liang@icann.org 472 Alexey Melnikov 473 Isode Ltd 474 5 Castle Business Village 475 36 Station Road 476 Hampton, Middlesex TW12 2BX 477 UK 479 Email: Alexey.Melnikov@isode.com 481 David Conrad 482 ICANN 483 12025 Waterfront Drive, Suite 300 484 Los Angeles, CA 90094 485 US 487 Email: drc@virtualized.org