The LoST-Validation S-NAPTR Application Service Tag
draft-gellens-lost-validation-03

Document Type Active Internet-Draft (individual in art area)
Last updated 2020-02-07 (latest revision 2020-01-30)
Stream IETF
Intended RFC status Informational
Formats plain text xml pdf htmlized bibtex
Stream WG state (None)
Document shepherd Ben Campbell
IESG IESG state AD Evaluation::Point Raised - writeup needed
Consensus Boilerplate Unknown
Telechat date
Responsible AD Barry Leiba
Send notices to Ben Campbell <ben@nostrum.com>
Network Working Group                                         R. Gellens
Internet-Draft                                Core Technology Consulting
Intended status: Informational                                  B. Rosen
Expires: August 2, 2020                                 January 30, 2020

          The LoST-Validation S-NAPTR Application Service Tag
                    draft-gellens-lost-validation-03

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 August 2, 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 August 2, 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 . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  S-NAPTR Registration  . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   7.  Changes from Previous Versions  . . . . . . . . . . . . . . .   4
     7.1.  Changes from -00 to -01 . . . . . . . . . . . . . . . . .   4
     7.2.  Changes from -01 to -02 . . . . . . . . . . . . . . . . .   5
     7.3.  Changes from -02 to -03 . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative references  . . . . . . . . . . . . . . . . .   5
   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.

Gellens & Rosen          Expires August 2, 2020                 [Page 2]
Internet-Draft               LoST-Validation                January 2020

   In order to permit this separability, any entity querying a LoST
Show full document text