Private Enterprise Number (PEN) practices and registration procedures
draft-liang-iana-pen-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Pearl Liang , Alexey Melnikov | ||
| Last updated | 2012-03-05 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liang-iana-pen-00
Network Working Group P. Liang
Internet-Draft ICANN
Intended status: Informational A. Melnikov
Expires: September 6, 2012 Isode Ltd
March 5, 2012
Private Enterprise Number (PEN) practices and registration procedures
draft-liang-iana-pen-00
Abstract
Private Enterprise Numbers (PENs), are assigned as part of the
technical protocol parameters and are frequently used 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 and
registration procedures. The registration procedures include
instructions for obtaining a new Private Enterprise Number,
modification to existing numbers and removal.
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 September 6, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Liang & Melnikov Expires September 6, 2012 [Page 1]
Internet-Draft PEN v.0.2 March 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Example of use for Private Enterprise Numbers . . . . . . . . . 3
3. Who can get a Private Enterprise Number? . . . . . . . . . . . 4
4. Other useful things to know . . . . . . . . . . . . . . . . . . 4
5. Syntax for Private Enterprise Numbers . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Liang & Melnikov Expires September 6, 2012 [Page 2]
Internet-Draft PEN v.0.2 March 2012
1. Introduction
A Private Enterprise Number (PEN) is a non-negative integer that can
be used to reference an organization ("enterprise") in protocols that
require numeric values instead of a human readable organization name.
Currently, the assignment procedures for assignment of new PENs and
the modification of existing PENs is 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). However, none of the above mentioned
RFCs clearly describe PENs and define the registration procedures.
Additionally, updates to existing Private Enterprise Numbers can also
be problematic resulting from the lack of clear registration
requirements. Historical assignments that pre-exist ICANN's
management of the registry, contains inaccurate information. As
result of that, ICANN/IANA has no reliable records of the historical
registrations to verify new information against the original
requests. Furthermore, modification requests can be hardly validated
in cases like companies change names and/or legal ownerships, a
product was sold to another company, email addresses of existing
assignments were not coming from the original companies, etc.
This purpose of this document is to describe the basics of PENs, how
they are most commonly used and define the registration and update
procedures.
2. Example of use for Private Enterprise Numbers
PENs, are frequently embedded in OIDs (Object Identifiers) , which
are often used in Simple Network Management Protocol (SNMP)
Management Information Base (MIB) configurations but are also
commonly used in a number of other protocols. These 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.
Liang & Melnikov Expires September 6, 2012 [Page 3]
Internet-Draft PEN v.0.2 March 2012
3. Who can get a Private Enterprise Number?
Private Enterprise Numbers (PENs) are assigned through First Come
First Served registration policy as described in [RFC5226]. A new
request can be submitted to IANA by individuals or organizations for
obtaining a unique value with a little required information that
includes the organization name (or the name of an individual),
contact name, and e-mail address. 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 as the name of the Registrant (Company/Organization) Name
as described in Section 7 below.
In other instances, applicants insist that new requests are
subsidiaries of some groups but the subsidiaries are completely
independent of the parent groups. The subsidiaries are located in
different locations and countries from the parent companies and such
the subsidiaries cannot use existing allocations. However, this does
not contribute to new allocations as the global companies shall be
able to create sub-trees and to allocate the sub-numbers globally.
IANA does not further allocate new numbers to companies that are
subsidiaries of existing registrations.
Further, joint ventures of business enterprises may request new
allocations if the joint ventures are considered new legal bodies.
Open resource forums may request new allocations under the
registration requirement as describe in Section 7 (IANA
Considerations). Individuals may requests new allocations under the
registration requirement as describe in Section 7 (IANA
Considerations).
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) arc. Increasingly used
form of OID is in the area of health care and public health
informatics in the United States. 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) node.
Additional sub-trees of the existing arc
iso.org.dod.internet.private.enterprise.<PEN> can be created by an
administrator of the arc when the Registrant (Company) needs
Liang & Melnikov Expires September 6, 2012 [Page 4]
Internet-Draft PEN v.0.2 March 2012
additional OIDs. In such cases there is no need to request multiple
PENs. Note that IANA does not manage allocations of sub-OIDs below a
iso.org.dod.internet.private.enterprise.<PEN> OID, so it doesn't need
to be notified about suballocations.
The owner of a Private Enterprise Number can append any number of
numbers at the end (i.e. to perform its own sub-allocations). For
example, for LDAP, one 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
But 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, etc.
5. Syntax for Private Enterprise Numbers
Valid information for registrations are hereby normatively defined as
follows:
o MUST NOT begin or end with a hyphen
o TBD: Subset of ASCII character (at least ALPHA, DIGIT and "-")
o TBD: Special characters (At least Unicode letters?)
Liang & Melnikov Expires September 6, 2012 [Page 5]
Internet-Draft PEN v.0.2 March 2012
6. Acknowledgements
The authors would like to thank Dan Romascanu, Michelle Cotton, and
(TBA if needed) for their contributions to this document.
7. IANA Considerations
o 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 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)
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 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.
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
Liang & Melnikov Expires September 6, 2012 [Page 6]
Internet-Draft PEN v.0.2 March 2012
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: The e-mail address of the individual responsible for
the PEN. This e-mail address will be publicly available in the IANA
PEN Registry.
A single PEN is granted per organization. IANA does not expect to
allocate additional PENs to Registrants (Companies/Organizations)
that have existing PEN records listed in the IANA PEN registry.
o Modification of existing Private Enterprise Numbers:
Registrant (Company/Organization) Name can never be changed. However
if the Company/Organization has been merged or acquired by another
enterprise, the Registrant 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/or official
letters from the existing owner (if applicable) to provide proofs of
the changes. If either the existing owner or Contact is obsoleted,
an official letter from the proposed Registrant (Company/
Organization) Name will be required. Additional documentations will
be required subject to the conditions of the changes of the numbers
in questions.
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
information associated with an existing PEN record shall be submitted
to 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
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
Liang & Melnikov Expires September 6, 2012 [Page 7]
Internet-Draft PEN v.0.2 March 2012
verifications cannot be fulfilled and if it deems to be necessary.
Letters and documentations can be in forms of e-documents, PDF, fax
however feasible to the applicants. The documents can be supplied to
IANA via an email message or in facsimile.
Requests can only be fulfilled upon verification by IANA and/or
subject matter experts.
o Removal of Private Enterprise Numbers:
A Contact Name can request to remove the corresponding PEN allocation
if the resource is no longer in used or the resource does not meet
the needs. (In a case when the Contact Name is no longer with the
Company/Organization, the Modification procedure described above MUST
be used first.) Such request does not happen often and regularly.
Requests can only be fulfilled upon verification by IANA and/or
subject matter experts.
If the removal request is honoured, the entry is marked as
"Unassigned" and can be reallocated by IANA later unless specified
otherwise, i.e. by marking the entry as "Reserved".
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
[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.
Liang & Melnikov Expires September 6, 2012 [Page 8]
Internet-Draft PEN v.0.2 March 2012
9.2. Informative References
[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.
[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
4676 Admiralty Way Suite 330
Marina del Rey, CA 90232
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
Liang & Melnikov Expires September 6, 2012 [Page 9]