Re: [Ecrit] country specific emergency URNs

Henning Schulzrinne <hgs@cs.columbia.edu> Thu, 13 July 2017 16:23 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 ABCB9124BE8 for <ecrit@ietfa.amsl.com>; Thu, 13 Jul 2017 09:23:27 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 5JmApOMd6afv for <ecrit@ietfa.amsl.com>; Thu, 13 Jul 2017 09:23:24 -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 94CF3124B0A for <ecrit@ietf.org>; Thu, 13 Jul 2017 09:23:24 -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 v6DGInjq054879 for <ecrit@ietf.org>; Thu, 13 Jul 2017 12:23:23 -0400
Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id BBAA380 for <ecrit@ietf.org>; Thu, 13 Jul 2017 12:23:23 -0400 (EDT)
Received: from sendprodmail03.cc.columbia.edu (sendprodmail03.cc.columbia.edu [128.59.72.15]) by hazelnut (Postfix) with ESMTP id 68D8C7E for <ecrit@ietf.org>; Thu, 13 Jul 2017 12:23:23 -0400 (EDT)
Received: from mail-oi0-f72.google.com (mail-oi0-f72.google.com [209.85.218.72]) by sendprodmail03.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id v6DGNMwS040842 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for <ecrit@ietf.org>; Thu, 13 Jul 2017 12:23:23 -0400
Received: by mail-oi0-f72.google.com with SMTP id 6so4506298oik.11 for <ecrit@ietf.org>; Thu, 13 Jul 2017 09:23:23 -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=wWQVWBSZ9uqx3bUGiDDAzbrKgXCBG6VPiRy7n7YPTr0=; b=UTXFwX3ISejC2YCIisI5xQ8BMhSc7IDhGkdZolxGDAZJg2kprKr0/XmYXAgs82aEJ2 wMSo3BopTb8cgsMUfLa8QfGyLjTdLVLvKoxE86LY87wrD/Q5N6dlz69Phj9cjwPyKH// vxUlSUk/1dH0PqTg5dl1LendDrg+euoJ/THmuQMUdXtQ762x7oPlalc7ctufYL9WLgJw C5zhhf7/j/ltm2Re3wq5Hj7Rpqrwil/kBR0NTPREqODe963451ZiKFm0XxyMgXPQN0Fd RyXWinjs3nYR9iclFzuScHWJdmtiI2V3we1Cbj0DG/P2QJ+w/K4EOLzCqt5RBZ0EVptE YAgg==
X-Gm-Message-State: AIVw111w4sAQRSBtPgfnDmIxrdCyE2o8Bd9qYkM6YAh3149QxfAvFIKD chJa+V8EGfJWRmxHpvtv09qvRKLkNeg5hTGa6/VLEZtc19W+p3oMVWQ0OptjVIlFVYw8bCN82dI Mh5pBokYH/QMSjSXDV7mc
X-Received: by 10.202.207.20 with SMTP id f20mr2840093oig.170.1499963001847; Thu, 13 Jul 2017 09:23:21 -0700 (PDT)
X-Received: by 10.202.207.20 with SMTP id f20mr2840080oig.170.1499963001439; Thu, 13 Jul 2017 09:23:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.116.34 with HTTP; Thu, 13 Jul 2017 09:23:00 -0700 (PDT)
In-Reply-To: <52809D5B0606C049903AD6AD07E033E10327178B14@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>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Date: Thu, 13 Jul 2017 12:23:00 -0400
Message-ID: <CACgrgBYfshZjN9Q7CZsZoAetfO_g7cs-TwzEyT7n6BhbXoQWkQ@mail.gmail.com>
To: "Aleksiev, Vasil" <Vasil.Aleksiev@t-mobile.at>
Cc: Brian Rosen <br@brianrosen.net>, "ecrit@ietf.org" <ecrit@ietf.org>
Content-Type: multipart/alternative; boundary="001a113def20e0a3a105543559fb"
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.78 on 128.59.72.15
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/GsaKmSMeESs7IXRlxMSSuRyt7rg>
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, 13 Jul 2017 16:23:28 -0000

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/18t1siLVrPTwyYWUm8TQK7EnwC9Y4hwkYZmEa846Pzig/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.
> ____________________________________________________________
> ______________________________
>