<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902" docName="draft-ietf-lisp-name-encoding-17">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<!--  Edited by Dino Farinacci farinacci@gmail.com -->
<!--  Edited by Luigi Iannone ggx@gigix.net -->

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?> docName="draft-ietf-lisp-name-encoding-17" number="9735" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

<front>
  <title>LISP
    <title abbrev="LISP Name Encoding">Locator/ID Separation Protocol (LISP) Distinguished Name Encoding</title>
    <seriesInfo name="RFC" value="9735"/>
    <author initials='D' initials="D" surname="Farinacci" fullname='Dino Farinacci'> fullname="Dino Farinacci">
      <organization>lispers.net</organization>
      <address>
        <postal>
      <street></street>
          <city>San Jose</city>
          <region>CA</region>
      <code></code>
      <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>farinacci@gmail.com</email>
      </address>
    </author>
    <author initials="L." surname="Iannone" fullname="Luigi Iannone" role="editor">
      <organization abbrev="Huawei">Huawei Technologies France S.A.S.U.</organization>
      <address>
        <postal>
          <street>18, Quai du Point du Jour</street>
          <city>Boulogne-Billancourt</city>
          <code>92100</code>
          <country>France</country>
        </postal>
        <email>luigi.iannone@huawei.com</email>
      </address>
    </author>
    <date />
  <area>Routing Area</area>
  <workgroup>Internet Engineering Task Force</workgroup>
  <keyword>template</keyword> month="February" year="2025"/>
    <area>RTG</area>
    <workgroup>lisp</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

    <abstract>
      <t>This documents document defines how to use the Address Family Identifier (AFI) 17 "Distinguished Names" Name" in LISP. the Locator/ID Separation Protocol (LISP).  LISP introduces two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). Distinguished Names (DNs) can be used either in Endpoint Identifiers (EID) records either EID-Records or Routing Locators (RLOC) records RLOC-Records in LISP control messages to convey additional information.</t>
    </abstract>

  <note title="Requirements Language">
    <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
    "MAY", and "OPTIONAL" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all
    capitals, as shown here.</t>
  </note>
  </front>
  <middle>
    <section title="Introduction">
    <t>The LISP architecture and protocols numbered="true" toc="default">
      <name>Introduction</name>

      <t>LISP (<xref target="RFC9300"/>, target="RFC9300" format="default"/> and <xref target="RFC9301"/>) target="RFC9301" format="default"/>) introduces two new numbering spaces, spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). To provide flexibility for current and future applications, these values can be encoded in
    LISP control messages using a general syntax that includes the Address
    Family Identifier (AFI).</t>
      <t>The length of addresses encoded in EID EID-Records and RLOC records RLOC-Records can be easily be determined by the AFI field, as the size of the address is implicit in its AFI value. For instance, for AFI = equal to 1, which is IP "IP (IP version 4, 4)", the address length is known to be 4 octets. However, AFI 17 "Distinguished Name", is a variable length variable-length value, so the length cannot be determined solely from the AFI value 17. 17 <xref target="ADDRESS-FAMILY" format="default"/>. This document defines a termination character, an 8-bit value of 0 0, to be used as a string terminator so the length can be determined.</t>
      <t>LISP Distinguished Names DNs are useful when encoded either in
    EID-Records or RLOC-records RLOC-Records in LISP control messages. As EIDs,
    they can be registered in the mapping system Mapping System to find resources,
    services, or simply be used as a self-documenting feature that
    accompany
    accompanies other address specific address-specific EIDs. As RLOCs, Distinguished
    Names, DNs, along with RLOC specific RLOC-specific addresses and parameters, can be
    used as labels to identify equipment type, location, or any
    self-documenting string a registering device desires to
      convey.</t>

      <t>The Distinguished Name field in this document has no relationship to the similarly named field in the Public-Key Infrastructure using X.509 (PKIX) specifications (e.g., <xref target="RFC5280"/>.</t> target="RFC5280" format="default"/>).</t>
    </section>
    <section title="Definition of Terms">
    <t><list style="hanging">
      <t hangText="Address numbered="true" toc="default">
      <name>Terminology</name>
    <section numbered="true" toc="default">
      <name>Definition</name>
      <dl newline="false" spacing="normal">
        <dt>Address Family Identifier (AFI):">a (AFI):</dt>
        <dd>a term used to describe an address encoding in a packet. An
        address family is currently defined for IPv4 or IPv6 addresses. See
        <xref
      target="IANA-ADDRESS-FAMILY-REGISTRY" /> target="ADDRESS-FAMILY" format="default"/> for
        details on other types of information that can be AFI encoded.</t>
    </list></t> encoded.</dd>
      </dl>
    </section>
    <section title="Distinguished Name Format">

    <figure>
      <preamble>An AFI=17 Distinguished numbered="true" toc="default">
      <name>Requirements Language</name>

        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
    </section>
    </section>

    <section numbered="true" toc="default">
      <name>Distinguished Name Format</name>
      <t>An AFI 17 "Distinguished Name" is encoded as:</preamble>
      <artwork><![CDATA[ as:</t>

      <artwork name="" type="" align="left" alt=""><![CDATA[
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |            AFI = 17           |    NULL Terminated US-ASCII    NULL-Terminated (0x00)     ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    US-ASCII String            |
 ~                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ]]></artwork>
      <postamble />
    </figure>
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

      <t>The variable length variable-length string of characters are encoded as a NULL NULL-terminated (0x00) terminated US-ASCII character-set character set as defined in <xref target="RFC3629" />, format="default"/>, where UTF-8 has the characteristic of preserving the full US-ASCII
      range. A NULL character MUST be <bcp14>MUST</bcp14> appear only once in the string and MUST <bcp14>MUST</bcp14> be at the end of the string.</t>

      <t>When Distinguished Names DNs are encoded for EIDs, the EID Mask-Len
    length of the EIDs as they appear in EID-Records EID-Records, for all LISP
    control messages <xref target="RFC9301"/> target="RFC9301" format="default"/>, is the length of the
    string in bits (including the terminating NULL NULL-terminated 0x00 octet).</t>
      <t>Where Distinguished Names DNs are encoded anywhere else (i.e., nested in LCAF LISP Canonical Address Format (LCAF) encodings <xref target="RFC8060"/>), then a target="RFC8060" format="default"/>), an explicit length field can be used to indicate the length of the ASCII string in octets, the octets.  The length field MUST <bcp14>MUST</bcp14> include the NULL 0 octet. octet (0x00). The string MUST <bcp14>MUST</bcp14> still be NULL terminated. NULL-terminated (0x00). If a NULL 0 octet (0x00) appears before the end of the octet field, i.e., the NULL octet (0x00) appears before the the last position in the octet fields, then the string MAY <bcp14>MAY</bcp14> be accepted and the octets after the NULL 0 octet MUST NOT (0x00) <bcp14>MUST NOT</bcp14> be used as part of the octet string.</t>
      <t>If the octet after the AFI field is the NULL 0 octet, octet (0x00), the
    string is a NULL string and MUST <bcp14>MUST</bcp14> be accepted. That is, an AFI=17 AFI 17 "Distinguished Name"
    encoded string MUST <bcp14>MUST</bcp14> be at least 1 octet in length.</t>
    </section>
    <section title="Mapping System numbered="true" toc="default">
      <name>Mapping-System Lookups for Distinguished Name EIDs">
     <t>Distinguished Name EID lookups MUST DN EIDs</name>

      <t>When performing DN-EID lookups, Map-Request messages <bcp14>MUST</bcp14> carry as an EID Mask-Len length equal to the length of the name string. string in bits. This instructs the mapping system Mapping System to do either an exact match exact-match or longest match a longest-match lookup.</t>
      <t>If the Distinguished Name DN EID is registered with the same length as the length in a Map-Request, the Map-Server (when configured for proxy Map-Replying) returns an exact match exact-match lookup with the same EID Mask-Len length. If a less specific name is registered, then the Map-Server
      returns the registered name with the registered EID Mask-Len length.</t>

      <t>For example, if the registered EID name is "ietf" with an EID Mask-Len length of 40 bits (the length of the string "ietf" plus the null length of the NULL octet is (0x00) makes 5 octets), and a Map-Request is received for EID name "ietf.lisp" with an EID Mask-Len length of 80 bits, the Map-Server will return EID "ietf" with a length of 40 bits.</t>
    </section>
    <section title="Example Use-Cases" anchor="USECASE"> anchor="USECASE" numbered="true" toc="default">
      <name>Example Use Cases</name>
      <t>This section identifies three specific use-cases use-case examples for
    the Distinguished Name format. Two DN format: two are used for an EID encoding
    and one for an RLOC-record RLOC-Record encoding. When storing public keys in
    the mapping system, Mapping System, as in <xref
    target="I-D.ietf-lisp-ecdsa-auth"/>, target="I-D.ietf-lisp-ecdsa-auth" format="default"/>, a well-known format for a
    public-key hash can be encoded as a Distinguished Name. DN. When
    street location to GPS coordinate
    street-location-to-GPS-coordinate mappings exist in the mapping
    system, Mapping
    System, as in <xref target="I-D.ietf-lisp-geo"/>, target="I-D.ietf-lisp-geo" format="default"/>, the street
    location can be a free form free-form UTF-8 ASCII representation (with whitespace
    characters) encoded as a Distinguished Name. DN. An RLOC that
    describes an Ingress or Egress Tunnel Router (xTR) behind a NAT
    device can be identified by its router name, as in <xref
    target="I-D.farinacci-lisp-lispers-net-nat"/>. target="I-D.farinacci-lisp-lispers-net-nat" format="default"/>. In this case,
    Distinguished Name
    DN encoding is used in NAT Info-Request messages
    after the EID-prefix field of the message.</t>
    </section>
    <section title="Name Collision Considerations"> numbered="true" toc="default">
      <name>Name-Collision Considerations</name>
      <t>When a Distinguished Name DN encoding is used to format an EID,
    the uniqueness and allocation concerns are no different than
    registering IPv4 or IPv6 EIDs to the mapping system. Mapping System. See <xref
    target="RFC9301"/> target="RFC9301" format="default"/> for more details. Also, the use-case documents
    specified use cases documented in <xref target="USECASE"/> target="USECASE" format="default"/> of this specification provide allocation recommendations for their specific uses.</t>
      <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that each use-case use case register their Distinguished
    Names DNs with a unique Instance-ID. For any use-cases which Any use cases that require
    different uses for Distinguish Names DNs within an Instance-ID MUST <bcp14>MUST</bcp14>
    define their own Instance-ID and structure syntax structure for the name
    registered to the Mapping System. See the encoding procedures in
    <xref target="I-D.ietf-lisp-vpn"/> target="I-D.ietf-lisp-vpn" format="default"/> for an example.</t>
    </section>
    <section title="Security Considerations">
    <t>Distinguished Names numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>DNs are used in mappings that are part of the LISP control plane and may be encoded using LCAF, as such LCAF; thus, the security considerations of <xref target="RFC9301"/> target="RFC9301" format="default"/> and <xref target="RFC8060"/> target="RFC8060" format="default"/> apply.</t>
    </section>
    <section title="IANA Considerations">
    <t>The code-point value in this specification, namely AFI 17, is already
    allocated in <xref target="IANA-ADDRESS-FAMILY-REGISTRY" />.</t> numbered="true" toc="default">
      <name>IANA Considerations</name>

      <t>This document has no IANA actions.</t>

    </section>
    <section title="Sample numbered="true" toc="default">
      <name>Sample LISP Distinguished Name (DN) DN Deployment Experience"> Experience</name>

      <t>Practical implementations of the LISP Distinguished Name
    specification DN, defined in this document, have been running in production networks for some
    time. The following sections provide some examples of its usage
    and lessons gathered learned out of this experience.</t>
      <section title="DNs numbered="true" toc="default">
        <name>DNs to Advertise Specific Device Roles or Functions"> Functions</name>

<!--[rfced] We had a few questions regarding this text:

Original:
In a practical implementation of
[I-D.ietf-lisp-site-external-connectivity] on LISP deployments,
routers running as Proxy Egress Tunnel Routers (Proxy-ETRs) register
their role with the Mapping System in order to attract traffic
destined for external networks.

a) Is there an update we can make to describe which part/concept of
the cited document is being practically implemented (e.g., the
registration procedures, requirements, etc.).
-->
        <t>In a practical implementation of <xref target="I-D.ietf-lisp-site-external-connectivity" /> format="default"/> on LISP
      deployments, routers running as Proxy Egress Tunnel Routers
      (Proxy-ETRs) register their role with the Mapping System in
      order to attract traffic destined for external
      networks. Practical implementations of this functionality make
      use of a Distinguished Name DN as an EID to identify the Proxy-ETR
	role in a Map-Registration.</t>

        <t>In this case case, all Proxy-ETRs supporting this function register
      a common Distinguished Name DN together with their own offered
      locator. The Mapping-System Mapping System aggregates the locators received
      from all Proxy-ETRs as a common locator-set that is associated
      with this DN EID. The Distinguished Name in In this case scenario, the DN serves as a
      common reference EID that can be requested (or subscribed as per
      <xref target="RFC9437"/>) target="RFC9437" format="default"/>) to dynamically gather this Proxy-ETR
      list as specified in the LISP Site External Connectivity
      document.</t>
      document <xref target="I-D.ietf-lisp-site-external-connectivity" format="default"/>.</t>
        <t>The use of a Distinguished Name in this case DN here provides
      descriptive information about the role being registered and
      allows the Mapping System to form locator-sets associated to with a
      specific role. These locator-sets can be distributed on-demand
      based on using the shared DN as EID. It also allows the network
      admin and the Mapping System to selectively choose what roles
      and functions can be registered and distributed to the rest of
      the participants in the network.</t>
      </section>
      <section title="DNs numbered="true" toc="default">
        <name>DNs to Drive xTR On-Boarding Procedures"> Onboarding Procedures</name>
        <t>Following the LISP reliable transport <xref target="I-D.ietf-lisp-map-server-reliable-transport" />, format="default"/>, ETRs
      that plan to switch to using reliable transport to hold
      registrations first need to start with traditional UDP
      registrations. The UDP registration allows the Map-Server to
      perform basic authentication of the ETR and to create the necessary
      state to permit the reliable transport session to be established
      (e.g., establish a passive open on TCP port 4342 and add the ETR
      RLOC to the list allowed to establish a session).</t>
        <t>In the basic implementation of this process, the ETRs need to
      wait until local mappings are available and ready to be
      registered with the Mapping System. Furthermore, when the mapping
      system Mapping
      System is distributed, the ETR requires having one specific
      mapping ready to be registered with each one of the relevant
      Map-Servers. This process may delay the onboarding of ETRs with
      the Mapping System so that they can switch to using reliable
      transport. This can also lead to generating unnecessary
      signaling as a reaction to certain triggers like local port
      flaps and device failures.</t>
        <t>The use of dedicated name registrations allows driving this
      initial ETR on-boarding onboarding on the Mapping System as a deterministic
      process that does not depend on the availability of other
      mappings. It also provides more stability to the reliable
      transport session to survive through transient events.</t>
        <t>In practice, LISP deployments use dedicated Distinguished
      Names DNs that are registered as soon as xTRs come online with all
      the necessary Map-Servers in the Mapping System. The mapping
      with the dedicated DN together with the RLOCs of each Egress
      Tunnel Router (ETR) in the locator-set is used to drive the
      initial UDP registration and also to keep the reliable transport
      state stable through network condition changes. On the
      Map-Server, these DN registrations facilitate setting up the
      necessary state to onboard new ETRs rapidly and in a more
      deterministic manner.</t>
      </section>
      <section title="DNs for NAT-Traversal">
      <t>The numbered="true" toc="default">

<!--[rfced] We had a few questions about these similar sentences
     appearing in Sections 9.3-9.5:

a) Perhaps we can update to avoid saying a website has had
experience in these sentences?

b) Should the same citation appear in each of the sentences?

Original:
The open source lispers.net NAT-Traversal implementation
      <xref target="I-D.farinacci-lisp-lispers-net-nat"/>
[I-D.farinacci-lisp-lispers-net-nat] has had 10 years of deployment
experience using Distinguished Names for documenting xTRs versus Re-encapsulating Re-
encapsulating Tunnel Router (RTRs) as they appear in a locator-set.</t>
    </section>

    <section title="DNs locator-set.

Perhaps:
At the time of writing, the open-source lispers.net NAT-Traversal
implementation [I-D.farinacci-lisp-lispers-net-nat] has deployed
Distinguished Names for Self-Documenting RLOC Names">
      <t>The documenting xTRs versus Re-encapsulating
Tunnel Routers (RTRs) as they appear in a locator-set for 10 years.

Original:
The open source lispers.net implementation has had 10 years of
      self-documenting self-
documenting RLOC names in production and pilot environments.

Perhaps:
At the time of writing, the open-source lispers.net implementation
[I-D.farinacci-lisp-lispers-net-nat] has self-documented RLOC names in
production and pilot environments.

Original:
The open source lispers.net implementation has had 10 years of
deployment experience allowing xTRs to register EIDs as Distinguished
Names.

Perhaps:
At the time of writing, the open-source lispers.net implementation
[I-D.farinacci-lisp-lispers-net-nat] has deployed xTRs that are
allowed to register EIDs as Distinguished Names for 10 years.

-->

        <name>DNs for NAT-Traversal</name>
        <t>At the time of writing, the open-source lispers.net NAT-Traversal implementation
      <xref target="I-D.farinacci-lisp-lispers-net-nat" format="default"/> has deployed DNs for
      documenting xTRs versus Re-encapsulating Tunnel Routers (RTRs) as
      they appear in a locator-set for 10 years.</t>
      </section>
      <section numbered="true" toc="default">
        <name>DNs for Self-Documenting RLOC Names</name>
        <t>At the time of writing, the open-source lispers.net implementation <xref target="I-D.farinacci-lisp-lispers-net-nat" format="default"/> has self-documented RLOC names in production and pilot
      environments for 10 years. The RLOC name is encoded with the RLOC address in
      Distinguished Name
      DN format.</t>
      </section>
      <section title="DNs used numbered="true" toc="default">
        <name>DNs Used as EID Names">
      <t>The open source Names</name>
        <t>At the time of writing, the open-source lispers.net implementation <xref target="I-D.farinacci-lisp-lispers-net-nat" format="default"/> has had 10 years of deployment
      experience allowing deployed xTRs that are allowed to register EIDs as Distinguished
      Names. DNs for 10 years. The LISP Mapping System can be used as a DNS proxy for
      Name-to-EID-address or Name-to-RLOC-address mappings. The
      implementation also supports Name-to-Public-Key mappings to
      provide key management features in <xref target="I-D.ietf-lisp-ecdsa-auth" />.</t> format="default"/>.</t>
      </section>
    </section>
  </middle>

  <back>
  <references title='Normative References'>
    <?rfc include="reference.RFC.2119'?>
    <?rfc include="reference.RFC.8174'?>
    <?rfc include="reference.RFC.9300'?>
    <?rfc include="reference.RFC.9301'?>
    <?rfc include="reference.RFC.9437'?>
    <?rfc include="reference.RFC.3629'?>
      <displayreference target="I-D.ietf-lisp-ecdsa-auth" to="LISP-ECDSA"/>
      <displayreference target="I-D.ietf-lisp-geo" to="LISP-GEO"/>
      <displayreference target="I-D.farinacci-lisp-lispers-net-nat" to="LISPERS-NET-NAT"/>
      <displayreference target="I-D.ietf-lisp-vpn" to="LISP-VPN"/>
      <displayreference target="I-D.ietf-lisp-site-external-connectivity" to="LISP-EXT"/>
      <displayreference target="I-D.ietf-lisp-map-server-reliable-transport" to="LISP-MAP"/>

    <references>

      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9300.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9301.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9437.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>

        <reference anchor="IANA-ADDRESS-FAMILY-REGISTRY"> anchor="ADDRESS-FAMILY" target="https://www.iana.org/assignments/address-family-numbers">
          <front>
	    <title>IANA Address
            <title>Address Family Numbers Registry</title>
        <author fullname="IANA"/>
	    <date year="2024" month="December" /> Numbers</title>
            <author>
	      <organization>IANA</organization>
	    </author>
          </front>
      <refcontent>https://www.iana.org/assignments/address-family-numbers/</refcontent>
        </reference>

      </references>

  <references title='Informative References'>
    <?rfc include="reference.RFC.5280'?>
    <?rfc include="reference.RFC.8060'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-ecdsa-auth.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-geo.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.farinacci-lisp-lispers-net-nat.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-vpn.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-site-external-connectivity.xml'?>
    <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-map-server-reliable-transport.xml'?>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8060.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-ecdsa-auth.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-geo.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.farinacci-lisp-lispers-net-nat.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-vpn.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-site-external-connectivity.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-map-server-reliable-transport.xml"/>
      </references>
    </references>
    <section title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The author authors would like to thank the LISP WG for their review and
      acceptance of this draft. And a document. A special thank you goes to Marc
    Portoles <contact
      fullname="Marc Portoles"/> for moving this document through the process
      and providing deployment experience deployment-experience samples.</t>
    </section>

  <section title="Document Change Log">

    <section title="Changes to draft-ietf-lisp-name-encoding-17">
      <t><list style="symbols">
        <t>Submitted 9 December 2024.</t>
       <t>Refined wording for explicit length usage.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-16">
      <t><list style="symbols">
        <t>Submitted 6 December 2024.</t>
       <t>Fixed wording for explicit length usage.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-15">
      <t><list style="symbols">
        <t>Submitted 3 December 2024.</t>
       <t>Luigi Iannone joined as editor.</t>
       <t>Re-wording some text for clarification and address Paul Wouters concerns.</t>
       <t> Updated security consideration section.</t>
       <t> Updated abstract.</t>
       <t> Moved some references to avoid downref.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-14">
      <t><list style="symbols">
        <t>Submitted August 2024.</t>
       <t>Use Paul Wouters suggestion to draw packet format for AFI=17 encoding in Section 3.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-13">
      <t><list style="symbols">
        <t>Submitted August 2024.</t>
        <t>Use Paul Wouters referene suggestion for RFC3629 to point ASCII references in this
        document to UTF-8.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-12">
      <t><list style="symbols">
        <t>Submitted August 2024.</t>
        <t>Made changes based on comments from Mahesh Jethanandani and Paul Wouters during
        IESG review.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-11">
      <t><list style="symbols">
        <t>Submitted August 2024.</t>
        <t>Fix typo found by Erik Kline.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-10">
      <t><list style="symbols">
        <t>Submitted August 2024.</t>
        <t>Change to "EID mask-len" per Roman Danyliw's comments.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-09">
      <t><list style="symbols">
        <t>Submitted July 2024.</t>
        <t>Added editorial suggestions from Acee Lindem.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-08">
      <t><list style="symbols">
        <t>Submitted June 2024.</t>
        <t>Made changes to reflect AD Jim Guichard's comments.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-07">
      <t><list style="symbols">
        <t>Submitted May 2024.</t>
        <t>Changed document status to "Proposed Standard" and some rewording per Alberto
        for

<!-- [rfced] Please review the pETR use-case section.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-06">
      <t><list style="symbols">
        <t>Submitted April 2024.</t>
        <t>Add Deployment Experience section for standards track requirements.</t>
	    <t>Update references.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-05">
      <t><list style="symbols">
        <t>Submitted December 2023.</t>
	    <t>Update IANA AFI reference.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-04">
      <t><list style="symbols">
        <t>Submitted December 2023.</t>
        <t>More comments from Alberto. Change to standard spellings throughout.</t>
        <t>Add RFC 2119 boilerplate.</t>
	    <t>Update reference RFC1700 to RFC3232.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-03">
      <t><list style="symbols">
        <t>Submitted December 2023.</t>
        <t>Address comments from Alberto, document shepherd.</t>
	    <t>Update references.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-02">
      <t><list style="symbols">
        <t>Submitted August 2023.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-01">
      <t><list style="symbols">
        <t>Submitted February 2023.</t>
	    <t>Update references and document expiry timer.</t>
	    <t>Change 68**.bis references to proposed RFC references.</t>
      </list></t>
    </section>

    <section title="Changes to draft-ietf-lisp-name-encoding-00">
      <t><list style="symbols">
        <t>Submitted August 2022.</t>
        <t>Move individual submission to LISP WG document.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-15">
      <t><list style="symbols">
        <t>Submitted July 2022.</t>
        <t>Added more clarity text about how using VPNs (instance-ID encoding) addresses name
        collisions from multiple use-cases.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-14">
      <t><list style="symbols">
        <t>Submitted May 2022.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-13">
      <t><list style="symbols">
        <t>Submitted November 2021.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-12">
      <t><list style="symbols">
        <t>Submitted May 2021.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-11">
      <t><list style="symbols">
        <t>Submitted November 2020.</t>
        <t>Made changes to reflect working group comments.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-10">
      <t><list style="symbols">
        <t>Submitted August 2020.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-09">
      <t><list style="symbols">
        <t>Submitted March 2020.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-08">
      <t><list style="symbols">
        <t>Submitted September 2019.</t>
	    <t>Update references and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-07">
      <t><list style="symbols">
        <t>Submitted March 2019.</t>
	    <t>Update referenes and document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-06">
      <t><list style="symbols">
        <t>Submitted September 2018.</t>
	    <t>Update document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-05">
      <t><list style="symbols">
        <t>Submitted March 2018.</t>
	    <t>Update document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-04">
      <t><list style="symbols">
        <t>Submitted September 2017.</t>
	    <t>Update document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-03">
      <t><list style="symbols">
        <t>Submitted March 2017.</t>
	<t>Update document expiry timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-02">
      <t><list style="symbols">
        <t>Submitted October 2016.</t>
	<t>Add a comment that "Inclusive Language" portion of the distinguished-name encoding
     online Style Guide
     <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
     and let us know if any changes are needed.  Updates of this
     nature typically result in more precise language, which is
	restricted to ASCII character encodings only.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-01">
      <t><list style="symbols">
        <t>Submitted October 2016.</t>
	<t>Update document timer.</t>
      </list></t>
    </section>

    <section title="Changes to draft-farinacci-lisp-name-encoding-00">
      <t><list style="symbols">
        <t>Initial draft submitted April 2016.</t>
      </list></t>
    </section>

  </section>
     helpful for readers.

For example, please consider whether the following should be updated:

whitespace

-->

  </back>
</rfc>