Private Enterprise Number (PEN) practices and Internet Assigned Numbers Authority (IANA) registration considerations
draft-liang-iana-pen-05

Network Working Group                                           P. Liang
Internet-Draft                                                     ICANN
Intended status: Informational                               A. Melnikov
Expires: September 8, 2015                                     Isode Ltd
                                                               D. Conrad
                                                                   ICANN
                                                           March 7, 2015

Private Enterprise Number (PEN) practices and Internet Assigned Numbers
              Authority (IANA) registration considerations
                        draft-liang-iana-pen-05

Abstract

   Private Enterprise Numbers (PENs) are a technical protocol parameter
   frequently assigned for use 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 of PENs, and registration
   procedures for IANA Considerations.  The registration procedures
   include instructions and requirements for obtaining a new Private
   Enterprise Number, modifying existing numbers, and the removal of
   existing numbers.

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 8, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Liang, et al.           Expires September 8, 2015               [Page 1]
Internet-Draft               IANA PEN v.0.2                   March 2015

   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
   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Example of use for Private Enterprise Numbers . . . . . . . .   3
   3.  Who can get a Private Enterprise Number?  . . . . . . . . . .   3
   4.  Other useful things to know . . . . . . . . . . . . . . . . .   4
   5.  Syntax for Private Enterprise Names and PENs  . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  New Private Enterprise Numbers  . . . . . . . . . . . . .   6
     7.2.  Modification of Private Enterprise Numbers  . . . . . . .   7
     7.3.  Removals of Private Enterprise Numbers  . . . . . . . . .   8
     7.4.  Historical Assignments  . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   A Private Enterprise Number (also known as a "PEN"), is a non-
   negative integer, unique within the
   iso.org.dod.internet.private.enterprise (1.3.6.1.4.1) Object
   Identifiers (OIDs ) subtree, that can be used to reference an
   organization ("enterprise") in protocols that require numeric values
   instead of a human readable organization name.  The
   iso.org.dod.internet.private.enterprise OID is known as the Private
   Enterprise Number OID.  The Private Enterprise Number OID was
   originally defined in [RFC1065].

   Currently, procedures for assignment of new PENs and the modification
   of existing PENs are 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) structures.  However, none of these RFCs clearly
   describe PENs and define their registration procedures.

Liang, et al.           Expires September 8, 2015               [Page 2]
Internet-Draft               IANA PEN v.0.2                   March 2015

   Additionally, updates to existing Private Enterprise Numbers can be
   challenging due to the lack of clear registration requirements and
   difficulties in validation, particularly in cases such as
   organization name or legal ownership changes, changes in email
   addresses of the registered PEN owner, etc.

   This purpose of this document is to describe the basics of PENs, how
   they are most commonly used, and to define PEN registration and
   update procedures.

2.  Example of use for Private Enterprise Numbers

   PENs are frequently embedded in OIDs (Object Identifiers) , 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.  Examples of other uses 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 health-care related standards, including HL7.

3.  Who can get a Private Enterprise Number?

   PENs are assigned through a "First Come First Served" registration
   policy as described in [RFC5226].  A new request can be submitted to
   IANA by individuals or organizations in order to obtain a unique
   value for their "enterprise".  In order to facilitate appropriate
   registration, a small amount of information is required including the
   requesting organization (or individual's) name, the name of the
   contact person for the PEN, and an e-mail address of the contact.  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 the name of the Registrant
   (Company/Organization) as described in Section 7.

   In other cases, applicants that already have a PEN make requests for
   new PENs for subsidiaries claiming the subsidiaries are completely

Liang, et al.           Expires September 8, 2015               [Page 3]
Internet-Draft               IANA PEN v.0.2                   March 2015

   independent of the parent organization, the subsidiaries are located
   in different locations, the listed Contact person(s) are unknown or
   unreachable, or other reasons why the subsidiaries cannot use
   existing the existing PEN allocation.  However, this does not justify
   new allocations as the parent company is able to create sub-trees and
   allocate the sub-numbers themselves.  Before requesting additional
   OID, IANA encourages companies to coordinate implementations of
   multiple projects within the organization and identify the existing
   OID assignment(s) whether those numbers have been properly
   maintained.  Nevertheless, this registry allows for large number of
   allocations and, as of now (this version), there are approximately
   45,000 allocations.  IANA may allocate new numbers to companies that
   are subsidiaries of existing registrations if justfication for
   multiple allocations is provided.

   However, joint ventures of business enterprises may request new
   allocations if the joint venture is considered a new legal body.  In
   addition, open resource forums and individuals may request new
   allocations under the registration requirement as describe in
   Section 7.

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) tree.  However,
   increasingly, an OID with health care and public health informatics
   in the United States is being used.  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) tree.

   It is important to note that despite the name PENs do not necessarily
   represent a manufacturer or Vendor ID.  For example they can
   represent organizations and even independent developers.

   The registrant of a Private Enterprise Number can create sub-trees by
   appending a "." along with unique numbers at the end of their PEN,
   i.e. to perform its own sub-allocations.  For example, for LDAP, the
   registrant of PEN <PEN> 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

Liang, et al.           Expires September 8, 2015               [Page 4]
Internet-Draft               IANA PEN v.0.2                   March 2015

   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

   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.

   iso.org.dod.internet.private.enterprise.<PEN>.1.3 can be used for
   instant messaging related object classes, etc.

5.  Syntax for Private Enterprise Names and PENs

   Valid information for the Registrant (Company/Organization) Name for
   PEN registrations are normatively defined as follows:

   o Names of Private Enterprises MUST satisfy the requirements of the
   NicknameFreeformClass [I-D.ietf-precis-nickname].  ( Basically, this
   means that all ASCII letters, ASCII digits, ASCII punctuation
   characters, Unicode symbols are allowed.)

   o Names of Private Enterprises MUST NOT begin or end with a hyphen

   o Maximum value for PENs is hereby defined within 2**32-1 with 0 and
   0xFFFFFF (in hex) marked as Reserved.  (Note that while the original
   PEN definition has no upper bound, this document defines the upper
   bound, because some protocol make assumptions about how big PENs can
   be.  For example, DIAMETER [RFC3588] assumes that this value is no
   bigger than 2**32-1.)

   o Values marked as "Reserved" (excluding value zero) in the registry
   can not be reassigned to a new company or individual without
   consulting IESG assigned expert(s).  Reserved entries mark entries
   with unclear ownership.

   o Value "Unassigned" SHOULD NOT be re-assigned unless specified
   otherwise, i.e. when the available pool of PENs runs out.

Liang, et al.           Expires September 8, 2015               [Page 5]
Internet-Draft               IANA PEN v.0.2                   March 2015

6.  Acknowledgements

   The authors would like to thank Dan Romascanu, Michelle Cotton, and
   Bert Wijnen for their contributions to this document.

7.  IANA Considerations

7.1.  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.
   (Suspected allocation requests coming from the same organization/
   person that try to allocate a range of PENs up to a desired number
   will be reported to IESG.)  The requester can submit an online
   application form.  Information to be included:

   Registrant (Company/Organization) Name (REQUIRED)

   Registrant (Company/Organization) E-mail Address (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)

   Reference (OPTIONAL)

   Comments (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 (Company/Organization) E-mail Address: An e-mail address
   belonging to the organization that requests the PEN.  This e-mail
   address will be publicly available in the IANA PEN Registry.  The

Liang, et al.           Expires September 8, 2015               [Page 6]
Internet-Draft               IANA PEN v.0.2                   March 2015

   E-mail address should be a valid email address and can be a role
   account e-mail address.

   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.

   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: 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.

   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 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.

   Reference: A document associated with the implementation of the OID
   can be referenced with the registration.

   Comments: Initially empty.  This field can be updated upon request to
   modify Registrant Name associated with a PEN (see Section 7.2).

   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.

7.2.  Modification of Private Enterprise Numbers

   Modification of existing Private Enterprise Numbers:

Liang, et al.           Expires September 8, 2015               [Page 7]
Internet-Draft               IANA PEN v.0.2                   March 2015

   When a Company/Organization has been merged or acquired by another
   enterprise, the Registrant (Company/Organization) Name can be
   annotated in the registry with the new owner/name in the Comments
   field.  This requires verification in the form of emails from the
   both existing Contact and proposed Contact, and, if it deems to be
   necessary, official letters from the existing owner (if applicable)
   to provide proofs of the changes to IANA.  If either the existing
   owner or Contact is obsoleted, an official letter from the proposed
   Registrant (Company/ Organization) Name will be required and be
   supplied to IANA for verification.  Additional documentations will be
   required subject to the conditions of the changes of the numbers in
   questions.  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.

   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
   to IANA using an online submission.  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
   verifications cannot be fulfilled and if it deems to be necessary.

   Requests can only be fulfilled upon verification by IANA and/or
   subject matter experts if it deems to be necessary.

7.3.  Removals of Private Enterprise Numbers

   Such request does not happen often and regularly.

   Considering the fact that there might be legacy uses of any existing
   allocation, registrations SHOULD NOT be removed.

   A Contact Name can request to remove the corresponding Contact
   information if the company is no longer in operation, the Contact
   does not wish to be listed in the IANA PEN registry and if the PEN is

Liang, et al.           Expires September 8, 2015               [Page 8]
Internet-Draft               IANA PEN v.0.2                   March 2015

   no longer believed to be in use.  The Modification procedure
   described above SHOULD be followed.

   Requests can only be fulfilled upon verification by IANA and/or
   subject matter experts if it deems to be necessary.

   IF the removal request is honoured, the entry is marked as
   "Unassigned" and annotated as "returned on yyyy-mm-dd by xxxxxxx".  A
   future update to this document can allow IANA to reallocate such
   returned PEN, however this document doesn't allow for that.

7.4.  Historical Assignments

   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".  These numbers MAY be re-assigned when the available pool of
   PENs runs out upon instructions from IESG (or IESG assigned
   expert(s)).

   2187, 2188, 3513, 4164, 4565, 4600, 4913, 4999, 5099, 5144, 5201,
   5683, 5777, 6260, 6619, 14827, 16739, 26975

   The range from 11670 to 11769

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

   [I-D.ietf-precis-nickname]
              Saint-Andre, P., "Preparation and Comparison of
              Nicknames", draft-ietf-precis-nickname-09 (work in
              progress), January 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Liang, et al.           Expires September 8, 2015               [Page 9]
Internet-Draft               IANA PEN v.0.2                   March 2015

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

9.2.  Informative References

   [RFC1065]  Rose, M. and K. McCloghrie, "Structure and identification
              of management information for TCP/IP-based internets", RFC
              1065, August 1988.

   [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.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [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
   12025 Waterfront Drive, Suite 300
   Los Angeles, CA  90094
   USA

   Email: pearl.liang@icann.org

Liang, et al.           Expires September 8, 2015              [Page 10]
Internet-Draft               IANA PEN v.0.2                   March 2015

   Alexey Melnikov
   Isode Ltd
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   Email: Alexey.Melnikov@isode.com

   David Conrad
   ICANN
   12025 Waterfront Drive, Suite 300
   Los Angeles, CA  90094
   US

   Email: drc@virtualized.org

Liang, et al.           Expires September 8, 2015              [Page 11]