rfc9036xml2.original.xml   rfc9036.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 RFC5222 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.5222.xml">
<!ENTITY RFC5226 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/referenc
e.RFC.5226.xml">
]>
<?rfc inline="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" updates="5222"
<?rfc symrefs="yes" ?> docName="draft-ietf-ecrit-location-profile-registry-policy-02" number="9036" ob
<?rfc iprnotified="no" ?> soletes="" submissionType="IETF" category="std" consensus="true" xml:lang="en" t
<?rfc strict="no" ?> ocInclude="true" tocDepth="2" symRefs="true" sortRefs="true" version="3">
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<!-- <?rfc colonspace='yes' ?> -->
<rfc category="std" ipr="trust200902" updates="5222" docName="draft-ietf-ecrit-l ocation-profile-registry-policy-02">
<front> <front>
<title abbrev="LoST-Validation">Changing the LoST Location Profile Registry Policy</title>
<author fullname="Randall Gellens" initials="R." <title abbrev="LoST Profiles Registry Policy">Changing the Location-to-Servi
surname="Gellens"> ce Translation (LoST) Location Profiles Registry Policy</title>
<seriesInfo name="RFC" value="9036"/>
<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> </region>
<code> </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>
<!-- <date year="2021" month="June" />
<author initials="B." surname="Rosen" fullname="Brian Rosen">
<organization></organization>
<address>
<postal>
<street>470 Conrad Dr</street>
<city>Mars</city>
<region> PA </region>
<code>16046 </code>
<country>US </country>
</postal>
<phone> </phone>
<email>br@brianrosen.net
</email>
</address>
</author>
<date year="2021"/>
<area>Applications and Real Time</area> <area>Applications and Real Time</area>
<workgroup>ecrit</workgroup> <workgroup>ecrit</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>This document changes the policy of the Location-to-Service Translation (LoST) Location Profile IANA registry established by RFC5222 from Standards Act ion to Specification Required. This allows standards development organizations (SDOs) other than the IETF to add new values.</t> <t>This document changes the policy of the "Location-to-Service Translatio n (LoST) Location Profiles" IANA registry established by RFC 5222 from Standards Action to Specification Required. This allows standards development organizati ons (SDOs) other than the IETF to add new values.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<!-- <section anchor="intro" numbered="true" toc="default">
<section anchor="terminology" title="Terminology"> <name>Introduction</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH <t>The Location-to-Service Translation (LoST) Protocol <xref target="RFC52
OULD", "SHOULD NOT", 22" format="default"/> uses a location profile when conveying location (e.g., in
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpre a mapping request and a service boundary result). <xref target="RFC5222" forma
ted as described in t="default"/> established an IANA registry of location profiles <xref target="re
<xref target="RFC2119"/>. </t> g" format="default"/> with a registry policy of Standards Action. This requires
</section> a Standards Track RFC for any new registry values. The National Emergency Numb
er Association (NENA) is a standards development organization (SDO) that makes s
<section anchor="scope" title="Document Scope"> ignificant use of LoST in its emergency call specifications (e.g., <xref target=
<t>This document changes the policy of the Location-to-Service Translati "NENA-i3" format="default"/>) and has identified a need for additional location
on (LoST) Location Profile IANA registry <xref target="reg"/> established by <xr profiles. This document changes the registry policy to Specification Required,
ef target="RFC5222"/> from Standards Action to Specification Required (as define allowing other SDOs such as NENA to add values.</t>
d in <xref target="RFC8126"/>). This allows standards development organizations
(SDOs) other than the IETF to add new values.</t>
</section> </section>
<section anchor="scope" numbered="true" toc="default">
<section anchor="intro" title="Introduction"> <name>Document Scope</name>
<t>The Location-to-Service Translation Protocol, LoST <xref target="RFC522 <t>This document changes the policy of the "Location-to-Service Translatio
2"/> uses a location profile when conveying location (e.g., in a mapping request n (LoST) Location Profiles" IANA registry <xref target="reg" format="default"/>
and a service boundary result). <xref target="RFC5222"/> established an IANA r established by <xref target="RFC5222" format="default"/> from Standards Action t
egistry of location profiles <xref target="reg"/>, with a registry policy of Sta o Specification Required (as defined in <xref target="RFC8126" format="default"/
ndards Action. This requires a standards-track RFC for any new registry values. >). This allows SDOs other than the IETF to add new values.</t>
The National Emergency Number Association (NENA) is an SDO that makes signific
ant use of LoST in its emergency call specifications (e.g., <xref target="NENA-i
3"/>) and has identified a need for additional location profiles. This document
changes the registry policy to Specification Required, allowing other SDOs such
as NENA to add values.</t>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section anchor="security" title="Security Considerations"> <name>Security Considerations</name>
<t>No new security considerations are identified by this change in registr y policy.</t> <t>No new security considerations are identified by this change in registr y policy.</t>
</section> </section>
<section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="iana" title="IANA Considerations"> <t>IANA has changed the policy of the "Location-to-Service Translation (Lo
ST) Location Profiles" registry (established by
<t>IANA is requested to change the policy of the Location-to-Service Trans <xref target="RFC5222" format="default"/>) to Specification Required. IA
lation (LoST) Location Profile Registry (established by <xref target="RFC5222"/> NA has also added this document as a reference for the registry. The Expert Revi
) to Specification Required. The expert reviewer is designated per <xref target ewer is designated per <xref target="RFC8126" format="default"/>. The reviewer
="RFC8126"/>. The reviewer should verify that: should verify that:
<?rfc compact="yes" ?> </t>
<?rfc subcompact="yes" ?> <ul spacing="normal">
<list style="symbols"> <li>the proposed new value is specified by the IETF, NENA, or a similar
<t>the proposed new value is specified by the IETF, NENA, or a similar S SDO in which location profiles are in scope;</li>
DO in which location profiles are in scope;</t> <li>the proposed new value has a clear need (which includes there not be
<t>the proposed new value has a clear need (which includes there not bei ing an existing profile that meets the need); and</li>
ng an existing profile that meets the need);</t> <li>the profile specification is unambiguous and interoperable.</li>
<t>the profile specification is unambiguous and interoperable.</t> </ul>
</list>
</t>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
</section> <!-- title="IANA Considerations" -->
<!-- <section title="Contributors">
<t></t>
</section> -->
<section title="Acknowledgements">
<t>Many thanks to Ted Hardie for his helpful review and suggestions, and t
o Guy Caron for his suggestion to clarify that "clear need" includes there not b
eing an existing profile.</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> </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.RF
C.5222.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
<references title="Normative References"> <reference anchor="reg" target="https://www.iana.org/assignments/lost-lo
<!-- &RFC2119; --> cation-profiles">
<?rfc include="reference.RFC.5222.xml"?> <front>
<?rfc include="reference.RFC.8126.xml"?> <title>Location-to-Service Translation (LoST) Location Profiles</tit
le>
<reference anchor="reg" target="https://www.iana.org/assignments <author>
/lost-location-profiles/lost-location-profiles.xhtml"> <organization>IANA</organization>
<front> </author>
<title>Location-to-Service Translation (LoST) Location Profile Regis <date/>
try</title> </front>
<author/> </reference>
<date /> </references>
</front> <references>
</reference> <name>Informative References</name>
</references> <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>
<author><organization>National Emergency Number Association (NENA)</
organization></author>
<date year="2016" month="September"/>
</front>
<refcontent>NENA i3 Solution - Stage 3, NENA-STA-010.2-2016</refconte
nt>
<references title="Informative references"> </reference>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<reference anchor="NENA-i3" <t>Many thanks to <contact fullname="Ted Hardie"/> for his helpful review
target="https://www.nena.org/page/i3_Stage3"> and suggestions and to <contact fullname="Guy Caron"/> for his suggestion to cla
<front> rify that "clear need" includes there not being an existing profile.</t>
<title>Detailed Functional and Interface Standards for the NENA i3 S </section>
olution</title>
<author fullname="" initials="" surname="National Emergency Number A
ssociation (NENA) Interconnection and Security Committee, i3 Architecture Workin
g Group"/>
<date year="2016"/>
</front>
</reference>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 22 change blocks. 
228 lines changed or deleted 99 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/