Internet DRAFT - draft-liang-iana-pen
draft-liang-iana-pen
Network Working Group P. Liang
Internet-Draft ICANN
Intended status: Informational A. Melnikov
Expires: January 7, 2016 Isode Ltd
D. Conrad
ICANN
July 6, 2015
Private Enterprise Number (PEN) practices and Internet Assigned Numbers
Authority (IANA) registration considerations
draft-liang-iana-pen-06
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 7, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Liang, et al. Expires January 7, 2016 [Page 1]
Internet-Draft IANA PEN v2.0 July 2015
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. Introduction to Private Enterprise Numbers . . . . . . . . . 3
2.1. Various uses of PENs "in the wild" . . . . . . . . . . . 3
3. PEN Assignment . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Assignment of a New PEN . . . . . . . . . . . . . . . . . 5
3.2. Update of an Assigned PEN . . . . . . . . . . . . . . . . 7
3.3. Removals of Private Enterprise Numbers . . . . . . . . . 8
4. Registration in the Private Enterprise Number registry . . . 8
4.1. Registration of PEN . . . . . . . . . . . . . . . . . . . 8
4.2. Syntax for Private Enterprise Names and PENs . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Historical Assignments . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
A Private Enterprise Number (also known as a "PEN"), is a non-
negative integer, unique within the
iso.org.dod.internet.private.enterprise (1.3.6.1.4.1) Object
Identifiers (OIDs) subtree of the ISO Object Identifier (OID)
hierarchy. This hierarchy, jointly developed by ITU-T and ISO/IEC
was developed to name "any type of object, concept or 'thing' with a
globaly unambiguous name which requires a persistent name" (See
http://www.oid-info.com/#oid). The sub-tree for which the IETF is
the Registration Authority, originally defined in [RFC1065], is used
to allow any entity to obtain a globally unique identifier to
reference an organization ("enterprise") in protocols.
To date, the procedures for the assignment of new PENs and the
modification of assigned PENs have not been clearly documented.
Private Enterprise Numbers are referenced in RFCs [RFC1157] [RFC1213]
Liang, et al. Expires January 7, 2016 [Page 2]
Internet-Draft IANA PEN v2.0 July 2015
and [RFC2578]. These documents primarily define Simple Network
Management Protocol (SNMP), Management Information Base (MIB) and
Structure of Management Information (SMI) structures. As such, none
of these RFCs clearly describe PENs nor do they define PEN
registration procedures.
As a result of the lack of documented process, updates to assigned
PENs can be challenging. Given there are no clear registration
requirements, it can be difficult to validate change requests,
particularly in cases such as updates to organization names or legal
ownership, changes to email addresses of the registered PEN owner,
etc.
This document introduces PENs, how they are commonly used, and their
registration and update procedures.
2. Introduction to 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
Languages. There is no restriction for using private enterprise
numbers for other protocols or data models than SNMP or MIB.
If the OID is only to be used privately, then enterprise numbers are
to be used. PEN is a number under the prefix 1.3.6.1.4.1. and PEN
appears as follows:
Prefix: iso.org.dod.internet.private.enterprise.(Your node)
1.3.6.1.4.1.xxxx
IANA only manages and maintain this hierarchy tree under the IESG
guidelines. There are many other prefixes, such as 2.16.840.1113883,
1.2.840.113549.1.9.16.2.21, etc., under completely different arcs and
managed by other repositories (which might or might not be managed by
IANA). This document doesn't cover management of these other
repositories.
2.1. Various uses of PENs "in the wild"
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. Increasingly, an OID
with health care and public health informatics in the United States
is being used. Health Level Seven (HL7), a standards-developing
Liang, et al. Expires January 7, 2016 [Page 3]
Internet-Draft IANA PEN v2.0 July 2015
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 <PEN> can use:
iso.org.dod.internet.private.enterprise.<PEN>.1 for LDAP Object
Classes
iso.org.dod.internet.private.enterprise.<PEN>.2 for LDAP attribute
types
iso.org.dod.internet.private.enterprise.<PEN>.3 for LDAP syntaxes
A particular Object class can have OID:
iso.org.dod.internet.private.enterprise.<PEN>.1.100
iso.org.dod.internet.private.enterprise.<PEN>.1.200 for subsidiaries
an/or divisions
In general any number of additional levels are permitted, for
example:
iso.org.dod.internet.private.enterprise.<PEN>.1.1 can be used as a
parent OID for all email related object classes, and
iso.org.dod.internet.private.enterprise.<PEN>.1.2 can be used for web
related object classes.
iso.org.dod.internet.private.enterprise.<PEN>.1.3 can be used for
instant messaging related object classes, etc.
Below are more example uses of PENs:
Distinguished Names and other components in X.509 certificates;
Various schema elements in X.500/LDAP directories;
GSS-API
Liang, et al. Expires January 7, 2016 [Page 4]
Internet-Draft IANA PEN v2.0 July 2015
extensions to DIAMETER
PA-TNC [RFC5792] and PB-TNC [RFC5793]
Important to note that how the numbers are used is up to the various
implementers and companies building products. Neither ICANN or the
IETF can police how people use the numbers out in the wild. The
parties in question should resolve any inappropriate usage among
themselves, and ICANN and the IETF have no role in such disputes.
3. PEN Assignment
Assignments of PENs are done by the Internet Assigned Numbers
Authority (IANA). This section provides information relating to the
assignment of new PENs and the requirements associated with updating
already assigned PENs.
3.1. Assignment of a New PEN
PENs are assigned through a "First Come First Served" registration
policy as described in [RFC5226]. They are assigned sequentially.
There is no opportunity to request a particular private enterprise
number.
A PEN can be requested by individuals or organizations in order to
obtain a unique value for their "enterprise". Requests for new PENs
can be submitted via an automated form at IANA.
In order to facilitate appropriate registration, and in particular,
subsequent update of an assigned PEN, a small amount of information
is required. This information includes the name and contact
information of the requesting organization (or individual), the name
of the contact person for the PEN, and an e-mail address of the
contact.
Historically, users submit a program name, product, project, and
random abbreviation as the organization name to when applying for a
PEN. This practice is discouraged since multiple programs, product,
and/or projects can have their own sub-trees under the PEN assigned
to the organization (or individual), thus there is rarely a need for
an organization to have multiple IANA-assigned PENs.
Before requesting additional OIDs, IANA encourages the identification
of any existing OID assignment(s) to the requesting organization (or
individual) and the creation of sub-trees where possible and
appropriate. IANA may decline the allocation of new PENs to
organizations that have existing registrations unless justification
for multiple allocations is provided.
Liang, et al. Expires January 7, 2016 [Page 5]
Internet-Draft IANA PEN v2.0 July 2015
The following information will be requested for a new registration:
Registrant (Company/Organization) Name in ASCII (REQUIRED)
UTF-8 version of the Registrant (Company/Organization) Name
(OPTIONAL)
Registrant (Company/Organization) E-mail Address (REQUIRED)
Registrant Postal Address (REQUIRED)
Contact Name (REQUIRED)
Contact E-mail Address (REQUIRED)
Contact Postal Address (OPTIONAL)
Contact Phone Number (OPTIONAL)
Reference (OPTIONAL)
Comments (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.
UTF-8 version: If a UTF-8 version of the company name is available,
the requester can provide the UTF-8 name. This will be listed in the
registry.
Registrant (Company/Organization) E-mail Address: An e-mail address
belonging to 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 postal address/location of the
organization/individual requesting the PEN. This information is only
used by IANA for verification and will be kept private.
Contact Name: Name of the individual who will be responsible for the
PEN on behalf of the company. This Contact person is authorized to
submit changes on behalf of the Registrant (Company/Organization)
described above.
Liang, et al. Expires January 7, 2016 [Page 6]
Internet-Draft IANA PEN v2.0 July 2015
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.
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.
Reference: A document associated with the implementation of the OID
can be referenced with the registration.
Comments: This field will contain the old Registrant/Company Name
associated with a PEN if applicable.
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.
3.2. Update of an Assigned PEN
When a Company/Organization has been merged or acquired by another
enterprise, the Registrant (Company/Organization) Name can be
annotated in the registry. IANA will verify the requested changes,
and, if it deems to be necessary, official letters from the existing
owner might be required. 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.
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
via an automated form at IANA. 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
Liang, et al. Expires January 7, 2016 [Page 7]
Internet-Draft IANA PEN v2.0 July 2015
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.
3.3. Removals of Private Enterprise Numbers
Such request does not happen often and regularly.
Considering the fact that there might be legacy uses of any existing
allocation, registrations SHOULD NOT be removed.
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.
4. Registration in the Private Enterprise Number registry
4.1. Registration of PEN
The registry table consists of a list of the following properties:
PEN number
Registrant (Company/Organization) Name (in ASCII)
UTF-8 version of the Registrant (Company/Organization) Name
Registrant (Company/Organization) E-mail Address (REQUIRED)
Contact Name
Contact E-mail Address
Date Assigned
Date Modified
Liang, et al. Expires January 7, 2016 [Page 8]
Internet-Draft IANA PEN v2.0 July 2015
Reference
Comments
NOTE: See Section 3.1 for definition of these properties.
o Values marked as "Reserved" (excluding value zero) in the registry
can not be reassigned to a new company or individual without
consulting IESG (or expert(s) designated by IESG). 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.
4.2. Syntax for Private Enterprise Names and PENs
o UTF-8 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 while the original
PEN definition has no upper bound, this document defines the upper
bound, 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.)
5. Acknowledgements
The authors would like to thank Dan Romascanu, Michelle Cotton, and
Bert Wijnen for their contributions to this document.
6. IANA Considerations
This document requests IANA to update the PEN online template forms
both NEW and Modification as defined in sections Section 3.1 and
Section 3.2.
The PEN registry should be updated to include the information as
defined in Section 4.1.
Liang, et al. Expires January 7, 2016 [Page 9]
Internet-Draft IANA PEN v2.0 July 2015
6.1. 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-
dd" in the registry. These numbers MAY be re-assigned when the
available pool of PENs runs out upon instructions from IESG (or IESG
assigned expert(s)).
2187, 2188, 3513, 4164, 4565, 4600, 4913, 4999, 5099, 5144, 5201,
5683, 5777, 6260, 6619, 14827, 16739, 26975
The range from 11670 to 11769
7. 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.
As mentioned in a preceding section, given there are no clear
registration requirements in the past, only limited information is
recorded, significant out-of-date information is listed in the
registry, and there is no strong authentication mechanism in place,
the implications (if any) of the theft of PENs is possible. There is
a possibility that the registration data can be transferred to
someone else unintentionally.
8. References
8.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.
Liang, et al. Expires January 7, 2016 [Page 10]
Internet-Draft IANA PEN v2.0 July 2015
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
8.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.
[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
Liang, et al. Expires January 7, 2016 [Page 11]
Internet-Draft IANA PEN v2.0 July 2015
Alexey Melnikov
Isode Ltd
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
UK
Email: Alexey.Melnikov@isode.com
David Conrad
ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094
US
Email: david.conrad@icann.org
Liang, et al. Expires January 7, 2016 [Page 12]
