Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
Janet P Gunn <jgunn6@csc.com> Tue, 28 October 2008 03:46 UTC
Return-Path: <ecrit-bounces@ietf.org>
X-Original-To: ecrit-archive@megatron.ietf.org
Delivered-To: ietfarch-ecrit-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69F8328C261; Mon, 27 Oct 2008 20:46:14 -0700 (PDT)
X-Original-To: ecrit@core3.amsl.com
Delivered-To: ecrit@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E9E3A688A; Mon, 27 Oct 2008 20:46:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqUezfbGZN9M; Mon, 27 Oct 2008 20:46:07 -0700 (PDT)
Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by core3.amsl.com (Postfix) with ESMTP id 7B2B03A6A86; Mon, 27 Oct 2008 20:46:00 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-5.tower-171.messagelabs.com!1225165557!19482176!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [20.137.2.88]
Received: (qmail 9071 invoked from network); 28 Oct 2008 03:45:58 -0000
Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-5.tower-171.messagelabs.com with AES256-SHA encrypted SMTP; 28 Oct 2008 03:45:58 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id m9S3jvWk016291; Mon, 27 Oct 2008 23:45:57 -0400
In-Reply-To: <XFE-RTP-202i89QtpfT000001f7@xfe-rtp-202.amer.cisco.com>
To: "James M. Polk" <jmpolk@cisco.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn <jgunn6@csc.com>
Message-ID: <OF2EA0E393.832AFED1-ON852574F0.001137FF-852574F0.0014AB67@csc.com>
Date: Mon, 27 Oct 2008 23:45:43 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 10/27/2008 11:48:32 PM, Serialize complete at 10/27/2008 11:48:32 PM
Cc: 'ECRIT' <ecrit@ietf.org>, ecrit-bounces@ietf.org
Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/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>
Content-Type: multipart/mixed; boundary="===============1024826478=="
Sender: ecrit-bounces@ietf.org
Errors-To: ecrit-bounces@ietf.org
I apologize for not tracking this as closely as I meant to, as these comments apply to earlier versions as well. This sentence at the end of sec 1 doesn't quite work. "This document IANA registers the "esnet" RPH namespace for use within emergency services networks, not just of those from citizens to PSAPs." (no clear antecedent for "those") Perhaps "This document IANA registers the "esnet" RPH namespace for use within emergency services networks, not just for calls or sessions from citizens to PSAPs." Section 2 says "This document updates the behaviors of the SIP Resource Priority header, defined in [RFC4412], during the treatment options surrounding this new "esnet" namespace only. The usage of the "esnet" namespace does not have a normal, or routine call level. Every use of this namespace will be in times of an emergency, where at least one end of the signaling is with a local emergency organization." I don't see this as an "update of the behavior of 4412". Neither the ets namespace not the wps namespace have a "normal" or "routine" call level. Every use of the wps and ets namespaces will have priority over calls without RPH. You say "This namespace, therefore, MAY be overwritten or deleted, contrary to the rules of RFC 4412 [RFC4412]." It is not clear to me why this is "contrary to the rules of 4412". It is certainly anticipated that other RPH will be overwritten or deleted, when the UAS understands the namespace. 4412 says "Existing implementations of RFC 3261 that do not participate in the resource priority mechanism follow the normal rules of RFC 3261, Section 8.2.2: "If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message". " But I do not see anywhere that is says that a UAS that DOES understand the namespace is forbidden from deleting it. For instance, sec 4.7.1 of 4412 says that "the UAC MAY attempt a subsequent request with the same or different resource value." This certainly implies the ability to overwrite or delete an RPH namespace. (See also, for instance the PTSC SAC document on the use of the ets and wps namespaces) Immediately following these statements, you give 3 options- "These proxies in the service provider MAY either o accept the existing RPH value with "esnet" in it, if one is present, and grant relative preferential treatment to the request when forwarding it to the ESINet. o replace any existing RPH value, if one is present, and insert an "esnet" namespace and give relative preferential treatment to the request when forwarding it to the ESINet. o insert an "esnet" namespace in a new RPH and give relative preferential treatment to the request when forwarding the SIP request towards the ESINet." Why do you exclude the possibility of adding the esnet RPH value without "replacing" an existing RPH value? Finally, there is another point that needs to be made clear. At least one person has contacted me expressing concern that this ID implied that the esnet namespace would have priority over other namespaces (in particular wps and ets). I assured him that this was not the case, that there was nothing prevent the expected behavior - that the ets and wps namespaces would be prioritized ahead of esnet in GETS Service Provider networks. However, since the question has already arisen, it would be a good idea to clarify this, perhaps in section 3, where you discuss the other namespaces. In particular, it needs to be made clear in section 3.2 that, even if "the local jurisdiction preferred to preempt normal calls in lieu of completing emergency calls. ", esnet calls will NOT preempt wps or ets calls. By the way, I think you mean "the local jurisdiction preferred to preempt normal calls in order to complete emergency calls. " - not "in lieu of". Or perhaps "the local jurisdiction preferred to preempt normal calls in lieu of dropping emergency calls. " In fact, it is not clear to me that 4412 permits a call with an RPH (e.g., esnet) to preempt a "normal" call (with no RPH namespace). Section 4.7.2.1 of 4412 says "4.7.2.1. User Agent Servers and Preemption Algorithm A UAS compliant with this specification MUST terminate a session established with a valid namespace and lower-priority value in favor of a new session set up with a valid namespace and higher relative priority value, unless local policy has some form of call-waiting capability enabled. " It doesn't say anything about preempting a call with no RPH Thanks Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. "James M. Polk" <jmpolk@cisco.com> Sent by: ecrit-bounces@ietf.org 10/27/2008 08:32 PM To "'ECRIT'" <ecrit@ietf.org> cc Subject [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 ECRIT WG Here is a update to a ID I think is pretty near done, given that this is merely an IANA registration ID of an existing mechanism. Comments are wanted >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Emergency Context Resolution with >Internet Technologies Working Group of the IETF. > > > Title : IANA Registering a SIP Resource Priority > Header Namespace for Local Emergency Communications > Author(s) : J. Polk > Filename : > draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > Pages : 9 > Date : 2008-10-27 > >This document creates and IANA registers the new Session Initiation >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for >local emergency usage to a public safety answering point (PSAP), >between PSAPs, and between a PSAP and first responders and their >organizations. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > > > >< ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-00.txt > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit
- [Ecrit] draft-ietf-ecrit-local-emergency-rph-name… James M. Polk
- Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-… Janet P Gunn
- [Ecrit] earlier comments Re: draft-ietf-ecrit-loc… Janet P Gunn
- Re: [Ecrit] earlier comments Re: draft-ietf-ecrit… James M. Polk