[Docs] [txt|pdf] [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: April 20, 2014                                        Isode Ltd
                                                        October 17, 2013


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

Abstract

   Private Enterprise Numbers (PENs), are assigned as part of the
   technical protocol parameters and are frequently used 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 and
   registration procedures for IANA Considerations.  The registration
   procedures include instructions and requirement for obtaining a new
   Private Enterprise Number, modification to existing numbers and
   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 April 20, 2014.

Copyright Notice

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

   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



Liang & Melnikov         Expires April 20, 2014                 [Page 1]


Internet-Draft                  PEN v.0.2                   October 2013


   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 Numbers . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  New Private Enterprise Numbers  . . . . . . . . . . . . .   5
     7.2.  Modification of Private Enterprise Numbers  . . . . . . .   7
     7.3.  Removals of Private Enterprise Numbers  . . . . . . . . .   8
     7.4.  Historical Assignments  . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

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

   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).  However, none of the above mentioned
   RFCs clearly describe PENs and define the registration procedures.

   Additionally, updates to existing Private Enterprise Numbers can also
   be problematic resulting from the lack of clear registration
   requirements.  Furthermore, modification requests can be hardly
   validated in cases like companies change names and/or legal



Liang & Melnikov         Expires April 20, 2014                 [Page 2]


Internet-Draft                  PEN v.0.2                   October 2013


   ownerships, a product was sold to another company, email addresses of
   existing assignments were not coming from the original companies,
   etc.

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

2.  Example of use for Private Enterprise Numbers

   PENs, are frequently embedded in OIDs (Object Identifiers) , which
   are often used in Simple Network Management Protocol (SNMP)
   Management Information Base (MIB) configurations but PENs are
   designed to be used by multiple protocols and DMLs.  These 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 healthcare related standards, including HL7.

3.  Who can get a Private Enterprise Number?

   Private Enterprise Numbers (PENs) are assigned through First Come
   First Served registration policy as described in [RFC5226].  A new
   request can be submitted to IANA by individuals or organizations for
   obtaining a unique value with a little required information that
   includes the organization name (or the name of an individual),
   contact name, and e-mail address.  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 as the name of the Registrant (Company/Organization) Name
   as described in Section 7.

   In other instances, applicants insist that new requests are
   subsidiaries of some groups but the subsidiaries are completely
   independent of the parent groups.  The subsidiaries are located in
   different locations and countries from the parent companies and such
   the subsidiaries cannot use existing allocations.  However, this does
   not contribute to new allocations as the global companies shall be
   able to create sub-trees and to allocate the sub-numbers globally.



Liang & Melnikov         Expires April 20, 2014                 [Page 3]


Internet-Draft                  PEN v.0.2                   October 2013


   IANA does not further allocate new numbers to companies that are
   subsidiaries of existing registrations.

   Further, joint ventures of business enterprises may request new
   allocations if the joint ventures are considered new legal bodies.
   Open resource forums may request new allocations under the
   registration requirement as describe in Section 7.  Individuals may
   requests 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) arc.  Increasingly used
   form of OID is in the area of health care and public health
   informatics in the United States.  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) node.

   Important to note that PENs are not always representing manufacturer
   ID or Vendor ID.

   Additional sub-trees of the existing arc
   iso.org.dod.internet.private.enterprise.<PEN> can be created by an
   administrator of the arc when the Registrant (Company) needs
   additional OIDs.  In such cases there is no need to request multiple
   PENs.  Note that IANA does not manage allocations of sub-OIDs below a
   iso.org.dod.internet.private.enterprise.<PEN> OID, so it doesn't need
   to be notified about suballocations.

   The owner of a Private Enterprise Number can append any number of
   numbers at the end (i.e. to perform its own sub-allocations).  For
   example, for LDAP, one 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



Liang & Melnikov         Expires April 20, 2014                 [Page 4]


Internet-Draft                  PEN v.0.2                   October 2013


   iso.org.dod.internet.private.enterprise.<PEN>.1.200 for subsidiaries
   an/or divisions

   But 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, etc.

5.  Syntax for Private Enterprise Numbers

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

   o Maximum value for PENs is hereby defined within 2**32-1 with 0 and
   0xFFFFFF (in hex) marked as Reserved.

   o TBD: Subset of ASCII character (at least ALPHA, DIGIT and "-", SP)

   o TBD: Special characters (Use LetterDigits from draft-ietf-precis-
   framework?)

   o MUST NOT begin or end with a hyphen

   o Values "Reserved" MUST NOT be allocated

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

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.  The
   requester can submit an online application form.  Information to be
   included:

   Registrant (Company/Organization) Name (REQUIRED)



Liang & Melnikov         Expires April 20, 2014                 [Page 5]


Internet-Draft                  PEN v.0.2                   October 2013


   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)

   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: The e-mail address
   of 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 full postal address of the
   organization/individual requesting the PEN, including state/province,
   zip/postal code, country, etc.

   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: The full name of the individual who will be responsible
   for the PEN on behalf of the company.

   Contact Postal Address: The full postal address of the individual
   responsible the PEN, including state/province, zip/postal code,
   country, etc.






Liang & Melnikov         Expires April 20, 2014                 [Page 6]


Internet-Draft                  PEN v.0.2                   October 2013


   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.

   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:

   Registrant (Company/Organization) Name can never be changed.  However
   if the Company/Organization has been merged or acquired by another
   enterprise, the Registrant Name can be annotated in the registry with
   the new owner.  Note that such annotations would require 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 verifications.  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.





Liang & Melnikov         Expires April 20, 2014                 [Page 7]


Internet-Draft                  PEN v.0.2                   October 2013


   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.

   Letters and documentations can be in forms of e-documents, PDF, fax
   however feasible to the applicants.  The documents can be supplied to
   IANA via an email message or in facsimile.

   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 by an existing
   allocation, it is NOT recommended to remove the registration.

   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 "Reserved"
   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.  2187, 2188,
   3513, 4164, 4565, 4600, 4913, 4999, 5099, 5144, 5201, 5683, 5777,
   6260, 6619, 14827, and the range from 11670 to 11769, 16739, 26975

8.  Security Considerations

   See the Security Considerations section in BCP 26 [RFC5226], and note
   that improper definition and application of IANA registration



Liang & Melnikov         Expires April 20, 2014                 [Page 8]


Internet-Draft                  PEN v.0.2                   October 2013


   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

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

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

   [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





Liang & Melnikov         Expires April 20, 2014                 [Page 9]


Internet-Draft                  PEN v.0.2                   October 2013


   Pearl Liang
   ICANN
   12025 Waterfront Drive, Suite 300
   Los Angeles, CA  90094
   USA

   Email: pearl.liang@icann.org


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

   Email: Alexey.Melnikov@isode.com


































Liang & Melnikov         Expires April 20, 2014                [Page 10]


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