<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="true" docName="draft-pti-pen-registration-10" indexInclude="true" ipr="trust200902" number="9371" prepTime="2023-03-01T16:42:09" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="4" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-pti-pen-registration-10" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9371" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="PEN Registration">Registration Procedures for Private Enterprise Numbers (PENs)</title>
    <seriesInfo name="RFC" value="9371" stream="IETF"/>
    <author initials="A." surname="Baber" fullname="Amanda Baber">
      <organization abbrev="IANA" showOnFrontPage="true">Internet Assigned Numbers Authority</organization>
      <address>
        <postal>
          <extaddr>PTI/ICANN</extaddr>
          <street>12025 Waterfront Drive</street>
          <city>Los Angeles</city>
          <code>90094</code>
          <country>United States of America</country>
        </postal>
        <email>amanda.baber@iana.org</email>
      </address>
    </author>
    <author fullname="Paul Hoffman" initials="P" surname="Hoffman">
      <organization showOnFrontPage="true">ICANN</organization>
      <address>
        <postal>
          <street>12025 Waterfront Drive</street>
          <city>Los Angeles</city>
          <code>90094</code>
          <country>United States of America</country>
        </postal>
        <email>paul.hoffman@icann.org</email>
      </address>
    </author>
    <date month="03" year="2023"/>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
This document describes how Private Enterprise Numbers (PENs) are registered by IANA. It
shows how to request a new PEN and how to modify a current PEN. It also gives
a brief overview of PEN uses.
</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9371" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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 Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-uses-of-pens">Uses of PENs</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pen-assignment">PEN Assignment</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requesting-a-pen-assignment">Requesting a PEN Assignment</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-modifying-an-existing-recor">Modifying an Existing Record</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-deleting-a-pen-record">Deleting a PEN Record</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pen-registry-specifics">PEN Registry Specifics</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
Private Enterprise Numbers (PENs) are identifiers that can be used anywhere that an ASN.1
object identifier (OID) <xref target="ASN1" format="default" sectionFormat="of" derivedContent="ASN1"/> can be used. Originally, PENs were developed
so that organizations that needed to identify themselves in Simple Network Management
Protocol (SNMP) <xref target="RFC3411" format="default" sectionFormat="of" derivedContent="RFC3411"/> Management Information Base (MIB) configurations
could do so easily. PENs are also useful in any application or configuration language that
needs OIDs to identify organizations. 
</t>
      <t indent="0" pn="section-1-2">
The IANA Functions Operator, referred to in this document as "IANA",
manages and maintains the PEN registry in consultation with the IESG.
PENs are issued from an OID prefix that was assigned to IANA. That OID
prefix is 1.3.6.1.4.1. Using the (now archaic) notation of ownership names in the OID
tree, that corresponds to:
</t>
      <artwork name="" type="" align="left" alt="" pn="section-1-3">
1   3   6   1        4       1
iso.org.dod.internet.private.enterprise
</artwork>
      <t indent="0" pn="section-1-4">
A PEN is an OID that begins with the PEN prefix. Thus, the OID 1.3.6.1.4.1.32473 is a
PEN.
</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-uses-of-pens">Uses of PENs</name>
        <t indent="0" pn="section-1.1-1">
Once a PEN has been assigned to an organization, individual, or other entity, that assignee can use the
PEN by itself (possibly to represent the assignee) or as the root of other OIDs
associated with the assignee. For example, if an assignee is assigned the PEN
1.3.6.1.4.1.32473, it might use 1.3.6.1.4.1.32473.7 to identify a protocol extension
and use 1.3.6.1.4.1.32473.12.3 to identify a set of algorithms that it supports in a
protocol.
</t>
        <t indent="0" pn="section-1.1-2">
Neither IANA nor the IETF can control how an assignee uses
its PEN. In fact, no one can exert such control: that is the meaning of "private"
in "private enterprise number". Similarly, no one can prevent an assignee that
is not the registered owner of a PEN from using that PEN, or any PEN, however they want.
</t>
        <t indent="0" pn="section-1.1-3">
A very common use of PENs is to give unique identifiers in IETF protocols. SNMP MIB
configuration files use PENs for identifying the origin of values. Protocols that use
PENs as identifiers of extension mechanisms include
RADIUS <xref target="RFC2865" format="default" sectionFormat="of" derivedContent="RFC2865"/>,
Diameter <xref target="RFC6733" format="default" sectionFormat="of" derivedContent="RFC6733"/>,
Syslog <xref target="RFC5424" format="default" sectionFormat="of" derivedContent="RFC5424"/>,
RSVP <xref target="RFC5284" format="default" sectionFormat="of" derivedContent="RFC5284"/>,
and vCard <xref target="RFC6350" format="default" sectionFormat="of" derivedContent="RFC6350"/>.
</t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-pen-assignment">PEN Assignment</name>
      <t indent="0" pn="section-2-1">
PENs are assigned by IANA. The registry is located at 
<eref target="https://www.iana.org/assignments/enterprise-numbers" brackets="angle"/>, and requests for new assignments 
or the modification of existing assignments can also be submitted at that URL.
</t>
      <t indent="0" pn="section-2-2">
IANA maintains the PEN registry in accordance with the "First Come First
Served" registration policy described in <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.  Values are 
assigned sequentially.
</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-requesting-a-pen-assignment">Requesting a PEN Assignment</name>
        <t indent="0" pn="section-2.1-1">
Requests for assignment must provide the name of the assignee, the name of a 
public contact who can respond to questions about the assignment, and contact 
information that can be used to verify change requests. The contact's name and
email address will be included in the public registry.
</t>
        <t indent="0" pn="section-2.1-2">
A prospective assignee may request multiple PENs, but obtaining one PEN and making 
internal sub-assignments is typically more appropriate. (Sub-assignments 
should not be reported to IANA.)
</t>
        <t indent="0" pn="section-2.1-3">
IANA may refuse to process abusive requests.
</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-modifying-an-existing-recor">Modifying an Existing Record</name>
        <t indent="0" pn="section-2.2-1">
Any of the information associated
with a registered value can be modified, including the name of the assignee.
</t>
        <t indent="0" pn="section-2.2-2">
Modification requests require authorization by a representative of the 
assignee.  Authorization will be validated either with information kept on 
file with IANA or with other identifying documentation, if necessary.
</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.3">
        <name slugifiedName="name-deleting-a-pen-record">Deleting a PEN Record</name>
        <t indent="0" pn="section-2.3-1">
Although such requests are rare, registrations can be deleted. When a 
registration is deleted, all identifying information is removed from the 
registry, and the value is marked as "returned." Returned values will not be 
made available for reassignment until all other unassigned values have been 
exhausted; as can be seen in <xref target="specifics" format="default" sectionFormat="of" derivedContent="Section 3"/>, the unassigned values
are unlikely to ever run out.
</t>
      </section>
    </section>
    <section anchor="specifics" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-pen-registry-specifics">PEN Registry Specifics</name>
      <t indent="0" pn="section-3-1">
The range for values after the PEN prefix is 0 to 2**32-1. The values 0 and 4294967295
(2**32-1) are reserved. Note that while the original PEN definition had no upper bound for
the value after the PEN prefix, there is now an upper bound due to some IETF
protocols limiting the size of that value. For example, Diameter <xref target="RFC6733" format="default" sectionFormat="of" derivedContent="RFC6733"/>
limits the value to 2**32-1.
</t>
      <t indent="0" pn="section-3-2">
There is a PEN number, 32473, reserved for use as an example in documentation. This
reservation is described in <xref target="RFC5612" format="default" sectionFormat="of" derivedContent="RFC5612"/>.
</t>
      <t indent="0" pn="section-3-3">
Values in the registry that have unclear ownership are marked "Reserved". These values
will not be reassigned to a new company or individual without consulting the IESG.
</t>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-4-1">
Per this document, IANA has made the following changes to the PEN registry:
</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4-2">
        <li pn="section-4-2.1">Values 2187, 2188, 3513, 4164, 4565, 4600, 4913, 4999, 5099, 5144, 5201,
5683, 5777, 6260, 6619, 14827, 16739, 26975, and the range from 11670 to
11769, which had been missing from the registry, have been listed as
"Reserved." As described in <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>, reserved values can be
released by the IESG.
</li>
        <li pn="section-4-2.2">
This document has been listed in the registry's "Reference" field.
</li>
        <li pn="section-4-2.3">
"First Come First Served" has been listed as its registration procedure.
</li>
      </ul>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">
Registering PENs does not introduce any significant security considerations.
</t>
      <t indent="0" pn="section-5-2">
There is no cryptographic binding of a registrant in the PEN registry and the PEN(s)
assigned to them. Thus, the entries in the PEN registry cannot be used to validate the
ownership of a PEN in use. For example, if the PEN 1.3.6.1.4.1.32473 is seen in a protocol
as indicating the owner of some data, there is no way to securely correlate that use with
the name and assignee of the owner listed in the PEN registry.
</t>
    </section>
  </middle>
  <back>
    <references pn="section-6">
      <name slugifiedName="name-references">References</name>
      <references pn="section-6.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
      </references>
      <references pn="section-6.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="ASN1" target="https://www.itu.int/rec/T-REC-X.690/en" quoteTitle="true" derivedAnchor="ASN1">
          <front>
            <title>Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date month="February" year="2021"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.690"/>
        </reference>
        <reference anchor="RFC2865" target="https://www.rfc-editor.org/info/rfc2865" quoteTitle="true" derivedAnchor="RFC2865">
          <front>
            <title>Remote Authentication Dial In User Service (RADIUS)</title>
            <author fullname="C. Rigney" initials="C." surname="Rigney"/>
            <author fullname="S. Willens" initials="S." surname="Willens"/>
            <author fullname="A. Rubens" initials="A." surname="Rubens"/>
            <author fullname="W. Simpson" initials="W." surname="Simpson"/>
            <date month="June" year="2000"/>
            <abstract>
              <t indent="0">This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2865"/>
          <seriesInfo name="DOI" value="10.17487/RFC2865"/>
        </reference>
        <reference anchor="RFC3411" target="https://www.rfc-editor.org/info/rfc3411" quoteTitle="true" derivedAnchor="RFC3411">
          <front>
            <title>An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks</title>
            <author fullname="D. Harrington" initials="D." surname="Harrington"/>
            <author fullname="R. Presuhn" initials="R." surname="Presuhn"/>
            <author fullname="B. Wijnen" initials="B." surname="Wijnen"/>
            <date month="December" year="2002"/>
            <abstract>
              <t indent="0">This document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks.  The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time.  The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data.  This document obsoletes RFC 2571. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="62"/>
          <seriesInfo name="RFC" value="3411"/>
          <seriesInfo name="DOI" value="10.17487/RFC3411"/>
        </reference>
        <reference anchor="RFC5284" target="https://www.rfc-editor.org/info/rfc5284" quoteTitle="true" derivedAnchor="RFC5284">
          <front>
            <title>User-Defined Errors for RSVP</title>
            <author fullname="G. Swallow" initials="G." surname="Swallow"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <date month="August" year="2008"/>
            <abstract>
              <t indent="0">The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user-defined errors exists in RSVP.</t>
              <t indent="0">This document defines a USER_ERROR_SPEC to be used in addition to the ERROR_SPEC to carry additional user information related to errors. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5284"/>
          <seriesInfo name="DOI" value="10.17487/RFC5284"/>
        </reference>
        <reference anchor="RFC5424" target="https://www.rfc-editor.org/info/rfc5424" quoteTitle="true" derivedAnchor="RFC5424">
          <front>
            <title>The Syslog Protocol</title>
            <author fullname="R. Gerhards" initials="R." surname="Gerhards"/>
            <date month="March" year="2009"/>
            <abstract>
              <t indent="0">This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way.</t>
              <t indent="0">This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5424"/>
          <seriesInfo name="DOI" value="10.17487/RFC5424"/>
        </reference>
        <reference anchor="RFC5612" target="https://www.rfc-editor.org/info/rfc5612" quoteTitle="true" derivedAnchor="RFC5612">
          <front>
            <title>Enterprise Number for Documentation Use</title>
            <author fullname="P. Eronen" initials="P." surname="Eronen"/>
            <author fullname="D. Harrington" initials="D." surname="Harrington"/>
            <date month="August" year="2009"/>
            <abstract>
              <t indent="0">This document describes an Enterprise Number (also known as SMI Network Management Private Enterprise Code) for use in documentation.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5612"/>
          <seriesInfo name="DOI" value="10.17487/RFC5612"/>
        </reference>
        <reference anchor="RFC6350" target="https://www.rfc-editor.org/info/rfc6350" quoteTitle="true" derivedAnchor="RFC6350">
          <front>
            <title>vCard Format Specification</title>
            <author fullname="S. Perreault" initials="S." surname="Perreault"/>
            <date month="August" year="2011"/>
            <abstract>
              <t indent="0">This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.).  This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6350"/>
          <seriesInfo name="DOI" value="10.17487/RFC6350"/>
        </reference>
        <reference anchor="RFC6733" target="https://www.rfc-editor.org/info/rfc6733" quoteTitle="true" derivedAnchor="RFC6733">
          <front>
            <title>Diameter Base Protocol</title>
            <author fullname="V. Fajardo" initials="V." role="editor" surname="Fajardo"/>
            <author fullname="J. Arkko" initials="J." surname="Arkko"/>
            <author fullname="J. Loughney" initials="J." surname="Loughney"/>
            <author fullname="G. Zorn" initials="G." role="editor" surname="Zorn"/>
            <date month="October" year="2012"/>
            <abstract>
              <t indent="0">The Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations.  This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications.  The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6733"/>
          <seriesInfo name="DOI" value="10.17487/RFC6733"/>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">
An earlier draft version of this document was authored by <contact fullname="Pearl Liang"/> and
<contact fullname="Alexey Melnikov"/>. Additional significant contributions have come from
<contact fullname="Dan Romascanu"/>, <contact fullname="Bert Wijnen"/>, <contact fullname="David Conrad"/>, <contact fullname="Michelle Cotton"/>, and <contact fullname="Benoit Claise"/>.
</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="A." surname="Baber" fullname="Amanda Baber">
        <organization abbrev="IANA" showOnFrontPage="true">Internet Assigned Numbers Authority</organization>
        <address>
          <postal>
            <extaddr>PTI/ICANN</extaddr>
            <street>12025 Waterfront Drive</street>
            <city>Los Angeles</city>
            <code>90094</code>
            <country>United States of America</country>
          </postal>
          <email>amanda.baber@iana.org</email>
        </address>
      </author>
      <author fullname="Paul Hoffman" initials="P" surname="Hoffman">
        <organization showOnFrontPage="true">ICANN</organization>
        <address>
          <postal>
            <street>12025 Waterfront Drive</street>
            <city>Los Angeles</city>
            <code>90094</code>
            <country>United States of America</country>
          </postal>
          <email>paul.hoffman@icann.org</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
