The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag
RFC 8917

Document Type RFC - Proposed Standard (October 2020; No errata)
Updates RFC 5222
Authors Randall Gellens  , Brian Rosen 
Last updated 2020-10-22
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Reviews
Stream WG state (None)
Document shepherd Ben Campbell
Shepherd write-up Show (last changed 2020-02-25)
IESG IESG state RFC 8917 (Proposed Standard)
Consensus Boilerplate Yes
Telechat date
Responsible AD Barry Leiba
Send notices to Ben Campbell <ben@nostrum.com>
IANA IANA review state IANA OK - Actions Needed
IANA action state RFC-Ed-Ack
IANA expert review state Expert Reviews OK


Internet Engineering Task Force (IETF)                        R. Gellens
Request for Comments: 8917                    Core Technology Consulting
Updates: 5222                                                   B. Rosen
Category: Standards Track                                   October 2020
ISSN: 2070-1721

 The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR)
                        Application Service Tag

Abstract

   This document adds the 'LoST-Validation' service tag to the
   Straightforward-Naming Authority PoinTeR (S-NAPTR) Application
   Service Tag IANA registry.  This tag can appear in a Naming Authority
   Pointer (NAPTR) Domain Name System (DNS) record to assist clients of
   the Location-to-Service Translation (LoST) Protocol in identifying
   LoST servers designated for location validation.  This tag and the
   information about its use update RFC 5222, which enables the explicit
   discovery of a server that supports location validation.

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
   https://www.rfc-editor.org/info/rfc8917.

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
   (https://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.

Table of Contents

   1.  Document Scope
   2.  Introduction
     2.1.  Requirements Language
   3.  The LoST-Validation Application Service Tag
   4.  Backwards Compatibility
   5.  Security Considerations
   6.  IANA Considerations
     6.1.  S-NAPTR Registration
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Acknowledgements
   Authors' Addresses

1.  Document Scope

   This document adds 'LoST-Validation' to the S-NAPTR Application
   Service Tag IANA registry and describes how this tag fits in the LoST
   server discovery procedure described in [RFC5222].  This tag is used
   with Naming Authority Pointer (NAPTR) Domain Name System (DNS)
   records so that clients of the Location-to-Service Translation (LoST)
   Protocol [RFC5222] can identify servers designated for location
   validation.  This tag and the information on its use is an update to
   [RFC5222] that enables the explicit discovery of a server that
   supports location validation.

2.  Introduction

   The LoST Protocol [RFC5222] defines a mapping service with the
   additional ability for a client to request that a civic address be
   validated.  The LoST protocol allows servers to ignore a request to
   perform location validation.  The National Emergency Number
   Association (NENA) has defined an architecture for all-IP emergency
   services (known as "i3" [NENA-i3]), which defines the mapping
   (routing) and validation functions as two distinct functional
   elements, defined as an Emergency Call Routing Function (ECRF) and a
   Location Validation Function (LVF).  NENA i3 requires that the
   mapping (ECRF) and validation (LVF) functions be separable; 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; 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.  Another organization
   might choose to use the same sets of servers for both services,
   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)
Show full document text