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

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

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