Re: [Ecrit] Country-Specific Emergency Service sub-type

Henning Schulzrinne <hgs@cs.columbia.edu> Thu, 30 March 2017 03:12 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 0C681127275 for <ecrit@ietfa.amsl.com>; Wed, 29 Mar 2017 20:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.701
X-Spam-Level:
X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, 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 V1UxDTJCat6s for <ecrit@ietfa.amsl.com>; Wed, 29 Mar 2017 20:12:10 -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 774B2128D2E for <ecrit@ietf.org>; Wed, 29 Mar 2017 20:12:10 -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 v2U3A6jm015692 for <ecrit@ietf.org>; Wed, 29 Mar 2017 23:12:09 -0400
Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 7E7706D for <ecrit@ietf.org>; Wed, 29 Mar 2017 23:12:09 -0400 (EDT)
Received: from sendprodmail03.cc.columbia.edu (sendprodmail03.cc.columbia.edu [128.59.72.15]) by hazelnut (Postfix) with ESMTP id 22E716D for <ecrit@ietf.org>; Wed, 29 Mar 2017 23:12:09 -0400 (EDT)
Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by sendprodmail03.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id v2U3C8ft005095 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for <ecrit@ietf.org>; Wed, 29 Mar 2017 23:12:08 -0400
Received: by mail-oi0-f69.google.com with SMTP id b187so13409345oif.11 for <ecrit@ietf.org>; Wed, 29 Mar 2017 20:12:08 -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=u2qHD7X/Z7lwpVkfUho++WB8COVGd2jjdfAz/UboK+E=; b=dQbYa0Q4Zp0SQopGzKbPZoEjnNPTG6gOovLx+N4cElnXCiXh7Ej3JswWtfl0akV5u4 t8qgbdzaC4KQRxqp9lm8txE5oeI6ehQn4bQMgjpqSZD3lp1rn7Zxf18i+oTz/pZ3WsNc L5ozlHht0T4JQtxHeQJPO8t4NXg8qu5THR5RHC9n2SYsfYwom4eo7EmdAFzpW8enNkTl At2IAudTHYZ7yYSRjtHs8GaXqPFumlrQyR5jPscEDQgmnmKP96Owp5cgHKDqzs3cJqgx F1q3GWaQhbs+DMmfBA0OdxMuzzW8PLyOB4m3CkgFciOvX1f0N1nODzwinfIqBcwCfE2z oAFg==
X-Gm-Message-State: AFeK/H3n3bVZDW190OCHO6PB8ojvlZl1ZT+SZhPtjAmiZoJKOvNXzanT/oD8D6+6FF+Fc7ul5l59WFP5LutVup+luINbEha6rUxq6h9kV8o4EnJnUJkWJKUrJC73AOujMAqrrFqly0gymrBrDVUiTfos
X-Received: by 10.202.173.10 with SMTP id w10mr2326927oie.101.1490843166494; Wed, 29 Mar 2017 20:06:06 -0700 (PDT)
X-Received: by 10.202.173.10 with SMTP id w10mr2309004oie.101.1490842715162; Wed, 29 Mar 2017 19:58:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.3.116 with HTTP; Wed, 29 Mar 2017 19:58:14 -0700 (PDT)
In-Reply-To: <c27a6789-797a-7312-8bba-2a2aed254f9a@gmx.com>
References: <c27a6789-797a-7312-8bba-2a2aed254f9a@gmx.com>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Date: Wed, 29 Mar 2017 22:58:14 -0400
Message-ID: <CACgrgBbyuCQsWyKUvJg-dbHbQ58TO8nHsJ4eKApLmHU1S8BEUg@mail.gmail.com>
To: Georg Mayer <georg.mayer.huawei@gmx.com>
Cc: ECRIT <ecrit@ietf.org>, Ben Campbell <ben@nostrum.com>, Adam Roach <adam@nostrum.com>, Brian Rosen <br@salsgiver.com>
Content-Type: multipart/alternative; boundary="001a113cebb4741de9054be9de17"
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/mBab77_p3WkvhCmVHKk9dYqeMt8>
Subject: Re: [Ecrit] Country-Specific Emergency Service sub-type
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, 30 Mar 2017 03:12:13 -0000

Sorry I missed the discussion. I second the notion that we need data, i.e.,
is there a real problem?

Note that having the same service have different names in different
countries is not a problem - it's a feature, since the URNs are never
exposed to users. Routing is done by location, so it should generally be
clear what service is needed. It's obviously possible that certain services
exist in only one country (maybe Huldufolk reporting in Iceland?).

We do need the discovery mechanisms described in the ECRIT architecture so
that tourists and others know what emergency services are available,
preferably in terms that are roughly translatable into their UI language.
But that's a separate problem (but one I hope 3GPP is addressing in its
discussions.)

Country-specific names make it much harder to build internationalized user
interfaces, in addition to the other problems discussed below.

I look forward to seeing the tentative list of emergency services so that
we have something specific to discuss.

Henning

On Wed, Mar 29, 2017 at 4:30 PM, Georg Mayer <georg.mayer.huawei@gmx.com>
wrote:

> Hello Ecrit experts,
>
> here are the notes and once more the slides from the discussions on
> country-specific emergency service sub-type which we had during the
> IETF/3GPP coordination meeting this week.
>
> Cheers,
> Georg
>
>
>
> Participants:
> - Ben Campell
> - Adam Roach
> - Robert Sparks
> - Roger Marshall
> - Georg Mayer
> - Andrew Allen
> - Roland Jesske
> - Wu-Chi Feng
> - Danny Moses
> - ...
>
> Georg: presented slides
>
> Ben/Adam:
> The proposal circumvents the registration policy of emergency services,
> which mandates new emergency services to undergo expert reviewed.
>
> The registry and the registration policy were established by IETF
> consensus.
>
> In order to change the process in a way that something like the
> suggested sub-type could be done, a change proposal would need to go
> through IETF last call. The community needs to have consensus to change
> the process.
>
> Ben:
> Current process allows for country specific registrations, but only in a
> way as e.g. "xy-specific-service", where "xy" would indicate the
> country. So all country specific services would in fact be top-level
> emergency services and would need to go through the IANA experts review
> process.
>
> Adam:
> Country specific registrations are not the best approach. The idea was
> an abstraction level, independent of the country.
>
> Andrew:
> but even the same service could have different meaning in different
> countries (counsel, animal control)
>
> Christer:
> How can we flexibly assign temporary URNs, e.g. flood, avalanche
>
> Georg:
> There needs to be (country specific) flexibility to allow for assignment
> of emergency services provided by currently deployed (CS-based) PSAPs.
>
> Adam:
> The current registration process is not complicated and quite open. It
> is also fast (new registrations should go through in approximately one
> week).
>
> The emergency-services should not indicate numbers, but the service itself.
>
>
> Ben/Adam/Robert:
> There are practically three ways to approach this.
>
> 1) Change the registration process
> 3GPP comes up with an internet draft that shows that the current
> registration of emergency service types is not flexible enough. The
> draft could suggest that the expert review is not needed anymore. Such
> draft would need to result in a standards track RFC.
>
> 2) Create an exception of the registration process
> 3GPP comes up with an internet draft that shows that for
> country-specific emergency services a different registration policy
> (without expert review) would be needed. Such draft would as well need
> to result in a standards track RFC.
>
> 3) Use the process
> Collect a list of country-specific services (per country) and send them
> via one of the ADs for IANA registration. The list doesn't need to be
> exhaustive, but as complete as possible.
>
>
> Open Question to 3GPP:
> If the country-specific sub-type would be granted, how and where would
> the country specific sub-types be registered? Who would take care of the
> related registry/registries? Would that be 3GPP? If yes, how would the
> registration of sub-types work?
>
>
> Next steps:
> 3GPP should discuss this input and see if the proposed ways forward are
> feasible or if more input is needed. Future discussions should, if
> possible, take place on the ECRIT mailing list.
>
>
>
>
> --
> Georg Mayer
> 3GPP CT Chairman
> HUAWEI Technologies
> Mobile: +43 699 1900 5758
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>