Subject: [Ecrit] Fwd: I-D Action: draft-rosen-ecrit-service-urn-subregistries-00.txt

From: Brian Rosen <[email-masked]>
Date: Fri, 16 Dec 2016 15:32:44 -0500

FYI

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: I-D Action: draft-rosen-ecrit-service-urn-subregistries-00.txt
> Date: December 16, 2016 at 3:31:51 PM EST
> To: <[email-masked]>
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : A Subregistry for urn:service:sos.police, fire and ambulance
>        Author          : Brian Rosen
> 	Filename        : draft-rosen-ecrit-service-urn-subregistries-00.txt
> 	Pages           : 5
> 	Date            : 2016-12-16
> 
> Abstract:
>   In most countries, there are multiple kinds of police forces.
>   RFC5031 defines a "Service URN" which is used to route emergency
>   calls.  The urn has a sub registry for different kinds of emergency
>   services that may be reached from different telephone numbers or
>   service numbers (as opposed to a single number like 112).  In many
>   countries, the "police" service is not a single service, but more
>   than one service where the service area and/or types of emergencies
>   they respond to are different.  In some countries there are multiple
>   ambulance services.  This document defines sub registries for
>   urn:service:sos.police, urn:service:sos.ambulance and, for
>   completeness, urn:service:sos.fire.  It also provides an initial set
>   of entries for these sub registries.  These services are in addition
>   to the base urn:service:sos.police, etc. services.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-rosen-ecrit-service-urn-subregistries/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-rosen-ecrit-service-urn-subregistries-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Ted Hardie <[email-masked]>
Date: Fri, 16 Dec 2016 14:36:06 -0800

Howdy,

No objection to this, but this read oddly:

 This document extends the urn:service:sos.police to allow the type of
   police force.  The type of force is a token separated from
   urn:service.sos.police by a period.

Perhaps instead of "type of force" you could say "The type of
law enforcement agency is a token..."?

Also, it might be slightly better to say "allow the system to
distinguish the type"
.

Ted

On Fri, Dec 16, 2016 at 12:32 PM, Brian Rosen <[email-masked]> wrote:

> FYI
>
> Begin forwarded message:
>
> *From: [email-masked]
> *Subject: **I-D Action:
> draft-rosen-ecrit-service-urn-subregistries-00.txt*
> *Date: *December 16, 2016 at 3:31:51 PM EST
> *To: *<[email-masked]>
> *Reply-To: [email-masked]
>
>
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>
>

---

From: Brian Rosen <[email-masked]>
Date: Sat, 17 Dec 2016 11:58:50 -0500

I see your point.  I’ll make these edits.

Brian

> On Dec 16, 2016, at 5:36 PM, Ted Hardie <[email-masked]> wrote:
> 
> Howdy,
> 
> Also, it might be slightly better to say "allow the system to distinguish the type"
> .
> 
> Ted
> 
> On Fri, Dec 16, 2016 at 12:32 PM, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
> FYI
> 
>> Begin forwarded message:
>> 
>> From: [email-masked] <mailto:[email-masked]>
>> To: <[email-masked] <mailto:[email-masked]>>
>> Reply-To: [email-masked] <mailto:[email-masked]>
>> 
>> 
>> https://datatracker.ietf.org/doc/draft-rosen-ecrit-service-urn-subregistries/ <https://datatracker.ietf.org/doc/draft-rosen-ecrit-service-urn-subregistries/>
>> 
>> https://tools.ietf.org/html/draft-rosen-ecrit-service-urn-subregistries-00 <https://tools.ietf.org/html/draft-rosen-ecrit-service-urn-subregistries-00>
>> 
>> 
>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> 
>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce>
>> Internet-Draft directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>
> 
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 20 Dec 2016 13:58:39 +0000

Hello,

Two comments to the draft:

Comment-1:
rfc5031 defines sub-services using the following ABNF where several sub-services can be included in a service URN.

     service-URN  = "URN:service:" service
    service      = top-level *("." sub-service)
     top-level    = let-dig [ *25let-dig-hyp let-dig ]
     sub-service  = let-dig [ *let-dig-hyp let-dig ]
     let-dig-hyp  = let-dig / "-"
     let-dig      = ALPHA / DIGIT
     ALPHA        = %x41-5A / %x61-7A   ; A-Z / a-z
     DIGIT        = %x30-39 ; 0-9

rfc7163 allows registration of additional sub-services of the service URN with the 'sos' service type using expert review.

Thus, registration of sub-services under urn:service.sos.police (under urn:service.sos.ambulance, and under urn:service.sos.fire) is possible already now and there should be no need to define new subregistries.

Comment-2:

The proposed new police emergency services do not address the needs of the Czech republic as:
- Czech republic defines emergency service of national police; and
- Czech republic is not a federation of states or provinces (and thus "federal" does not fit).
Proposal: change "federal" to "national".

Kind regards

Ivo Sedlacek

From: Ecrit [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Friday, December 16, 2016 9:33 PM
To: ECRIT <[email-masked]>
Subject: [Ecrit] Fwd: I-D Action: draft-rosen-ecrit-service-urn-subregistries-00.txt

FYI

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-rosen-ecrit-service-urn-subregistries-00.txt
Date: December 16, 2016 at 3:31:51 PM EST
To: <[email-masked]<mailto:[email-masked]>>
Reply-To: [email-masked]<mailto:[email-masked]>

Abstract:

[email-masked]<mailto:[email-masked]>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 20 Dec 2016 10:04:28 -0500

Thanks for your comments.

Although the ABNF allows it, I think that it’s much cleaner to have the separate registries.  I will note that we have allowed the registration in the existing registry, although if/when this document is published, we will remove it from the main sos registry and put it in the police sub registry.  I have consulted with IANA on this.

I was careful to note that the token is NOT the name of the service, and trying to actually have the token be the actual name of the service will lead to many, many registrations that are effectively duplicates of one another.  Any police force which has true national scope would use the same token.  In the US, for example, it’s the FBI.

However, I do think “national” is actually a better token for this service, and I will change it in the next version.  However, I would not want to see a registration for the FBI, nor any other specific name for a national police force.  Having said that, in many countries, there are several national police forces with specialized responsibilities.  In the U.S., we have U.S. Marshalls, Drug Enforcement Agency, Immigration and Customs. Secret Service, and several others.  We don’t have emergency calling to them, so we don’t need sos tokens for them, but there are countries where there are more than one national police that do have emergency numbers and we will need tokens for them.  I would not want a “city” token instead of “municipal”.

At one point I was thinking of explicitly referencing the “A” levels from PIDF-LO for these tokens (so “A1” instead of “Provincial” and A2 instead of “Municipal”), but eventually decided that since we didn’t have A levels for all the tokens we would need that it didn’t make sense to use the A levels as the token name.  But I intended the tokens to be used that way.

Brian

> On Dec 20, 2016, at 8:58 AM, Ivo Sedlacek <[email-masked]> wrote:
> 
> Hello,
>  
> From: Ecrit [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Brian Rosen
> To: ECRIT <[email-masked] <mailto:[email-masked]>>

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 20 Dec 2016 15:19:29 +0000

Hello,

> Although the ABNF allows it, I think that it’s much cleaner to have the separate registries.  I will note that we have allowed the registration in
> the existing registry, although if/when this document is published, we will remove it from the main sos registry and put it in the police sub registry.

How would it work for other services?

Imagine that a person X registers

                urn:service.sos.foo

and later on a person Y would like to register:

                urn:service.sos.foo.subfoo1
                               and
                urn:service.sos.foo.subfoo2

What would the IANA registration policy for request to establish sub-registry of urn:service.sos.foo?
And what would the IANA registration policy be for new entries in the urn:service.sos.foo subregistry?

> However, I do think “national” is actually a better token for this service, and I will change it in the next version.

Thanks.

Kind regards

Ivo

From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, December 20, 2016 4:04 PM
To: Ivo Sedlacek <[email-masked]>
Cc: ECRIT <[email-masked]>
Subject: Re: [Ecrit] I-D Action: draft-rosen-ecrit-service-urn-subregistries-00.txt

Brian

On Dec 20, 2016, at 8:58 AM, Ivo Sedlacek <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

Comment-1:

Comment-2:

Kind regards

Ivo Sedlacek

From: Ecrit [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Friday, December 16, 2016 9:33 PM
To: ECRIT <[email-masked]<mailto:[email-masked]>>
Subject: [Ecrit] Fwd: I-D Action: draft-rosen-ecrit-service-urn-subregistries-00.txt

FYI

Begin forwarded message:

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

---

From: Brian Rosen <[email-masked]>
Date: Tue, 20 Dec 2016 11:43:09 -0500

I think it’s an issue of whether we expect a number of registrations of subfoos.  If there is only 1 maybe not bother, but if we expect several, create the sub registry.  The expert can help guide.

You need a document with IANA considerations to create a registry, but an INFO will do.

The policy for the sub registry would be specified in that document.  I specified expert review in these 3. 

Brian

> On Dec 20, 2016, at 10:19 AM, Ivo Sedlacek <[email-masked]> wrote:
> 
> Hello,
>  
> From: Brian Rosen [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Ivo Sedlacek <[email-masked] <mailto:[email-masked]>>
> Cc: ECRIT <[email-masked] <mailto:[email-masked]>>
> On Dec 20, 2016, at 8:58 AM, Ivo Sedlacek <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hello,
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 21 Dec 2016 06:50:32 +0000

> You need a document with IANA considerations to create a registry, but an INFO will do.

Do you mean an RFC?

That makes getting emergency URN a lot toughter than today and pretty much prevents easy and quick deployment of new emergency services, which are subservices of an existing emergency service.

Kind regards

Ivo

Sent: Tuesday, December 20, 2016 5:43 PM

Brian

On Dec 20, 2016, at 10:19 AM, Ivo Sedlacek <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

                urn:service.sos.foo

Thanks.

Kind regards

Ivo

From: Brian Rosen [mailto:[email-masked]]
Sent: Tuesday, December 20, 2016 4:04 PM
To: Ivo Sedlacek <[email-masked]<mailto:[email-masked]>>
Cc: ECRIT <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ecrit] I-D Action: draft-rosen-ecrit-service-urn-subregistries-00.txt

Brian

Hello,

Comment-1:

Comment-2:

Kind regards

Ivo Sedlacek

FYI

Begin forwarded message:

Abstract:

---

From: Brian Rosen <[email-masked]>
Date: Wed, 21 Dec 2016 09:50:12 -0500

There shouldn’t be any hurry to get a URN defined.  Deployments typically take years of planning, acquiring new systems, training, etc.
If there is a time crunch, the expert can authorize a temporary registration as we did with police.national until the sub registry document is published.

Most services won’t need this two level registration.

Brian

> On Dec 21, 2016, at 1:50 AM, Ivo Sedlacek <[email-masked]> wrote:
> 
> On Dec 20, 2016, at 10:19 AM, Ivo Sedlacek <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hello,
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 22 Dec 2016 13:57:29 +0000

Hello,

> There shouldn’t be any hurry to get a URN defined.  Deployments typically take years of planning, acquiring new systems, training, etc.

If you meant solely establishment of a *completely new* emergency service, then you might be right.

If you (also) meant that there was no hurry for obtaining emergency URNs for any emergency services *already available via public switched telephony network*, then I disagree.

Reasons:
- according to RFC 5031, emergency services are identified by emergency URNs (i.e. an URN with 'sos' service type)
- an operator of a 3GPP specified SIP based network offering voice services needs to be able to identify any emergency service specified in the country of its SIP based network, since:
                - normally, the user agent sets the Request-URI of the initial INVITE request to a emergency URN identifying the requested emergency service and this emergency URN is input to routing decisions in the SIP based network.
                - in some cases, the user agent can set the Request-URI of the initial INVITE request to a TEL URI with an emergency number. In such case, the edge of the SIP based network changes the Request-URI to an emergency URN appropriate for the particular emergency number in the TEL URI and, again, this emergency URN is input to routing decisions in the SIP based network.
                - any emergency service which a user can reach via a public switched telephony network in a country has to be reachable via SIP based network in the same country too.

Today, some operators do not offer emergency services via 3GPP specified SIP based network and steer UEs to use 3GPP specified circuit switched network, but that only works as long as the 3GPP specified circuit switched network is available, This will be less-and-less frequent as there is a trend of reusing radio resources of 3GPP specified circuit switched network for 3GPP specified SIP based network.

Therefore, an operator rolling out voice service using 3GPP specified SIP based network needs to have emergency URNs for any emergency service *already available via public switched telephony network*, at the time of the full scale rollout.

So, emergency URNs for any emergency services *already available via public switched telephony network* are needed *urgently*.

> If there is a time crunch, the expert can authorize a temporary registration as we did with police.national until the sub registry document is published.

Firstly, is the process of the "temporary" IANA registration described anywhere? It does not seem to be mentioned in RFC 5031, RFC 7163 or the draft.

Secondly, I can see that IANA now maintains the "urn:service:sos.police.municipal" URN and "urn:service:sos.police.federal" URN at http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels.xhtml

The "urn:service:sos.police.municipal" URN is OK, thanks.

The "urn:service:sos.police.federal" URN is strange -  I asked for "urn:service:sos.police.national", we discussed it below and you seemed to agree that "urn:service:sos.police.national" is more appropriate than "sos.police.federal", but IANA still has "urn:service:sos.police.federal" URN.

Can "urn:service:sos.police.federal" be changed to "urn:service:sos.police.national" in IANA? Thanks.

Kind regards

Ivo Sedlacek

Sent: Wednesday, December 21, 2016 3:50 PM

Brian

Do you mean an RFC?

Kind regards

Ivo

Brian

Hello,

                urn:service.sos.foo

Thanks.

Kind regards

Ivo

Brian

Hello,

Comment-1:

Comment-2:

Kind regards

Ivo Sedlacek

FYI

Begin forwarded message:

Abstract:

---

From: Brian Rosen <[email-masked]>
Date: Thu, 22 Dec 2016 11:58:28 -0500

At least in my experience, the changes in the network take a lot of time to plan and implement.

The expert merely authorizes an entry in the sos registry for a service with a period in it.  When the document creating a sub-registry is published, that entry is removed from the sos registry, and included in the sub registry.  The net effect is no change, the service is exactly the same.

I asked IANA to change “federal” to “national”, but it hasn’t happened yet.  Please remember that the actual token value isn’t anything important.  It has to be consistently used to make cross-border calling work, but the actual content of the token could be “foo” and work as well as “national” or “federal”.  It’s not user visible and it’s not used in any other context other than the service sent to LoST.

Brian

> On Dec 22, 2016, at 8:57 AM, Ivo Sedlacek <[email-masked]> wrote:
> 
> Hello,
>  
> Secondly, I can see that IANA now maintains the "urn:service:sos.police.municipal" URN and "urn:service:sos.police.federal" URN athttp://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels.xhtml <http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels.xhtml>
>  
> On Dec 21, 2016, at 1:50 AM, Ivo Sedlacek <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Fri, 23 Dec 2016 09:15:47 +0000

Hello,

> At least in my experience, the changes in the network take a lot of time to plan and implement.

When all required emergency URNs are specified, then providing emergency services in a 3GPP specified SIP network requires solely enhancements of the operator's network as:
- any SIP user agent in a 3GPP mobile phone supporting non-emergency voice service over a 3GPP specified SIP network is already required to support also the emergency voice service over the 3GPP specified SIP network; and
- PSAPs do not need to be changed - if a PSAP is connected to public switched telephony network (PSTN) only, then a node in the operator's SIP network interworks the emergency SIP call to an PSTN call towards PSAP.

So, when all required emergency URNs are specified, including an emergency URN for any emergency service *already available via public switched telephony network* in the country of the SIP based network, then it is just matter of decision of the operator.

And the operator needs to make that decision at a moment when, in *a location*, a 3GPP specified SIP based network is available while 3GPP specified circuit switched networks is not available. That can happen soon.

So, stating it in a different way, if a country defines an emergency service *already available via public switched telephony network* for which an emergency URN is not specified, then the operator is forced to keep 3GPP specified circuit switched network in any location where 3GPP specified SIP based network is available (and that's costly and inefficient use of precious radio resources).

That's why getting emergency URNs for any any emergency service *already available via public switched telephony network* needs to be reasonably quick.

> The expert merely authorizes an entry in the sos registry for a service with a period in it.  When the document creating a sub-registry is published,
> that entry is removed from the sos registry, and included in the sub registry.  The net effect is no change, the service is exactly the same.

Let me try to reformulate the above to check if I understood correctly. To me, the above suggests:
- the sub-registries are solely a way of organizing and showing the emergency URNs at IANA pages.
- the sub-registries do not state any restrictions on registration of new emergency URNs (and do not make it any easier either). I.e. rfc7163 applies no matter whether IANA keeps a sub-registry or not.

If that's correct understanding and assuming the draft explicitly state so, I would be OK with it.

If it is incorrect understanding, can you please explain?

> I asked IANA to change “federal” to “national”, but it hasn’t happened yet.

Thanks.

Kind regards

Ivo

---

From: Brian Rosen <[email-masked]>
Date: Fri, 23 Dec 2016 16:27:51 -0500

You’re understanding is correct, although in theory, the sub registry could have a different management policy than the sos registry.  For sos.police, sos.fire, and sos.ambulance, the policy is expert review, the same as sos.

Brian

> On Dec 23, 2016, at 4:15 AM, Ivo Sedlacek <[email-masked]> wrote:
> 
> Hello,
>