Changing the Location-to-Service Translation (LoST) Location Profiles Registry PolicyCore Technology ConsultingUnited States of Americarg+ietf@coretechnologyconsulting.comhttp://www.coretechnologyconsulting.com
Applications and Real Time
ecritThis document changes the policy of the "Location-to-Service Translation (LoST) Location Profiles" IANA registry established by RFC 5222 from Standards Action to Specification Required. This allows standards development organizations (SDOs) other than the IETF to add new values.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
. Introduction
. Document Scope
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgements
Author's Address
IntroductionThe Location-to-Service Translation (LoST) Protocol uses a location profile when conveying location (e.g., in a mapping request and a service boundary result). established an IANA registry of location profiles with a registry policy of Standards Action. This requires a Standards Track RFC for any new registry values. The National Emergency Number Association (NENA) is a standards development organization (SDO) that makes significant use of LoST in its emergency call specifications (e.g., ) 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.Document ScopeThis document changes the policy of the "Location-to-Service Translation (LoST) Location Profiles" IANA registry established by from Standards Action to Specification Required (as defined in ). This allows SDOs other than the IETF to add new values.Security ConsiderationsNo new security considerations are identified by this change in registry policy.IANA ConsiderationsIANA has changed the policy of the "Location-to-Service Translation (LoST) Location Profiles" registry (established by
) to Specification Required. IANA has also added this document as a reference for the registry. The Expert Reviewer is designated per . The reviewer should verify that:
the proposed new value is specified by the IETF, NENA, or a similar SDO in which location profiles are in scope;
the proposed new value has a clear need (which includes there not being an existing profile that meets the need); and
the profile specification is unambiguous and interoperable.
ReferencesNormative ReferencesLocation-to-Service Translation (LoST) Location ProfilesIANALoST: A Location-to-Service Translation ProtocolThis document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. [STANDARDS-TRACK]Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.Informative ReferencesDetailed Functional and Interface Standards for the NENA i3 SolutionNational Emergency Number Association (NENA)NENA i3 Solution - Stage 3, NENA-STA-010.2-2016AcknowledgementsMany thanks to for his helpful review and suggestions and to for his suggestion to clarify that "clear need" includes there not being an existing profile.Author's AddressCore Technology ConsultingUnited States of Americarg+ietf@coretechnologyconsulting.comhttp://www.coretechnologyconsulting.com