rfc9371.original   rfc9371.txt 
Network Working Group A. Baber Internet Engineering Task Force (IETF) A. Baber
Internet-Draft IANA Request for Comments: 9371 IANA
Intended status: Informational P. Hoffman Category: Informational P. Hoffman
Expires: 18 June 2023 ICANN ISSN: 2070-1721 ICANN
15 December 2022 February 2023
Registration Procedures for Private Enterprise Numbers (PENs) Registration Procedures for Private Enterprise Numbers (PENs)
draft-pti-pen-registration-10
Abstract Abstract
This document describes how Private Enterprise Numbers (PENs) are This document describes how Private Enterprise Numbers (PENs) are
registered by IANA. It shows how to request a new PEN and how to 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 modify a current PEN. It also gives a brief overview of PEN uses.
of PEN uses.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 18 June 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9371.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Uses of PENs . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Uses of PENs
2. PEN Assignment . . . . . . . . . . . . . . . . . . . . . . . 3 2. PEN Assignment
2.1. Requesting a PEN Assignment . . . . . . . . . . . . . . . 3 2.1. Requesting a PEN Assignment
2.2. Modifying an Existing Record . . . . . . . . . . . . . . 3 2.2. Modifying an Existing Record
2.3. Deleting a PEN Record . . . . . . . . . . . . . . . . . . 4 2.3. Deleting a PEN Record
3. PEN Registry Specifics . . . . . . . . . . . . . . . . . . . 4 3. PEN Registry Specifics
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 6. References
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References
7.1. Normative References . . . . . . . . . . . . . . . . . . 5 6.2. Informative References
7.2. Informative References . . . . . . . . . . . . . . . . . 5 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses
1. Introduction 1. Introduction
Private Enterprise Numbers (PENs) are identifiers that can be used Private Enterprise Numbers (PENs) are identifiers that can be used
anywhere that an ASN.1 object identifier (OID) [ASN1] 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 Originally, PENs were developed so that organizations that needed to
identify themselves in Simple Network Management Protocol (SNMP) identify themselves in Simple Network Management Protocol (SNMP)
[RFC3411] Management Information Base (MIB) configurations could do [RFC3411] Management Information Base (MIB) configurations could do
so easily. PENs are also useful in any application or configuration so easily. PENs are also useful in any application or configuration
language that needs OIDs to identify organizations. language that needs OIDs to identify organizations.
skipping to change at page 3, line 13 skipping to change at line 104
of algorithms that it supports in a protocol. of algorithms that it supports in a protocol.
Neither IANA nor the IETF can control how an assignee uses its PEN. Neither IANA nor the IETF can control how an assignee uses its PEN.
In fact, no one can exert such control: that is the meaning of In fact, no one can exert such control: that is the meaning of
"private" in "private enterprise number". Similarly, no one can "private" in "private enterprise number". Similarly, no one can
prevent an assignee that is not the registered owner of a PEN from prevent an assignee that is not the registered owner of a PEN from
using that PEN, or any PEN, however they want. using that PEN, or any PEN, however they want.
A very common use of PENs is to give unique identifiers in IETF A very common use of PENs is to give unique identifiers in IETF
protocols. SNMP MIB configuration files use PENs for identifying the protocols. SNMP MIB configuration files use PENs for identifying the
origin of values. Some protocols that use PENs as identifiers of origin of values. Protocols that use PENs as identifiers of
extension mechanisms include RADIUS [RFC2865], Diameter [RFC6733], extension mechanisms include RADIUS [RFC2865], Diameter [RFC6733],
Syslog [RFC5424], RSVP [RFC5284], and vCard [RFC6350]. Syslog [RFC5424], RSVP [RFC5284], and vCard [RFC6350].
2. PEN Assignment 2. PEN Assignment
Private Enterprise Numbers (PENs) are assigned by IANA. The registry PENs are assigned by IANA. The registry is located at
is located at https://www.iana.org/assignments/enterprise-numbers, <https://www.iana.org/assignments/enterprise-numbers>, and requests
and requests for new assignments or the modification of existing for new assignments or the modification of existing assignments can
assignments can also be submitted at that URL. also be submitted at that URL.
IANA maintains the PEN registry in accordance with the "First Come IANA maintains the PEN registry in accordance with the "First Come
First Served" registration policy described in [RFC8126]. Values are First Served" registration policy described in [RFC8126]. Values are
assigned sequentially. assigned sequentially.
2.1. Requesting a PEN Assignment 2.1. Requesting a PEN Assignment
Requests for assignment must provide the name of the assignee, the Requests for assignment must provide the name of the assignee, the
name of a public contact who can respond to questions about the name of a public contact who can respond to questions about the
assignment, and contact information that can be used to verify change assignment, and contact information that can be used to verify change
requests. The contact's name and email address will be included in requests. The contact's name and email address will be included in
the public registry. the public registry.
A proposed assignee may request multiple PENs, but obtaining one PEN A prospective assignee may request multiple PENs, but obtaining one
and making internal sub-assignments is typically more appropriate. PEN and making internal sub-assignments is typically more
(Sub-assignments should not be reported to IANA.) appropriate. (Sub-assignments should not be reported to IANA.)
IANA may refuse to process abusive requests. IANA may refuse to process abusive requests.
2.2. Modifying an Existing Record 2.2. Modifying an Existing Record
Any of the information associated with a registered value can be Any of the information associated with a registered value can be
modified, including the name of the assignee. modified, including the name of the assignee.
Modification requests require authorization by a representative of Modification requests require authorization by a representative of
the assignee. Authorization will be validated either with the assignee. Authorization will be validated either with
information kept on file with IANA or with other identifying information kept on file with IANA or with other identifying
documentation, if necessary. documentation, if necessary.
2.3. Deleting a PEN Record 2.3. Deleting a PEN Record
Although such requests are rare, registrations can be deleted. When Although such requests are rare, registrations can be deleted. When
a registration is deleted, all identifying information is removed a registration is deleted, all identifying information is removed
from the registry, and the value is marked as "returned." Returned from the registry, and the value is marked as "returned." Returned
values will not be made available for re-assignment until all other values will not be made available for reassignment until all other
unassigned values have been exhausted; as can be seen in Section 3, unassigned values have been exhausted; as can be seen in Section 3,
the unassigned values are unlikely to ever run out. the unassigned values are unlikely to ever run out.
3. PEN Registry Specifics 3. PEN Registry Specifics
The range for values after the PEN prefix is 0 to 2**32-1. The 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 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 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 PEN prefix, there is now an upper bound due to some IETF protocols
limiting the size of that value. For example, Diameter [RFC6733] limiting the size of that value. For example, Diameter [RFC6733]
skipping to change at page 4, line 32 skipping to change at line 170
There is a PEN number, 32473, reserved for use as an example in There is a PEN number, 32473, reserved for use as an example in
documentation. This reservation is described in [RFC5612]. documentation. This reservation is described in [RFC5612].
Values in the registry that have unclear ownership are marked Values in the registry that have unclear ownership are marked
"Reserved". These values will not be reassigned to a new company or "Reserved". These values will not be reassigned to a new company or
individual without consulting the IESG. individual without consulting the IESG.
4. IANA Considerations 4. IANA Considerations
This document requires two changes to the PEN registry. Per this document, IANA has made the following changes to the PEN
registry:
Values 2187, 2188, 3513, 4164, 4565, 4600, 4913, 4999, 5099, 5144, * Values 2187, 2188, 3513, 4164, 4565, 4600, 4913, 4999, 5099, 5144,
5201, 5683, 5777, 6260, 6619, 14827, 16739, 26975 and the range from 5201, 5683, 5777, 6260, 6619, 14827, 16739, 26975, and the range
11670 to 11769, which had been missing from the registry, will be from 11670 to 11769, which had been missing from the registry,
listed as "Reserved." As described in [RFC8126], reserved values can have been listed as "Reserved." As described in [RFC8126],
be released by the IESG. reserved values can be released by the IESG.
In addition, this document will be listed in the registry's * This document has been listed in the registry's "Reference" field.
"Reference" field.
* "First Come First Served" has been listed as its registration
procedure.
5. Security Considerations 5. Security Considerations
Registering PENs does not introduce any significant security Registering PENs does not introduce any significant security
considerations. considerations.
There is no cryptographic binding of a registrant in the PEN registry 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 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. registry cannot be used to validate the ownership of a PEN in use.
For example, if the PEN 1.3.6.1.4.1.32473 is seen in a protocol as For example, if the PEN 1.3.6.1.4.1.32473 is seen in a protocol as
indicating the owner of some data, there is no way to securely indicating the owner of some data, there is no way to securely
correlate that use with the name and assignee of the owner listed in correlate that use with the name and assignee of the owner listed in
the PEN registry. the PEN registry.
6. Acknowledgements 6. References
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, Michelle Cotton, and Benoit
Claise.
7. References
7.1. Normative References 6.1. Normative References
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
7.2. Informative References 6.2. Informative References
[ASN1] ITU-T, "ITU-T X.690: Information technology - ASN.1 [ASN1] ITU-T, "Information technology - ASN.1 encoding rules:
encoding rules", 2016, <https://www.itu.int/itu- Specification of Basic Encoding Rules (BER), Canonical
t/recommendations/rec.aspx?rec=x.690>. Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, February 2021,
<https://www.itu.int/rec/T-REC-X.690/en>.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000, RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>. <https://www.rfc-editor.org/info/rfc2865>.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
DOI 10.17487/RFC3411, December 2002, DOI 10.17487/RFC3411, December 2002,
skipping to change at page 6, line 18 skipping to change at line 246
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
DOI 10.17487/RFC6350, August 2011, DOI 10.17487/RFC6350, August 2011,
<https://www.rfc-editor.org/info/rfc6350>. <https://www.rfc-editor.org/info/rfc6350>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733, Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012, DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>. <https://www.rfc-editor.org/info/rfc6733>.
Acknowledgements
An earlier draft version of this document was authored by Pearl Liang
and Alexey Melnikov. Additional significant contributions have come
from Dan Romascanu, Bert Wijnen, David Conrad, Michelle Cotton, and
Benoit Claise.
Authors' Addresses Authors' Addresses
Amanda Baber Amanda Baber
Internet Assigned Numbers Authority Internet Assigned Numbers Authority
PTI/ICANN PTI/ICANN
12025 Waterfront Drive 12025 Waterfront Drive
Los Angeles, 90094 Los Angeles, 90094
United States of America United States of America
Email: amanda.baber@iana.org Email: amanda.baber@iana.org
 End of changes. 21 change blocks. 
72 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.48.