<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3958   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3958.xml">
<!ENTITY RFC4848   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4848.xml">
<!ENTITY RFC4033   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC5222   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5222.xml">
<!ENTITY RFC5582   PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5582.xml">
]>

<?rfc inline="yes"?>
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<!-- <?rfc colonspace='yes' ?> --> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" ipr="trust200902" updates="5222" docName="draft-gellens-lost-validation-09"> docName="draft-gellens-lost-validation-09" number="8917" obsoletes="" xml:lang="en" tocInclude="true" tocDepth="2" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="LoST-Validation">The LoST-Validation S-NAPTR Straightforward-Naming
    Authority PoinTeR (S-NAPTR) Application Service Tag</title>
    <seriesInfo name="RFC" value="8917"/>
    <author fullname="Randall Gellens" initials="R." surname="Gellens">
      <organization>Core Technology Consulting</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region> </region>
          <code> </code>
          <country>US </country>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>United States of America</country>
        </postal>
        <email>rg+ietf@coretechnologyconsulting.com</email>
        <uri>http://www.coretechnologyconsulting.com</uri>
      </address>
    </author>
    <author initials="B." surname="Rosen" fullname="Brian Rosen">
      <organization></organization>
      <organization/>
      <address>
        <postal>
          <street>470 Conrad Dr</street> Dr.</street>
          <city>Mars</city>
          <region> PA </region>
          <code>16046 </code>
          <country>US </country>
          <country>United States of America</country>
        </postal>
        <phone> </phone>
        <email>br@brianrosen.net
        </email>
      </address>
    </author>
    <date year="2020"/> month="October" year="2020" />
    <area>Real-Time Applications and Infrastructure</area>
    <workgroup></workgroup>
    <keyword>Internet-Draft</keyword>
<keyword>location</keyword>
<keyword>LoST</keyword>
<keyword>emergency</keyword>
<keyword>emergency services</keyword>
<keyword>ecrf</keyword>
<keyword>lvf</keyword>
<keyword>i3</keyword>

    <abstract>
      <t>This document adds the "LoST-Validation" 'LoST-Validation' service tag to the Straightforward Naming
      Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service
      Tag IANA registry.  This tag can appear in a Naming Authority Pointer
      (NAPTR) Domain Name System (DNS) record to assist clients of the
      Location-to-Service Translation Protocol (LoST) Protocol in identifying LoST
      servers explicitly willing to perform designated for location validation.  This tag and
      the information on about its use is an update to RFC5222 that RFC 5222, which enables the explicit discovery of a server that supports location validation.</t>
    </abstract>
  </front>
  <middle>

<!--
    <section anchor="terminology" title="Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
        "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
          <xref target="RFC2119"/>. </t>
    </section>
-->
    <section anchor="scope" title="Document Scope"> numbered="true" toc="default">
      <name>Document Scope</name>
      <t>This document adds 'LoST-Validation' to the S-NAPTR Application
      Service Tag IANA registry, registry and describes how this tag fits in the LoST
      server discovery procedure described in <xref target="RFC5222"/>. target="RFC5222"
      format="default"/>.  This tag is used with Naming Authority Pointer
      (NAPTR) Domain Name System (DNS) records so that clients of the
      Location-to-Service Translation Protocol (LoST) Protocol <xref target="RFC5222"/> target="RFC5222"
      format="default"/> can identify servers explicitly willing to perform designated for location validation.  This tag and the information on its use is an update to <xref target="RFC5222"/> target="RFC5222" format="default"/> that enables the explicit discovery of a server that supports location validation.</t>
    </section>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Location-to-Service Translation Protocol, LoST Protocol <xref target="RFC5222"/>
      target="RFC5222" format="default"/> defines a mapping service with the
      additional ability for a client to request that a civic address be
      validated.  The LoST protocol allows servers to ignore a request to
      perform location validation.  The National Emergency Number Association
      (NENA) has defined an architecture for all-IP emergency services (known
      as "i3" <xref target="NENA-i3"/>), target="NENA-i3" format="default"/>), which defines the
      mapping (routing) and validation functions as two distinct functional
      elements, defined as an Emergency Call Routing Function (ECRF) and a
      Location Validation Function (LVF).  NENA i3 requires that the mapping
      (ECRF) and validation (LVF) functions be separable, so that separable; an entity
      responsible for a LoST server cluster can decide to provide mapping and
      validation services using consolidated or separate server clusters
      (i.e., using the same or separate boxes).  The rationale is that the
      mapping service is used in real-time real time during emergency call routing,
      while the validation service is used in advance, typically when data is provisioned, and therefore
      provisioned; therefore, the mapping service has much higher availability
      and response time response-time requirements than the validation service.  An
      organization might choose to deploy these services using different
      server clusters to make it easier to provide higher levels of service
      for the mapping function while shielding it from the potentially bursty
      load of validation, while another validation. Another organization might choose to use the same
      sets of servers for both, both services, configured and deployed to offer the high service level demanded of the mapping service.</t>
      <t>In order to permit this separability, any entity querying a LoST
      server needs to be able to resolve an Application Unique String (AUS)
      into a URL for a LoST server that offers designated for the required service (mapping
      or validation).  This separability needs to be maintained throughout the
      LoST tree structure, from forest guide to leaf node (LoST architecture
      is described in <xref target="RFC5582"/>). target="RFC5582" format="default"/>).  Because
      LoST referrals return an AUS rather than a URL, either a different Service Tag
      service tag or a DNS name convention (e.g., "ecrf.example.org" and
      "lvf.example.org") is needed to differentiate between the different services.  DNS name conventions are inflexible and fragile, making a different service tag the preferred approach.</t>
      <t>Because a server discovered using the "LoST" application service tag LoST servers may ignore a request to perform location
      validation, a service tag explicitly for location validation also
      reduces the likelihood (which has existed since <xref target="RFC5582"/>) of target="RFC5582"
      format="default"/>) that a client requiring needing location validation reaching will reach servers unwilling that are not doing so
      (due to do so.</t> configuration and/or conditions).</t>
<section anchor="req" title="Requirements Language">
        <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 14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
</section>
    </section>
    <section anchor="LoST-Validation" title="The numbered="true" toc="default">
      <name>The LoST-Validation Application Service Tag"> Tag</name>
      <t>This document adds 'LoST-Validation' to the S-NAPTR "S-NAPTR Application
      Service Tag Tags" registry created by <xref target="RFC3958"/>. target="RFC3958"
      format="default"/>.  The 'LoST-Validation' tag serves as a counterpart
      to the 'LoST' tag added by <xref target="RFC5222"/>: The target="RFC5222" format="default"/>:
      the 'LoST' tag identifies servers able to perform the core mapping
      function, while 'LoST-Validation' identifies servers explicitly willing to perform designated for the validation function.</t>
      <t>Because some servers might be configured to provide both mapping and
      validation functions, a server identified using the 'LoST' service tag
      might also perform the validation function (and resolving the two tags
      might result in the same URL).  Because the two functions might be
      separate, clients seeking a LoST server for location validation can
      first try U-NAPTR a URI-Enabled NAPTR (U-NAPTR) resolution using the 'Lost-Validation'
      'LoST-Validation' service tag, tag and fallback can fall back to the 'LoST' service tag if this does not resolve to a usable LoST server.</t>
      <t>LoST <xref target="RFC5222"/> target="RFC5222" format="default"/> specifies that LoST
      servers are located by resolving an application Unique String (AUS) AUS using U-NAPTR/DDDS (URI-Enabled NAPTR/Dynamic
      NAPTR / Dynamic Delegation Discovery Service) <xref target="RFC4848"/>, target="RFC4848"
      format="default"/> and defines the 'LoST' Application application service tag.  In
      order to permit separability of the mapping and validation services
      performed using LoST, and to reduce this document defines the 'LoST-Validation'
      service tag. This tag also reduces the likelihood of that a client requiring needing
      location validation reaching might reach servers unwilling that are not performing validation (due to do so, this document defines the 'LoST-Validation' service tag.
      configuration and/or conditions).  NAPTR records for LoST servers available for location validation contain the 'LoST-Validation' service tag.  An entity needing to perform location validation using LoST performs the discovery procedure as described in <xref target="RFC5222"/>, target="RFC5222" format="default"/>, except that the 'LoST-Validation' service tag is used in preference to the 'LoST' service tag.  For both service tags, the HTTP and HTTPS URL schemes are used.  In the absense absence of any NAPTR records containing the 'LoST-Validation' service tag, the 'LoST' service tag is used.  Fallback to the 'LoST' service tag may follow if the 'Lost-Validation' 'LoST-Validation' service tag fails to result in a usable LoST server.  The discovery procedure with the 'LoST-Validation' service tag might result in the same URL as the 'LoST' service tag, or it may result in a different URL.  When the URLs are different, they could lead to the same physical servers, servers or different servers.</t>
    </section>

    <section anchor="back" title="Backwards Compatability"> numbered="true" toc="default">
      <name>Backwards Compatibility</name>
      <t>The primary use of LoST in general, and the location validation functionality in particular, is within the emergency services area.  Within North America, the NENA i3 <xref target="NENA-i3"/> target="NENA-i3" format="default"/> document specifies how protocols including LoST are used.  The i3 document is expected to reference the 'LoST-Validation' service tag, tag and specify its use in both server NAPTR DNS records and client resolution of Application Unique Strings (AUS).</t> AUS.</t>
      <t>LoST allows a server to refuse to perform location validation, validation and
      defines the 'locationValidationUnavailable' warning. LoST also allows a
      server to refer to another server rather than answering itself. So, in a
      deployment where a LoST tree has separate server clusters for mapping
      and for validation, mapping servers receiving a request for validation
      could either perform the validation as requested, requested or return the
      'locationValidationUnavailable' warning, warning and potentially also include a
      &lt;redirect&gt; element to redirect to a validation server. However,
      the &lt;redirect&gt; element contains an Application Unique String, AUS, so
      unless the AUSs for validation and mapping are different (e.g.,
      'ecrf.example.org' and 'lvf.example.org'), we still need a different
      service tag to allow for flexible deployment choices (i.e., not
      requiring a DNS name convention).</t>
      <t>LoST clients performing emergency services operations in North
      America are expected to
      comply with the latest NENA i3 specification, specification and hence support the
      'LoST-Validation' service tag when defined.  A LoST client implemented
      prior to the addition of the 'LoST-Validation' tag would use the 'LoST'
      tag to resolve an AUS.  Such a client might not be performing location
      validation, but if it is, the LoST server it contacts may perform the
      service.  Even in a deployment where mapping and validation are split,
      the data is identical; the split is a load and deployment optimization
      strategy.  The server  Servers designated for mapping is likely to might perform validation when requested, potentially unless it is under load.
      requested (potentially depending on load or other factors).  If an older
      client attempts validation using a designated mapping server that
      refuses the request, the client will retry later, at which point the
      server may no longer be under load and may might provide the function. function (e.g., if its load or other conditions
      have changed).  Even
      in the (unlikely) case of a designated mapping server that refuses to
      perform validation at any time, the server could return a redirect with
      a different AUS (e.g., "lvf.example.com") that resolves to a designated
      validation server.  In the (unlikely) worst case, the client will be
      unable to reach a server willing to perform validation, validation and will follow
      up (e.g., submit a discrepancy report, report as specified in NENA i3. i3).  The discrepancy report
      resolution would may be to update the client with the 'LoST-Validation'
      service tag, update the AUS returned in a redirect and DNS to use a
      different DNS host name, or permit the server to perform validation when
      not under stress (or a combination).  Note that, because LoST does not
      require servers to perform validation, the situation described can exist
      regardless of the addition of the 'LoST-Validation' service tag.  The addition  Use of
      the tag improves the likelihood of that a client needing validation being is able to do so.</t> validate a
      location when needed.</t>
    </section>
    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security considerations described in <xref target="RFC3958"/>, target="RFC3958"
      format="default"/>, <xref target="RFC4848"/>, target="RFC4848" format="default"/>, and <xref target="RFC5222"/>
      target="RFC5222" format="default"/> apply here.  No additional security
      aspects are foreseen by the addition of an extra tag.  Separation of
      services might be desired, for example, to be able to allocate different levels of resources (such as server capacity, attack mitigation, bandwidth, etc.) to the mapping and validation services, in which case separate tags are needed to allow LoST clients (which may include other LoST servers) to identify the correct server cluster.</t>
      <t><xref target="RFC5222"/> target="RFC5222" format="default"/> descriptively discusses the
      use of DNS Security security <xref target="RFC4033"/> target="RFC4033" format="default"/> to
      mitigate the risk of DNS-based attacks.  Because DNS Security security has become
      more widely deployed since the publication of <xref target="RFC5222"/>, target="RFC5222"
      format="default"/>, such measures SHOULD <bcp14>SHOULD</bcp14> be used when
      performing NAPTR resolution.  Note that, while there are valid reasons
      to proceed with a LoST mapping query despite security failures while
      initiating or processing an emergency call, these concerns generally do
      not apply to a loST LoST validation query done in advance of an emergency
      call.</t>
    </section>
    <section anchor="iana" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is requested to add has added 'LoST-Validation' to the S-NAPTR "S-NAPTR Application Service Tag
      Tags" registry created by <xref target="RFC3958"/> target="RFC3958" format="default"/>.
      This tag serves as a counterpart to the 'LoST' tag added by <xref target="RFC5222"/>.</t>
      target="RFC5222" format="default"/>.</t>

      <t>(Note that IANA and <xref target="RFC3958"/> target="RFC3958" format="default"/> call this registry "S-NAPTR Application Service Tags" Tags", while <xref target="RFC5222"/> target="RFC5222" format="default"/> calls it "U-NAPTR application service tag".)</t>
      <section title="S-NAPTR Registration"> numbered="true" toc="default">
        <name>S-NAPTR Registration</name>
        <t>This document registers an S-NAPTR application service tag:</t>

        <t>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
        <list style="empty">
           <t>Application
        <dl spacing="normal">
          <dt>Application Service Tag:  LoST-Validation</t>
           <t>Defining Publication:  This document.</t>
        </list>
<?rfc compact="no" ?>
        </t>

      </section> <!-- title="S-NAPTR Registration" -->
    </section> <!-- title="IANA Considerations" -->

    <!-- <section title="Contributors">
      <t></t>
    </section> -->

    <section title="Acknowledgements">
      <t>Many thanks to Ted Hardie, Ben Campbell, Dan Banks, Pete Resnick, Shawn Emery, Robert Wilton, Roman Danyliw, and Benjamin Kaduk for their helpful reviews and suggestions, and to Barry Leiba for shepherding the document.</t> Tag:</dt> <dd>LoST-Validation</dd>
          <dt>Defining Publication:</dt>  <dd>This document</dd>
        </dl>
      </section>

    <section title="Changes from Previous Versions">
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
      <section title="Changes from -00 to -01">
        <t>
        <list style="symbols">
            <t>Fixed incorrect tag in <xref target="iana"/></t>
            <t>Clarified background and explanation in <xref target="intro"/></t>
            <t>Clarified text in <xref target="LoST-Validation"/></t>
            <t>Expanded text in <xref target="security"/></t>
        </list>
        </t>
      </section>
      <section title="Changes from -01 to -02">
        <t>
        <list style="symbols">
            <t>Fixed bug in .xml file</t>
        </list>
        </t>
      </section>
      <section title="Changes from -02 to -03">
        <t>
        <list style="symbols">
            <t>Reworded fallback text in <xref target="intro"/></t>
        </list>
        </t>
      </section>
      <section title="Changes from -03 to -04">
        <t>
        <list style="symbols">
            <t>Fixed some references to <xref target="RFC4848"/> that should be to <xref target="RFC5222"/> in sections <xref target="intro"/> and <xref target="LoST-Validation"/></t>
            <t>Added clarifying text in Abstract</t>
            <t>Copied text from Abstract to <xref target="scope"/></t>
            <t>Added clarifying text in <xref target="intro"/></t>
        </list>
        </t>
      </section>
      <section title="Changes from -04 to -05">
        <t>
        <list style="symbols">
            <t>Added reference to <xref target="RFC5222"/> in <xref target="security"/></t>
            <t>Added clarifying text to <xref target="intro"/></t>
            <t>Moved some text from <xref target="intro"/> to <xref target="LoST-Validation"/></t>
            <t>Added new section <xref target="back"/></t>
        </list>
        </t>
      </section>
      <section title="Changes from -05 to -06">
        <t>
        <list style="symbols">
            <t>Changed intended status from Informational to Standards Track</t>
            <t>Added indication that the document (if approved) updates RFC 5222</t>
            <t>Added text to Abstract, Document Scope (<xref target="scope"/>), and Introduction (<xref target="intro"/>) to better explain document purpose.</t>
            <t>Added Informational reference to <xref target="RFC5582"/></t>
            <t>Minor wording improvements in multiple sections</t>
        </list>
        </t>
      </section>
      <section title="Changes from -06 to -07">
        <t>
        <list style="symbols">
            <t>Minor editorial changes to Introduction (<xref target="intro"/>)</t>
        </list>
        </t>
      </section>
      <section title="Changes from -07 to -08">
        <t>
        <list style="symbols">
            <t>Added text in Abstract and Document Scope (<xref target="scope"/>) clarifying the updates to <xref target="RFC5582"/></t>
        </list>
        </t>
      </section>
<section title="Changes from -08 to -09">
        <t>
        <list style="symbols">
            <t>Added text in Security Considerations (<xref target="security"/>) making the use of DNS Security <xref target="RFC4033"/> a SHOULD</t>
        </list>
        </t>
      </section>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
    </section>
  </middle>
  <back>

    <references title="Normative References">
        <!-- &RFC2119; -->
        &RFC3958;
<?rfc include="reference.RFC.4033.xml"?>
<?rfc include="reference.RFC.4848.xml"?>
<?rfc include="reference.RFC.5222.xml"?>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3958.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4848.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5222.xml"/>
      </references>

  <references title="Informative references">

<?rfc include="reference.RFC.5582.xml"?>
      <references>
        <name>Informative References</name>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5582.xml"/>
        <reference anchor="NENA-i3" target="https://www.nena.org/page/i3_Stage3">
          <front>
            <title>Detailed Functional and Interface Standards for the NENA i3 Solution</title>
            <author fullname="" initials="" surname="National Emergency Number Association (NENA) Interconnection and Security Committee, i3 Architecture Working Group"/>
            <date year="2016"/>
          </front>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Many thanks to <contact fullname="Ted Hardie"/>, <contact fullname="Ben Campbell"/>, <contact fullname="Dan Banks"/>, <contact fullname="Pete Resnick"/>, <contact fullname="Shawn Emery"/>, <contact fullname="Robert Wilton"/>, <contact fullname="Roman Danyliw"/>, and <contact fullname="Benjamin Kaduk"/> for their helpful reviews and suggestions and to <contact fullname="Barry Leiba"/> for shepherding the document.</t>
    </section>
  </back>
</rfc>