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

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

Version -02 of the draft was uploaded today.  (Version -01 that 
addressed Ted's comments and some glitches I noticed was published on 
the 21st.)  This is a very short draft that registers a new NAPTR 
service tag.  I appreciate any reviews.

https://www.ietf.org/internet-drafts/draft-gellens-lost-validation-02.txt

Thanks!

On 21 Jan 2020, at 17:30, Randall Gellens wrote:

> 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