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

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

On 30 Jan 2020, at 16:02, Ted Hardie wrote:

> Looks fine to me.
>
> Ted
> Mobile/Terse
>
> On Thu, Jan 30, 2020 at 3:44 PM Randall Gellens <[e-mail]>
> wrote:
>
>> On 29 Jan 2020, at 12:03, Ted Hardie wrote:
>>
>>> 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
>>
>>
>>
>> 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
>>
>>
>>> On Tue, Jan 28, 2020 at 4:51 PM Randall Gellens
>>> <[e-mail]>
>>> wrote:
>>>
>>>> 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
>>>>
>>


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

--Randall