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
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
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 counterpart 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.
Because some servers might be configured to provide both mapping and
validation functions, a server identified using the 'LoST' service
tag might also perform the validation function (and resolving the two
tags might result in the same URL). Because the two functions might
be separate, clients seeking a LoST server for location validation
should first try U-NAPTR resolution using the 'Lost-Validation'
service tag, and may fallback to the 'LoST' service tag if the 'Lost-
Validation' service tag cannot be resolved to a usable LoST server.
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 defines
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. Fallback to the 'LoST' service tag may follow
if the 'Lost-Validation' service tag fails to result in a usable LoST
server. 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.
Gellens & Rosen Expires August 2, 2020 [Page 3]
Internet-Draft LoST-Validation January 2020
4. Security Considerations
The security considerations described in [RFC3958] and [RFC4848]
apply here. No additional security aspects are foreseen by the
addition of an extra tag. Separation of services might be desired,
for example, to be able to allocate different levels of resources
(such as server capacity, attack mitigation, bandwidth, etc.) to the
mapping and validation services, in which case separate tags are
needed to allow LoST clients (which may include other LoST servers)
to identify the correct server cluster.
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
counterpart to the 'LoST' tag added by [RFC5222].
(Note that IANA and [RFC3958] call this registry "S-NAPTR Application
Service Tags" while [RFC5222] calls it "U-NAPTR application service
tag".)
5.1. S-NAPTR Registration
This document registers an S-NAPTR application service tag:
Application Service Tag: LoST-Validation
Defining Publication: This document.
6. Acknowledgements
Many thanks to Ted Hardie for his helpful review and suggestions.
7. Changes from Previous Versions
7.1. Changes from -00 to -01
o Fixed incorrect tag in Section 5
o Clarified background and explanation in Section 2
o Clarified text in Section 3
o Expanded text in Section 4
Gellens & Rosen Expires August 2, 2020 [Page 4]
Internet-Draft LoST-Validation January 2020
7.2. Changes from -01 to -02
o Fixed bug in .xml file
7.3. Changes from -02 to -03
o Reworded fallback text in Section 2
8. References
8.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>.
8.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>.
Authors' Addresses
Randall Gellens
Core Technology Consulting
US
Email: rg+ietf@coretechnologyconsulting.com
URI: http://www.coretechnologyconsulting.com
Gellens & Rosen Expires August 2, 2020 [Page 5]
Internet-Draft LoST-Validation January 2020
Brian Rosen
470 Conrad Dr
Mars, PA 16046
US
Email: br@brianrosen.net
Gellens & Rosen Expires August 2, 2020 [Page 6]