Changing the Location-to-Service Translation (LoST) Location Profiles Registry Policy Core Technology Consulting
United States of America rg+ietf@coretechnologyconsulting.com http://www.coretechnologyconsulting.com
Applications and Real Time ecrit This 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
Introduction The 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 Scope This 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 Considerations No new security considerations are identified by this change in registry policy.
IANA Considerations IANA 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.
 References Normative References Location-to-Service Translation (LoST) Location Profiles IANA LoST: A Location-to-Service Translation Protocol This 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 RFCs Many 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 References Detailed Functional and Interface Standards for the NENA i3 Solution National Emergency Number Association (NENA) NENA i3 Solution - Stage 3, NENA-STA-010.2-2016
Acknowledgements Many 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 Address Core Technology Consulting
United States of America rg+ietf@coretechnologyconsulting.com http://www.coretechnologyconsulting.com