Re: [Ecrit] country specific emergency URNs

Brian Rosen <br@brianrosen.net> Thu, 06 July 2017 21:09 UTC

Return-Path: <br@brianrosen.net>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E236D12EA58 for <ecrit@ietfa.amsl.com>; Thu, 6 Jul 2017 14:09:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Xh7v-_e_UG1 for <ecrit@ietfa.amsl.com>; Thu, 6 Jul 2017 14:09:25 -0700 (PDT)
Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1EAC131553 for <ecrit@ietf.org>; Thu, 6 Jul 2017 14:09:22 -0700 (PDT)
Received: by mail-yb0-x231.google.com with SMTP id p207so4850374yba.2 for <ecrit@ietf.org>; Thu, 06 Jul 2017 14:09:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KQjoXHqeFeLxUy/mOfwNA/Xw4jucc4YtfMgfr+wzNiA=; b=Wpp7p95vj7ik2O+hUysTBL3mIYFG2ZK2xF/iWTS+OGaF+1xPA+JV9JQH8ym9Pwz0R5 dHDyBfJn3c8SNnZyzLrgVpzQej0pS3/qei53cutcTzZE8mbk5YMIW4cD+RHBzEABRBvm mPKAaCpKd3y6NKQOOmVMAW7MHR0ZWXoQk++lIvllIyHxFs2nplqo923MGMQVnRtYU6Wb WZMiPSuqday3oPzNV/4UiXsGeM9NTlxfwSYbZhHtATWRhBsFFJh7zDbvdyojQTLpT7O6 jNjp5JjHFqguRQVOBbAzFLzPzJzfpiUYipi/gUjH8vZPz1zQ4ov9JpzeOsTVOmBWBt6/ Anzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KQjoXHqeFeLxUy/mOfwNA/Xw4jucc4YtfMgfr+wzNiA=; b=FMv0SIkhv3tC6SAdkr40qSMHnzQ+C7kqoal5wYqYzOwxO6Nfm6emhnKpIdPWeDLV1N AyOyTIziheHNAOnArImB/QtNz9e/eVvlQ3WBkCRwLT+SOWTYiguKqJqqpIVhB5BfZ9Xe 0VR6q6XElcfKosUpShEE+zgazluFYg0YCICMDAuvBPe8BDAMSogoN1xkZyJg6ATgKDjO dC2yZzFChuoXJqyz0BJLaaRcJ8sfb7wQ8ZTfvUIYOx1vNoNevq6vfXxTR0oJGGb2qlk/ iaw/FbZp0tLvq12OYho0ykx8H+Nfiu0YirclCesM3aHpUSPVXZLYZqHDA6TZC9F9xwYK si2w==
X-Gm-Message-State: AIVw113fB45TDipsUWNVwe8Ah/72k3kwgpUhpOpKlsuPPZu9Hs38K5y2 L6sukz5CA7gtS5CbijXjfg==
X-Received: by 10.37.16.3 with SMTP id 3mr1672181ybq.60.1499375361932; Thu, 06 Jul 2017 14:09:21 -0700 (PDT)
Received: from [10.96.8.35] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id t140sm578734ywe.6.2017.07.06.14.09.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2017 14:09:21 -0700 (PDT)
From: Brian Rosen <br@brianrosen.net>
Message-Id: <AF1BEB84-A0D2-44AD-9666-1C608B73BC68@brianrosen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9FCA10D0-1740-4144-903E-07EDA76C262D"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 06 Jul 2017 17:09:19 -0400
In-Reply-To: <52809D5B0606C049903AD6AD07E033E10326EF8FFD@ATWIREMXSC0101.sv.ad.tmo>
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
To: "Aleksiev, Vasil" <Vasil.Aleksiev@t-mobile.at>
References: <52809D5B0606C049903AD6AD07E033E10326EF8FFD@ATWIREMXSC0101.sv.ad.tmo>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/qRbksrEKPZvaYQ850P74lD0LscA>
Subject: Re: [Ecrit] country specific emergency URNs
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jul 2017 21:09:29 -0000

There seems to be a fundamental misunderstanding of what the values in the registry are supposed to be used for.

They are meant to be used to identify unique services.  

It’s useful to try to not have a lot of services that really are the same service having different entries, but two services that are indeed different ought to have different entries.


Also, the routing of a service can be whatever is needed; no assumption about routing is made other than the implication that the routing element will have different service URNs for different services.

With that it mind, my suggestions for the cases you cited are inline:


> On Jul 6, 2017, at 7:36 AM, Aleksiev, Vasil <Vasil.Aleksiev@t-mobile.at> wrote:
> 
> Hello,
> 3GPP tried to register “sos.country-specific” sub-service type with IANA and got a comment back that “country-specific” is not an emergency service. There was a discussion on the last IETF meeting on this topic and as outcome 3 ways forward presented to 3GPP CT1 – change the registration process, create an exception in the registration process or use the current process. 
> There were discussions how to go forward with this topic in 3GPP CT1. With the help of some of the delegates list with emergency services was prepared in order to see what exactly problems we might have with registration. You can see the list attached. 
> Looking to the list there are some issues which I believe cannot be solved within the current registration process. I have tried to summarize the comments and the examples that we had during our discussions in 3GPP CT1 and to start a discussion in ECRIT mailing list regarding the possible registration of these specific emergency services. Meanwhile there is a process to make the list with the emergency services bigger.
> There are some conclusions seen from the list:
>  
> Each emergency service needs to have unique emergency service URN. Handling in IMS can be different than handling in CS.
>  
> Example1:
>  
> In Czech republic, there is a "Municipal police" emergency service (156) and a "Police of the Czech Republic" emergency service (158) + other emergency services. 
>  
> Within the CS domain it is possible to indicate the emergency service required, but in a limited set (3GPP TS 22.101) - there is only one bit for Police in the Emergency category Information Element.
>  
> An operator in Czech republic can provide to a UE via NAS a mapping of 158 and the Police bit in the Emergency category IE. Whenever the user dials 158 in Czech republic, this causes the UE to use a CS EMERGENCY SETUP with the Emergency category IE with the Police bit set or a UE-detectable IMS emergency call setup with the Request-URI set to the urn:service:sos.police, sent within emergency PDN connection. Either the MSC or the IMS network in Czech republic route the call to the PSAP providing the "Police of the Czech Republic" emergency service.
>  
> The operator in Czech republic canNOT provide to a UE via NAS a mapping of 156 and a bit in the Emergency category Information element since:
> - the "Police" bit is taken for the "Police of the Czech Republic" emergency service (which is provided by a different PSAP than the PSAP providing the "Municipal police" emergency service);
> - there is no other related bit; and
> - providing no bit implies a generic emergency service (which is provided by a different PSAP than the PSAP providing the "Municipal police" emergency service).
>  
> Given that the UE is not configured with 156, whenever the user dials 156 in Czech republic, this causes the UE to use a CS SETUP for 156 or a non-emergency IMS call setup for tel:156;phone-context=<phone-context <tel:156;phone-context=%3cphone-context>>. 
> In CS, the MSC is always in the same country as the UE so the MSC just routes the non-emergency CS domain call for 156 to the PSAP providing the "Municipal police" emergency service.
> In IMS, it is not so easy since inbound-roamer would have P-CSCF abroad. 
>                 The P-CSCF abroad sends a 380 response to the UE to inform the UE that the UE dialed an emergency number. In the 380 response, there is a Contact header field indicating the "Municipal police" emergency service. 
>                 Based on the 380 response, the UE determines that a call to an emergency number was attempted and the UE selects whether to attempt the emergency call in CS or in IMS.
>                                If in IMS, the UE establishes an emergency PDN connection, and sets up a UE-detectable IMS emergency call and sets the Request-URI to the Contact of the 380 response, i.e. the Request-URI contains a sos URN identifying the "Municipal police" emergency service. Based on the Request-URI, the IMS network in Czech republic routes the call to the PSAP providing the "Municipal police" emergency service.
>                                If in CS, since the the Contact of the 380 response does not match any of urn:service:sos, urn:service:sos.police, urn:service:sos.ambulance, urn:service:sos.fire, urn:service:sos.marine, urn:service:sos.mountain, the UE sends CS SETUP for 156.
>  
> The marked text above is one reason why each emergency service needs to have a unique emergency service URN (either country specific emergency URN or an emergency URN assigned by IANA and ECRIT).
There will be some form of “national.police” and some form of “local.police” or “municipal.police" registrations.   If needed, other police registrations can be made, but just using the two registrations for “national.police” and “local.police” and mapping 158 to “national.police’ and “156” to “local.police” would make sense here.  The routing element can still route a call marked “national.police” to the local PSAP or a call marked “national.police” to the local PSAP if it needs to.  Routing can be anything you need it to be; the name of the service doesn’t influence routing.  The system clearly can correctly route a 156 call and a 158 call on the ÇS or IMS networks, and it can clearly route a local.police and a national.police the same way.  The point here is that you have exactly two service codes (156 and 158) and you need exactly two service URNs, and there isn’t any reason at all that using “local.police” and “national.police” won’t work fine.
>  
>  
> It is not possible to consolidate services which are in different nations.
>  
> Emergency service X might have a different meaning in different countries, e.g. X.A in country A and X.B in country B.
> Furthermore, even if at the moment X.A and X.B would be identical, it cannot be guaranteed that national regulations of A and B would keep X.A and X.B in-line.
> From this perspective it would make sense to allow national regulators to determine their national emergency service URNs in a way that is clearly indicated as country-specific.
I don’t agree.  While it may be the case that in some future time some country changes the generally accepted definition of a service, all that we care about is that there is a reasonable mapping available.  If we need to, when the new service is defined, it can get a new service urn if it is indeed a different service.

> Assume there are several countries defining the following emergency service:
> * 555 - religious/spiritual counselling
> It might be difficult to ensure to people of different religious convictions that they end up with a counsellor of their need/expectation. Whilst this maybe could be solved by a designator for specific religion, the issue would for sure be seen by some countries as their decision to make (locally).
Like police, fire and ems, if we need a service URN for “spiritualCounseling” and in some country there is “christian.spiritualCounseling” and “moslem.spiritualCounseling” where in another country there is “Catholic.spiritualCounseling” and “easternOrthodox.spiritualCounseling” then we can make registrations for each of them, because they are actually different services.
>  
> EXAMPLE 2
> 142- Telefonseelsorge (Telefone soul care) is defined as emergency number in Austria and is served by the Catholic and Evangelistic Churches in Austria.
> 106 - Mental problems hotline in Belgium has nothing to do with the Church.
> 988 - Helpline (domestic violence/ suicides) in Poland.
>  
> It is not possible to consolidate these emergency numbers in 3 different countries under only one urn. They provide almost the same service, but have different ways to help. These 3 numbers cannot be referred to a single URN, since public and regulator expectations towards them are different.
I think those are separate services and would clearly qualify for separate registrations.    While one country might have a suicide prevention service and a separate domestic violence service, there could be a question of whether a combined service is a separate service.  I would think it would be, and would qualify for a registration.  It would clearly work if 988 in Poland used the “suicidePrevention” service URN even though it combines it with domestic violence.  However, I think it’s probably best to give it a separate service URN.
>  
> EXAMPLE 3
> 197- Terror Alert - Child Alert in France
> 114 - Child emergency in Italy
> They cannot be under one URN since the number in France is also responsible for Terror Alert. 
Same as above. I think France should have a separate registration, but it would work fine if they just used “childEmergency”.
>  
> In some countries some counselling services are considered as emergency and in other countries they are only counselling services.
>  
> EXAMPLE 4
> In Austria:
> -  147 - Notrufdienst für Kinder und Jugendliche is emergency number according to the regulators/ law. While in Germany +49 800 1110333 Kinder- und Jugendtelefon is not emergency service.
So?  Do you want to map +49 800 1110333 in Germany to “childEmergency” or not?  If it’s not mapped to the service URN, then there is no problem.  If it is, then the call is not an emergency call.  The service URN is designed to work with non-emergency services.  There is no restriction on sos:counseling that it can only be used for non-emergency calls.  If it makes sense in some country to treat it as an emergency call, do it.  Nothing will break somewhere else.

>  
> IANA have registered urn:service:sos for “emergency services” and urn:sos:counceling for non-emergency services. 147 has to be mapped under the “emergency services” tree to satisfy Austrian regulatory requirements, while +49 800 1110333 has to remain under the “non-emergency services” tree. It is unclear how the ECRIT expert will handle these requests given the following description for the expert’s role in 4.3 of RFC 5031: 
> “The expert review should take into account whether these services are offered widely and in different countries, with approximately the same caller expectation in terms of services rendered.”
This is urn:service:sos.childEmergency (or something like it), not urn:service.sos or urn:sos:counceling.

>  
> The local regulator may want to have the routing urns in local language or may want to have a better translation to English that what is chosen in the time of the registration.
>  
> All the examples show that emergency services have its local peculiarities in different countries and consolidating them under respective sos sub-services is difficult. In some cases consolidation is possible (the sos urns which are already registered). But in other cases it is not possible to use the current registration process and to satisfy the regulatory requirements in different countries. 
Once again, this is a urn, not a human readable tag.  It could be X4476 and work fine.  

If there are distinct services, they should get distinct service urns.  Service urns are inexpensive and the process to get a new one is simple.  The fact that in some countries some unusual services, or service combinations exist doesn’t detract from the overall observation that in most countries, there is a common set of services that they all agree on.  Where there are distinct services, ask for a service urn and you will get one.

> I believe the examples above give arguments to use “sos.country-specific”.
I don’t agree at all

Brian