idnits 2.17.1 draft-liang-iana-pen-02.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 (October 17, 2013) is 3844 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 395, 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: April 20, 2014 Isode Ltd 6 October 17, 2013 8 Private Enterprise Number (PEN) practices and Internet Assigned Numbers 9 Authority (IANA) registration considerations 10 draft-liang-iana-pen-02 12 Abstract 14 Private Enterprise Numbers (PENs), are assigned as part of the 15 technical protocol parameters and are frequently used in the 16 management of network connected equipment or software via SNMP-based 17 network management systems, LDAP, DIAMETER or GSS-API. This document 18 discusses what a Private Enterprise Number (PEN) is, common uses and 19 registration procedures for IANA Considerations. The registration 20 procedures include instructions and requirement for obtaining a new 21 Private Enterprise Number, modification to existing numbers and 22 removal of existing numbers. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 20, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Example of use for Private Enterprise Numbers . . . . . . . . 3 60 3. Who can get a Private Enterprise Number? . . . . . . . . . . 3 61 4. Other useful things to know . . . . . . . . . . . . . . . . . 4 62 5. Syntax for Private Enterprise Numbers . . . . . . . . . . . . 5 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 7.1. New Private Enterprise Numbers . . . . . . . . . . . . . 5 66 7.2. Modification of Private Enterprise Numbers . . . . . . . 7 67 7.3. Removals of Private Enterprise Numbers . . . . . . . . . 8 68 7.4. Historical Assignments . . . . . . . . . . . . . . . . . 8 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 9.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 A Private Enterprise Number (PEN, prefix: 78 iso.org.dod.internet.private.enterprise (1.3.6.1.4.1)) is a subtree 79 of Object Identifiers (OIDs ). The Private Enterprise Number OID was 80 originally defined in [RFC1065]. PEN is a non-negative integer that 81 can be used to reference an organization ("enterprise") in protocols 82 that require numeric values instead of a human readable organization 83 name. 85 Currently, procedures for assignment of new PENs and the modification 86 of existing PENs are not clearly documented. Private Enterprise 87 Numbers are referenced in RFCs [RFC1157] [RFC1213] and [RFC2578]. 88 These documents mostly define Simple Network Management Protocol 89 (SNMP), Management Information Base (MIB), and Structure of 90 Management Information (SMI). However, none of the above mentioned 91 RFCs clearly describe PENs and define the registration procedures. 93 Additionally, updates to existing Private Enterprise Numbers can also 94 be problematic resulting from the lack of clear registration 95 requirements. Furthermore, modification requests can be hardly 96 validated in cases like companies change names and/or legal 97 ownerships, a product was sold to another company, email addresses of 98 existing assignments were not coming from the original companies, 99 etc. 101 This purpose of this document is to describe the basics of PENs, how 102 they are most commonly used and define the registration and update 103 procedures. 105 2. Example of use for Private Enterprise Numbers 107 PENs, are frequently embedded in OIDs (Object Identifiers) , which 108 are often used in Simple Network Management Protocol (SNMP) 109 Management Information Base (MIB) configurations but PENs are 110 designed to be used by multiple protocols and DMLs. These include: 112 Distinguished Names and other components in X.509 certificates; 114 Various schema elements in X.500/LDAP directories; 116 GSS-API 118 extensions to DIAMETER 120 PA-TNC [RFC5792] and PB-TNC [RFC5793] 122 Various healthcare related standards, including HL7. 124 3. Who can get a Private Enterprise Number? 126 Private Enterprise Numbers (PENs) are assigned through First Come 127 First Served registration policy as described in [RFC5226]. A new 128 request can be submitted to IANA by individuals or organizations for 129 obtaining a unique value with a little required information that 130 includes the organization name (or the name of an individual), 131 contact name, and e-mail address. In some cases, users submit a 132 program name, product, project, and random abbreviation as the 133 organization name to apply for a new registration. However this 134 should be discouraged since the program name is not and should not be 135 considered as the name of the Registrant (Company/Organization) Name 136 as described in Section 7. 138 In other instances, applicants insist that new requests are 139 subsidiaries of some groups but the subsidiaries are completely 140 independent of the parent groups. The subsidiaries are located in 141 different locations and countries from the parent companies and such 142 the subsidiaries cannot use existing allocations. However, this does 143 not contribute to new allocations as the global companies shall be 144 able to create sub-trees and to allocate the sub-numbers globally. 146 IANA does not further allocate new numbers to companies that are 147 subsidiaries of existing registrations. 149 Further, joint ventures of business enterprises may request new 150 allocations if the joint ventures are considered new legal bodies. 151 Open resource forums may request new allocations under the 152 registration requirement as describe in Section 7. Individuals may 153 requests new allocations under the registration requirement as 154 describe in Section 7. 156 4. Other useful things to know 158 As some examples documented on Wikipedia, the most common OIDs seen 159 "in the wild" usually belong to the private enterprise numbers 160 allocated by IANA under the 1.3.6.1.4.1 161 (iso.org.dod.internet.private.enterprise) arc. Increasingly used 162 form of OID is in the area of health care and public health 163 informatics in the United States. Health Level Seven (HL7), a 164 standards-developing organization in the area of electronic health 165 care data exchange, is an assigning authority at the 166 2.16.840.1.113883 (joint-iso-itu-t.country.us.organization.hl7) node. 168 Important to note that PENs are not always representing manufacturer 169 ID or Vendor ID. 171 Additional sub-trees of the existing arc 172 iso.org.dod.internet.private.enterprise. can be created by an 173 administrator of the arc when the Registrant (Company) needs 174 additional OIDs. In such cases there is no need to request multiple 175 PENs. Note that IANA does not manage allocations of sub-OIDs below a 176 iso.org.dod.internet.private.enterprise. OID, so it doesn't need 177 to be notified about suballocations. 179 The owner of a Private Enterprise Number can append any number of 180 numbers at the end (i.e. to perform its own sub-allocations). For 181 example, for LDAP, one can use: 183 iso.org.dod.internet.private.enterprise..1 for LDAP Object 184 Classes 186 iso.org.dod.internet.private.enterprise..2 for LDAP attribute 187 types 189 iso.org.dod.internet.private.enterprise..3 for LDAP syntaxes 191 A particular Object class can have OID: 193 iso.org.dod.internet.private.enterprise..1.100 194 iso.org.dod.internet.private.enterprise..1.200 for subsidiaries 195 an/or divisions 197 But in general any number of additional levels are permitted, for 198 example: 200 iso.org.dod.internet.private.enterprise..1.1 can be used as a 201 parent OID for all email related object classes, and 203 iso.org.dod.internet.private.enterprise..1.2 can be used for web 204 related object classes, etc. 206 5. Syntax for Private Enterprise Numbers 208 Valid information for the Registrant (Company/Organization) Name for 209 registrations are hereby normatively defined as follows: 211 o Maximum value for PENs is hereby defined within 2**32-1 with 0 and 212 0xFFFFFF (in hex) marked as Reserved. 214 o TBD: Subset of ASCII character (at least ALPHA, DIGIT and "-", SP) 216 o TBD: Special characters (Use LetterDigits from draft-ietf-precis- 217 framework?) 219 o MUST NOT begin or end with a hyphen 221 o Values "Reserved" MUST NOT be allocated 223 o Value "Unassigned" SHOULD NOT be re-assigned unless specified 224 otherwise, i.e. when the available pool of PENs runs out. 226 6. Acknowledgements 228 The authors would like to thank Dan Romascanu, Michelle Cotton, and 229 Bert Wijnen for their contributions to this document. 231 7. IANA Considerations 233 7.1. New Private Enterprise Numbers 235 New Private Enterprise Numbers are assigned on a First Come First 236 Served basis [RFC5226] and are assigned sequentially. There is no 237 opportunity to request a particular private enterprise number. The 238 requester can submit an online application form. Information to be 239 included: 241 Registrant (Company/Organization) Name (REQUIRED) 242 Registrant (Company/Organization) E-mail Address (REQUIRED) 244 Registrant Postal Address (REQUIRED) 246 Registrant Phone Number (Optional) 248 Registrant Fax Number (OPTIONAL) 250 Contact Name (REQUIRED) 252 Contact E-mail Address (REQUIRED) 254 Contact Postal Address (OPTIONAL) 256 Contact Phone Number (OPTIONAL) 258 Reference (OPTIONAL) 260 Registrant (Company/Organization) Name: The name of the organization 261 or individual responsible for the registration of Private Enterprise 262 Number. If the organization is a company, it should be the full 263 legal name including "Inc.", "Ltd.", etc. 265 Registrant (Company/Organization) E-mail Address: The e-mail address 266 of the organization that requests the PEN. This e-mail address will 267 be publicly available in the IANA PEN Registry. The E-mail address 268 should be a valid email address and can be a role account e-mail 269 address. 271 Registrant Postal Address: The full postal address of the 272 organization/individual requesting the PEN, including state/province, 273 zip/postal code, country, etc. 275 Registrant Phone: The main telephone number of the organization/ 276 individual requesting the PEN, including the country code. 278 Registrant Fax Number: The facsimile number of the organization/ 279 individual responsible for the PEN, including the country code. 281 Contact Name: The full name of the individual who will be responsible 282 for the PEN on behalf of the company. 284 Contact Postal Address: The full postal address of the individual 285 responsible the PEN, including state/province, zip/postal code, 286 country, etc. 288 Contact Phone: The telephone number (with extension where 289 appropriate) of the individual responsible for the PEN, including 290 country code. 292 Contact E-Mail Address: The e-mail address of the individual 293 responsible for the PEN. The e-mail address must be one the Contact 294 person can email confirmation from. This e-mail address will be 295 publicly available in the IANA PEN Registry. The Contact E-mail 296 Address can be the same one as the Registrant's E-mail address. 298 Reference: A document associated with the implementation of the OID 299 can be referenced with the registration. 301 It is recommended that a single PEN is granted per organization. 302 IANA does not expect to allocate additional PENs to the same 303 Registrants (Companies/Organizations) that have existing PEN records 304 listed in the IANA PEN registry. 306 7.2. Modification of Private Enterprise Numbers 308 Modification of existing Private Enterprise Numbers: 310 Registrant (Company/Organization) Name can never be changed. However 311 if the Company/Organization has been merged or acquired by another 312 enterprise, the Registrant Name can be annotated in the registry with 313 the new owner. Note that such annotations would require emails from 314 the both existing Contact and proposed Contact, and, if it deems to 315 be necessary, official letters from the existing owner (if 316 applicable) to provide proofs of the changes to IANA. If either the 317 existing owner or Contact is obsoleted, an official letter from the 318 proposed Registrant (Company/Organization) Name will be required and 319 be supplied to IANA for verifications. Additional documentations 320 will be required subject to the conditions of the changes of the 321 numbers in questions. It is not guarantee that the request will be 322 granted if IANA does not have sufficient information to verify the 323 changes, or if there is legacy use of the PEN out in the wild. 325 All information associated with existing PEN records, excluding the 326 Registrant (Company/Organization) Name, shall be updated if the 327 information is obsoleted. (See the preceding section to update the 328 Registrant (Company/Organization) Name.) A request to update Contact 329 information associated with an existing PEN record shall be submitted 330 to IANA using an online submission. Requests can only be fulfilled 331 upon verification by IANA and/or subject matter experts. Additional 332 documentations will be required if it deems to be necessary to 333 validate the request. 335 A change to the Contact Name of existing PEN records can be made to 336 IANA in case of personnel changes, change of employment, 337 acquisitions, etc. It would be ideal that new requests shall be 338 completed by the existing Contacts for the PEN records. E-mail 339 verifications of the requested changes are required. Alternatively, 340 supplemental documentations and/or letters issued by the Company/ 341 Organization (Registrant Name) will be required if E-mail 342 verifications cannot be fulfilled and if it deems to be necessary. 344 Letters and documentations can be in forms of e-documents, PDF, fax 345 however feasible to the applicants. The documents can be supplied to 346 IANA via an email message or in facsimile. 348 Requests can only be fulfilled upon verification by IANA and/or 349 subject matter experts if it deems to be necessary. 351 7.3. Removals of Private Enterprise Numbers 353 Such request does not happen often and regularly. 355 Considering the fact that there might be legacy uses by an existing 356 allocation, it is NOT recommended to remove the registration. 358 A Contact Name can request to remove the corresponding Contact 359 information if the company is no longer in operation, the Contact 360 does not wish to be listed in the IANA PEN registry and if the PEN is 361 no longer believed to be in use. The Modification procedure 362 described above SHOULD be followed. 364 Requests can only be fulfilled upon verification by IANA and/or 365 subject matter experts if it deems to be necessary. 367 IF the removal request is honoured, the entry is marked as "Reserved" 368 and annotated as "returned on yyyy-mm-dd by xxxxxxx". A future 369 update to this document can allow IANA to reallocate such returned 370 PEN, however this document doesn't allow for that. 372 7.4. Historical Assignments 374 This document will correct the missing historical assignments that 375 predates ICANN's management of the existing registry. 2187, 2188, 376 3513, 4164, 4565, 4600, 4913, 4999, 5099, 5144, 5201, 5683, 5777, 377 6260, 6619, 14827, and the range from 11670 to 11769, 16739, 26975 379 8. Security Considerations 381 See the Security Considerations section in BCP 26 [RFC5226], and note 382 that improper definition and application of IANA registration 383 policies can introduce both interoperability and security issues. It 384 is critical that registration policies be considered carefully and 385 separately for each registry. Overly restrictive policies can result 386 in the lack of registration of code points and parameters that need 387 to be registered, while overly permissive policies can result in 388 inappropriate registrations. Striking the right balance is an 389 important part of document development. 391 9. References 393 9.1. Normative References 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, March 1997. 398 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 399 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 400 May 2008. 402 9.2. Informative References 404 [RFC1065] Rose, M. and K. McCloghrie, "Structure and identification 405 of management information for TCP/IP-based internets", RFC 406 1065, August 1988. 408 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 409 "Simple Network Management Protocol (SNMP)", STD 15, RFC 410 1157, May 1990. 412 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 413 for Network Management of TCP/IP-based internets:MIB-II", 414 STD 17, RFC 1213, March 1991. 416 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 417 Schoenwaelder, Ed., "Structure of Management Information 418 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 420 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 421 (PA) Protocol Compatible with Trusted Network Connect 422 (TNC)", RFC 5792, March 2010. 424 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 425 A Posture Broker (PB) Protocol Compatible with Trusted 426 Network Connect (TNC)", RFC 5793, March 2010. 428 Authors' Addresses 429 Pearl Liang 430 ICANN 431 12025 Waterfront Drive, Suite 300 432 Los Angeles, CA 90094 433 USA 435 Email: pearl.liang@icann.org 437 Alexey Melnikov 438 Isode Ltd 439 5 Castle Business Village 440 36 Station Road 441 Hampton, Middlesex TW12 2BX 442 UK 444 Email: Alexey.Melnikov@isode.com