RFC 9036
Changing the Location-to-Service Translation (LoST) Location Profiles Registry Policy
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 Notice π
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
- [reg] IANA, "Location-to-Service Translation (LoST) Location Profiles",
https://www.iana.org/assignments/lost-location-profiles. - [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
https://www.rfc-editor.org/info/rfc5222. - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
https://www.rfc-editor.org/info/rfc8126.
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
- Email:
rg+ietf@coretechnologyconsulting.com - URI:
http://www.coretechnologyconsulting.com
π¦ where this page comes from
- ietf: rfc9036 2021-06
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms