Network Working Group R. Gellens Internet-Draft Core Technology Consulting Intended status: Informational B. Rosen Expires: July 20, 2020 January 17, 2020 The LoST-Validation S-NAPTR Application Service Tag draft-gellens-lost-validation-00.txt Abstract This document adds LoST-Validation to the S-NAPTR Application Service Tag IANA registry. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 20, 2020. Copyright Notice Copyright (c) 2020 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 (http://trustee.ietf.org/license-info) 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. Gellens & Rosen Expires July 20, 2020 [Page 1] Internet-Draft LoST-Validation January 2020 Table of Contents 1. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. The LoST-Validation Application Service Tag . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 5.1. U-NAPTR Registration . . . . . . . . . . . . . . . . . . 4 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 8. Changes from Previous Versions . . . . . . . . . . . . . . . 4 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 9.2. Informative references . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Document Scope This document only adds a new Service Tag. 2. Introduction The Location-to-Service Translation Protocol, LoST [RFC5222] defines a mapping service with the additional ability to request that a civic address be validated. The National Emergency Number Association (NENA) has defined an architecture (known as "i3" [NENA-i3]) which defines the mapping and routing functions as two distinct roles, defined as an Emergency Call Routing Function (ECRF) and a Location Verification Function (LVF). NENA i3 requires that the mapping (ECRF) and validation (LVF) functions be separable, so that an entity responsible for a LoST server cluster can decide to provide mapping and validation services using consolidated or separate server clusters (i.e., using the same or separate boxes). The rationale is that the mapping service is used in real-time during emergency call routing, while the validation service is used in advance, typically when data is provisioned, and therefore the mapping service has much higher availability and response time requirements than the validation service. An organization might choose to deploy these services using different server clusters to make it easier to provide higher levels of service for the mapping function while shielding it from the potentially bursty load of validation, while another organization might choose to use the same sets of servers for both, configured and deployed to offer the high service level demanded of the mapping service. In order to permit this separability, any entity querying a LoST server needs to be able to resolve an Application Unique String (AUS) into a URL for a server that offers the required service (mapping or Gellens & Rosen Expires July 20, 2020 [Page 2] Internet-Draft LoST-Validation January 2020 validation). This separability needs to be maintained throughout the LoST tree structure, from forest guide to leaf node. Because LoST referrals return an AUS rather than a URL, different Service Tags are needed for the different services. This document adds 'LoST- Validation' to the S-NAPTR Application Service Tag registry created by [RFC3958]. The 'LoST-Validation' tag serves as a counter-part to the 'LoST' tag added by [RFC4848]: The 'LoST' tag identifies servers able to perform the core mapping function, while 'LoST-Validation' identifies servers explicitly willing to perform the validation function. A server identified using the 'LoST' service tag might also perform the validation function (and might resolve to the same URL as a server identified using the 'LoST-Validation' service tag), but the 'LoST-Validation' tag makes this explicit. 3. The LoST-Validation Application Service Tag LoST [RFC4848] specifies that LoST servers are located by resolving an application Unique String (AUS) using U-NAPTR/DDDS (URI-Enabled NAPTR/Dynamic Delegation Discovery Service) [RFC4848], and defined the 'LoST' Application Service Tag. In order to permit separability of the mapping and validation services performed using LoST, this document defines the 'LoST-Validation' Service Tag. NAPTR records for LoST servers available for location validation contain the 'LoST- Validation' Service Tag. An entity needing to perform location validation using LoST performs the discovery procedure as described in [RFC4848], except that the 'LoST-Validation' Service Tag is used in preference to the 'LoST' Service Tag. For both Service Tags, the HTTP and HTTPS URL schemes are used. In the absense of any NAPTR records containing the 'LoST-Validation' Service Tag, the 'LoST' Service Tag is used. Using the 'LoST-Validation' Service Tag might result in the same URL as the 'LoST' Service Tag, or it may result in a different URL. The URLs might result in the same physical servers being contacted, or different servers. 4. Security Considerations The security considerations described in [RFC3958] and [RFC4848] apply here. ... 5. IANA Considerations IANA is requested to add 'LoST-Validation' to the S-NAPTR Application Service Tag registry created by [RFC3958] This tag serves as a counter-part to the 'LoST' tag added by [RFC4848]. Gellens & Rosen Expires July 20, 2020 [Page 3] Internet-Draft LoST-Validation January 2020 5.1. U-NAPTR Registration This document registers the following U-NAPTR application service tag: Application Service Tag: LoST Defining Publication: This document. 6. Contributors 7. Acknowledgements 8. Changes from Previous Versions This is the initial version 9. References 9.1. Normative References [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, January 2005, . [RFC4848] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, DOI 10.17487/RFC4848, April 2007, . [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, . 9.2. Informative references [NENA-i3] National Emergency Number Association (NENA) Interconnection and Security Committee, i3 Architecture Working Group, , "Detailed Functional and Interface Standards for the NENA i3 Solution", 2016, . Gellens & Rosen Expires July 20, 2020 [Page 4] Internet-Draft LoST-Validation January 2020 Authors' Addresses Randall Gellens Core Technology Consulting Email: rg+ietf@coretechnologyconsulting.com URI: http://www.coretechnologyconsulting.com Brian Rosen 470 Conrad Dr Mars, PA 16046 US Email: br@brianrosen.net Gellens & Rosen Expires July 20, 2020 [Page 5]