Re: [Ecrit] I-D Action: draft-rosen-ecrit-service-urn-subregistries-00.txt

Brian Rosen <br@brianrosen.net> Fri, 23 December 2016 21:28 UTC

Return-Path: <br@brianrosen.net>
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 2815C129557 for <ecrit@ietfa.amsl.com>; Fri, 23 Dec 2016 13:28:04 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
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 GNZyxMU_Fw7U for <ecrit@ietfa.amsl.com>; Fri, 23 Dec 2016 13:28:02 -0800 (PST)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A8412956F for <ecrit@ietf.org>; Fri, 23 Dec 2016 13:27:56 -0800 (PST)
Received: by mail-io0-x229.google.com with SMTP id n85so28439743ioi.2 for <ecrit@ietf.org>; Fri, 23 Dec 2016 13:27:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=RYpsct0y5DXY5MckcwreQjHNgox6M9P55rn5lTUZ7dE=; b=18N/wfetzfW0XX0NdTuUHY3SYZdTO7K7j75J5LRP0DjeBC5Nzb1Lg9uoFHiykqkAO7 bVXWOGrq9zlYpLCW7/7ejjGdZL9lRyPazIOGgzOIQA3hk7VlXRlS1O7WkIlPxMOI22EK TWjt5NVsClwi5Zc0bksfjmlONXlpEWLVuisICnIYr7eDvDx43zJrCFXj6PcAq5pw1KHN 5IXQX+MjlK4rdycbteFo2X3D/vnl3BASwt6GAm08MLmNur/fQ7sFDUHIi7vNLlxlty83 Vd+VACBVXOwRwnx6oGvPvbvhq0+a7yE6wItm4EVqlcp9Pr8Bpd93LFGUqZypzqSM6kBv q48g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=RYpsct0y5DXY5MckcwreQjHNgox6M9P55rn5lTUZ7dE=; b=KNsN0BEoocLKpmzmhkw7gf6gqcznmOxUhxLSLbgk0TSSFCPjRjVBp8l2Fzu46QHOvT jHTf7oGw1t3zX9oOVsfS7FDT6euzWN8/eFlPI2V7MmVS9dnvLyDlem4nx65DjBJGEgqF m0xwPP4zZglocaHxxx0txx7Z8wWQEYyx/4DhQ+smqMmbxBJSLzHJbnQKxFLO3MYOCr07 M9wMxr8LoYLI5Y73gimMe17kPD45Ihji5sDppt0aFmUDdLSBsv0op3LZMBZz4RikYphu Z/UB6rIui3ljUDtQTgJLhVsK1B/y7+33fBGY2WgJfK90doleSEDriTCpsBQ9+7Zhq6QQ tSwg==
X-Gm-Message-State: AIkVDXLFChm5Pf1UoBhcuWF+OoyBvQI+giIFIw3nK5WmXywBtTu3ubko/iZN5CzcNz1N9A==
X-Received: by 10.107.141.211 with SMTP id p202mr14241053iod.47.1482528475455; Fri, 23 Dec 2016 13:27:55 -0800 (PST)
Received: from [10.96.8.253] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id j125sm743940ioe.23.2016.12.23.13.27.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 23 Dec 2016 13:27:54 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6C38E792-FF8E-4AB4-B9D3-466F8C1B8717"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <AM5PR0701MB24685E7A47D3EC32A3D8C451E5950@AM5PR0701MB2468.eurprd07.prod.outlook.com>
Date: Fri, 23 Dec 2016 16:27:51 -0500
Message-Id: <A8B8C537-1B0A-4B1E-A191-30F2E25CB74E@brianrosen.net>
References: <148192031155.14691.15926529065829067237.idtracker@ietfa.amsl.com> <80337302-56F1-4A10-A531-14C09A499B6B@brianrosen.net> <AM5PR0701MB2468356AEB66DF2D791718E7E5900@AM5PR0701MB2468.eurprd07.prod.outlook.com> <BF57D33D-CCBF-4F9D-B131-4BEF1AC2F508@brianrosen.net> <AM5PR0701MB24681C78CFD6E6332E1CC889E5900@AM5PR0701MB2468.eurprd07.prod.outlook.com> <3F1B2A2C-97DB-4E07-9913-A50438A859FB@brianrosen.net> <AM5PR0701MB24681A713CD739498C17C8C7E5930@AM5PR0701MB2468.eurprd07.prod.outlook.com> <2055C2AF-C910-44BE-81FC-CA06FE1E0E2C@brianrosen.net> <AM5PR0701MB24687FDB1AEE0DF0F772B0FEE5920@AM5PR0701MB2468.eurprd07.prod.outlook.com> <7292B4B6-D187-4703-8F4B-F69DC3292330@brianrosen.net> <AM5PR0701MB24685E7A47D3EC32A3D8C451E5950@AM5PR0701MB2468.eurprd07.prod.outlook.com>
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/4Ap5JupPcl2BiA9kQO0-2McNUk0>
Cc: ECRIT <ecrit@ietf.org>
Subject: Re: [Ecrit] I-D Action: draft-rosen-ecrit-service-urn-subregistries-00.txt
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: Fri, 23 Dec 2016 21:28:04 -0000

You’re understanding is correct, although in theory, the sub registry could have a different management policy than the sos registry.  For sos.police, sos.fire, and sos.ambulance, the policy is expert review, the same as sos.

Brian

> On Dec 23, 2016, at 4:15 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:
> 
> Hello,
>  
> > At least in my experience, the changes in the network take a lot of time to plan and implement.
>  
> When all required emergency URNs are specified, then providing emergency services in a 3GPP specified SIP network requires solely enhancements of the operator's network as:
> - any SIP user agent in a 3GPP mobile phone supporting non-emergency voice service over a 3GPP specified SIP network is already required to support also the emergency voice service over the 3GPP specified SIP network; and
> - PSAPs do not need to be changed - if a PSAP is connected to public switched telephony network (PSTN) only, then a node in the operator's SIP network interworks the emergency SIP call to an PSTN call towards PSAP.
>  
> So, when all required emergency URNs are specified, including an emergency URN for any emergency service *already available via public switched telephony network* in the country of the SIP based network, then it is just matter of decision of the operator.
>  
> And the operator needs to make that decision at a moment when, in *a location*, a 3GPP specified SIP based network is available while 3GPP specified circuit switched networks is not available. That can happen soon.
>  
> So, stating it in a different way, if a country defines an emergency service *already available via public switched telephony network* for which an emergency URN is not specified, then the operator is forced to keep 3GPP specified circuit switched network in any location where 3GPP specified SIP based network is available (and that's costly and inefficient use of precious radio resources).
>  
> That's why getting emergency URNs for any any emergency service *already available via public switched telephony network* needs to be reasonably quick.
>  
> > The expert merely authorizes an entry in the sos registry for a service with a period in it.  When the document creating a sub-registry is published,
> > that entry is removed from the sos registry, and included in the sub registry.  The net effect is no change, the service is exactly the same.
>  
> Let me try to reformulate the above to check if I understood correctly. To me, the above suggests:
> - the sub-registries are solely a way of organizing and showing the emergency URNs at IANA pages.
> - the sub-registries do not state any restrictions on registration of new emergency URNs (and do not make it any easier either). I.e. rfc7163 applies no matter whether IANA keeps a sub-registry or not.
>  
> If that's correct understanding and assuming the draft explicitly state so, I would be OK with it.
>  
> If it is incorrect understanding, can you please explain?
>  
> > I asked IANA to change “federal” to “national”, but it hasn’t happened yet.
>  
> Thanks.
>  
> Kind regards
>  
> Ivo