Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8917.
Authors Randall Gellens , Brian Rosen
Last updated 2020-01-17
RFC stream (None)
Formats
Reviews
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 8917 (Proposed Standard)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-gellens-lost-validation-00
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, <https://www.rfc-editor.org/info/rfc3958>.

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

   [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>.

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,
              <https://www.nena.org/page/i3_Stage3>.

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]