Re: [Ecrit] country specific emergency URNs

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Thu, 13 July 2017 05:52 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 249E213181E for <ecrit@ietfa.amsl.com>; Wed, 12 Jul 2017 22:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 hKqoaVJUtKJJ for <ecrit@ietfa.amsl.com>; Wed, 12 Jul 2017 22:52:02 -0700 (PDT)
Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (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 3A43213180F for <ecrit@ietf.org>; Wed, 12 Jul 2017 22:52:02 -0700 (PDT)
X-Halon-ID: 5fa88e7a-678f-11e7-b24e-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [85.238.220.142]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id 5fa88e7a-678f-11e7-b24e-005056917a89; Thu, 13 Jul 2017 07:51:54 +0200 (CEST)
To: Brian Rosen <br@brianrosen.net>, Christer Holmberg <christer.holmberg@ericsson.com>
References: <52809D5B0606C049903AD6AD07E033E10326EF8FFD@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> <ED1B93BE-A29D-46F5-8417-C8D56C9F83C5@brianrosen.net> <DB5PR07MB14809D599D828F1A5420CD34F7AF0@DB5PR07MB1480.eurprd07.prod.outlook.com> <1FFAF3E4-3FCF-43A9-8194-AA4B337FFFE2@brianrosen.net> <7594FB04B1934943A5C02806D1A2204B4CC600F4@ESESSMB109.ericsson.se> <3ABCE27C-CC6F-47AF-AD69-4AD38F3B55DE@brianrosen.net>
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <152fb73d-d0fc-994d-e473-21ecb3714077@omnitor.se>
Date: Thu, 13 Jul 2017 07:51:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <3ABCE27C-CC6F-47AF-AD69-4AD38F3B55DE@brianrosen.net>
Content-Type: multipart/alternative; boundary="------------AEF2C9AAA099141E5225E732"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/k2AxQXyUk3McXlj6JvnoSzdTdjc>
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 05:52:05 -0000

Den 2017-07-12 kl. 21:57, skrev Brian Rosen:
>> If that is true, we do we separate the sub-services to begin with? Why do we define sub-service specific registration procedures (even though they happen to be identical for the existing sub-services?
> Because we would like the name to be suggestive of the function so that provisioning and debugging is easier.  That really is why we did it that way.  Using a GUID would have worked.
>
>>   
>> RFC 5031 defines semantics for the sos sub-service, and at least my understanding is that sos is to be used for emergency services, and nothing else.
> There is no limit expressed, or implied, that sos is restricted to “flashing lights” emergencies.  It’s suggestive of emergency, but not exclusively used that way.  The counter example was the non-emergency ambulance service.  Using sos.ambulance for a non emergency ambulance service, unless a country has both an emergency and a non-emergency ambulance service that needs urns, is appropriate I think.  I don’t think it would be wrong to create a non-emergency ambulance registration, but I also don’t think we need to.
>
>> Where is it said that it is ok to use sos also for non-emergency services, and to use non-sos for emergency services?
> There is no MUST language at all.  Anything is acceptable, although the expert review gets to offer an opinion, and take it to the list if needed.  The review is merely supposed to make sure the service is distinct from an existing registration.  Registrations are cheap.
I agree with Christer that this reasoning would create a mess. There is 
must language in RFC 5031. The idea is that resources working with 
emergencies shall be able to handle them rapidly and efficiently without 
having them placed in queues merged with non-emergency calls.

RFC 5031 says about sos and the sub-services :
"The 'sos' service type describes emergency services requiring an
immediate response, typically offered by various branches of the 
government or other public institutions. Additional sub-services can be 
added after expert review and must be of general public interest and 
have a similar emergency nature."

I think that is clear enough to avoid using sos subservices for services 
not requiring an immediate response.

English might lack a simple word for the non-emergency ambulance 
service. In Swedish, we call it "sjuktransport"
  and the German word is "krankentransport". Maybe that is why you feel 
it would be hard to find a good term in English for the registration of 
the non-emergency ambulance service and got into the reasoning in this 
thread.

>
>>   
>> If we start using non-sos for emergency services, and sos for non-emergency services, I think we will end up in a mess…
> The above example is how I think we don’t get into a mess.  I don’t think there is a good reason to create an ambulance service that isn’t in the sos tree unless we have an incidence of two services and we need to differentiate.  Even if the ambulance service in a country is not considered an emergency service, using sos.ambulance for it is fine in my opinion.
>
>
>>   
>
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit