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

[Ted Hardie <[e-mail]>]

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


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
>