[Ecrit] Registering the 'LoST-Validation' NAPTR Service Tag

"Randall Gellens" <rg+ietf@randy.pensive.org> Fri, 21 February 2020 11:57 UTC

Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F4B120813 for <ecrit@ietfa.amsl.com>; Fri, 21 Feb 2020 03:57:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRvf-a3A_e6D for <ecrit@ietfa.amsl.com>; Fri, 21 Feb 2020 03:57:15 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 304A1120800 for <ecrit@ietf.org>; Fri, 21 Feb 2020 03:57:15 -0800 (PST)
Received: from [10.8.1.10] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 21 Feb 2020 03:57:13 -0800
From: Randall Gellens <rg+ietf@randy.pensive.org>
To: ecrit@ietf.org
Date: Fri, 21 Feb 2020 03:57:08 -0800
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <B55A3230-29F5-4335-8259-431DBE4A6205@randy.pensive.org>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; markup="markdown"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/FSsxw6S-bgAxvQFOkA1Wl51KiNM>
Subject: [Ecrit] Registering the 'LoST-Validation' NAPTR Service Tag
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2020 11:57:17 -0000

Working in NENA, we've identified a need to register a new S-NAPTR 
service tag 'LoST-Validation'.

Background: as some may recall, the key motivator for LoST was emergency 
services, primarily the ability to lookup a service URN for a location 
(i.e., map "URN:SERVICE:SOS" to a SIP URI for a PSAP for a specific 
location), and secondarily the ability to validate a civic location 
(i.e., validate that a civic address is unique, dispatchable, and meets 
the requirements for the area). LoST provides the ability to do both. 
NENA i3 (which defines NG9-1-1) makes extensive use of LoST. One thing 
NENA i3 does that was not originally contemplated when LoST was 
developed is to allow separation of the core mapping function of LoST 
from the validation function. NENA i3 allows (but does not require) 
these two services to be provided separately (with the motivation that 
mapping is a time-crucial service done during emergency call routing, 
while validation is performed as data is provisioned into entities and 
is not time-crucial, so a provider might potentially provision and 
operate these two services differently). LoST uses U-NAPTR Application 
Unique Strings rather than URIs to refer to other LoST servers. There is 
currently one U-NAPTR service tag for LoST ("LoST"). In order to be able 
to separate service mapping from location validation, a second service 
tag is needed. Otherwise an entity can't tell from an Application Unique 
String which server should be used for which service, and can't resolve 
an Application Unique String into a URI for a LoST server that should be 
used for location validation. We therefore propose to define 
"LoST-Validation" as a service tag. This will allow an entity to locate 
a LoST server identified as performing civic location validation, 
leaving "LoST" as the service tag for core service mapping.  (Of course, 
a LoST server located using the 'LoST' service tag might offer both 
mapping and validation, but the ability to use 'LoST-Validation' in 
NAPTR records makes explicit which LoST servers are intended for 
validation.)

The Service Tags registry rules that require an RFC to add a tag, so I 
have submitted a small RFC to do this: 
https://www.ietf.org/internet-drafts/draft-gellens-lost-validation-04.txt

Comments, feedback, etc. are appreciated.

--Randall