RFC 9036

Changing the Location-to-Service Translation (LoST) Location Profiles Registry Policy

πŸ“… published June 2021, from ietf

RFC 9036 πŸ’– is a Standards Track doc from June 2021 (ISSN 2070-1721) by Randall Gellens of Core Technology Consulting πŸŽ€. It's called "Changing the Location-to-Service Translation (LoST) Location Profiles Registry Policy" and it updates RFC 5222 πŸ¦‹. The header doesn't list anything it obsoletes.

Abstract ✨

okay so this doc changes the registry policy for the "Location-to-Service Translation (LoST) Location Profiles" IANA registry from Standards Action to Specification Required πŸ’…. the big deal? other standards development organizations (SDOs) besides the IETF can now add new values 🌸

Status of This Memo 🧚

this is an Internet Standards Track document πŸ”₯

it's a product of the Internet Engineering Task Force (IETF) and represents IETF community consensus. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 7841 πŸ“š

info about the current status, errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc9036 πŸ’œ


Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. 🫢

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. read those carefully, they spell out your rights and restrictions πŸ‘€

Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License ⭐


Table of Contents πŸ“

1.  Introduction
2.  Document Scope
3.  Security Considerations
4.  IANA Considerations
5.  References
  5.1.  Normative References
  5.2.  Informative References
Acknowledgements
Author's Address

1. Introduction πŸ¦‹

okay the Location-to-Service Translation (LoST) Protocol [RFC5222] uses a location profile whenever it conveys location, like in a mapping request or a service boundary result ✨ [RFC5222] set up an IANA registry of location profiles [reg], but its registry policy was Standards Action. that means any new value needed a Standards Track RFC, which is a lot 😭

the National Emergency Number Association (NENA) is an SDO that uses LoST heavily in its emergency call specs (see [NENA-i3]) and has spotted a need for more location profiles 🚨 so this doc switches the policy to Specification Required, which lets SDOs like NENA add values themselves πŸŽ€

2. Document Scope πŸ’–

this doc changes the policy of the "Location-to-Service Translation (LoST) Location Profiles" IANA registry [reg], which [RFC5222] created, from Standards Action to Specification Required (as defined in [RFC8126]) πŸ¦‹ SDOs other than the IETF can now add new values ✨

3. Security Considerations πŸ”

no new security considerations come from this change in registry policy 🫢

4. IANA Considerations 🌸

IANA changed the policy of the "Location-to-Service Translation (LoST) Location Profiles" registry (created by [RFC5222]) to Specification Required πŸ’… IANA also added this document as a reference for the registry. the Expert Reviewer is designated per [RFC8126] 🧚 the reviewer should check that:

  • the new value is specified by the IETF, NENA, or a similar SDO where location profiles are in scope;
  • the new value has a clear need (and that includes there not being an existing profile that already meets the need); and
  • the profile specification is unambiguous and interoperable.

5. References πŸ“š

5.1. Normative References

5.2. Informative References

  • [NENA-i3] National Emergency Number Association (NENA), "Detailed Functional and Interface Standards for the NENA i3 Solution", NENA i3 Solution - Stage 3, NENA-STA-010.2-2016, September 2016, https://www.nena.org/page/i3_Stage3.

Acknowledgements πŸ’œ

huge thanks to Ted Hardie for the helpful review and suggestions πŸ™Œ and to Guy Caron for the idea to spell out that "clear need" includes there not being an existing profile πŸ‘‘

Author's Address πŸŽ€

Randall Gellens Core Technology Consulting United States of America

πŸ“¦ where this page comes from