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." <front>
surname="Gellens"> <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> <region/>
<code> </code> <code/>
<country>US </country> <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="October" 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"
</section> format="default"/> can identify servers designated for location validation
. This tag and the information on its use is an update to <xref target="RFC5222
<section anchor="scope" title="Document Scope"> " format="default"/> that enables the explicit discovery of a server that suppor
<t>This document adds 'LoST-Validation' to the S-NAPTR Application Servi ts location validation.</t>
ce Tag IANA registry, and describes how this tag fits in the LoST server discove
ry procedure described in <xref target="RFC5222"/>. This tag is used with Namin
g Authority Pointer (NAPTR) Domain Name System (DNS) records so that clients of
the Location-to-Service Translation Protocol (LoST) <xref target="RFC5222"/> can
identify servers explicitly willing to perform location validation. This tag a
nd the information on its use is an update to <xref target="RFC5222"/> that enab
les the explicit discovery of a server that supports location validation.</t>
</section>
<section anchor="intro" title="Introduction">
<t>The Location-to-Service Translation Protocol, LoST <xref target="RFC522
2"/> defines a mapping service with the additional ability for a client to reque
st that a civic address be validated. The LoST protocol allows servers to ignor
e a request to perform location validation. The National Emergency Number Assoc
iation (NENA) has defined an architecture for all-IP emergency services (known a
s "i3" <xref target="NENA-i3"/>), which defines the mapping (routing) and valida
tion functions as two distinct functional elements, defined as an Emergency Call
Routing Function (ECRF) and a Location Validation Function (LVF). NENA i3 requ
ires that the mapping (ECRF) and validation (LVF) functions be separable, so tha
t an entity responsible for a LoST server cluster can decide to provide mapping
and validation services using consolidated or separate server clusters (i.e., us
ing the same or separate boxes). The rationale is that the mapping service is u
sed in real-time during emergency call routing, while the validation service is
used in advance, typically when data is provisioned, and therefore the mapping s
ervice has much higher availability and response time requirements than the vali
dation service. An organization might choose to deploy these services using dif
ferent 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 val
idation, while another organization might choose to use the same sets of servers
for both, configured and deployed to offer the high service level demanded of t
he mapping service.</t>
<t>In order to permit this separability, any entity querying a LoST serv
er needs to be able to resolve an Application Unique String (AUS) into a URL for
a LoST server that offers the required service (mapping or validation). This s
eparability needs to be maintained throughout the LoST tree structure, from fore
st guide to leaf node (LoST architecture is described in <xref target="RFC5582"/
>). 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 the different services. DNS name conventions a
re inflexible and fragile, making a different service tag the preferred approach
.</t>
<t>Because a server discovered using the "LoST" application service tag
may ignore a request to perform location validation, a service tag explicitly fo
r location validation also reduces the likelihood (which has existed since <xref
target="RFC5582"/>) of a client requiring location validation reaching servers
unwilling to do so.</t>
</section> </section>
<section anchor="intro" numbered="true" toc="default">
<section anchor="LoST-Validation" title="The LoST-Validation Application Ser <name>Introduction</name>
vice Tag"> <t>The LoST Protocol <xref
target="RFC5222" format="default"/> defines a mapping service with the
<t>This document adds 'LoST-Validation' to the S-NAPTR Application Servi additional ability for a client to request that a civic address be
ce Tag registry created by <xref target="RFC3958"/>. The 'LoST-Validation' tag validated. The LoST protocol allows servers to ignore a request to
serves as a counterpart to the 'LoST' tag added by <xref target="RFC5222"/>: The perform location validation. The National Emergency Number Association
'LoST' tag identifies servers able to perform the core mapping function, while (NENA) has defined an architecture for all-IP emergency services (known
'LoST-Validation' identifies servers explicitly willing to perform the validatio as "i3" <xref target="NENA-i3" format="default"/>), which defines the
n function.</t> mapping (routing) and validation functions as two distinct functional
elements, defined as an Emergency Call Routing Function (ECRF) and a
<t>Because some servers might be configured to provide both mapping and vali Location Validation Function (LVF). NENA i3 requires that the mapping
dation functions, a server identified using the 'LoST' service tag might also pe (ECRF) and validation (LVF) functions be separable; an entity
rform the validation function (and resolving the two tags might result in the sa responsible for a LoST server cluster can decide to provide mapping and
me URL). Because the two functions might be separate, clients seeking a LoST se validation services using consolidated or separate server clusters
rver for location validation can first try U-NAPTR resolution using the 'Lost-Va (i.e., using the same or separate boxes). The rationale is that the
lidation' service tag, and fallback to the 'LoST' service tag if this does not r mapping service is used in real time during emergency call routing,
esolve to a usable LoST server.</t> while the validation service is used in advance, typically when data is
provisioned; therefore, the mapping service has much higher availability
<t>LoST <xref target="RFC5222"/> specifies that LoST servers are located by and response-time requirements than the validation service. An
resolving an application Unique String (AUS) using U-NAPTR/DDDS (URI-Enabled NAP organization might choose to deploy these services using different
TR/Dynamic Delegation Discovery Service) <xref target="RFC4848"/>, and defines t server clusters to make it easier to provide higher levels of service
he 'LoST' Application service tag. In order to permit separability of the mappi for the mapping function while shielding it from the potentially bursty
ng and validation services performed using LoST, and to reduce the likelihood of load of validation. Another organization might choose to use the same
a client requiring location validation reaching servers unwilling to do so, thi sets of servers for both services, configured and deployed to offer the hi
s document defines the 'LoST-Validation' service tag. NAPTR records for LoST se gh service level demanded of the mapping service.</t>
rvers available for location validation contain the 'LoST-Validation' service ta <t>In order to permit this separability, any entity querying a LoST
g. An entity needing to perform location validation using LoST performs the dis server needs to be able to resolve an Application Unique String (AUS)
covery procedure as described in <xref target="RFC5222"/>, except that the 'LoST into a URL for a LoST server designated for the required service (mapping
-Validation' service tag is used in preference to the 'LoST' service tag. For b or validation). This separability needs to be maintained throughout the
oth service tags, the HTTP and HTTPS URL schemes are used. In the absense of an LoST tree structure, from forest guide to leaf node (LoST architecture
y NAPTR records containing the 'LoST-Validation' service tag, the 'LoST' service is described in <xref target="RFC5582" format="default"/>). Because
tag is used. Fallback to the 'LoST' service tag may follow if the 'Lost-Valida LoST referrals return an AUS rather than a URL, either a different
tion' service tag fails to result in a usable LoST server. The discovery proced service tag or a DNS name convention (e.g., "ecrf.example.org" and
ure with the 'LoST-Validation' service tag might result in the same URL as the ' "lvf.example.org") is needed to differentiate between the services. DNS n
LoST' service tag, or it may result in a different URL. When the URLs are diffe ame conventions are inflexible and fragile, making a different service tag the p
rent, they could lead to the same physical servers, or different servers.</t> 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="back" title="Backwards Compatability"> <name>The LoST-Validation Application Service Tag</name>
<t>This document adds 'LoST-Validation' to the "S-NAPTR Application
<t>The primary use of LoST in general, and the location validation functiona Service Tags" registry created by <xref target="RFC3958"
lity in particular, is within the emergency services area. Within North America format="default"/>. The 'LoST-Validation' tag serves as a counterpart
, the NENA i3 <xref target="NENA-i3"/> document specifies how protocols includin to the 'LoST' tag added by <xref target="RFC5222" format="default"/>:
g LoST are used. The i3 document is expected to reference the 'LoST-Validation' the 'LoST' tag identifies servers able to perform the core mapping
service tag, and specify its use in both server NAPTR DNS records and client re function, while 'LoST-Validation' identifies servers designated for the va
solution of Application Unique Strings (AUS).</t> lidation function.</t>
<t>Because some servers might be configured to provide both mapping and
<t>LoST allows a server to refuse to perform location validation, and define validation functions, a server identified using the 'LoST' service tag
s the 'locationValidationUnavailable' warning. LoST also allows a server to refe might also perform the validation function (and resolving the two tags
r to another server rather than answering itself. So, in a deployment where a Lo might result in the same URL). Because the two functions might be
ST tree has separate server clusters for mapping and for validation, mapping ser separate, clients seeking a LoST server for location validation can
vers receiving a request for validation could either perform the validation as r first try a URI-Enabled NAPTR (U-NAPTR) resolution using the
equested, or return the 'locationValidationUnavailable' warning, and potentially 'LoST-Validation' service tag and can fall back to the 'LoST' service tag
also include a &lt;redirect&gt; element to redirect to a validation server. How if this does not resolve to a usable LoST server.</t>
ever, the &lt;redirect&gt; element contains an Application Unique String, so unl <t>LoST <xref target="RFC5222" format="default"/> specifies that LoST
ess the AUSs for validation and mapping are different (e.g., 'ecrf.example.org' servers are located by resolving an AUS using U-NAPTR/DDDS (URI-Enabled
and 'lvf.example.org'), we still need a different service tag to allow for flexi NAPTR / Dynamic Delegation Discovery Service) <xref target="RFC4848"
ble deployment choices (i.e., not requiring a DNS name convention).</t> format="default"/> and defines the 'LoST' application service tag. In
order to permit separability of the mapping and validation services
<t>LoST clients performing emergency services operations are expected to com performed using LoST, this document defines the 'LoST-Validation'
ply with the latest NENA i3 specification, and hence support the 'LoST-Validatio service tag. This tag also reduces the likelihood that a client needing
n' service tag when defined. A LoST client implemented prior to the addition of location validation might reach servers that are not performing validation
the 'LoST-Validation' tag would use the 'LoST' tag to resolve an AUS. Such a c (due to
lient might not be performing location validation, but if it is, the LoST server configuration and/or conditions). NAPTR records for LoST servers availabl
it contacts may perform the service. Even in a deployment where mapping and va e for location validation contain the 'LoST-Validation' service tag. An entity
lidation are split, the data is identical; the split is a load and deployment op needing to perform location validation using LoST performs the discovery procedu
timization strategy. The server designated for mapping is likely to perform val re as described in <xref target="RFC5222" format="default"/>, except that the 'L
idation when requested, potentially unless it is under load. If an older client oST-Validation' service tag is used in preference to the 'LoST' service tag. Fo
attempts validation using a designated mapping server that refuses the request, r both service tags, the HTTP and HTTPS URL schemes are used. In the absence of
the client will retry later, at which point the server may no longer be under l any NAPTR records containing the 'LoST-Validation' service tag, the 'LoST' serv
oad and may provide the function. Even in the (unlikely) case of a designated m ice tag is used. Fallback to the 'LoST' service tag may follow if the 'LoST-Val
apping server that refuses to perform validation at any time, the server could r idation' service tag fails to result in a usable LoST server. The discovery pro
eturn a redirect with a different AUS (e.g., "lvf.example.com") that resolves to cedure with the 'LoST-Validation' service tag might result in the same URL as th
a designated validation server. In the (unlikely) worst case, the client will e 'LoST' service tag, or it may result in a different URL. When the URLs are di
be unable to reach a server willing to perform validation, and will submit a dis fferent, they could lead to the same physical servers or different servers.</t>
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="security" title="Security Considerations"> <section anchor="back" numbered="true" toc="default">
<t>The security considerations described in <xref target="RFC3958"/>, <xre <name>Backwards Compatibility</name>
f target="RFC4848"/>, and <xref target="RFC5222"/> apply here. No additional se <t>The primary use of LoST in general, and the location validation functio
curity aspects are foreseen by the addition of an extra tag. Separation of serv nality in particular, is within the emergency services area. Within North Ameri
ices might be desired, for example, to be able to allocate different levels of r ca, the NENA i3 <xref target="NENA-i3" format="default"/> document specifies how
esources (such as server capacity, attack mitigation, bandwidth, etc.) to the ma protocols including LoST are used. The i3 document is expected to reference th
pping and validation services, in which case separate tags are needed to allow L e 'LoST-Validation' service tag and specify its use in both server NAPTR DNS rec
oST clients (which may include other LoST servers) to identify the correct serve ords and client resolution of AUS.</t>
r cluster.</t> <t>LoST allows a server to refuse to perform location validation and
<t><xref target="RFC5222"/> descriptively discusses the use of DNS Securit defines the 'locationValidationUnavailable' warning. LoST also allows a
y <xref target="RFC4033"/> to mitigate the risk of DNS-based attacks. Because D server to refer to another server rather than answering itself. So, in a
NS Security has become more widely deployed since the publication of <xref targe deployment where a LoST tree has separate server clusters for mapping
t="RFC5222"/>, such measures SHOULD be used when performing NAPTR resolution. N and for validation, mapping servers receiving a request for validation
ote that, while there are valid reasons to proceed with a LoST mapping query des could either perform the validation as requested or return the
pite security failures while initiating or processing an emergency call, these c 'locationValidationUnavailable' warning and potentially also include a
oncerns generally do not apply to a loST validation query done in advance of an &lt;redirect&gt; element to redirect to a validation server. However,
emergency call.</t> the &lt;redirect&gt; element contains an 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 NENA i3 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. Servers designated for mapping might perform validation when
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 might provide the function (e.g., if its load or other conditions
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="iana" title="IANA Considerations"> <name>Security Considerations</name>
<t>The security considerations described in <xref target="RFC3958"
<t>IANA is requested to add 'LoST-Validation' to the S-NAPTR Application S format="default"/>, <xref target="RFC4848" format="default"/>, and <xref
ervice Tag registry created by <xref target="RFC3958"/> This tag serves as a co target="RFC5222" format="default"/> apply here. No additional security
unterpart to the 'LoST' tag added by <xref target="RFC5222"/>.</t> aspects are foreseen by the addition of an extra tag. Separation of
services might be desired, for example, to be able to allocate different l
<t>(Note that IANA and <xref target="RFC3958"/> call this registry "S-NAPT evels of resources (such as server capacity, attack mitigation, bandwidth, etc.)
R Application Service Tags" while <xref target="RFC5222"/> calls it "U-NAPTR app to the mapping and validation services, in which case separate tags are needed
lication service tag".)</t> to allow LoST clients (which may include other LoST servers) to identify the cor
rect server cluster.</t>
<section title="S-NAPTR Registration"> <t><xref target="RFC5222" format="default"/> descriptively discusses the
use of DNS security <xref target="RFC4033" format="default"/> to
<t>This document registers an S-NAPTR application service tag:</t> mitigate the risk of DNS-based attacks. Because DNS security has become
more widely deployed since the publication of <xref target="RFC5222"
<t> format="default"/>, such measures <bcp14>SHOULD</bcp14> be used when
<?rfc compact="yes" ?> performing NAPTR resolution. Note that, while there are valid reasons
<?rfc subcompact="no" ?> to proceed with a LoST mapping query despite security failures while
<list style="empty"> initiating or processing an emergency call, these concerns generally do
<t>Application Service Tag: LoST-Validation</t> not apply to a LoST validation query done in advance of an emergency
<t>Defining Publication: This document.</t> call.</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 revie
ws and suggestions, and to Barry Leiba for shepherding the document.</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 title="Changes from Previous Versions"> <t>(Note that IANA and <xref target="RFC3958" format="default"/> call this
<?rfc compact="yes" ?> registry "S-NAPTR Application Service Tags", while <xref target="RFC5222" forma
<?rfc subcompact="yes" ?> t="default"/> calls it "U-NAPTR application service tag".)</t>
<section title="Changes from -00 to -01"> <section numbered="true" toc="default">
<t> <name>S-NAPTR Registration</name>
<list style="symbols"> <t>This document registers an S-NAPTR application service tag:</t>
<t>Fixed incorrect tag in <xref target="iana"/></t> <dl spacing="normal">
<t>Clarified background and explanation in <xref target="intro"/></t <dt>Application Service Tag:</dt> <dd>LoST-Validation</dd>
> <dt>Defining Publication:</dt> <dd>This document</dd>
<t>Clarified text in <xref target="LoST-Validation"/></t> </dl>
<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> </section>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
</section> </section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
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="Normative References"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<!-- &RFC2119; --> FC.5582.xml"/>
&RFC3958; <reference anchor="NENA-i3" target="https://www.nena.org/page/i3_Stage3"
<?rfc include="reference.RFC.4033.xml"?> >
<?rfc include="reference.RFC.4848.xml"?> <front>
<?rfc include="reference.RFC.5222.xml"?>
</references>
<references title="Informative references">
<?rfc include="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 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. 25 change blocks. 
364 lines changed or deleted 268 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/