idnits 2.17.1 draft-pti-pen-registration-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 5, 2017) is 2393 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Cotton 3 Internet-Draft A. Baber 4 Intended status: Informational PTI 5 Expires: April 8, 2018 P. Hoffman 6 ICANN 7 October 5, 2017 9 Registration Procedures for Private Enterprise Numbers (PENs) 10 draft-pti-pen-registration-00 12 Abstract 14 This document describes how Private Enterprise Numbers (PENs) are 15 registered by IANA. It shows how to request a new PEN and how to 16 request an update to a current PEN. It also gives a brief overview 17 of PEN uses. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 8, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Uses of PENs . . . . . . . . . . . . . . . . . . . . . . 2 55 2. PEN Assignment . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Requesting a PEN Assignment . . . . . . . . . . . . . . . 3 57 2.2. Modifying an Existing Record . . . . . . . . . . . . . . 4 58 2.3. Deleting a PEN Record . . . . . . . . . . . . . . . . . . 4 59 3. PEN Registry Specifics . . . . . . . . . . . . . . . . . . . 4 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 63 7. Informative References . . . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 Private Enterprise Numbers (PENs) are identifiers that can be used 69 anywhere that an ASN.1 object identifier (OID) [ASN1] can be used. 70 Originally, PENs were developed so that organizations that needed to 71 identify themselves in Simple Network Management Protocol (SNMP) 72 [RFC3411] Management Information Base (MIB) configurations could do 73 so easily. PENs are also useful in any application or configuration 74 language that needs OIDs to identify organizations. 76 The IANA Functions Operator, referred to in this document as "IANA", 77 manages and maintains the PEN registry in consultation with the IESG. 78 PENs are issued from an OID prefix that was assigned to IANA. That 79 OID prefix is 1.3.6.1.4.1. Using the (now archaic) notation of 80 ownership names in the OID tree, that corresponds to: 82 1 3 6 1 4 1 83 iso.org.dod.internet.private.enterprise 85 A PEN is an OID that begins with the PEN prefix. Thus, the OID 86 1.3.6.1.4.1.32473 is a PEN. 88 1.1. Uses of PENs 90 Once a PEN has been assigned to an organization, that organization 91 can use the PEN by itself (possibly to represent the organization) or 92 as the root of other OIDs associated with the organization. For 93 example, if an organization is assigned the PEN 1.3.6.1.4.1.32473, it 94 might use 1.3.6.1.4.1.32473.7 to identify a protocol extension and 95 use 1.3.6.1.4.1.32473.12.3 to identify a set of algorithms that it 96 supports in a protocol. 98 Neither IANA nor the IETF can control how an organization uses its 99 PEN. In fact, no one can exert such control: that is the meaning of 100 "private" in "private enterprise number". Similarly, no one can 101 prevent an organization that is not the registered owner of a PEN 102 from using that PEN, or any PEN, however they want. 104 A very common use of PENs is to give unique identifiers in IETF 105 protocols. SNMP MIB configuration files use PENs for identifying the 106 origin of values. Some protocols that use PENs as identifiers of 107 extension mechanisms include RADIUS [RFC2865], DIAMETER [RFC3588], 108 Syslog [RFC5424], RSVP [RFC5284], and vCard [RFC6350]. 110 2. PEN Assignment 112 Assignments of PENs are made by IANA, which maintains the Private 113 Enterprise Number (PEN) registry. Requests for new assignments and 114 for the modification of existing assignments can be submitted by 115 using the form at . 117 2.1. Requesting a PEN Assignment 119 IANA maintains the PEN registry using a "First Come First Served" 120 registration policy as described in [RFC8126]. Values are generally 121 assigned sequentially. 123 First Come First Served registries require the identification of a 124 "change controller" as described in [RFC8126]. In this registry, the 125 assignee is understood to be the change controller, unless the 126 requestor specifies otherwise. The assignee may be an individual, an 127 organization, a project, or some other entity. Required information 128 for registration includes the assignee name, contact person, postal 129 address and email address for the contact. The public registry 130 contains only the assignee name, contact name, and contact email 131 address. 133 Applicants can request that a title or role be listed in the registry 134 in place of a contact name, but must supply the name of an out-of- 135 band contact for IANA's internal records. 137 ASCII text submitted for registration as part of a name or contact 138 field can be accompanied by non-ASCII text in parentheses. 140 Parties may register more than one PEN, but in most cases it is 141 probably more appropriate to obtain a sub-assignment of the existing 142 registration. Sub-assignments are maintained by the assignee and are 143 not to be reported to IANA. 145 IANA may refuse to process abusive requests. However, any such 146 refusal can be appealed to the IESG. 148 2.2. Modifying an Existing Record 150 Assignees can request the modification of any of the information 151 associated with a registration, including the name of the assignee. 152 IANA will ask any existing or proposed contacts to confirm the 153 request. Additional documentation may be required, particularly if 154 the original contact is unavailable. 156 2.3. Deleting a PEN Record 158 If necessary, an assignee can ask IANA to delete a registration. 159 Values associated with deleted registrations will not become 160 available for re-assignment until all other unassigned values have 161 been exhausted. 163 3. PEN Registry Specifics 165 The range for values after the PEN prefix is 0 to 2**32-1. The 166 values 0 and 4294967295 (2**32-1) are reserved. Note that while the 167 original PEN definition had no upper bound for the value after the 168 PEN prefix, there is now an upper bound due to some IETF protocols 169 limiting the size of that value. For example, DIAMETER [RFC3588] 170 limits the value to 2**32-1. 172 There is a PEN number, 32473, reserved for use as an example in 173 documentation. This reservation is described in [RFC5612]. 175 Values in the registry that have unclear ownership are marked 176 "Reserved". These values will not be reassigned to a new company or 177 individual without consulting the IESG. 179 The PEN registry has some missing assignments. These numbers will be 180 available for assignment, but will only be assigned with the 181 permission of the IESG. At the time of publication of this document, 182 the list of missing assignments is: 2187, 2188, 3513, 4164, 4565, 183 4600, 4913, 4999, 5099, 5144, 5201, 5683, 5777, 6260, 6619, 14827, 184 16739, 26975 and the range from 11670 to 11769. 186 4. IANA Considerations 188 This entire document consists of considerations for IANA and for its 189 customers who want to apply for, modify, or delete a PEN. 191 5. Security Considerations 193 Registering PENs does not introduce any significant security 194 considerations. 196 There is no cryptographic binding of a registrant in the PEN registry 197 and the PEN(s) assigned to them. Thus, the entries in the PEN 198 registry cannot be used to validate the ownership of a PEN in use. 199 For example, if the PEN 1.3.6.1.4.1.32473 is seen in a protocol as 200 indicating the owner of some data, there is no way to securely 201 correlate that use with the name and organization of the owner listed 202 in the PEN registry. 204 6. Acknowledgements 206 An earlier version of this document was authored by Pearl Liang and 207 Alexey Melnikov. Additional significant contributions have come from 208 Dan Romascanu, Bert Wijnen, David Conrad, and Benoit Claise. 210 7. Informative References 212 [ASN1] ITU-T, "ITU-T X.690: Information technology - ASN.1 213 encoding rules", 2016, . 216 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 217 "Remote Authentication Dial In User Service (RADIUS)", 218 RFC 2865, DOI 10.17487/RFC2865, June 2000, 219 . 221 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 222 Architecture for Describing Simple Network Management 223 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 224 DOI 10.17487/RFC3411, December 2002, . 227 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 228 Arkko, "Diameter Base Protocol", RFC 3588, 229 DOI 10.17487/RFC3588, September 2003, . 232 [RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP", 233 RFC 5284, DOI 10.17487/RFC5284, August 2008, 234 . 236 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 237 DOI 10.17487/RFC5424, March 2009, . 240 [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for 241 Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 242 2009, . 244 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 245 DOI 10.17487/RFC6350, August 2011, . 248 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 249 Writing an IANA Considerations Section in RFCs", BCP 26, 250 RFC 8126, DOI 10.17487/RFC8126, June 2017, 251 . 253 Authors' Addresses 255 Michelle Cotton 256 PTI, an affiliate of ICANN 258 Email: michelle.cotton@iana.org 260 Amanda Baber 261 PTI, an affiliate of ICANN 263 Email: amanda.baber@iana.org 265 Paul Hoffman 266 ICANN 268 Email: paul.hoffman@icann.org