idnits 2.17.1 draft-liang-iana-pen-06.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 11 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 6, 2015) is 3214 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 470, 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 (~~), 6 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 7, 2016 Isode Ltd 6 D. Conrad 7 ICANN 8 July 6, 2015 10 Private Enterprise Number (PEN) practices and Internet Assigned Numbers 11 Authority (IANA) registration considerations 12 draft-liang-iana-pen-06 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 7, 2016. 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. Introduction to Private Enterprise Numbers . . . . . . . . . 3 62 2.1. Various uses of PENs "in the wild" . . . . . . . . . . . 3 63 3. PEN Assignment . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Assignment of a New PEN . . . . . . . . . . . . . . . . . 5 65 3.2. Update of an Assigned PEN . . . . . . . . . . . . . . . . 7 66 3.3. Removals of Private Enterprise Numbers . . . . . . . . . 8 67 4. Registration in the Private Enterprise Number registry . . . 8 68 4.1. Registration of PEN . . . . . . . . . . . . . . . . . . . 8 69 4.2. Syntax for Private Enterprise Names and PENs . . . . . . 9 70 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 6.1. Historical Assignments . . . . . . . . . . . . . . . . . 10 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 8.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 A Private Enterprise Number (also known as a "PEN"), is a non- 82 negative integer, unique within the 83 iso.org.dod.internet.private.enterprise (1.3.6.1.4.1) Object 84 Identifiers (OIDs) subtree of the ISO Object Identifier (OID) 85 hierarchy. This hierarchy, jointly developed by ITU-T and ISO/IEC 86 was developed to name "any type of object, concept or 'thing' with a 87 globaly unambiguous name which requires a persistent name" (See 88 http://www.oid-info.com/#oid). The sub-tree for which the IETF is 89 the Registration Authority, originally defined in [RFC1065], is used 90 to allow any entity to obtain a globally unique identifier to 91 reference an organization ("enterprise") in protocols. 93 To date, the procedures for the assignment of new PENs and the 94 modification of assigned PENs have not been clearly documented. 95 Private Enterprise Numbers are referenced in RFCs [RFC1157] [RFC1213] 96 and [RFC2578]. These documents primarily define Simple Network 97 Management Protocol (SNMP), Management Information Base (MIB) and 98 Structure of Management Information (SMI) structures. As such, none 99 of these RFCs clearly describe PENs nor do they define PEN 100 registration procedures. 102 As a result of the lack of documented process, updates to assigned 103 PENs can be challenging. Given there are no clear registration 104 requirements, it can be difficult to validate change requests, 105 particularly in cases such as updates to organization names or legal 106 ownership, changes to email addresses of the registered PEN owner, 107 etc. 109 This document introduces PENs, how they are commonly used, and their 110 registration and update procedures. 112 2. Introduction to Private Enterprise Numbers 114 PENs are frequently embedded in OIDs (Object Identifiers) , which are 115 most often used in Simple Network Management Protocol (SNMP) 116 Management Information Base (MIB) configurations. However, PENs are 117 not designed to be used exclusively for SNMP purposes, but rather 118 they can be and are used by a variety protocols and Data Manipulation 119 Languages. There is no restriction for using private enterprise 120 numbers for other protocols or data models than SNMP or MIB. 122 If the OID is only to be used privately, then enterprise numbers are 123 to be used. PEN is a number under the prefix 1.3.6.1.4.1. and PEN 124 appears as follows: 126 Prefix: iso.org.dod.internet.private.enterprise.(Your node) 127 1.3.6.1.4.1.xxxx 129 IANA only manages and maintain this hierarchy tree under the IESG 130 guidelines. There are many other prefixes, such as 2.16.840.1113883, 131 1.2.840.113549.1.9.16.2.21, etc., under completely different arcs and 132 managed by other repositories (which might or might not be managed by 133 IANA). This document doesn't cover management of these other 134 repositories. 136 2.1. Various uses of PENs "in the wild" 138 As some examples documented on Wikipedia, the most common OIDs seen 139 "in the wild" usually belong to the private enterprise numbers 140 allocated by IANA under the 1.3.6.1.4.1 141 (iso.org.dod.internet.private.enterprise) tree. Increasingly, an OID 142 with health care and public health informatics in the United States 143 is being used. Health Level Seven (HL7), a standards-developing 144 organization in the area of electronic health care data exchange is 145 an assigning authority at the 2.16.840.1.113883 (joint-iso-itu- 146 t.country.us.organization.hl7) tree. 148 It is important to note that despite the name PENs do not necessarily 149 represent a manufacturer or Vendor ID. For example they can 150 represent organizations and even independent developers. 152 The registrant of a Private Enterprise Number can create sub-trees by 153 appending a "." along with unique numbers at the end of their PEN, 154 i.e. to perform its own sub-allocations. For example, for LDAP, the 155 registrant of PEN can use: 157 iso.org.dod.internet.private.enterprise..1 for LDAP Object 158 Classes 160 iso.org.dod.internet.private.enterprise..2 for LDAP attribute 161 types 163 iso.org.dod.internet.private.enterprise..3 for LDAP syntaxes 165 A particular Object class can have OID: 167 iso.org.dod.internet.private.enterprise..1.100 169 iso.org.dod.internet.private.enterprise..1.200 for subsidiaries 170 an/or divisions 172 In general any number of additional levels are permitted, for 173 example: 175 iso.org.dod.internet.private.enterprise..1.1 can be used as a 176 parent OID for all email related object classes, and 178 iso.org.dod.internet.private.enterprise..1.2 can be used for web 179 related object classes. 181 iso.org.dod.internet.private.enterprise..1.3 can be used for 182 instant messaging related object classes, etc. 184 Below are more example uses of PENs: 186 Distinguished Names and other components in X.509 certificates; 188 Various schema elements in X.500/LDAP directories; 190 GSS-API 191 extensions to DIAMETER 193 PA-TNC [RFC5792] and PB-TNC [RFC5793] 195 Important to note that how the numbers are used is up to the various 196 implementers and companies building products. Neither ICANN or the 197 IETF can police how people use the numbers out in the wild. The 198 parties in question should resolve any inappropriate usage among 199 themselves, and ICANN and the IETF have no role in such disputes. 201 3. PEN Assignment 203 Assignments of PENs are done by the Internet Assigned Numbers 204 Authority (IANA). This section provides information relating to the 205 assignment of new PENs and the requirements associated with updating 206 already assigned PENs. 208 3.1. Assignment of a New PEN 210 PENs are assigned through a "First Come First Served" registration 211 policy as described in [RFC5226]. They are assigned sequentially. 212 There is no opportunity to request a particular private enterprise 213 number. 215 A PEN can be requested by individuals or organizations in order to 216 obtain a unique value for their "enterprise". Requests for new PENs 217 can be submitted via an automated form at IANA. 219 In order to facilitate appropriate registration, and in particular, 220 subsequent update of an assigned PEN, a small amount of information 221 is required. This information includes the name and contact 222 information of the requesting organization (or individual), the name 223 of the contact person for the PEN, and an e-mail address of the 224 contact. 226 Historically, users submit a program name, product, project, and 227 random abbreviation as the organization name to when applying for a 228 PEN. This practice is discouraged since multiple programs, product, 229 and/or projects can have their own sub-trees under the PEN assigned 230 to the organization (or individual), thus there is rarely a need for 231 an organization to have multiple IANA-assigned PENs. 233 Before requesting additional OIDs, IANA encourages the identification 234 of any existing OID assignment(s) to the requesting organization (or 235 individual) and the creation of sub-trees where possible and 236 appropriate. IANA may decline the allocation of new PENs to 237 organizations that have existing registrations unless justification 238 for multiple allocations is provided. 240 The following information will be requested for a new registration: 242 Registrant (Company/Organization) Name in ASCII (REQUIRED) 244 UTF-8 version of the Registrant (Company/Organization) Name 245 (OPTIONAL) 247 Registrant (Company/Organization) E-mail Address (REQUIRED) 249 Registrant Postal Address (REQUIRED) 251 Contact Name (REQUIRED) 253 Contact E-mail Address (REQUIRED) 255 Contact Postal Address (OPTIONAL) 257 Contact Phone Number (OPTIONAL) 259 Reference (OPTIONAL) 261 Comments (OPTIONAL) 263 Registrant (Company/Organization) Name: The name of the organization 264 or individual responsible for the registration of Private Enterprise 265 Number. If the organization is a company, it should be the full 266 legal name including "Inc.", "Ltd.", etc. 268 UTF-8 version: If a UTF-8 version of the company name is available, 269 the requester can provide the UTF-8 name. This will be listed in the 270 registry. 272 Registrant (Company/Organization) E-mail Address: An e-mail address 273 belonging to the organization that requests the PEN. This e-mail 274 address will be publicly available in the IANA PEN Registry. The 275 E-mail address should be a valid email address and can be a role 276 account e-mail address. 278 Registrant Postal Address: The postal address/location of the 279 organization/individual requesting the PEN. This information is only 280 used by IANA for verification and will be kept private. 282 Contact Name: Name of the individual who will be responsible for the 283 PEN on behalf of the company. This Contact person is authorized to 284 submit changes on behalf of the Registrant (Company/Organization) 285 described above. 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 Contact Postal Address: The full postal address of the individual 294 responsible the PEN, including state/province, zip/postal code, 295 country, etc. 297 Contact Phone: The telephone number (with extension where 298 appropriate) of the individual responsible for the PEN, including 299 country code. 301 Reference: A document associated with the implementation of the OID 302 can be referenced with the registration. 304 Comments: This field will contain the old Registrant/Company Name 305 associated with a PEN if applicable. 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 3.2. Update of an Assigned PEN 314 When a Company/Organization has been merged or acquired by another 315 enterprise, the Registrant (Company/Organization) Name can be 316 annotated in the registry. IANA will verify the requested changes, 317 and, if it deems to be necessary, official letters from the existing 318 owner might be required. It is not guarantee that the request will 319 be granted if IANA does not have sufficient information to verify the 320 changes, or if there is legacy use of the PEN out in the wild. 322 All information associated with existing PEN records, excluding the 323 Registrant (Company/Organization) Name, shall be updated if the 324 information is obsoleted. (See the preceding section to update the 325 Registrant (Company/Organization) Name.) A request to update Contact 326 information associated with an existing PEN record shall be submitted 327 via an automated form at IANA. Requests can only be fulfilled upon 328 verification by IANA and/or subject matter experts. Additional 329 documentations will be required if it deems to be necessary to 330 validate the request. 332 A change to the Contact Name of existing PEN records can be made to 333 IANA in case of personnel changes, change of employment, 334 acquisitions, etc. It would be ideal that new requests shall be 335 completed by the existing Contacts for the PEN records. E-mail 336 verifications of the requested changes are required. Alternatively, 337 supplemental documentations and/or letters issued by the Company/ 338 Organization (Registrant Name) will be required if E-mail 339 verifications cannot be fulfilled and if it deems to be necessary. 341 3.3. Removals of Private Enterprise Numbers 343 Such request does not happen often and regularly. 345 Considering the fact that there might be legacy uses of any existing 346 allocation, registrations SHOULD NOT be removed. 348 A Contact Name can request to remove the corresponding Contact 349 information if the company is no longer in operation, the Contact 350 does not wish to be listed in the IANA PEN registry and if the PEN is 351 no longer believed to be in use. The Modification procedure 352 described above SHOULD be followed. 354 Requests can only be fulfilled upon verification by IANA and/or 355 subject matter experts if it deems to be necessary. 357 IF the removal request is honoured, the entry is marked as 358 "Unassigned" and annotated as "returned on yyyy-mm-dd by xxxxxxx". A 359 future update to this document can allow IANA to reallocate such 360 returned PEN, however this document doesn't allow for that. 362 4. Registration in the Private Enterprise Number registry 364 4.1. Registration of PEN 366 The registry table consists of a list of the following properties: 368 PEN number 370 Registrant (Company/Organization) Name (in ASCII) 372 UTF-8 version of the Registrant (Company/Organization) Name 374 Registrant (Company/Organization) E-mail Address (REQUIRED) 376 Contact Name 378 Contact E-mail Address 380 Date Assigned 382 Date Modified 383 Reference 385 Comments 387 NOTE: See Section 3.1 for definition of these properties. 389 o Values marked as "Reserved" (excluding value zero) in the registry 390 can not be reassigned to a new company or individual without 391 consulting IESG (or expert(s) designated by IESG). Reserved entries 392 mark entries with unclear ownership. 394 o Value "Unassigned" SHOULD NOT be re-assigned unless specified 395 otherwise, i.e. when the available pool of PENs runs out. 397 4.2. Syntax for Private Enterprise Names and PENs 399 o UTF-8 Names of Private Enterprises MUST satisfy the requirements of 400 the NicknameFreeformClass [I-D.ietf-precis-nickname]. ( Basically, 401 this means that all ASCII letters, ASCII digits, ASCII punctuation 402 characters, Unicode symbols are allowed.) 404 o Names of Private Enterprises MUST NOT begin or end with a hyphen 406 o Maximum value for PENs is hereby defined within 2**32-1 with 0 and 407 0xFFFFFF (in hex) marked as Reserved. (Note that while the original 408 PEN definition has no upper bound, this document defines the upper 409 bound, because some protocol make assumptions about how big PENs can 410 be. For example, DIAMETER [RFC3588] assumes that this value is no 411 bigger than 2**32-1.) 413 5. Acknowledgements 415 The authors would like to thank Dan Romascanu, Michelle Cotton, and 416 Bert Wijnen for their contributions to this document. 418 6. IANA Considerations 420 This document requests IANA to update the PEN online template forms 421 both NEW and Modification as defined in sections Section 3.1 and 422 Section 3.2. 424 The PEN registry should be updated to include the information as 425 defined in Section 4.1. 427 6.1. Historical Assignments 429 This document will correct the missing historical assignments that 430 predates ICANN's management of the existing registry. These entries 431 will be marked as "Reserved" and annotated as "Returned on yyyy-mm- 432 dd" in the registry. These numbers MAY be re-assigned when the 433 available pool of PENs runs out upon instructions from IESG (or IESG 434 assigned expert(s)). 436 2187, 2188, 3513, 4164, 4565, 4600, 4913, 4999, 5099, 5144, 5201, 437 5683, 5777, 6260, 6619, 14827, 16739, 26975 439 The range from 11670 to 11769 441 7. Security Considerations 443 See the Security Considerations section in BCP 26 [RFC5226], and note 444 that improper definition and application of IANA registration 445 policies can introduce both interoperability and security issues. It 446 is critical that registration policies be considered carefully and 447 separately for each registry. Overly restrictive policies can result 448 in the lack of registration of code points and parameters that need 449 to be registered, while overly permissive policies can result in 450 inappropriate registrations. Striking the right balance is an 451 important part of document development. 453 As mentioned in a preceding section, given there are no clear 454 registration requirements in the past, only limited information is 455 recorded, significant out-of-date information is listed in the 456 registry, and there is no strong authentication mechanism in place, 457 the implications (if any) of the theft of PENs is possible. There is 458 a possibility that the registration data can be transferred to 459 someone else unintentionally. 461 8. References 463 8.1. Normative References 465 [I-D.ietf-precis-nickname] 466 Saint-Andre, P., "Preparation and Comparison of 467 Nicknames", draft-ietf-precis-nickname-09 (work in 468 progress), January 2014. 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, March 1997. 473 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 474 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 475 May 2008. 477 8.2. Informative References 479 [RFC1065] Rose, M. and K. McCloghrie, "Structure and identification 480 of management information for TCP/IP-based internets", RFC 481 1065, August 1988. 483 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 484 "Simple Network Management Protocol (SNMP)", STD 15, RFC 485 1157, May 1990. 487 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 488 for Network Management of TCP/IP-based internets:MIB-II", 489 STD 17, RFC 1213, March 1991. 491 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 492 Schoenwaelder, Ed., "Structure of Management Information 493 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 495 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 496 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 498 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 499 (PA) Protocol Compatible with Trusted Network Connect 500 (TNC)", RFC 5792, March 2010. 502 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 503 A Posture Broker (PB) Protocol Compatible with Trusted 504 Network Connect (TNC)", RFC 5793, March 2010. 506 Authors' Addresses 508 Pearl Liang 509 ICANN 510 12025 Waterfront Drive, Suite 300 511 Los Angeles, CA 90094 512 USA 514 Email: pearl.liang@icann.org 515 Alexey Melnikov 516 Isode Ltd 517 5 Castle Business Village 518 36 Station Road 519 Hampton, Middlesex TW12 2BX 520 UK 522 Email: Alexey.Melnikov@isode.com 524 David Conrad 525 ICANN 526 12025 Waterfront Drive, Suite 300 527 Los Angeles, CA 90094 528 US 530 Email: david.conrad@icann.org