-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-liang-iana-pen.xml
474 lines (394 loc) · 20.3 KB
/
draft-liang-iana-pen.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC5792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5792.xml">
<!ENTITY RFC5793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5793.xml">
<!ENTITY RFC2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY RFC5424 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5424.xml">
<!ENTITY RFC5612 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5612.xml">
<!ENTITY RFC6350 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6350.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5284 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5284.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC): -->
<?rfc toc="yes"?> <!-- generate a ToC -->
<?rfc tocdepth="2"?> <!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references: -->
<?rfc symrefs="yes"?> <!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?> <!-- sort the reference entries alphabetically -->
<!-- control vertical white space:
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?> <!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?> <!-- keep one blank line between list items -->
<!-- end of popular PIs -->
<rfc category="info" docName="draft-liang-iana-pen-07" ipr="trust200902">
<front>
<title abbrev="IANA PEN v2.0">IANA Registration Considerations for Private Enterprise Numbers (PENs)</title>
<author fullname="Pearl Liang" initials="P" surname="Liang">
<organization>ICANN</organization>
<address>
<postal><street>12025 Waterfront Drive, Suite 300</street>
<city>Los Angeles</city><region>CA</region><code>90094</code>
<country>USA</country></postal>
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>[email protected]</email>
<!-- <uri/> -->
</address>
</author>
<author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
<organization>Isode Ltd</organization>
<address>
<postal>
<street>5 Castle Business Village</street>
<street>36 Station Road</street>
<city>Hampton</city>
<region>Middlesex</region>
<code>TW12 2BX</code>
<country>UK</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date year="2015"/>
<!-- <area/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<abstract>
<t>
Private Enterprise Numbers (PENs) are a technical protocol parameter frequently used
for network management, and in protocols such as
LDAP, DIAMETER or GSS-API. This document
discusses what a PEN is, common uses for PENs, and
IANA's registration procedures PENs. The registration
procedures include instructions and requirements for obtaining a new
PEN, modifying existing registrations, and the
removal of existing registrations.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
A Private Enterprise Number (also known as a "PEN"), is a non-negative integer, unique within
the ISO Object Identifier (OID) hierarchy. The full OID hierarchy was jointly developed by ITU-T
and ISO/IEC to allow the assignment of globaly unambiguous numeric names.
(The original document describing the OID hierarchy has been withdrawn by ITU-T, but some
current description can be found in the ITU-T X.660 and X.670 Recommendation series.)
The basic idea behind OIDs is that
each level of the hierarchy could have its own registration process for names in that level.
PENs are a set of numbers in a subtree of the OIDs tree.
</t>
<t>
The PEN sub-tree for which the IETF is the Registration Authority, originally defined sometime before 1990,
is used to allow any entity to obtain a globally unique identifier to reference
an organization ("enterprise"), often in protocols. IANA is now the Registration Authority.
The location of the PEN subtree in the OID
hierarchy is 1.3.6.1.4.1, which is also known as "iso.org.dod.internet.private.enterprise".
</t>
<t>
Many standards, both from the IETF and other organizations, use PENs as identifiers. These standards
sometimes use just the PEN (the single integer assigned by IANA, such as "42"), or sometimes use
the entire OID including the PEN (such as "1.3.6.1.4.1.42").
</t>
<t>To date, the procedures for the assignment of PENs have not been clearly documented. RFCs from the
early 1990s talk about the use of PENs, but not how they are assigned. This document fixes that
problem by defining the procedures IANA uses to assign PENs.
</t>
<t>
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.
</t>
</section>
<section title="Introduction to Private Enterprise Numbers">
<t>
PENs are frequently embedded in OIDs (Object Identifiers) <!--////Alexey: add reference for OIDs-->,
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.</t>
<t>
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:
<list>
<t>
Prefix: iso.org.dod.internet.private.enterprise.(Your node)<vspace/>
1.3.6.1.4.1.xxxx
</t>
</list>
</t>
<t>
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.
</t>
<!--Alexey: not sure about this
<t>OID-info.com has detailed resources on OIDs See: http://oid-info.com/faq.htm#3.</t>
-->
<section anchor="others" title="Various Uses of PENs "in the wild"">
<t>
PENs as integers are used in many ways. In IETF protocols, they are often used in extension
mechanisms to cause an extension to have a unique identifier.
Examples of protocols that use PEN values in their extension mechanisms include
RADIUS <xref target="RFC2865"/>,
DIAMETER <xref target="RFC3588"/>,
Syslog <xref target="RFC5424"/>,
RSVP <xref target="RFC5284"/>,
and vCard <xref target="RFC6350"/>.
</t>
<t>
PENs as part of an OID are also used in protocols for extension identification, although generally only in protocols that
already use OIDs as identifiers. For examle, extensions in PKIX <xref target="RFC5280"/> are given as OIDs,
so private extensions that use PENs would use the full OID.
</t>
<t>
The places that PENs are used is completely up to implementers. Neither IANA nor the IETF police how
people use the numbers out in the wild, nor do they have any say in disputes about how any
particular PEN might or might not be used.
</t>
</section>
</section>
<section title="PEN Assignment">
<t>
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.
</t>
<section anchor="new-assignment" title="Assignment of a New PEN">
<t>
PENs are assigned through a "First Come First Served" registration policy as described in <xref target="RFC5226"/>.
They are assigned sequentially. There is no opportunity to request a particular private enterprise number.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
<!--/////Alexey: open issue, need more text to discourage that-->
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.
</t>
<t>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.</t>
<t>The following information will be requested for a new registration:</t>
<t> Registrant (Company/Organization) Name (REQUIRED)</t>
<t> Registrant Postal Address (REQUIRED)</t>
<t> Contact Name (REQUIRED)</t>
<t> Contact E-mail Address (REQUIRED)</t>
<t> Contact Postal Address (OPTIONAL)</t>
<t> Contact Phone Number (OPTIONAL)</t>
<t> Reference (OPTIONAL)</t>
<t> Comments (OPTIONAL)</t>
<t>
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.
The registrant name can contain non-ASCII characters, but IANA might limit the characters allowed.
</t>
<t>
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.
</t>
<t>
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.
The contact name can contain non-ASCII characters, but IANA might limit the characters allowed.
</t>
<t>
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.
</t>
<t>
Contact Postal Address: The full postal address of the individual
responsible the PEN, including state/province, zip/postal code,
country, etc.
</t>
<t>
Contact Phone: The telephone number (with extension where appropriate)
of the individual responsible for the PEN, including country code.
</t>
<t>
Reference: A document associated with the implementation of the OID
can be referenced with the registration.
</t>
<t>Comments: This field will contain the old Registrant/Company Name associated with a PEN if applicable.</t>
<t>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.</t>
</section>
<section anchor="update" title="Update of an Assigned PEN">
<t>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.
</t>
<t>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.</t>
<t>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 verifications cannot be fulfilled and if it deems to be necessary. </t>
<t>IANA does not allow removal of entries from this registry.</t>
</section>
</section>
<section title="Registration in the Private Enterprise Number registry">
<section title="Registration of PEN" anchor="registry-content">
<t>The registry table consists of a list of the following properties:</t>
<t> PEN number</t>
<t> Registrant (Company/Organization) Name</t>
<t> Contact Name</t>
<t> Contact E-mail Address</t>
<t> Date Assigned</t>
<t> Date Modified</t>
<t> Reference</t>
<t> Comments</t>
<t>NOTE: See <xref target="new-assignment"/> for definition of these properties.</t>
<t>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.</t>
<t>o Value "Unassigned" SHOULD NOT be re-assigned unless specified
otherwise, i.e. when the available pool of PENs runs out.</t>
</section>
<section anchor="syntax" title="Syntax for Private Enterprise Names and PENs">
<t>o Names of Private Enterprises MUST NOT begin or end with a hyphen</t>
<t>
The range for PENs is 0 to 2**32-1. The values 0 and 4294967295 (2**32-1) are marked as Reserved.
Note that while the original PEN definition had no upper bound, this document now defines the upper bound
because some protocols limit how big PENs can be.
For example, DIAMETER <xref target="RFC3588"/> specifies that PENs used in that protocol can be no bigger than 2**32-1.
</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
The authors would like to thank Dan Romascanu, Michelle Cotton,
and Bert Wijnen for their contributions to this document.
</t>
<!--///Pearl: to add Benoit? -->
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This document requests IANA to update the PEN online template forms both new and modified registrations
as defined in sections <xref target="new-assignment"/> and <xref target="update"/>.
</t>
<t>
The PEN registry should be updated to include the information as defined
in <xref target="registry-content"/>.
</t>
<t>
There is a PEN number, 32473, reserved for use as examples in documentation.
This reservation is described in <xref target="RFC5612"/>.
</t>
<section anchor="Historic" title="Historical Assignments">
<t>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)).</t>
<t>2187, 2188, 3513, 4164, 4565, 4600, 4913, 4999, 5099, 5144, 5201, 5683,
5777, 6260, 6619, 14827, 16739, 26975</t>
<t>The range from 11670 to 11769</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>
See the Security Considerations section in BCP 26 <xref target="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.
</t>
<t>
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.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC1229;
&RFC5226;
</references>
<references title="Informative References">
&RFC3588;
&RFC5280;
&RFC5284;
&RFC5424;
&RFC2865;
&RFC5612;
&RFC5792;
&RFC5793;
&RFC6350;
</references>
<section title="Acknowledgements">
<t>David Conrad edited an earlier version of this document.</t>
</section>
<!-- Changes from last versions:
- Changes in 05:
1. cleaned up some redundant texts
2. modified the Reserved value not for allocation
- Changes in 04:
1. Use draft-ietf-precis-nickname to describe allowed Unicode characters in Names of Private Enterprises.
2. Clarified the limit of 2**32-1 on PENs.
3. Reordered requirements, so that requirements on Names of Private Enterprises and PEN values are grouped together.
4. Replaced one use of Reserved with Unassigned.
- Changes in 03:
1. Removed an internal note in the IANA Considerations section.
2. Editted the "Modification of Private Enterprise Numbers" section to
clarify that the Registrant/Company Name can be changed with verification.
-
-->
</back>
</rfc>