Subject: [Ecrit] Forward of Off-List Service URN Draft Discussions (1)

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 16 Aug 2006 14:26:19 +0200

-----Ursprüngliche Nachricht-----
Von: Leslie Daigle [mailto:[email-masked]] 
Gesendet: Samstag, 22. Juli 2006 01:16
An: 'Henning Schulzrinne'
Cc: Marc Linsner; Tschofenig, Hannes; 'James M. Polk'; [email-masked]
Betreff: Re: Moving forward with the Service URN Draft

Some comments, as promised, below.  I just hit "reply" to this thread,
without particular regard to adding the authors of the LoST document;
feel free to forward this as useful.

One point of clarification -- many registered URN services in fact
say "there is no resolution service".  However, if one is *intended*,
it would indeed be best to have it referenced normatively and have
the document wait on any other required documents (here, apparently,
LoST).

Except.

It's not at all clear to me that LoST is the resolution service for
service URNs; rather, it seems service URNs are used as data elements
in the LoST specification, and maybe they are useful in doing service
discovery for LoST servers.  Neither of those is URN resolution.  So,
maybe "no resolution service available" is the right answer in this
URN nid registration.

Comments on draft-ietf-ecrit-service-urn-03.txt:

>    Process for identifier resolution: 'service' identifiers are resolved
>       by the mapping protocols, an instance of a Resolution Discovery
>       System (RDS) as described in RFC 2276 [3].  Each top-level service
>       can provide its own distinct set of mapping protocols.  Within
>       each top-level service, all mapping protocols MUST return the same
>       set of mappings.  Section 4 describes how the S-NAPTR mechanism is
>       used to find an instance of a mapping service.

See comments above -- I think this becomes something like "there is no
global resolution process for service URNs; they are used by other
protocols to identify services and acquire relevant local information."

>   Validation mechanism: Validation determines whether a given string is
>       currently a validly-assigned URN [15].  The S-NAPTR mechanism also
>       allows to determine if a mapping protocol for a particular top-
>       level service exists.  The mapping protocol itself would then
>       answer the question whether the service identifier exists.  (The
[header snipped]
>       issue of whether a particular combination of service and location
>       yields a usable answer is beyond the scope of this specification.)

I suggest there is no validation mechanism, and this section should
say that (plenty of URN namespaces do).  As I understand it,
LoST will yield a highly localized result -- something may provide
a result in one context, but not another (e.g., if there is no
911 service?).  It's not right, then, to say that the 911 service
URN is invalid.  This is not a validating function.

> 4.  Finding the Mapping Server
> 
>    When a network entity receives a service URN, it uses the S-NAPTR [6]
>    mechanism to determine how to map the service URN, possibly using
>    other information such as geographic location, to a routable URI.
>    Each top-level service may define one or more such mapping protocols
>    and mapping protocol servers may be operated by a range of providers.
>    Thus, the network entity that needs to resolve the service URN
>    queries an appropriate domain, typically its home or service provider
>    domain, for NAPTR records and then selects records that match the
>    service and the mapping protocols it supports.  The application
>    service for this URN is registered in IANA Considerations (Section 5)
>    of this document; the application protocols are registered in the
>    appropriate protocol document.
[snip to end of Section 4]

I will comment on this separately -- because it needs some attention
in order to fly as an S-NAPTR application, and it isn't clear to me
whether this is going in draft-ietf-ecrit-lost or some other document
altogether (as it seems to be geared towards LoST server location,
not the general spectrum of LoST itself).

> 5.1  New Service-Identifying Labels
> 
>    New service-identifying labels and sub-services are to be managed by
>    IANA, according to the processes outlined in [4].  The policy for
>    top-level service names is 'IETF Consensus'.  The policy for
>    assigning labels to sub-services may differ for each top-level
>    service designation and MUST be defined by the document describing
>    the top-level service.

This needs more explicit instructions for IANA.  [4] is the generic
"how you can build IANA registries" document.

If this is supposed to be adding labels to an existing registry,
that must be made clear:  which registry (e.g., the S-NAPTR
application service registry, perhaps?).

If this is supposed to be creating a new registry of services and
sub-services, it should say so, and be more explicit about whether
registrations are FCFS, or under what circumstances they are
reviewed (so that IANA can know, objectively, that they are ready
for assignment) etc.

IANA *will* prod for clarification at approval time, of course,
but getting some of that clarified now would help the rest of
us hapless readers ;-)

> 
>    To allow use within the constraints of S-NAPTR [6], all top-level
>    service names MUST NOT exceed 27 characters.

This comment probably still stands, even though the document
does not explicitly define an S-NAPTR usage.

> 5.2  S-NAPTR Application Service Tag

[snip]

I assume this section belongs with the discussion of LoST
discovery with S-NAPTR, and will comment on it there.

> 5.3  Sub-Services for the 'sos' Service
> 
>    The 'sos' service type describes emergency services requiring an
>    immediate response, typically offered by various branches of the
>    government or other public institutions.  Additional sub-services can
>    be added after expert review and should be of general public interest
>    and have a similar emergency nature.  The expert review should take
>    into account whether these emergency services are offered widely and
>    in different countries, with approximately the same caller
>    expectation in terms of services rendered.  The 'sos' service is not
>    meant to invoke general government, public information or social
>    services.

So -- I *think* this is a first service registration in the
IANA registry -- so it should declare that expliclty.

But, it also implies "expert review" -- so the earlier section must
make clearer how that expert review is to occur.   Also, it
must be made clear what the expert reviewer, or IANA, is expected
to do if the services are (or are not) widely offered -- what
does "take into account" mean?  Does it mean "refuse the registration
if they are not"?  In my experience, that's been hard to enforce;
people will push back and ultimately clear definitions of "what is
enough" are needed.  But, perhaps I've misunderstood, and this simply
needs clarification so that others do not share my misunderstanding
upon reading this.

>    urn:service:sos The generic 'sos' service reaches a public safety
>       answering point (PSAP) which in turn dispatches aid appropriate to
>       the emergency.  It encompasses all of the services listed below.
>    urn:service:sos.ambulance This service identifier reaches an
>       ambulance service that provides emergency medical assistance and
>       transportation.
[etc]

I think these are meant to be sub-service registrations?  If so, it
would be helpful to explicitly say so, so that they can be input into
whatever expert review process is applicable, etc.

Comments on LoST, S-NAPTR, and the service URN:

Okay, so it seems like LoST wants to use the service URN for 2 things:
as a data element, and as one mechanism for LoST server discovery.
Currently, the LoST document references the service URN document for
the S-NAPTR discovery mechanism, and that should change -- it should
take this material directly, or another document seems to be needed.

To use S-NAPTR, there are some basic registration and structural
requirements (as defined, probably not as coherently as one might
wish, in RFC3958 -- see the IANA Considerations of that document).

So -- what is the application service that is to be registered?
I infer it's meant to be SURN.<service>, but that needs to be
spelled out -- and perhaps changed to LOST.<service> if you like
as this is more about LoST than SURN in general.

And then, the $64k question -- *what* is the FQDN that is to
be queried for the NAPTR records?

I couldn't quite figure that out between the service URN and
LoST documents.  Is it "hostname"?  Or...?  It seems like
the basic purpose is to say "given I'm *here*, for some
value of *here*, where is my LoST service in protocol
A, B or C".  So, what is *here* expressed in a relevant FQDN?
That really needs to be made clear in defining the use of S-NAPTR.

Leslie.

Marc Linsner wrote:
> Hannes,
>  
> Henning and I discussed the draft and it appears we have two ways 
> forward.  When creating a new URN you must define how to resolve it.  So 
> in this draft, we either must discuss resolution of the URN or use 
> normative references to documents that solve this resolution.  The easy 
> way out is to use the normative references, which in this case would 
> point to the LoST draft(s).  Since the URN draft is way ahead of LoST, 
> this would cause the URN to sit in the RFC editors queue until LoST 
> arrived.  IMO, this is the best path forward, get it thru IESG and into 
> the RFC editor queue.
>  
> I believe if we remove the words/section(s) on resolution and LoST 
> server discovery, it will solve James Polk/Leslie Daigle's objections.
>  
> I queried Jon Peterson as to his opinion on which direction to take.
>  
> -Marc-
> 
>     ------------------------------------------------------------------------
>     *From:* Tschofenig, Hannes [mailto:[email-masked]]
>     *Sent:* Tuesday, July 18, 2006 6:15 AM
>     *To:* James M. Polk; Henning Schulzrinne; Marc Linsner
>     *Subject:* Moving forward with the Service URN Draft
> 
>     Hi all,
> 
>     James raised some concerns about the Service URN draft at the last
>     IETF meeting. I haven't yet seen a conclusion of the discussions.
> 
>     Since I would like to forward this document to Jon I wonder what the
>     next steps are.
> 
>     Ciao
>     Hannes
> 

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit