Subject: [Ecrit] NENA URN namespace registration

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 21 Sep 2010 11:27:11 -0600

Folks, I'm the sponsoring Area Director for an Internet-Draft that
requests registration of a URN namespace identifier for the National
Emergency Number Association (NENA):

https://datatracker.ietf.org/doc/draft-rosen-urn-nena/

I'd appreciate feedback from folks on this list as input to the IESG's
decision process (e.g., feedback regarding the relationship between the
proposed urn:nena:* tree and the urn:service:* tree registered by RFC
5031). I've deferred the ballot on this I-D for two weeks to enable
discussion on this list, so if you have comments please provide them
before October 7.

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 21 Sep 2010 14:07:03 -0400

This namespace is being requested by NENA for a number of things, but one of them is to define additional services for LoST that would only be used in an Emergency Services IP Network (ESInet).  For example, we plan to use a urn like urn:nena:service:police.dispatch to use LoST for a PSAP to determine how to route a call, or the data associated with a call used for dispatch, to the police department serves the location of an incident.  This kind of routing would not be available to anyone outside the ESInet.   Similarly, in our ESInets, we will often have multistage routing.  These routing steps involve an initial route, determined by a LoST query, followed by an evaluation of a policy for the entity whose URI is determined by the query.   

For example, the normal "PSAP URI" that is obtained with urn:service:sos would route to, perhaps, a state/province level ESRP.  That ESRP would query LoST and obtain, perhaps, the URI of a county level ESRP.  That ESRP might query LoST and obtain the actual PSAP URI.  However, suppose the county ESRP was unavailable due to flooding.  The policy for the country ESRP would specify an alternate route for the conditions (which would be an ESRP that was currently able to handle the duty).  Each of the routes obtained by the internal ESRPs would use a different service urn in the urn:nena namespace in their LoST query.   There are pretty compelling reasons to have multilevel route decisions in North America.  

None of this needs any IETF "supervision", since it's strictly limited to use within our (private) IP networks.  We do have to mint service urns for the purpose however.  We will use the IETF service urns exactly as IETF defines them.

NENA will have a registry for this namespace, and subregistries for urn:nena:service.  The NENA Registry Service will have processes similar to IANA processes for managing these name spaces.  The envisioned management policy for urn:nena and urn:nena:service is the NENA equivalent of "standards track RFC needed".  The registry contents will be public, and both text and xml versions of them will be available.

Brian

On Sep 21, 2010, at 1:27 PM, Peter Saint-Andre wrote:

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