Skip to main content

Registration Procedures for Private Enterprise Numbers (PENs)

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Michelle Cotton , Amanda Baber , Paul E. Hoffman
Last updated 2017-10-05
RFC stream (None)
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)
Network Working Group                                          M. Cotton
Internet-Draft                                                  A. Baber
Intended status: Informational                                       PTI
Expires: April 8, 2018                                        P. Hoffman
                                                         October 5, 2017

     Registration Procedures for Private Enterprise Numbers (PENs)


   This document describes how Private Enterprise Numbers (PENs) are
   registered by IANA.  It shows how to request a new PEN and how to
   request an update to a current PEN.  It also gives a brief overview
   of PEN uses.

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

   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 April 8, 2018.

Copyright Notice

   Copyright (c) 2017 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
   ( 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

Cotton, et al.            Expires April 8, 2018                 [Page 1]
Internet-Draft              PEN registration                October 2017

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Uses of PENs  . . . . . . . . . . . . . . . . . . . . . .   2
   2.  PEN Assignment  . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requesting a PEN Assignment . . . . . . . . . . . . . . .   3
     2.2.  Modifying an Existing Record  . . . . . . . . . . . . . .   4
     2.3.  Deleting a PEN Record . . . . . . . . . . . . . . . . . .   4
   3.  PEN Registry Specifics  . . . . . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Private Enterprise Numbers (PENs) are identifiers that can be used
   anywhere that an ASN.1 object identifier (OID) [ASN1] can be used.
   Originally, PENs were developed so that organizations that needed to
   identify themselves in Simple Network Management Protocol (SNMP)
   [RFC3411] Management Information Base (MIB) configurations could do
   so easily.  PENs are also useful in any application or configuration
   language that needs OIDs to identify organizations.

   The IANA Functions Operator, referred to in this document as "IANA",
   manages and maintains the PEN registry in consultation with the IESG.
   PENs are issued from an OID prefix that was assigned to IANA.  That
   OID prefix is  Using the (now archaic) notation of
   ownership names in the OID tree, that corresponds to:

   1   3   6   1        4       1

   A PEN is an OID that begins with the PEN prefix.  Thus, the OID is a PEN.

1.1.  Uses of PENs

   Once a PEN has been assigned to an organization, that organization
   can use the PEN by itself (possibly to represent the organization) or
   as the root of other OIDs associated with the organization.  For
   example, if an organization is assigned the PEN, it
   might use to identify a protocol extension and

Cotton, et al.            Expires April 8, 2018                 [Page 2]
Internet-Draft              PEN registration                October 2017

   use to identify a set of algorithms that it
   supports in a protocol.

   Neither IANA nor the IETF can control how an organization uses its
   PEN.  In fact, no one can exert such control: that is the meaning of
   "private" in "private enterprise number".  Similarly, no one can
   prevent an organization that is not the registered owner of a PEN
   from using that PEN, or any PEN, however they want.

   A very common use of PENs is to give unique identifiers in IETF
   protocols.  SNMP MIB configuration files use PENs for identifying the
   origin of values.  Some protocols that use PENs as identifiers of
   extension mechanisms include RADIUS [RFC2865], DIAMETER [RFC3588],
   Syslog [RFC5424], RSVP [RFC5284], and vCard [RFC6350].

2.  PEN Assignment

   Assignments of PENs are made by IANA, which maintains the Private
   Enterprise Number (PEN) registry.  Requests for new assignments and
   for the modification of existing assignments can be submitted by
   using the form at <>.

2.1.  Requesting a PEN Assignment

   IANA maintains the PEN registry using a "First Come First Served"
   registration policy as described in [RFC8126].  Values are generally
   assigned sequentially.

   First Come First Served registries require the identification of a
   "change controller" as described in [RFC8126].  In this registry, the
   assignee is understood to be the change controller, unless the
   requestor specifies otherwise.  The assignee may be an individual, an
   organization, a project, or some other entity.  Required information
   for registration includes the assignee name, contact person, postal
   address and email address for the contact.  The public registry
   contains only the assignee name, contact name, and contact email

   Applicants can request that a title or role be listed in the registry
   in place of a contact name, but must supply the name of an out-of-
   band contact for IANA's internal records.

   ASCII text submitted for registration as part of a name or contact
   field can be accompanied by non-ASCII text in parentheses.

   Parties may register more than one PEN, but in most cases it is
   probably more appropriate to obtain a sub-assignment of the existing

Cotton, et al.            Expires April 8, 2018                 [Page 3]
Internet-Draft              PEN registration                October 2017

   registration.  Sub-assignments are maintained by the assignee and are
   not to be reported to IANA.

   IANA may refuse to process abusive requests.  However, any such
   refusal can be appealed to the IESG.

2.2.  Modifying an Existing Record

   Assignees can request the modification of any of the information
   associated with a registration, including the name of the assignee.
   IANA will ask any existing or proposed contacts to confirm the
   request.  Additional documentation may be required, particularly if
   the original contact is unavailable.

2.3.  Deleting a PEN Record

   If necessary, an assignee can ask IANA to delete a registration.
   Values associated with deleted registrations will not become
   available for re-assignment until all other unassigned values have
   been exhausted.

3.  PEN Registry Specifics

   The range for values after the PEN prefix is 0 to 2**32-1.  The
   values 0 and 4294967295 (2**32-1) are reserved.  Note that while the
   original PEN definition had no upper bound for the value after the
   PEN prefix, there is now an upper bound due to some IETF protocols
   limiting the size of that value.  For example, DIAMETER [RFC3588]
   limits the value to 2**32-1.

   There is a PEN number, 32473, reserved for use as an example in
   documentation.  This reservation is described in [RFC5612].

   Values in the registry that have unclear ownership are marked
   "Reserved".  These values will not be reassigned to a new company or
   individual without consulting the IESG.

   The PEN registry has some missing assignments.  These numbers will be
   available for assignment, but will only be assigned with the
   permission of the IESG.  At the time of publication of this document,
   the list of missing assignments is: 2187, 2188, 3513, 4164, 4565,
   4600, 4913, 4999, 5099, 5144, 5201, 5683, 5777, 6260, 6619, 14827,
   16739, 26975 and the range from 11670 to 11769.

Cotton, et al.            Expires April 8, 2018                 [Page 4]
Internet-Draft              PEN registration                October 2017

4.  IANA Considerations

   This entire document consists of considerations for IANA and for its
   customers who want to apply for, modify, or delete a PEN.

5.  Security Considerations

   Registering PENs does not introduce any significant security

   There is no cryptographic binding of a registrant in the PEN registry
   and the PEN(s) assigned to them.  Thus, the entries in the PEN
   registry cannot be used to validate the ownership of a PEN in use.
   For example, if the PEN is seen in a protocol as
   indicating the owner of some data, there is no way to securely
   correlate that use with the name and organization of the owner listed
   in the PEN registry.

6.  Acknowledgements

   An earlier version of this document was authored by Pearl Liang and
   Alexey Melnikov.  Additional significant contributions have come from
   Dan Romascanu, Bert Wijnen, David Conrad, and Benoit Claise.

7.  Informative References

   [ASN1]     ITU-T, "ITU-T X.690: Information technology - ASN.1
              encoding rules", 2016, <

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, DOI 10.17487/RFC2865, June 2000,

   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
              DOI 10.17487/RFC3411, December 2002, <https://www.rfc-

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588,
              DOI 10.17487/RFC3588, September 2003, <https://www.rfc-

Cotton, et al.            Expires April 8, 2018                 [Page 5]
Internet-Draft              PEN registration                October 2017

   [RFC5284]  Swallow, G. and A. Farrel, "User-Defined Errors for RSVP",
              RFC 5284, DOI 10.17487/RFC5284, August 2008,

   [RFC5424]  Gerhards, R., "The Syslog Protocol", RFC 5424,
              DOI 10.17487/RFC5424, March 2009, <https://www.rfc-

   [RFC5612]  Eronen, P. and D. Harrington, "Enterprise Number for
              Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August
              2009, <>.

   [RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,
              DOI 10.17487/RFC6350, August 2011, <https://www.rfc-

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,

Authors' Addresses

   Michelle Cotton
   PTI, an affiliate of ICANN


   Amanda Baber
   PTI, an affiliate of ICANN


   Paul Hoffman


Cotton, et al.            Expires April 8, 2018                 [Page 6]