Re: [Ecrit] R: country specific emergency URNs

Henning Schulzrinne <hgs@cs.columbia.edu> Tue, 11 July 2017 10:59 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 AE1FF12EC11 for <ecrit@ietfa.amsl.com>; Tue, 11 Jul 2017 03:59:46 -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 5mHT4VM6bABy for <ecrit@ietfa.amsl.com>; Tue, 11 Jul 2017 03:59:45 -0700 (PDT)
Received: from outprodmail02.cc.columbia.edu (outprodmail02.cc.columbia.edu [128.59.72.51]) (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 39CD012EB99 for <ecrit@ietf.org>; Tue, 11 Jul 2017 03:59:45 -0700 (PDT)
Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail02.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id v6BAu6BD059808 for <ecrit@ietf.org>; Tue, 11 Jul 2017 06:59:44 -0400
Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 4AB167E for <ecrit@ietf.org>; Tue, 11 Jul 2017 06:59:44 -0400 (EDT)
Received: from sendprodmail04.cc.columbia.edu (sendprodmail04.cc.columbia.edu [128.59.72.16]) by hazelnut (Postfix) with ESMTP id 3448B7E for <ecrit@ietf.org>; Tue, 11 Jul 2017 06:59:44 -0400 (EDT)
Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by sendprodmail04.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id v6BAxhsv040480 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for <ecrit@ietf.org>; Tue, 11 Jul 2017 06:59:44 -0400
Received: by mail-oi0-f69.google.com with SMTP id t188so10021024oih.15 for <ecrit@ietf.org>; Tue, 11 Jul 2017 03:59:44 -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=S/l0hfzbkYcE3QpvXKKgIh0tAmh7GIo0yTGXTpfRnpk=; b=L5n64USDe2Ik0SpnZ2ozXLE2aZjqxXAnUSkBJkSA5h8VqyJVOxko1Qf19rdH9XMDdy XsVkLLfaP5IawWnk9X7w28JLcySmERMRIl5wnuGoMXmYX71UKOZuUe+ajaNpC8ekVq8Q 6Mao7T4wbsCwqLgzrJqRMdGYGWKUUU6xLnCaAfz/W9cDAKskgWaMqjZmGRCJqb9KvPLF gB0fG6FRZ6hms+8JEqkUKW0OIonUCvlwz6/xox6K2Jh2tRNG1wnHiXLI0Cd7QWzemp6N NS2vlvFyQC4eCFTA2glaV1ttz6Kh85S3vp4wndC/G9wyEBJuAesBdy++gZXZFGvqmPFT kZ+w==
X-Gm-Message-State: AIVw113HqB4PdWQkwdwRmlGagX6W2U3Z5rujZGpte7nEtKNwvLp1lktx GgnUcBy0tzdoPRKfN4AAJYRnwYQSUY99N97Bdg4l+KTAywMMdXFFkVIy0+voHwnLvWhXAsrT6DO NCWEFYp16LkcMELdjGrmL
X-Received: by 10.202.192.193 with SMTP id q184mr11700432oif.179.1499770782938; Tue, 11 Jul 2017 03:59:42 -0700 (PDT)
X-Received: by 10.202.192.193 with SMTP id q184mr11700423oif.179.1499770782713; Tue, 11 Jul 2017 03:59:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.65.66 with HTTP; Tue, 11 Jul 2017 03:59:22 -0700 (PDT)
In-Reply-To: <9ad2fe2695284ffbbed79035d3af18ec@TELMBXA02RM001.telecomitalia.local>
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> <9ad2fe2695284ffbbed79035d3af18ec@TELMBXA02RM001.telecomitalia.local>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Date: Tue, 11 Jul 2017 06:59:22 -0400
Message-ID: <CACgrgBaWi=-9B8Dxyy=mki33Sx_U3dwoCNfuxvUnvjKqJtjvWA@mail.gmail.com>
To: Procopio Roberto <roberto.procopio@telecomitalia.it>
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
Content-Type: multipart/alternative; boundary="001a113dd09abfa05f05540898ea"
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.78 on 128.59.72.16
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/UcVq-pAVvCNyB4FCHJyPP_2-RuA>
Subject: Re: [Ecrit] R: 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: Tue, 11 Jul 2017 10:59:47 -0000

For cross-national MVNOs, routing to a service that does not exist in the
country you are visiting is not helpful (or even possible). Thus, if you
define a country-specific service that exists only in, say, Italy, and then
visit Austria, the call will have to fail. In the SOS model, you get a
close approximation, which seems much more user friendly.

As I have stated repeatedly, and you seem to continue to ignore, is that
the label is an internal protocol label where the only requirement is that
there is a unique 1-1 mapping within one country from number to label. This
requirement exist even if you create country-specific labels unless your
"label" is sos:fr.147, i.e., you directly encode the number. This is
clearly a bad idea.

I disagree that this requires a "consolidation of emergency service
requirements". It requires a listing of services, which I have again asked
for again and again.

As I have also tried to explain several times, we only have to make sure
two things are true:

(1) The description is precise enough so that it is clear in each country
whether it matches an existing service. If a newly-discovered service does
not seem to match an existing one, a new label is created. The description
does not have to be a legal one or cover every aspect of operation (which
changes over time anyway). In all the cases we have discussed, this seems
relatively straightforward.

(2) Within each country, all existing numbers have to map to unique URNs.

It is very difficult to make progress if you (and your colleagues) insist
that something is not possible, but then make it impossible to make
progress by not providing the necessary information. It would be most
helpful if you could engage constructively rather than insisting on a
solution that violates the spirit and design principles of the architecture.

I continue to look forward to starting the list of services we should
discuss.

Henning


On Tue, Jul 11, 2017 at 6:00 AM, Procopio Roberto <
roberto.procopio@telecomitalia.it> wrote:

> Dear All,
>
>
>
> I share the points raised by Vasil. In some of the emails below I red that
> a way forward could be to identify a reasonable mapping between an
> emergency service and the related sos urns. I don’t think that this is a
> good way forward. The reason is that this way forward requires a
> consolidation of emergency service requirements among different countries
> and this requires a deep understanding of the emergency services definition
> in each country.
>
>
>
> Simply looking at the emergency services collected in the table shared by
> Vasil, it can be understood that services having the same name can have
> different requirements in different countries. This mistmatch generates
> problems in the emergency service operation as showed in the example raised
> by Vasil (e.g. roaming, borders). If we look at future possible deployments
> of mobile networks, we can also find other scenarios (such as
> cross-national MVNO) where is crucial to identify exactly one specific
> emergency service in one country.
>
>
>
> Therefore in my opinion is very important to guarantee the flexibility in
> the naming definition of the sos urns. As Vasil said, this flexibility was
> one of the reasons behind the proposal of the country specific emergency
> URN.
>
>
>
> BR
>
> Roberto
>
>
>