rfc8917xml2.original.xml   rfc8917.xml 
<?xml version="1.0"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.2119.xml">
<!ENTITY RFC3958 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.3958.xml">
<!ENTITY RFC4848 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.4848.xml">
<!ENTITY RFC4033 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.4033.xml">
<!ENTITY RFC5222 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.5222.xml">
<!ENTITY RFC5582 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.5582.xml">
]>
<?rfc inline="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<!-- <?rfc colonspace='yes' ?> -->
<rfc category="std" ipr="trust200902" updates="5222" docName="draft-gellens-lost <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
-validation-09"> std" consensus="true" ipr="trust200902" updates="5222" docName="draft-gellens-lo
<front> st-validation-09" number="8917" obsoletes="" xml:lang="en" tocInclude="true" toc
<title abbrev="LoST-Validation">The LoST-Validation S-NAPTR Application Serv Depth="2" symRefs="true" sortRefs="true" version="3">
ice Tag</title>
<author fullname="Randall Gellens" initials="R." <!-- xml2rfc v2v3 conversion 2.46.0 -->
surname="Gellens"> <front>
<title abbrev="LoST-Validation">The LoST-Validation 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> <organization>Core Technology Consulting</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city></city> <city/>
<region> </region> <!-- xml2rfc v2v3 conversion 2.46.0 -->
<code> </code> <region/>
<country>US </country> <code/>
<country>United States of America</country>
</postal> </postal>
<email>rg+ietf@coretechnologyconsulting.com</email> <email>rg+ietf@coretechnologyconsulting.com</email>
<uri>http://www.coretechnologyconsulting.com</uri> <uri>http://www.coretechnologyconsulting.com</uri>
</address> </address>
</author> </author>
<author initials="B." surname="Rosen" fullname="Brian Rosen"> <author initials="B." surname="Rosen" fullname="Brian Rosen">
<organization></organization> <organization/>
<address> <address>
<postal> <postal>
<street>470 Conrad Dr</street> <street>470 Conrad Dr.</street>
<city>Mars</city> <city>Mars</city>
<region> PA </region> <region> PA </region>
<code>16046 </code> <code>16046 </code>
<country>US </country> <country>United States of America</country>
</postal> </postal>
<phone> </phone> <phone> </phone>
<email>br@brianrosen.net <email>br@brianrosen.net
</email> </email>
</address> </address>
</author> </author>
<date month="September" year="2020" />
<date year="2020"/>
<area>Real-Time Applications and Infrastructure</area> <area>Real-Time Applications and Infrastructure</area>
<workgroup></workgroup> <keyword>location</keyword>
<keyword>Internet-Draft</keyword> <keyword>LoST</keyword>
<abstract> <keyword>emergency</keyword>
<t>This document adds the "LoST-Validation" service tag to the Straightfor <keyword>emergency services</keyword>
ward Naming Authority PoinTeR (S-NAPTR) Application Service Tag IANA registry. <keyword>ecrf</keyword>
This tag can appear in a Naming Authority Pointer (NAPTR) Domain Name System (DN <keyword>lvf</keyword>
S) record to assist clients of the Location-to-Service Translation Protocol (LoS <keyword>i3</keyword>
T) in identifying LoST servers explicitly willing to perform location validation
. This tag and the information on its use is an update to RFC5222 that enables
the explicit discovery of a server that supports location validation.</t>
<abstract>
<t>This document adds the 'LoST-Validation' service tag to the
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 (LoST) Protocol in identifying LoST
servers designated for location validation. This tag and
the information about its use update RFC 5222, which enables the explicit
discovery of a server that supports location validation.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="scope" numbered="true" toc="default">
<!-- <name>Document Scope</name>
<section anchor="terminology" title="Terminology"> <t>This document adds 'LoST-Validation' to the S-NAPTR Application
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH Service Tag IANA registry and describes how this tag fits in the LoST
OULD", "SHOULD NOT", server discovery procedure described in <xref target="RFC5222"
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpre format="default"/>. This tag is used with Naming Authority Pointer
ted as described in (NAPTR) Domain Name System (DNS) records so that clients of the
<xref target="RFC2119"/>. </t> Location-to-Service Translation (LoST) Protocol <xref target="RFC5222"
format="default"/> can identify servers designated for location validation
. This tag and the information on its use is an update to <xref target="RFC5222
" format="default"/> that enables the explicit discovery of a server that suppor
ts location validation.</t>
</section> </section>
<section anchor="intro" numbered="true" toc="default">
<section anchor="scope" title="Document Scope"> <name>Introduction</name>
<t>This document adds 'LoST-Validation' to the S-NAPTR Application Servi <t>The LoST Protocol <xref
ce Tag IANA registry, and describes how this tag fits in the LoST server discove target="RFC5222" format="default"/> defines a mapping service with the
ry procedure described in <xref target="RFC5222"/>. This tag is used with Namin additional ability for a client to request that a civic address be
g Authority Pointer (NAPTR) Domain Name System (DNS) records so that clients of validated. The LoST protocol allows servers to ignore a request to
the Location-to-Service Translation Protocol (LoST) <xref target="RFC5222"/> can perform location validation. The National Emergency Number Association
identify servers explicitly willing to perform location validation. This tag a (NENA) has defined an architecture for all-IP emergency services (known
nd the information on its use is an update to <xref target="RFC5222"/> that enab as "i3" <xref target="NENA-i3" format="default"/>), which defines the
les the explicit discovery of a server that supports location validation.</t> 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; 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 during emergency call routing,
while the validation service is used in advance, typically when data is
provisioned; therefore, the mapping service has much higher availability
and 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. Another organization might choose to use the same
sets of servers for both services, configured and deployed to offer the hi
gh 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 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" format="default"/>). Because
LoST referrals return an AUS rather than a URL, either a different
service tag or a DNS name convention (e.g., "ecrf.example.org" and
"lvf.example.org") is needed to differentiate between the services. DNS n
ame conventions are inflexible and fragile, making a different service tag the p
referred approach.</t>
<t>Because 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"
format="default"/>) that a client needing location validation will reach s
ervers that are not doing so
(due to 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>
<section anchor="LoST-Validation" numbered="true" toc="default">
<section anchor="intro" title="Introduction"> <name>The LoST-Validation Application Service Tag</name>
<t>The Location-to-Service Translation Protocol, LoST <xref target="RFC522 <t>This document adds 'LoST-Validation' to the "S-NAPTR Application
2"/> defines a mapping service with the additional ability for a client to reque Service Tags" registry created by <xref target="RFC3958"
st that a civic address be validated. The LoST protocol allows servers to ignor format="default"/>. The 'LoST-Validation' tag serves as a counterpart
e a request to perform location validation. The National Emergency Number Assoc to the 'LoST' tag added by <xref target="RFC5222" format="default"/>:
iation (NENA) has defined an architecture for all-IP emergency services (known a the 'LoST' tag identifies servers able to perform the core mapping
s "i3" <xref target="NENA-i3"/>), which defines the mapping (routing) and valida function, while 'LoST-Validation' identifies servers designated for the va
tion functions as two distinct functional elements, defined as an Emergency Call lidation function.</t>
Routing Function (ECRF) and a Location Validation Function (LVF). NENA i3 requ <t>Because some servers might be configured to provide both mapping and
ires that the mapping (ECRF) and validation (LVF) functions be separable, so tha validation functions, a server identified using the 'LoST' service tag
t an entity responsible for a LoST server cluster can decide to provide mapping might also perform the validation function (and resolving the two tags
and validation services using consolidated or separate server clusters (i.e., us might result in the same URL). Because the two functions might be
ing the same or separate boxes). The rationale is that the mapping service is u separate, clients seeking a LoST server for location validation can
sed in real-time during emergency call routing, while the validation service is first try a URI-Enabled NAPTR (U-NAPTR) resolution using the
used in advance, typically when data is provisioned, and therefore the mapping s 'Lost-Validation' service tag and can fall back to the 'LoST' service tag
ervice has much higher availability and response time requirements than the vali if this does not resolve to a usable LoST server.</t>
dation service. An organization might choose to deploy these services using dif <t>LoST <xref target="RFC5222" format="default"/> specifies that LoST
ferent server clusters to make it easier to provide higher levels of service for servers are located by resolving an AUS using U-NAPTR/DDDS (URI-Enabled
the mapping function while shielding it from the potentially bursty load of val NAPTR / Dynamic Delegation Discovery Service) <xref target="RFC4848"
idation, while another organization might choose to use the same sets of servers format="default"/> and defines the 'LoST' application service tag. In
for both, configured and deployed to offer the high service level demanded of t order to permit separability of the mapping and validation services
he mapping service.</t> performed using LoST, this document defines the 'LoSt-Validation'
<t>In order to permit this separability, any entity querying a LoST serv service tag. This tag also reduces the likelihood that a client needing
er needs to be able to resolve an Application Unique String (AUS) into a URL for location validation might reach servers that are not performing validation
a LoST server that offers the required service (mapping or validation). This s (due to
eparability needs to be maintained throughout the LoST tree structure, from fore configuration and/or conditions). NAPTR records for LoST servers availabl
st guide to leaf node (LoST architecture is described in <xref target="RFC5582"/ e for location validation contain the 'LoST-Validation' service tag. An entity
>). Because LoST referrals return an AUS rather than a URL, either a different needing to perform location validation using LoST performs the discovery procedu
Service Tag or a DNS name convention (e.g., "ecrf.example.org" and "lvf.example. re as described in <xref target="RFC5222" format="default"/>, except that the 'L
org") is needed to differentiate the different services. DNS name conventions a oST-Validation' service tag is used in preference to the 'LoST' service tag. Fo
re inflexible and fragile, making a different service tag the preferred approach r both service tags, the HTTP and HTTPS URL schemes are used. In the absence of
.</t> any NAPTR records containing the 'LoST-Validation' service tag, the 'LoST' serv
<t>Because a server discovered using the "LoST" application service tag ice tag is used. Fallback to the 'LoST' service tag may follow if the 'Lost-Val
may ignore a request to perform location validation, a service tag explicitly fo idation' service tag fails to result in a usable LoST server. The discovery pro
r location validation also reduces the likelihood (which has existed since <xref cedure with the 'LoST-Validation' service tag might result in the same URL as th
target="RFC5582"/>) of a client requiring location validation reaching servers e 'LoST' service tag, or it may result in a different URL. When the URLs are di
unwilling to do so.</t> fferent, they could lead to the same physical servers or different servers.</t>
</section> </section>
<section anchor="LoST-Validation" title="The LoST-Validation Application Ser <section anchor="back" numbered="true" toc="default">
vice Tag"> <name>Backwards Compatibility</name>
<t>The primary use of LoST in general, and the location validation functio
<t>This document adds 'LoST-Validation' to the S-NAPTR Application Servi nality in particular, is within the emergency services area. Within North Ameri
ce Tag registry created by <xref target="RFC3958"/>. The 'LoST-Validation' tag ca, the NENA i3 <xref target="NENA-i3" format="default"/> document specifies how
serves as a counterpart to the 'LoST' tag added by <xref target="RFC5222"/>: The protocols including LoST are used. The i3 document is expected to reference th
'LoST' tag identifies servers able to perform the core mapping function, while e 'LoST-Validation' service tag and specify its use in both server NAPTR DNS rec
'LoST-Validation' identifies servers explicitly willing to perform the validatio ords and client resolution of AUS.</t>
n function.</t> <t>LoST allows a server to refuse to perform location validation and
defines the 'locationValidationUnavailable' warning. LoST also allows a
<t>Because some servers might be configured to provide both mapping and vali server to refer to another server rather than answering itself. So, in a
dation functions, a server identified using the 'LoST' service tag might also pe deployment where a LoST tree has separate server clusters for mapping
rform the validation function (and resolving the two tags might result in the sa and for validation, mapping servers receiving a request for validation
me URL). Because the two functions might be separate, clients seeking a LoST se could either perform the validation as requested or return the
rver for location validation can first try U-NAPTR resolution using the 'Lost-Va 'locationValidationUnavailable' warning and potentially also include a
lidation' service tag, and fallback to the 'LoST' service tag if this does not r &lt;redirect&gt; element to redirect to a validation server. However,
esolve to a usable LoST server.</t> the &lt;redirect&gt; element contains an AUS, so
unless the AUSs for validation and mapping are different (e.g.,
<t>LoST <xref target="RFC5222"/> specifies that LoST servers are located by 'ecrf.example.org' and 'lvf.example.org'), we still need a different
resolving an application Unique String (AUS) using U-NAPTR/DDDS (URI-Enabled NAP service tag to allow for flexible deployment choices (i.e., not
TR/Dynamic Delegation Discovery Service) <xref target="RFC4848"/>, and defines t requiring a DNS name convention).</t>
he 'LoST' Application service tag. In order to permit separability of the mappi <t>LoST clients performing emergency services operations in North
ng and validation services performed using LoST, and to reduce the likelihood of America are expected to
a client requiring location validation reaching servers unwilling to do so, thi comply with the NENA i3 specification and hence support the
s document defines the 'LoST-Validation' service tag. NAPTR records for LoST se 'LoST-Validation' service tag when defined. A LoST client implemented
rvers available for location validation contain the 'LoST-Validation' service ta prior to the addition of the 'LoST-Validation' tag would use the 'LoST'
g. An entity needing to perform location validation using LoST performs the dis tag to resolve an AUS. Such a client might not be performing location
covery procedure as described in <xref target="RFC5222"/>, except that the 'LoST validation, but if it is, the LoST server it contacts may perform the
-Validation' service tag is used in preference to the 'LoST' service tag. For b service. Even in a deployment where mapping and validation are split,
oth service tags, the HTTP and HTTPS URL schemes are used. In the absense of an the data is identical; the split is a load and deployment optimization
y NAPTR records containing the 'LoST-Validation' service tag, the 'LoST' service strategy. Servers designated for mapping might perform validation when
tag is used. Fallback to the 'LoST' service tag may follow if the 'Lost-Valida requested (potentially depending on load or other factors). If an older
tion' service tag fails to result in a usable LoST server. The discovery proced client attempts validation using a designated mapping server that
ure with the 'LoST-Validation' service tag might result in the same URL as the ' refuses the request, the client will retry later, at which point the
LoST' service tag, or it may result in a different URL. When the URLs are diffe server might provide the function (e.g., if its load or other conditions
rent, they could lead to the same physical servers, or different servers.</t> have changed). Even
in the 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 worst case, the client will be
unable to reach a server willing to perform validation and will follow
up (e.g., submit a discrepancy report as specified in NENA i3). The
resolution 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. Use of
the tag improves the likelihood that a client is able to validate a
location when needed.</t>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section anchor="back" title="Backwards Compatability"> <name>Security Considerations</name>
<t>The security considerations described in <xref target="RFC3958"
<t>The primary use of LoST in general, and the location validation functiona format="default"/>, <xref target="RFC4848" format="default"/>, and <xref
lity in particular, is within the emergency services area. Within North America target="RFC5222" format="default"/> apply here. No additional security
, the NENA i3 <xref target="NENA-i3"/> document specifies how protocols includin aspects are foreseen by the addition of an extra tag. Separation of
g LoST are used. The i3 document is expected to reference the 'LoST-Validation' services might be desired, for example, to be able to allocate different l
service tag, and specify its use in both server NAPTR DNS records and client re evels of resources (such as server capacity, attack mitigation, bandwidth, etc.)
solution of Application Unique Strings (AUS).</t> 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 cor
<t>LoST allows a server to refuse to perform location validation, and define rect server cluster.</t>
s the 'locationValidationUnavailable' warning. LoST also allows a server to refe <t><xref target="RFC5222" format="default"/> descriptively discusses the
r to another server rather than answering itself. So, in a deployment where a Lo use of DNS security <xref target="RFC4033" format="default"/> to
ST tree has separate server clusters for mapping and for validation, mapping ser mitigate the risk of DNS-based attacks. Because DNS security has become
vers receiving a request for validation could either perform the validation as r more widely deployed since the publication of <xref target="RFC5222"
equested, or return the 'locationValidationUnavailable' warning, and potentially format="default"/>, such measures <bcp14>SHOULD</bcp14> be used when
also include a &lt;redirect&gt; element to redirect to a validation server. How performing NAPTR resolution. Note that, while there are valid reasons
ever, the &lt;redirect&gt; element contains an Application Unique String, so unl to proceed with a LoST mapping query despite security failures while
ess the AUSs for validation and mapping are different (e.g., 'ecrf.example.org' initiating or processing an emergency call, these concerns generally do
and 'lvf.example.org'), we still need a different service tag to allow for flexi not apply to a LoST validation query done in advance of an emergency
ble deployment choices (i.e., not requiring a DNS name convention).</t> call.</t>
<t>LoST clients performing emergency services operations are expected to com
ply with the latest NENA i3 specification, and hence support the 'LoST-Validatio
n' 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 c
lient 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 va
lidation are split, the data is identical; the split is a load and deployment op
timization strategy. The server designated for mapping is likely to perform val
idation when requested, potentially unless it is under load. 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 l
oad and may provide the function. Even in the (unlikely) case of a designated m
apping server that refuses to perform validation at any time, the server could r
eturn 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, and will submit a dis
crepancy report, as specified in NENA i3. The discrepancy report resolution wou
ld be to update the client with the 'LoST-Validation' service tag, update the AU
S 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 th
at, because LoST does not require servers to perform validation, the situation d
escribed can exist regardless of the addition of the 'LoST-Validation' service t
ag. The addition of the tag improves the likelihood of a client needing validat
ion being able to do so.</t>
</section> </section>
<section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA has added 'LoST-Validation' to the "S-NAPTR Application Service
Tags" registry created by <xref target="RFC3958" format="default"/>.
This tag serves as a counterpart to the 'LoST' tag added by <xref
target="RFC5222" format="default"/>.</t>
<section anchor="security" title="Security Considerations"> <t>(Note that IANA and <xref target="RFC3958" format="default"/> call this
<t>The security considerations described in <xref target="RFC3958"/>, <xre registry "S-NAPTR Application Service Tags", while <xref target="RFC5222" forma
f target="RFC4848"/>, and <xref target="RFC5222"/> apply here. No additional se t="default"/> calls it "U-NAPTR application service tag".)</t>
curity aspects are foreseen by the addition of an extra tag. Separation of serv <section numbered="true" toc="default">
ices might be desired, for example, to be able to allocate different levels of r <name>S-NAPTR Registration</name>
esources (such as server capacity, attack mitigation, bandwidth, etc.) to the ma <t>This document registers an S-NAPTR application service tag:</t>
pping and validation services, in which case separate tags are needed to allow L <dl spacing="normal">
oST clients (which may include other LoST servers) to identify the correct serve <dt>Application Service Tag:</dt> <dd>LoST-Validation</dd>
r cluster.</t> <dt>Defining Publication:</dt> <dd>This document</dd>
<t><xref target="RFC5222"/> descriptively discusses the use of DNS Securit </dl>
y <xref target="RFC4033"/> to mitigate the risk of DNS-based attacks. Because D </section>
NS Security has become more widely deployed since the publication of <xref targe <!-- title="S-NAPTR Registration" -->
t="RFC5222"/>, such measures SHOULD be used when performing NAPTR resolution. N
ote that, while there are valid reasons to proceed with a LoST mapping query des
pite security failures while initiating or processing an emergency call, these c
oncerns generally do not apply to a loST validation query done in advance of an
emergency call.</t>
</section> </section>
<!-- title="IANA Considerations" -->
<section anchor="iana" title="IANA Considerations">
<t>IANA is requested to add 'LoST-Validation' to the S-NAPTR Application S
ervice Tag registry created by <xref target="RFC3958"/> This tag serves as a co
unterpart to the 'LoST' tag added by <xref target="RFC5222"/>.</t>
<t>(Note that IANA and <xref target="RFC3958"/> call this registry "S-NAPT
R Application Service Tags" while <xref target="RFC5222"/> calls it "U-NAPTR app
lication service tag".)</t>
<section title="S-NAPTR Registration">
<t>This document registers an S-NAPTR application service tag:</t>
<t>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<list style="empty">
<t>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"> <!-- <section title="Contributors">
<t></t>
</section> --> </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 revie
ws and suggestions, and to Barry Leiba for shepherding the document.</t>
</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="secu
rity"/></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> </middle>
<back> <back>
<references>
<references title="Normative References"> <name>References</name>
<references>
<name>Normative References</name>
<!-- &RFC2119; --> <!-- &RFC2119; -->
&RFC3958; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.4033.xml"?> FC.2119.xml"/>
<?rfc include="reference.RFC.4848.xml"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.5222.xml"?> FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</references> FC.3958.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4033.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4848.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5222.xml"/>
</references>
<references>
<name>Informative References</name>
<references title="Informative references"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R FC.5582.xml"/>
<?rfc include="reference.RFC.5582.xml"?> <!-- [NENA-i3] The URL below is correct. Also found https://cdn.ymaws.com/www.n ena.org/resource/resmgr/standards/NENA-STA-010.2_i3_Architectu.pdf -->
<reference anchor="NENA-i3" <reference anchor="NENA-i3" target="https://www.nena.org/page/i3_Stage3"
target="https://www.nena.org/page/i3_Stage3"> >
<front> <front>
<title>Detailed Functional and Interface Standards for the NENA i3 S olution</title> <title>Detailed Functional and Interface Standards for the NENA i3 S olution</title>
<author fullname="" initials="" surname="National Emergency Number A ssociation (NENA) Interconnection and Security Committee, i3 Architecture Workin g Group"/> <author fullname="" initials="" surname="National Emergency Number A ssociation (NENA) Interconnection and Security Committee, i3 Architecture Workin g Group"/>
<date year="2016"/> <date year="2016"/>
</front> </front>
</reference> </reference>
</references> </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"/>, <cont
act fullname="Roman Danyliw"/>, and <contact fullname="Benjamin Kaduk"/> for the
ir helpful reviews and suggestions and to <contact fullname="Barry Leiba"/> for
shepherding the document.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 29 change blocks. 
359 lines changed or deleted 273 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/