[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

Network Working Group                                           P. Liang
Internet-Draft                                                     ICANN
Intended status: Informational                               A. Melnikov
Expires: January 7, 2016                                       Isode Ltd
                                                               D. Conrad
                                                                   ICANN
                                                            July 6, 2015


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

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 January 7, 2016.

Copyright Notice

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





Liang, et al.            Expires January 7, 2016                [Page 1]


Internet-Draft                IANA PEN v2.0                    July 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.  Introduction to Private Enterprise Numbers  . . . . . . . . .   3
     2.1.  Various uses of PENs "in the wild"  . . . . . . . . . . .   3
   3.  PEN Assignment  . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Assignment of a New PEN . . . . . . . . . . . . . . . . .   5
     3.2.  Update of an Assigned PEN . . . . . . . . . . . . . . . .   7
     3.3.  Removals of Private Enterprise Numbers  . . . . . . . . .   8
   4.  Registration in the Private Enterprise Number registry  . . .   8
     4.1.  Registration of PEN . . . . . . . . . . . . . . . . . . .   8
     4.2.  Syntax for Private Enterprise Names and PENs  . . . . . .   9
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Historical Assignments  . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

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 of the ISO Object Identifier (OID)
   hierarchy.  This hierarchy, jointly developed by ITU-T and ISO/IEC
   was developed to name "any type of object, concept or 'thing' with a
   globaly unambiguous name which requires a persistent name" (See
   http://www.oid-info.com/#oid).  The sub-tree for which the IETF is
   the Registration Authority, originally defined in [RFC1065], is used
   to allow any entity to obtain a globally unique identifier to
   reference an organization ("enterprise") in protocols.

   To date, the procedures for the assignment of new PENs and the
   modification of assigned PENs have not been clearly documented.
   Private Enterprise Numbers are referenced in RFCs [RFC1157] [RFC1213]



Liang, et al.            Expires January 7, 2016                [Page 2]


Internet-Draft                IANA PEN v2.0                    July 2015


   and [RFC2578].  These documents primarily define Simple Network
   Management Protocol (SNMP), Management Information Base (MIB) and
   Structure of Management Information (SMI) structures.  As such, none
   of these RFCs clearly describe PENs nor do they define PEN
   registration procedures.

   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.

   This document introduces PENs, how they are commonly used, and their
   registration and update procedures.

2.  Introduction to 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.  There is no restriction for using private enterprise
   numbers for other protocols or data models than SNMP or MIB.

   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:

      Prefix: iso.org.dod.internet.private.enterprise.(Your node)
      1.3.6.1.4.1.xxxx

   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.

2.1.  Various uses of PENs "in the wild"

   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.  Increasingly, an OID
   with health care and public health informatics in the United States
   is being used.  Health Level Seven (HL7), a standards-developing



Liang, et al.            Expires January 7, 2016                [Page 3]


Internet-Draft                IANA PEN v2.0                    July 2015


   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

   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.

   Below are more example uses of PENs:

      Distinguished Names and other components in X.509 certificates;

      Various schema elements in X.500/LDAP directories;

      GSS-API




Liang, et al.            Expires January 7, 2016                [Page 4]


Internet-Draft                IANA PEN v2.0                    July 2015


      extensions to DIAMETER

      PA-TNC [RFC5792] and PB-TNC [RFC5793]

   Important to note that how the numbers are used is up to the various
   implementers and companies building products.  Neither ICANN or the
   IETF can police how people use the numbers out in the wild.  The
   parties in question should resolve any inappropriate usage among
   themselves, and ICANN and the IETF have no role in such disputes.

3.  PEN Assignment

   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.

3.1.  Assignment of a New PEN

   PENs are assigned through a "First Come First Served" registration
   policy as described in [RFC5226].  They are assigned sequentially.
   There is no opportunity to request a particular private enterprise
   number.

   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.

   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.

   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.

   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.



Liang, et al.            Expires January 7, 2016                [Page 5]


Internet-Draft                IANA PEN v2.0                    July 2015


   The following information will be requested for a new registration:

   Registrant (Company/Organization) Name in ASCII (REQUIRED)

   UTF-8 version of the Registrant (Company/Organization) Name
   (OPTIONAL)

   Registrant (Company/Organization) E-mail Address (REQUIRED)

   Registrant Postal Address (REQUIRED)

   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.

   UTF-8 version: If a UTF-8 version of the company name is available,
   the requester can provide the UTF-8 name.  This will be listed in the
   registry.

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

   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.





Liang, et al.            Expires January 7, 2016                [Page 6]


Internet-Draft                IANA PEN v2.0                    July 2015


   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.

   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.

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

   Comments: This field will contain the old Registrant/Company Name
   associated with a PEN if applicable.

   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.

3.2.  Update of an Assigned PEN

   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.

   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.

   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



Liang, et al.            Expires January 7, 2016                [Page 7]


Internet-Draft                IANA PEN v2.0                    July 2015


   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.

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

4.  Registration in the Private Enterprise Number registry

4.1.  Registration of PEN

   The registry table consists of a list of the following properties:

   PEN number

   Registrant (Company/Organization) Name (in ASCII)

   UTF-8 version of the Registrant (Company/Organization) Name

   Registrant (Company/Organization) E-mail Address (REQUIRED)

   Contact Name

   Contact E-mail Address

   Date Assigned

   Date Modified



Liang, et al.            Expires January 7, 2016                [Page 8]


Internet-Draft                IANA PEN v2.0                    July 2015


   Reference

   Comments

   NOTE: See Section 3.1 for definition of these properties.

   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.

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

4.2.  Syntax for Private Enterprise Names and PENs

   o UTF-8 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.)

5.  Acknowledgements

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

6.  IANA Considerations

   This document requests IANA to update the PEN online template forms
   both NEW and Modification as defined in sections Section 3.1 and
   Section 3.2.

   The PEN registry should be updated to include the information as
   defined in Section 4.1.








Liang, et al.            Expires January 7, 2016                [Page 9]


Internet-Draft                IANA PEN v2.0                    July 2015


6.1.  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" 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)).

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

   The range from 11670 to 11769

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

   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.

8.  References

8.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 January 7, 2016               [Page 10]


Internet-Draft                IANA PEN v2.0                    July 2015


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

8.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 January 7, 2016               [Page 11]


Internet-Draft                IANA PEN v2.0                    July 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: david.conrad@icann.org


































Liang, et al.            Expires January 7, 2016               [Page 12]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/