Re: [Ecrit] Expert Reviewer's response to request to register 'country-specific' in 'sos' Subservice Registry in the Service URN Labels group

Brian Rosen <br@salsgiver.com> Wed, 16 November 2016 01:25 UTC

Return-Path: <br@salsgiver.com>
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 E7032129431 for <ecrit@ietfa.amsl.com>; Tue, 15 Nov 2016 17:25:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level:
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-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 2_2pgRxZrWsj for <ecrit@ietfa.amsl.com>; Tue, 15 Nov 2016 17:25:11 -0800 (PST)
Received: from email.salsgiver.com (email.salsgiver.com [206.67.234.106]) (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 EA869129405 for <ecrit@ietf.org>; Tue, 15 Nov 2016 17:25:10 -0800 (PST)
Received: from [10.96.8.226] ([156.154.81.54]) (authenticated bits=0) by email.salsgiver.com (8.15.2/8.15.2) with ESMTPA id uAG1P0GF014584; Tue, 15 Nov 2016 20:25:07 -0500 (EST) (envelope-from br@salsgiver.com)
X-Authentication-Warning: email.salsgiver.com: Host [156.154.81.54] claimed to be [10.96.8.226]
Content-Type: multipart/alternative; boundary="Apple-Mail=_B1C241B2-B799-4BAF-8C20-C10BB5C02ED8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Brian Rosen <br@salsgiver.com>
In-Reply-To: <8e9f6d731099499ca529eecb8236f4ce@HE105828.emea1.cds.t-internal.com>
Date: Wed, 16 Nov 2016 10:25:00 +0900
Message-Id: <C1E7834C-C326-4458-A399-6C4F72356FC3@salsgiver.com>
References: <CAJD5LR00UgK2u-T8soQmSJ0QryoOio6Ezjn3FTf4KonBidcWjA@mail.gmail.com> <6337FF74-A230-42C9-989A-AA7A9EC07277@salsgiver.com> <8e9f6d731099499ca529eecb8236f4ce@HE105828.emea1.cds.t-internal.com>
To: R.Jesske@telekom.de
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/plPa0O95omarEK2yS7tCJbeLQTY>
Cc: ECRIT <ecrit@ietf.org>
Subject: Re: [Ecrit] Expert Reviewer's response to request to register 'country-specific' in 'sos' Subservice Registry in the Service URN Labels group
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 16 Nov 2016 01:25:14 -0000

<leaving off IANA for now>
The URN is an address for routing, and not a user visible label. Creating new entries is simple and fast.  So we request that new entries be created for different services.

One simple approach is to create a “municipalPolice” urn, and use urn:service:sos.municipal.police for 986 and urn:service:sos.police for 997 in Poland.

Then any country that uses municipal police can use the same URN.

Actually, the problem of multiple police forces occurred in NENA, the North American emergency services group.  For internal routing purposes, we created a urn:nena::responder.police entry with sub registry for the various types of police.  I would be very willing to do the work to create a similar sub registry for urn:service:sos.police, which would allow urn:service:sos.police.municipal because many countries have multiple police forces that can be reached at different emergency numbers.  The sub registry could have “state”, “provincial”, “federal”, and other entries.

I also note that the registration says “This sub-service type is used before an appropriate sub-service type is registered with IANA for a specific emergency service.”  Emphasis added.  This explicitly says that this use is temporary and will be replaced with a “real” registration at some time.  Since registration is easy and fast, there is no need for a temporary work around to actual registration.

Brian

> On Nov 16, 2016, at 10:07 AM, R.Jesske@telekom.de wrote:
> 
> Hi Brian,
> the aimed registration is for 3GPP networks only and not to be intended to be used everywhere.
>  
> So from my understanding there are a many of existing specific emergency services out in the world which need the equivalent within the 3GPP IMS world.
>  
> An example is Poland:
> Please see http://uke.gov.pl/tablice-numerow-kierowania-alarmowego-nka-9410 <http://uke.gov.pl/tablice-numerow-kierowania-alarmowego-nka-9410> which lists the number 986 for "straż miejska" (= municipal police) and the number 997 for Policja (= police) as "numery alarmowe" (= emergency numbers).
> Which cannot use the normal sos urn.
>  
> 3GPP had the requirement to specify this for the 3GPP IMS world. And the easiest way was to have such an mechanism.
> Since this is only used for the 3GPP IMS world, 3GPP would like to have a mechanism to allow these  specific suptypes.
>  
> So what could be done to get such an solution where IETF can agree upon?
>  
> Best Regards
>  
> Roland
>  
> Von: Ecrit [mailto:ecrit-bounces@ietf.org <mailto:ecrit-bounces@ietf.org>] Im Auftrag von Brian Rosen
> Gesendet: Donnerstag, 10. November 2016 15:54
> An: iana@iana.org <mailto:iana@iana.org>
> Cc: ECRIT
> Betreff: [Ecrit] Expert Reviewer's response to request to register 'country-specific' in 'sos' Subservice Registry in the Service URN Labels group
>  
> I am the expert reviewer designated by the ecrit working group for this request.
>  
> I believe this request is not consistent with the words and the intent of the registry.  “country-specific’ is not an emergency service.  Since the management policy of the emergency service is “expert review”, the barrier to adding new, possibly experimental services is low, and the consequences of having services that are not eventually deployed persisting in the registry is minimal.  The URN was not intended to have a generic X- service or equivalent, which is what this registration attempts to do.  New services, even experimental services, should register the service with IANA following the normal procedure.
>  
> Therefore, I recommend that we deny this request and suggest that the specific services be registered with IANA as they are deployed.  This decision has been reviewed with the ecrit working group.
>  
> Brian
>  
> On Nov 3, 2016, at 3:59 PM, Az Mankin <azmankin@gmail.com <mailto:azmankin@gmail.com>> wrote:
>  
> ECRIT Working Group,
> 
> We need a volunteer for the following IANA Expert Review request that Amanda Baber of IANA just sent to Roger and me.  It needs to be written and sent to the mailing list, per the IESG's appointment of the WG as the Expert Reviewer (http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels.xhtml <http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels.xhtml>).  Amanda's message is under the line. Who'd like to step up for this?
> 
> Thanks!  from your Chairs
> ----------------
>  
> 
> The IANA Services Operator has received a request for registration in the 'sos' Sub-Services registry in the Service URN Labels group. This request comes from Frederic Firmin of ETSI.
> 
> According to RFC 7163, registration in 'sos' Sub-Services requires expert review as designated by the ECRIT working group or its successor (or, in their absence, the IESG). Can you send this request for review?
> 
> The IESG has asked that expert reviews be completed within two weeks, if possible.
> 
> See below.
> 
> thanks,
> 
> Amanda Baber
> Lead IANA Services Specialist
> PTI
> 
> ===
> 
> Contact Name:
> Frederic Firmin
> 
> Contact Email:
> frederic.firmin@etsi.org <mailto:frederic.firmin@etsi.org>
> 
> Type of Assignment:
> sub-service URN
> 
> Registry:
> Service URN Labels registry with the "sos" URN Service Labels subregistry.
> 
> Description:
> This sub-service type is used before an appropriate sub-service type is registered with IANA for a specific emergency service. This sub-service type is not used where an appropriate sub-service type has been registered with IANA for the specific emergency service.
> The next level of sub-services indicates the country where the specific emergency service is used. Subtypes below this are defined by national regulation of that country and are not registered with IANA.
> 
> 
> Additional Info:
> The following service URN is proposed to be registered:
> urn:service:sos.country-specific
> 
> reference: 24.229 12.14.0 available at http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-ce0.zip <http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-ce0.zip> (cf subclause 7.11.1)
> 
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org <mailto:Ecrit@ietf.org>
> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>
>  
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org <mailto:Ecrit@ietf.org>
> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>