<?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' ?> 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">

<!--  Edited by Dino Farinacci farinacci@gmail.com -->
<!--  Edited by Luigi Iannone ggx@gigix.net [rfced] Please note that the title of the document has been
     updated as follows:

a) Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
Style Guide"). Please review.

Original:
LISP Distinguished Name Encoding

Current:
Locator/ID Separation Protocol (LISP) Distinguished Name Encoding

b) Please note that we have added an abbreviated title that appears in
the running header of the pdf version.  Please review and let us know
if any updates are necessary.

Original:
[nothing]

Current:
LISP Name Encoding
-->

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

<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 "Distinguished Name" Address Family Identifier (AFI) 17 "Distinguished Names" in LISP. the Locator/ID Separation Protocol (LISP). Distinguished Names (DNs) can be used either in either Endpoint Identifiers Identifier (EID) records or Routing Locators Locator (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"
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>

<!--[rfced] Neither RFC 9300 nor RFC 9301 have "architecture" in this their
     title.  Are these document "nicknames" or concepts?  Please
     review this citation and sentence and let us know if any updates
     are to be interpreted as
    described in BCP 14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, needed.

Original:
The LISP architecture and only when, they appear in all
    capitals, as shown here.</t>
  </note>
</front>

<middle>
  <section title="Introduction"> protocols ([RFC9300], [RFC9301]) introduces
two new numbering spaces,...
-->

      <t>The LISP architecture and protocols (<xref target="RFC9300"/>, (see <xref target="RFC9301"/>) introduces target="RFC9300" format="default"/> and <xref target="RFC9301" format="default"/>) introduce 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 and 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 = 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="IANA-ADDRESS-FAMILY-REGISTRY" 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 are useful when encoded either in
    EID-Records or RLOC-records in LISP control messages. As EIDs,
    they can be registered in the 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, 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>

<!--[rfced] Is RFC 5280 to be read as one of a group of RFCs?  Or is
     this the only RFC the reader is being pointed to?

Original:
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 [RFC5280].

Perhaps:
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., [RFC5280]).
-->

      <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 <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" /> format="default"/> for
        details on other types of information that can be AFI encoded.</t>
    </list></t> encoded.</dd>
      </dl>
    </section>
    <section 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 title="Distinguished numbered="true" toc="default">
      <name>Distinguished Name Format">

    <figure>
      <preamble>An Format</name>
      <t>An AFI=17 Distinguished Name is encoded as:</preamble>
      <artwork><![CDATA[ as:</t>

<!--[rfced] Please review uses of NULL in this document.
     Particularly:

a) Should these be updated to NUL?  Please let us know any changes in
Old/New format or feel free to update the edited XML as desired.

b) We see the following similar uses.  Should these be made uniform?

NULL Terminated vs.
NULL (0x00) terminated vs.
terminating NULL 0x00 octet vs.
NULL 0 octet vs.
NULL terminated vs.
NULL octet vs.
null octet

Further, we would expect NULL Terminated to be hyphenated in
attributive position (before a noun).  Please see how (0x00) can fit
into that scheme.
-->

      <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   ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    String                     |
 ~                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ]]></artwork>
      <postamble />
    </figure>
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>

      <t>The variable length variable-length string of characters are encoded as a NULL (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>

<!--[rfced] We had a few questions about the following text:

Original:
When Distinguished Names are encoded for EIDs, the EID Mask-Len length
of the EIDs as they appear in EID-Records for all LISP control
messages [RFC9301] is the length of the string in bits (including the
terminating NULL 0x00 octet).

a) Might it be helpful to move this citation to RFC 9301 to a
previous/first use of LISP control messages (perhaps in the
Introduction)?  Or is this citation covering another/more parts of the
sentence here?

b) Is it redundant to say "the EID Mask-Len length of the EIDs"?

-->

      <t>When Distinguished Names are encoded for EIDs, the EID Mask-Len
    length of the EIDs as they appear in 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 0x00 octet).</t>
      <t>Where Distinguished Names 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. The string MUST <bcp14>MUST</bcp14> still be NULL terminated. If a NULL 0 octet appears before the end of the octet field, i.e., the NULL octet 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 <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, the
    string is a NULL string and MUST <bcp14>MUST</bcp14> be accepted. That is, an AFI=17
    encoded string MUST <bcp14>MUST</bcp14> be at least 1 octet in length.</t>
    </section>
    <section title="Mapping numbered="true" toc="default">
      <name>Mapping System Lookups for Distinguished Name EIDs">
     <t>Distinguished EIDs</name>

<!--[rfced] We are having trouble parsing this sentence. What MUST the
     lookups carry?

Original:
   Distinguished Name EID lookups MUST carry as an EID Mask-Len length
   equal to the length of the name string.
-->

      <t>Distinguished Name EID lookups <bcp14>MUST</bcp14> carry as an EID Mask-Len length equal to the length of the name string. This instructs the mapping system to do either an exact match exact-match or longest match a longest-match lookup.</t>
      <t>If the Distinguished Name 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>

<!--[rfced] In the following, please clarify the parenthetical.  What
     is 5 octets?  The null octet itself or the null octet plus
     "ietf"?

Original:
For example, if the registered EID name is "ietf" with EID Mask-Len
of 40 bits (the length of string "ietf" plus the null octet is 5
octets), and a Map-Request is received for EID name "ietf.lisp" with
an EID Mask-Len of 80 bits, the Map-Server will return EID "ietf"
with length of 40 bits.

-->

      <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 octet is 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 format: two are used for an EID encoding
    and one for an RLOC-record encoding. When storing public keys in
    the 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. When
    street location to GPS coordinate
    street-location-to-GPS-coordinate mappings exist in the 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. 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 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 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. 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 with a unique Instance-ID. For any use-cases which Any use cases that require
    different uses for Distinguish Distinguished Names 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"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Distinguished Names 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) Deployment Experience"> Experience</name>

<!--[rfced] To what does "LISP Distinguished Name specification"
     refer?  Is a citation necessary here?

Original:
Practical implementations of the LISP Distinguished Name
specification have been running in production networks for some time.

-->

      <t>Practical implementations of the LISP Distinguished Name
    specification 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.).

b) We note some inconsistencies in the abbreviation for "Proxy Egress
Tunnel Routers":

[I-D.ietf-lisp-site-external-connectivity] seems to use pETR

This document uses Proxy-ETR

Past RFCs have used PETR.

Please review and let us know what, if any, updates are necessary.
-->
        <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 as an EID to identify the Proxy-ETR
	role in a Map-Registration.</t>

      <t>In

<!--[rfced] What citation should be added to this sentence to point
     the reader to the LISP Site External Connectivity document?  Is
     this draft-ietf-lisp-site-external-connectivity?

Original:
The Distinguished Name in this case serves as a common reference EID
that can be requested (or subscribed as per [RFC9437]) to dynamically
gather this Proxy-ETR list as specified in the LISP Site External
Connectivity document.

-->

        <t>In this case, all Proxy-ETRs supporting this function register
      a common Distinguished Name together with their own offered
      locator. The Mapping-System aggregates the locators received
      from all Proxy-ETRs as a common locator-set that is associated
      with this DN EID. The In this scenario, the Distinguished Name in this case 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>
        <t>The use of a Distinguished Name in this case 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 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 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 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
[I-D.farinacci-lisp-lispers-net-nat] has had 10 years of deployment
experience using Distinguished Names for documenting xTRs versus Re-
encapsulating Tunnel Router (RTRs) as they appear in a 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 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 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 NAT-Traversal"> 10 years.

-->

        <name>DNs for NAT-Traversal</name>
        <t>The open source lispers.net NAT-Traversal implementation
      <xref target="I-D.farinacci-lisp-lispers-net-nat"/> target="I-D.farinacci-lisp-lispers-net-nat" format="default"/> has had 10
      years of deployment experience using Distinguished Names for
      documenting xTRs versus Re-encapsulating Tunnel Router Routers (RTRs) as
      they appear in a locator-set.</t>
      </section>
      <section title="DNs numbered="true" toc="default">
        <name>DNs for Self-Documenting RLOC Names"> Names</name>
        <t>The open source lispers.net implementation has had 10 years of
      self-documenting RLOC names in production and pilot
      environments. The RLOC name is encoded with the RLOC address in
      Distinguished Name format.</t>
      </section>
      <section title="DNs numbered="true" toc="default">
        <name>DNs used as EID Names"> Names</name>
        <t>The open source lispers.net implementation has had 10 years of deployment
      experience allowing xTRs to register EIDs as Distinguished
      Names. 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="LISP-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="IANA-ADDRESS-FAMILY-REGISTRY" 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

<!-- [rfced] We had the following questions related 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 terminology use throughout the document:

a) Please review the way that the AFI value is referred 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 throughout
the 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 (e.g., using an equals sign, spacing around the equals sign,
etc.).  We see:

Address Family Identifier (AFI) 17 "Distinguished Names"
AFI 17 "Distinguished Name"
the AFI value 17
An AFI=17 encoding Distinguished Name
an AFI=17 encoded string
AFI 17

See also: AFI = 1

How may we make these consistent throughout?

b) We see variation in Section 3.</t>
      </list></t>
    </section>

    <section title="Changes the way the term Distinguished Names is
referred to draft-ietf-lisp-name-encoding-13">
      <t><list style="symbols">
        <t>Submitted August 2024.</t>
        <t>Use Paul Wouters referene suggestion for RFC3629 (i.e., capitalization, pluralization, quotation, etc.).
In addition to point ASCII references the examples 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 a) above, please also see:

LISP Distinguished Names
AFI 17 "Distinguished Name" and Paul Wouters (AFI) 17 "Distinguished Names" (sg/pl)
Distinguished Name (DN)

Please consider if this is the name of the value or the concept in
general 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 your review and send us updates in either Old/New form
or update the edited XML file directly.

c) We see that the abbreviation DN was used nearly at the end of the
document.  Might we reduce some of the inconsistencies 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 moving the
abbreviation to draft-ietf-lisp-name-encoding-07">
      <t><list style="symbols">
        <t>Submitted May 2024.</t>
        <t>Changed document status first use (or the first use that is not to "Proposed Standard" the direct
name of the IANA-registered value) and some rewording per Alberto
        for then using DN thereafter?

d) We see variations in 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 following forms.  Should these be made
consistent?

Mapping System vs. mapping system
EID-Record vs. EID record
RLOC-record vs. RLOC record

-->

<!-- [rfced] FYI - We have added expansions 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 the following
     abbreviations per Section 3.6 of 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 7322 ("RFC Style
     Guide"). Please review each expansion in the 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 carefully
     to ensure correctness.

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 - Locator/ID Separation Protocol
LCAF - LISP Canonical Address Format

-->

<!-- [rfced] Please review the "Inclusive Language" portion of the
     online Style Guide
     <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
     and let us know if any 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 are needed.  Updates of this
     nature typically result in more precise language, which is
     helpful for readers.

For example, please consider whether the distinguished-name encoding following should be updated:

whitespace

In addition, please consider whether "tradition" should be updated for
clarity.  While the NIST website
<https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that this term 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> potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.

Original:
...to start with traditional UDP registrations.
-->

  </back>
</rfc>