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

[Ted Hardie <[e-mail]>]

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.

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?

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
>
> _______________________________________________
> art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/art
>