Re: [Ecrit] country specific emergency URNs

Henning Schulzrinne <hgs@cs.columbia.edu> Fri, 11 August 2017 01:18 UTC

Return-Path: <hgs10@columbia.edu>
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 4F3F8132026 for <ecrit@ietfa.amsl.com>; Thu, 10 Aug 2017 18:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 5U1WTiLe5h-1 for <ecrit@ietfa.amsl.com>; Thu, 10 Aug 2017 18:18:45 -0700 (PDT)
Received: from outprodmail01.cc.columbia.edu (outprodmail01.cc.columbia.edu [128.59.72.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07431131D2C for <ecrit@ietf.org>; Thu, 10 Aug 2017 18:18:44 -0700 (PDT)
Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id v7B1FAdQ056536 for <ecrit@ietf.org>; Thu, 10 Aug 2017 21:18:43 -0400
Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id D749A80 for <ecrit@ietf.org>; Thu, 10 Aug 2017 21:18:43 -0400 (EDT)
Received: from sendprodmail02.cc.columbia.edu (sendprodmail02.cc.columbia.edu [128.59.72.14]) by hazelnut (Postfix) with ESMTP id BD58380 for <ecrit@ietf.org>; Thu, 10 Aug 2017 21:18:43 -0400 (EDT)
Received: from mail-oi0-f71.google.com (mail-oi0-f71.google.com [209.85.218.71]) by sendprodmail02.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id v7B1IhLO053455 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for <ecrit@ietf.org>; Thu, 10 Aug 2017 21:18:43 -0400
Received: by mail-oi0-f71.google.com with SMTP id k82so2400079oih.1 for <ecrit@ietf.org>; Thu, 10 Aug 2017 18:18:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RxOg5MgTpqvR5tgC0+QTsQ7tj8HEe7aLqDkU+pldSRk=; b=uhPD7pmb0gdXNOXTT/GfG+15FWMeyWkVI+5ryoD0kSRwMBY7AJGg7PhFHymrwmTEne zHVSpn5LY6o34kiMh2Pblg2Wf5qR+BHKcX0TTNp+tS9w71ECsVmdwQk1KFDBhv+xi8Rn vd6txFlzytLUfNkMWXejGL1wIZ5V7vqAbftL0Ci3HCOqfcJGsY0BY3LX275W4vbsJHCj k/rOzvXr+QpflX5z6INnEhJqJyev1Fq8O3y7hE4EeVwr/1HnYQGOFlzbyFgN+yX9BTZy FiQb1vE1UVkcT3FGXwcoaTiXR6rn1qm0gGr6mNzzWkPXDeQITFm4GJE+fx1ZWZ1elBuN 8l5g==
X-Gm-Message-State: AHYfb5h1S6dGFDU1aFUJZoGHjLxNlvSDSyc89jTfqi8t1P4Z4R40KW/5 Ks8L0okS5bZvbrUW/RZxpla+ASr8F+JBSedg/yMZYcmUQ5UyVTBEo32CIjZvnNLTXOzSr19BK3+ 9BqmQrx3o5JgAvlLkaw5q
X-Received: by 10.202.243.132 with SMTP id r126mr16143934oih.304.1502414322073; Thu, 10 Aug 2017 18:18:42 -0700 (PDT)
X-Received: by 10.202.243.132 with SMTP id r126mr16143904oih.304.1502414321675; Thu, 10 Aug 2017 18:18:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.232.225 with HTTP; Thu, 10 Aug 2017 18:18:20 -0700 (PDT)
In-Reply-To: <52809D5B0606C049903AD6AD07E033E10327CBCE55@ATWIREMXSC0101.sv.ad.tmo>
References: <52809D5B0606C049903AD6AD07E033E10326EF8FFD@ATWIREMXSC0101.sv.ad.tmo> <AF1BEB84-A0D2-44AD-9666-1C608B73BC68@brianrosen.net> <CACgrgBbgMqWn3ovUogw6o_pLPhJBpSOPZ+JgDcSfgzzChcUcAQ@mail.gmail.com> <DB5PR07MB14806FA9F5D0FA90DEF2E1E2F7AB0@DB5PR07MB1480.eurprd07.prod.outlook.com> <CACgrgBY1Y_cT_F-eT-R50H81o5=9xgTjdLgRKS2x59Ar0M4gxw@mail.gmail.com> <52809D5B0606C049903AD6AD07E033E10327096BB1@ATWIREMXSC0101.sv.ad.tmo> <CACgrgBazRYu_XAu2S1t5-mEoMPYmRVFG+az71LLej_wTVFTiqw@mail.gmail.com> <52809D5B0606C049903AD6AD07E033E1032709747D@ATWIREMXSC0101.sv.ad.tmo> <CACgrgBYUs=CfyjuPM9BX9Z1u9o7Boqtpj4=viOMB0VjYu0Aq9w@mail.gmail.com> <52809D5B0606C049903AD6AD07E033E1032709783F@ATWIREMXSC0101.sv.ad.tmo> <CACgrgBY+d==tTbVCuwLcTP_M6saYZw0UpV4Mi66DL2ToCbVeeA@mail.gmail.com> <52809D5B0606C049903AD6AD07E033E10327178504@ATWIREMXSC0101.sv.ad.tmo> <1599E1B5-CBA4-43F9-90FC-FA8D4EBAC28F@brianrosen.net> <52809D5B0606C049903AD6AD07E033E103271785EB@ATWIREMXSC0101.sv.ad.tmo> <CACgrgBbTTBv0ZHShmsSyW3GS06t-MC3YnRqr-K2rD+_r-+PobA@mail.gmail.com> <52809D5B0606C049903AD6AD07E033E10327178B14@ATWIREMXSC0101.sv.ad.tmo> <CACgrgBYfshZjN9Q7CZsZoAetfO_g7cs-TwzEyT7n6BhbXoQWkQ@mail.gmail.com> <52809D5B0606C049903AD6AD07E033E10327CBCE55@ATWIREMXSC0101.sv.ad.tmo>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Date: Thu, 10 Aug 2017 21:18:20 -0400
Message-ID: <CACgrgBb5syk=NaPF+ud30OiQJyMdDPtWn-fEvC0nhhC0FX3pSQ@mail.gmail.com>
To: "Aleksiev, Vasil" <Vasil.Aleksiev@t-mobile.at>
Cc: Brian Rosen <br@brianrosen.net>, "ecrit@ietf.org" <ecrit@ietf.org>, Ivo Sedlacek <ivo.sedlacek@ericsson.com>
Content-Type: multipart/alternative; boundary="94eb2c09600af302bc055670178b"
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.78 on 128.59.72.14
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/efzN8rYhe8U_HJwqhD7e-g8iAVg>
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: Fri, 11 Aug 2017 01:18:48 -0000

Unfortunately, you offer no evidence of your assertions and no indication
that the proposed approach that follows the SOS URI does not work. (The
approach is simple: We define SOS URIs for emergency services as needed and
as requested by regulators or other relevant entities.)

The approach is pretty straightforward and depends on the local situation:

Case 1: The regulator does not care about SOS URNs, considering this a
user-invisible network-internal matter. The local (national) carriers map
the emergency numbers in a country to a SOS URN. If there's no suitable
match, a new URN is defined, with a short registration process that we are
currently exercising. (I suspect that the US would work that way.)

Case 2: The regulator cares about SOS URNs. In that case, they are involved
in the discussion, e.g., to determine whether this is a good opportunity to
create a regionally-unified label for a similar service (to facilitate
roaming, including accidental roaming, and cross-border handling).

Obviously, it's a good idea to find out in each case whether the regulator
cares or not, but as long as each emergency number maps to a unique URN,
it's just a user-invisible label.

Organizations such as EENA can help keep informational number-to-URN lists,
if that's helpful.

You are advocating, essentially, reverting to the number-based approach
which the ECRIT working group has rejected in its earlier standards effort,
because of the known deficiencies. Thus, I'm not sure how we can make
progress beyond repeating assertions about unnamed regulators who may or
may not like certain things. If you can explain, beyond mere assertion, why
the process above would not work, maybe we can make progress.

Henning

On Thu, Aug 10, 2017 at 12:25 PM, Aleksiev, Vasil <
Vasil.Aleksiev@t-mobile.at> wrote:

> Hi Henning,
>
> I was on a vacation and now back. Regulators are different in every
> country, experience with one regulator cannot give you a view regarding the
> regulators in the world.
>
> I can assure you that if a number is defined as emergency from a regulator
> it shall be treated as emergency. According to the Austrian text there I do
> not see fluid definitions. I think the regulator has the authority to
> decide what number is emergency and what not. So if a regulator has decided
> that the emergency numbers in one country shall be 10 different numbers –
> all of them shall be treated as emergency. CS has certain limitations –
> only 7 categories can be used for UE detected emergency calls. But this
> shall not be the case for other RATs. In this sense I do not see a reason
> why there shall be limitations on what service shall be treated as
> emergency and what not.
>
> I also fully support Ivo´s view.
>
>
>
> BR Vasil
>
>
>
>
>
> *Von:* Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> *Gesendet:* Donnerstag, 13. Juli 2017 18:23
> *An:* Aleksiev, Vasil <Vasil.Aleksiev@t-mobile.at>
> *Cc:* Brian Rosen <br@brianrosen.net>; ecrit@ietf.org
> *Betreff:* Re: [Ecrit] country specific emergency URNs
>
>
>
> Vasil,
>
>
>
> I assume you don't know that I have worked for a large telecom regulator
> for the past seven years, so grant me that I am somewhat familiar with this
> territory. (As usual, anything I say here is my personal opinion, etc.)
>
>
>
> This is much more complicated than you make it, unfortunately. To give you
> a US example:
>
>
>
> 911 was put into operation in 1968; it was only legally designated a
> national emergency number in 1999 (see https://www.gpo.gov/
> fdsys/pkg/PLAW-106publ81/pdf/PLAW-106publ81.pdf).
>
>
>
> Similarly, over time, obligations for interconnected VoIP carriers changed
> for handling 911. This didn't change the nature of 911, how carriers
> treated the number, the technology or consumer expectations.
>
>
>
> Secondly, we probably agree that there are numbers that are routinely
> treated as emergency numbers in practice. I gave an Austrian example of a
> listing of "Notrufnummern" that goes significantly beyond whatever list is
> encoded in some legislation. I'm not saying that all of these should be
> 'sos' (indeed, several should not), but it shows that even official
> government web sites have a more fluid definition, based on consumer
> expectations and common sense, of what constitutes an emergency number.
>
>
>
> Another example: I don't think anybody wants to convert sos.poison, an
> existing RFC 5031 registration, to something else. But there is no law (in
> the US) that designates the poison control number as an emergency number.
>
>
>
> There is a general good-engineering practice of not encoding policy into
> protocol (or identifiers), as you want to change policy without changing
> protocols.
>
>
>
> But I don't think these abstract philosophical discussions are getting us
> anywhere. Please take a look at the specific engineering proposals in
>
>
>
> https://docs.google.com/presentation/d/18t1siLVrPTwyYWUm8TQK7EnwC9Y4h
> wkYZmEa846Pzig/edit?usp=sharing
>
>
>
> and provide comments or alternatives. I think that will get us further
> than these abstract discussions.
>
>
>
> Henning
>
>
>
> On Thu, Jul 13, 2017 at 7:04 AM, Aleksiev, Vasil <
> Vasil.Aleksiev@t-mobile.at> wrote:
>
> Henning,
>
> In one country always there is a regulator commission which is monitoring
> the telecom carriers. The regulator issues rules in written form and
> monitors if all the carriers are following it. If the written rules are not
> followed, the regulator issues the respective penalties. So every mobile or
> fixed operator looks into the written rules and takes care of it. In this
> sense the telecom operators are only caring what is the regulator
> definition of emergency calls. That is why we have created a file with
> links to the respective documents, which are issued by the regulators in
> the respective countries (in form of law). In such document there is
> definition for emergency calls and list is present with the numbers
> considered as emergency in the country. The definition usually includes
> serving the calls with priority, providing location of the subscribers,
> providing possibility for call back.
>
> One operator uses such mechanisms only for numbers defined as emergency by
> the law. Of course every organisation is free to define its own emergency
> number for some reasons, but the operators do not have an obligation to
> take care of this and route such numbers as normal calls.
>
> I think there is no reason to search in google for every possible
> emergency number which nobody is routing as emergency according to the
> regulators requirements.
>
>
>
> BR Vasil
>
>
>
>
>
> *Von:* Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> *Gesendet:* Mittwoch, 12. Juli 2017 17:29
> *An:* Aleksiev, Vasil <Vasil.Aleksiev@t-mobile.at>
> *Cc:* Brian Rosen <br@brianrosen.net>; ecrit@ietf.org
> *Betreff:* Re: [Ecrit] country specific emergency URNs
>
>
>
> Vasil,
>
>
>
> the service URN does not prescribe any network priority treatment. Indeed,
> at least in the US, landline 911 calls are treated exactly the same as
> regular calls, e.g., during network congestion. (We have the SIP RPH
> mechanism for prioritizing call treatment, but it's not used for civilian
> emergency calls.)
>
>
>
> I suspect this is try for many of the non-112 calls today. I very much
> doubt that marine emergency calls in Finland or 1-800 calls to the poison
> control center in the US (and the equivalent set of numbers in Germany,
> say) receive any priority treatment in the network.
>
>
>
> Again, I think it helps make progress if we do not overload labels with
> policy.
>
>
>
> Naturally, any country or carrier is free to use any label, including the
> URN, to signify any treatment local law and regulation permits or requires.
> But the label does not *require* or imply such network treatment.
>
>
>
> I admit I'm thoroughly confused by this discussion. Where did the priority
> issue suddenly come from? It's not in any ECRIT document that I'm aware of.
>
> Henning
>
>
>
> On Wed, Jul 12, 2017 at 10:49 AM, Aleksiev, Vasil <
> Vasil.Aleksiev@t-mobile.at> wrote:
>
> Hi Brian,
>
> A service URN with a top-level service type of "sos" is used only when the
> user intends to establish an emergency call. The emergency call will be
> treated with priority in the network. For non-emergency numbers in one
> country sos shall not be used since priority there is not needed.
>
>
>
> Best regards,
>
>
>
> Vasil
>
>
>
>
>
> *Von:* Brian Rosen [mailto:br@brianrosen.net]
> *Gesendet:* Mittwoch, 12. Juli 2017 15:46
> *An:* Aleksiev, Vasil <Vasil.Aleksiev@t-mobile.at>
> *Cc:* Henning Schulzrinne <hgs@cs.columbia.edu>; ecrit@ietf.org
> *Betreff:* Re: [Ecrit] country specific emergency URNs
>
>
>
> Vasil
>
>
>
> Once again, the name has no significance as long as it is unique.  We use
> the names as suggestive for the service to aid the service providers,
> regulators and public safety authorities in setting up the systems, but the
> urn name is not used by anything other than computer software during an
> emergency.
>
>
>
> If one country has a service for an ambulance service that is considered
> an emergency service, but in another country it is not considered an
> emergency service, we can, and should still use the service in the sos tree
> for the non-emergency service.  On the other hand, if there was a country
> that had two ambulance services, one that was used for emergency transport
> and another that was used for non-emergency transport, then we would need
> two URNs, because we have distinct services and need different URNs.
>
>
>
> Brian
>
>
>
>
>
>
> ____________________________________________________________
> ______________________________
> Notice: This e-mail and any attachments are confidential and may be
> privileged.
> If you are not the intended recipient, notify the sender immediately,
> destroy all
> copies from your system and do not disclose or use the information for any
> purpose.
> Diese E-Mail inklusive aller Anhaenge ist vertraulich und koennte
> bevorrechtigtem
> Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind,
> informieren Sie
> bitte den Absender unverzueglich, loeschen Sie alle Kopien von Ihrem
> System und
> veroeffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich
> zu welchem Zweck.
>
> Think before you print!
>
> T-Mobile Austria GmbH
> Geschaeftsfuehrung: Dr. Andreas Bierwirth (Vorsitzender), Aufsichtsrat:
> Dr. Rolf Nafziger (Vorsitzender)
> Firmenbuch: Handelsgericht Wien, Sitz Wien, FN 171112k, UID ATU 45011703,
> DVR 0898295
> Konto: UniCredit Bank Austria AG IBAN: AT93 1200 0528 4407 2301, BIC:
> BKAUATWW
>
> T-Mobile – Das verbindet uns.
> ____________________________________________________________
> ______________________________
>
>
>
> ____________________________________________________________
> ______________________________
> Notice: This e-mail and any attachments are confidential and may be
> privileged.
> If you are not the intended recipient, notify the sender immediately,
> destroy all
> copies from your system and do not disclose or use the information for any
> purpose.
> Diese E-Mail inklusive aller Anhaenge ist vertraulich und koennte
> bevorrechtigtem
> Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind,
> informieren Sie
> bitte den Absender unverzueglich, loeschen Sie alle Kopien von Ihrem
> System und
> veroeffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich
> zu welchem Zweck.
>
> Think before you print!
>
> T-Mobile Austria GmbH
> Geschaeftsfuehrung: Dr. Andreas Bierwirth (Vorsitzender), Aufsichtsrat:
> Dr. Rolf Nafziger (Vorsitzender)
> Firmenbuch: Handelsgericht Wien, Sitz Wien, FN 171112k, UID ATU 45011703,
> DVR 0898295
> Konto: UniCredit Bank Austria AG IBAN: AT93 1200 0528 4407 2301, BIC:
> BKAUATWW
>
> T-Mobile – Das verbindet uns.
> ____________________________________________________________
> ______________________________
>