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

["Randall Gellens" <[e-mail]>]

On 21 Jan 2020, at 9:29, Ted Hardie wrote:

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

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


>
> 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?

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

>
> regards,
>
> Ted
>
> On Sat, Jan 18, 2020 at 12:05 PM Randall Gellens 
> <[e-mail]>
> wrote:
>
>> 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
>>
>> _______________________________________________
>> art mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/art
>>




--Randall