Network Working Group P. Liang Internet-Draft ICANN Intended status: Informational A. Melnikov Expires: January 5, 2015 Isode Ltd D. Conrad July 4, 2014 Private Enterprise Number (PEN) practices and Internet Assigned Numbers Authority (IANA) registration considerations draft-liang-iana-pen-04 Abstract Private Enterprise Numbers (PENs) are a technical protocol parameter frequently assigned for use in the management of network connected equipment or software via SNMP-based network management systems, LDAP, DIAMETER or GSS-API. This document discusses what a Private Enterprise Number (PEN) is, common uses of PENs, and registration procedures for IANA Considerations. The registration procedures include instructions and requirements for obtaining a new Private Enterprise Number, modifying existing numbers, and the removal of existing numbers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 5, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Liang, et al. Expires January 5, 2015 [Page 1] Internet-Draft PEN v.0.2 July 2014 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Example of use for Private Enterprise Numbers . . . . . . . . 3 3. Who can get a Private Enterprise Number? . . . . . . . . . . 3 4. Other useful things to know . . . . . . . . . . . . . . . . . 4 5. Syntax for Private Enterprise Numbers . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7.1. New Private Enterprise Numbers . . . . . . . . . . . . . 6 7.2. Modification of Private Enterprise Numbers . . . . . . . 7 7.3. Removals of Private Enterprise Numbers . . . . . . . . . 8 7.4. Historical Assignments . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction A Private Enterprise Number (also known as a "PEN"), is a subtree of Object Identifiers (OIDs ) with prefix iso.org.dod.internet.private.enterprise (1.3.6.1.4.1)). The Private Enterprise Number OID was originally defined in [RFC1065]. A PEN is a non-negative integer, unique within the iso.org.dod.internet.private.enterprise subtree, that can be used to reference an organization ("enterprise") in protocols that require numeric values instead of a human readable organization name. Currently, procedures for assignment of new PENs and the modification of existing PENs are not clearly documented. Private Enterprise Numbers are referenced in RFCs [RFC1157] [RFC1213] and [RFC2578]. These documents mostly define Simple Network Management Protocol (SNMP), Management Information Base (MIB) and Structure of Management Information (SMI) structures. However, none of these RFCs clearly describe PENs and define their registration procedures. Liang, et al. Expires January 5, 2015 [Page 2] Internet-Draft PEN v.0.2 July 2014 Additionally, updates to existing Private Enterprise Numbers can be challenging due to the lack of clear registration requirements and difficulties in validation, particuarly in cases such as organization name or legal ownership changes, changes in email addresses of the registered PEN owner, etc. This purpose of this document is to describe the basics of PENs, how they are most commonly used, and to define PEN registration and update procedures. 2. Example of use for Private Enterprise Numbers PENs are frequently embedded in OIDs (Object Identifiers) , which are most often used in Simple Network Management Protocol (SNMP) Management Information Base (MIB) configurations. However, PENs are not designed to be used exclusively for SNMP purposes, but rather they can be and are used by a variety protocols and Data Manipulation Languagess. These other uses include: Distinguished Names and other components in X.509 certificates; Various schema elements in X.500/LDAP directories; GSS-API extensions to DIAMETER PA-TNC [RFC5792] and PB-TNC [RFC5793] Various healthcare related standards, including HL7. 3. Who can get a Private Enterprise Number? PENs are assigned through a "First Come First Served" registration policy as described in [RFC5226]. A new request can be submitted to IANA by individuals or organizations in order to obtain a unique value for their "enterprise". In order to facilitate appropriate registration, a small amount of information is required including the requesting organization (or individual's) name, the name of the contact person for the PEN, and an e-mail address of the contact. In some cases, users submit a program name, product, project, and random abbreviation as the organization name to apply for a new registration. However this should be discouraged since the program name is not and should not be considered the name of the Registrant (Company/Organization) as described in Section 7. In other cases, applicants that already have a PEN make requests for new PENs for subsidiaries claiming the subsidiaries are completely Liang, et al. Expires January 5, 2015 [Page 3] Internet-Draft PEN v.0.2 July 2014 independent of the parent organization, the subsidiaries are located in different locations, or other reasons why the subsidiaries cannot use existing the existing PEN allocation. However, this does not justify new allocations as the parent company is able to create sub- trees and allocate the sub-numbers themselves. IANA does not allocate new numbers to companies that are subsidiaries of existing registrations. However, joint ventures of business enterprises may request new allocations if the joint venture is considered a new legal body. In addition, open resource forums and individuals may request new allocations under the registration requirement as describe in Section 7. 4. Other useful things to know As some examples documented on Wikipedia, the most common OIDs seen "in the wild" usually belong to the private enterprise numbers allocated by IANA under the 1.3.6.1.4.1 (iso.org.dod.internet.private.enterprise) tree. However, increasingly, an OID with health care and public health informatics in the United States is being used. Health Level Seven (HL7), a standards-developing organization in the area of electronic health care data exchange is an assigning authority at the 2.16.840.1.113883 (joint-iso-itu-t.country.us.organization.hl7) tree. It is important to note that despite the name PENs do not necessarily represent a manufacturer or Vendor ID. For example they can represent organizations and even independent developers. The registrant of a Private Enterprise Number can create sub-trees by appending a "." along with unique numbers at the end of their PEN, i.e. to perform its own sub-allocations. For example, for LDAP, the registrant of PEN can use: iso.org.dod.internet.private.enterprise..1 for LDAP Object Classes iso.org.dod.internet.private.enterprise..2 for LDAP attribute types iso.org.dod.internet.private.enterprise..3 for LDAP syntaxes A particular Object class can have OID: iso.org.dod.internet.private.enterprise..1.100 Liang, et al. Expires January 5, 2015 [Page 4] Internet-Draft PEN v.0.2 July 2014 iso.org.dod.internet.private.enterprise..1.200 for subsidiaries an/or divisions In general any number of additional levels are permitted, for example: iso.org.dod.internet.private.enterprise..1.1 can be used as a parent OID for all email related object classes, and iso.org.dod.internet.private.enterprise..1.2 can be used for web related object classes. iso.org.dod.internet.private.enterprise..1.3 can be used for instant messaging related object classes, etc. 5. Syntax for Private Enterprise Numbers Valid information for the Registrant (Company/Organization) Name for PEN registrations are normatively defined as follows: o Names of Private Enterprises MUST satisfy the requirements of the NicknameFreeformClass [I-D.ietf-precis-nickname]. ( Basically, this means that all ASCII letters, ASCII digits, ASCII punctuation characters, Unicode symbols are allowed.) o Names of Private Enterprises MUST NOT begin or end with a hyphen o Maximum value for PENs is hereby defined within 2**32-1 with 0 and 0xFFFFFF (in hex) marked as Reserved. (Note that the upper bound is selected, because some protocol make assumptions about how big PENs can be. For example, DIAMETER [RFC3588] assumes that this value is no bigger than 2**32-1.) o Values marked as "Reserved" excluding value zero in the registry MUST NOT be allocated. IESG expert(s) shall be consulted to re- assign the "Reserved" number to a new company or individual. Reserved entries mark entries with unclear ownership. o Value "Unassigned" SHOULD NOT be re-assigned unless specified otherwise, i.e. when the available pool of PENs runs out. 6. Acknowledgements The authors would like to thank Dan Romascanu, Michelle Cotton, and Bert Wijnen for their contributions to this document. Liang, et al. Expires January 5, 2015 [Page 5] Internet-Draft PEN v.0.2 July 2014 7. IANA Considerations 7.1. New Private Enterprise Numbers New Private Enterprise Numbers are assigned on a First Come First Served basis [RFC5226] and are assigned sequentially. There is no opportunity to request a particular private enterprise number. The requester can submit an online application form. Information to be included: Registrant (Company/Organization) Name (REQUIRED) Registrant (Company/Organization) E-mail Address (REQUIRED) Registrant Postal Address (REQUIRED) Registrant Phone Number (Optional) Registrant Fax Number (OPTIONAL) Contact Name (REQUIRED) Contact E-mail Address (REQUIRED) Contact Postal Address (OPTIONAL) Contact Phone Number (OPTIONAL) Reference (OPTIONAL) Registrant (Company/Organization) Name: The name of the organization or individual responsible for the registration of Private Enterprise Number. If the organization is a company, it should be the full legal name including "Inc.", "Ltd.", etc. Registrant (Company/Organization) E-mail Address: The e-mail address of the organization that requests the PEN. This e-mail address will be publicly available in the IANA PEN Registry. The E-mail address should be a valid email address and can be a role account e-mail address. Registrant Postal Address: The full postal address of the organization/individual requesting the PEN, including state/province, zip/postal code, country, etc. Registrant Phone: The main telephone number of the organization/ individual requesting the PEN, including the country code. Liang, et al. Expires January 5, 2015 [Page 6] Internet-Draft PEN v.0.2 July 2014 Registrant Fax Number: The facsimile number of the organization/ individual responsible for the PEN, including the country code. Contact Name: The full name of the individual who will be responsible for the PEN on behalf of the company. Contact Postal Address: The full postal address of the individual responsible the PEN, including state/province, zip/postal code, country, etc. Contact Phone: The telephone number (with extension where appropriate) of the individual responsible for the PEN, including country code. Contact E-Mail Address: The e-mail address of the individual responsible for the PEN. The e-mail address must be one the Contact person can email confirmation from. This e-mail address will be publicly available in the IANA PEN Registry. The Contact E-mail Address can be the same one as the Registrant's E-mail address. Reference: A document associated with the implementation of the OID can be referenced with the registration. It is recommended that a single PEN is granted per organization. IANA does not expect to allocate additional PENs to the same Registrants (Companies/Organizations) that have existing PEN records listed in the IANA PEN registry. 7.2. Modification of Private Enterprise Numbers Modification of existing Private Enterprise Numbers: Registrant (Company/Organization) Name can be modified with verification. When a Company/Organization has been merged or acquired by another enterprise, the Registrant (Company/Organization) Name can be annotated in the registry with the new owner. Note that such annotations would require emails from the both existing Contact and proposed Contact, and, if it deems to be necessary, official letters from the existing owner (if applicable) to provide proofs of the changes to IANA. If either the existing owner or Contact is obsoleted, an official letter from the proposed Registrant (Company/ Organization) Name will be required and be supplied to IANA for verifications. Additional documentations will be required subject to the conditions of the changes of the numbers in questions. It is not guarantee that the request will be granted if IANA does not have sufficient information to verify the changes, or if there is legacy use of the PEN out in the wild. Liang, et al. Expires January 5, 2015 [Page 7] Internet-Draft PEN v.0.2 July 2014 All information associated with existing PEN records, excluding the Registrant (Company/Organization) Name, shall be updated if the information is obsoleted. (See the preceding section to update the Registrant (Company/Organization) Name.) A request to update Contact information associated with an existing PEN record shall be submitted to IANA using an online submission. Requests can only be fulfilled upon verification by IANA and/or subject matter experts. Additional documentations will be required if it deems to be necessary to validate the request. A change to the Contact Name of existing PEN records can be made to IANA in case of personnel changes, change of employment, acquisitions, etc. It would be ideal that new requests shall be completed by the existing Contacts for the PEN records. E-mail verifications of the requested changes are required. Alternatively, supplemental documentations and/or letters issued by the Company/ Organization (Registrant Name) will be required if E-mail verifications cannot be fulfilled and if it deems to be necessary. Requests can only be fulfilled upon verification by IANA and/or subject matter experts if it deems to be necessary. 7.3. Removals of Private Enterprise Numbers Such request does not happen often and regularly. Considering the fact that there might be legacy uses by an existing allocation, it is NOT recommended to remove the registration. A Contact Name can request to remove the corresponding Contact information if the company is no longer in operation, the Contact does not wish to be listed in the IANA PEN registry and if the PEN is no longer believed to be in use. The Modification procedure described above SHOULD be followed. Requests can only be fulfilled upon verification by IANA and/or subject matter experts if it deems to be necessary. IF the removal request is honoured, the entry is marked as "Unassigned" and annotated as "returned on yyyy-mm-dd by xxxxxxx". A future update to this document can allow IANA to reallocate such returned PEN, however this document doesn't allow for that. 7.4. Historical Assignments This document will correct the missing historical assignments that predates ICANN's management of the existing registry. These entries will be marked as "Reserved" and annotated as "Returned on yyyy-mm- Liang, et al. Expires January 5, 2015 [Page 8] Internet-Draft PEN v.0.2 July 2014 dd". These numbers MAY be re-assigned when the available pool of PENs runs out. 2187, 2188, 3513, 4164, 4565, 4600, 4913, 4999, 5099, 5144, 5201, 5683, 5777, 6260, 6619, 14827, 16739, 26975 The range from 11670 to 11769 8. Security Considerations See the Security Considerations section in BCP 26 [RFC5226], and note that improper definition and application of IANA registration policies can introduce both interoperability and security issues. It is critical that registration policies be considered carefully and separately for each registry. Overly restrictive policies can result in the lack of registration of code points and parameters that need to be registered, while overly permissive policies can result in inappropriate registrations. Striking the right balance is an important part of document development. 9. References 9.1. Normative References [I-D.ietf-precis-nickname] Saint-Andre, P., "Preparation and Comparison of Nicknames", draft-ietf-precis-nickname-09 (work in progress), January 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 9.2. Informative References [RFC1065] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/IP-based internets", RFC 1065, August 1988. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. Liang, et al. Expires January 5, 2015 [Page 9] Internet-Draft PEN v.0.2 July 2014 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB-II", STD 17, RFC 1213, March 1991. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, March 2010. [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5793, March 2010. Authors' Addresses Pearl Liang ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 USA Email: pearl.liang@icann.org Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK Email: Alexey.Melnikov@isode.com David Conrad CA US Email: drc@virtualized.org Liang, et al. Expires January 5, 2015 [Page 10]