Subject: [art] Registering the 'LoST-Validation' NAPTR Service Tag

From: "Randall Gellens" <[email-masked]>
Date: Sat, 18 Jan 2020 12:05:28 -0800

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 setup, 
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 service is available and can't resolve an Application 
Unique String into a URI for a LoST server that assuredly is willing to 
perform location validation. We therefore propose to define 
"LoST-Validation" as a service tag. This will allow an entity to locate 
a LoST server willing to perform 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 willing to do 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-00.txt

Comments, feedback, etc. are appreciated.

--Randall

---

From: Ted Hardie <[email-masked]>
Date: Tue, 21 Jan 2020 09:29:44 -0800

Hi Randy, Brian,

Thanks for the message.  I took a quick look at the document, and there are
two things that might want consideration.  The first is this text, which
tells you that the bursty validation traffic and the real-time functions
may be performed by the same server:

   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.

The "tag makes this explicit." doesn't seem to quite cover what you
want to say here.  Maybe:

Because some services are configured to provide
both real-time and validation functions, a server identified
using the 'LoST' service tag may also perform the validation function.
The 'Lost-Validation' service tag should, however, always be used
first when seeking
the validation service, as the two functions may be separate.
Fallback to the 'LoST'

may follow if the Lost-Validation service does not resolve.

Alternatively, you might cut this text and rely on the text in section 3.

Second, the document's IANA considerations says this:

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

5.1.  U-NAPTR Registration

   This document registers the following U-NAPTR application service
   tag:

      Application Service Tag: LoST

      Defining Publication: This document.

Should this be S-NAPTR and LoST-Validation, respectively, or am I missing
something?

regards,

Ted

On Sat, Jan 18, 2020 at 12:05 PM Randall Gellens <[email-masked]>
wrote:

> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art
>

---

From: "Randall Gellens" <[email-masked]>
Date: Tue, 21 Jan 2020 17:30:33 -0800

> Alternatively, you might cut this text and rely on the text in section 

I see the issue and I like your first suggested rewording, I think that 
makes it more clear.  Thank you.

> Should this be S-NAPTR and LoST-Validation, respectively, or am I 

The tag name is definitely a typo, thank you very much for catching it.  
The registry name I'm not sure about.  The reason for the mismatch is 
that IANA calls the registry "S-NAPTR Application Service Tags" while 
RFC 5222 calls it "U-NAPTR application service tag" and RFC 3958 calls 
it "S-NAPTR Application Service Tags".  So, honestly, I don't know what 
to call it.  I've changed the draft to consistently use "S-NAPTR" since 
that's what IANA calls it.

The updated draft is at 
https://www.ietf.org/internet-drafts/draft-gellens-lost-validation-01.txt

(For some reason, the submit tool won't let me submit the .xml file, it 
insists the name is invalid.)

--Randall

--Randall