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

From: "Randall Gellens" <[email-masked]>
Date: Tue, 28 Jan 2020 16:51:22 -0800

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 
>> <[email-masked]>
>> 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

---

From: Ted Hardie <[email-masked]>
Date: Wed, 29 Jan 2020 12:03:04 -0800

I don't see any major issues with this.  As a very minor nit, this text:

   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.

is a bit confusing.  Changing:

   Fallback to the 'LoST' service tag may follow
   if the 'Lost-Validation' service tag fails to result in a usable LoST
   server.

to something like:  "Clients MAY also fallback to the "LoST" service tag
if the "LoST-validation" service tag fails to resolve to a usable LoST server"

Would be slightly more readable to me.

regards,

Ted Hardie

---

From: "Randall Gellens" <[email-masked]>
Date: Thu, 30 Jan 2020 15:44:10 -0800

> Would be slightly more readable to me.

Hi Ted,

Thanks for the comment.  What do you think of this wording:

    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.

--Randall

---

From: Ted Hardie <[email-masked]>
Date: Thu, 30 Jan 2020 16:02:09 -0800

Looks fine to me.

Ted
Mobile/Terse

---

From: "Randall Gellens" <[email-masked]>
Date: Thu, 30 Jan 2020 16:50:01 -0800

>>>>>>> Comments, feedback, etc. are appreciated.

Thanks, Ted.  I'll upload -03 now.

--Randall