Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
Janet P Gunn <jgunn6@csc.com> Thu, 20 November 2008 16:37 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 249E43A68BE; Thu, 20 Nov 2008 08:37:31 -0800 (PST)
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 93D4C28C1CD for <ecrit@core3.amsl.com>; Thu, 20 Nov 2008 08:37:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.598
X-Spam-Level:
X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.000, 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 0RyHC5BHThso for <ecrit@core3.amsl.com>; Thu, 20 Nov 2008 08:37:27 -0800 (PST)
Received: from mail87.messagelabs.com (mail87.messagelabs.com [216.82.250.19]) by core3.amsl.com (Postfix) with ESMTP id 64C683A67FA for <Ecrit@ietf.org>; Thu, 20 Nov 2008 08:37:27 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-2.tower-87.messagelabs.com!1227199043!41863287!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [20.137.2.87]
Received: (qmail 3614 invoked from network); 20 Nov 2008 16:37:23 -0000
Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-2.tower-87.messagelabs.com with AES256-SHA encrypted SMTP; 20 Nov 2008 16:37:23 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.0) with ESMTP id mAKGbMoH022229 for <Ecrit@ietf.org>; Thu, 20 Nov 2008 11:37:22 -0500
In-Reply-To: <015301c94b2b$60155ee0$20401ca0$@net>
To: Brian Rosen <br@brianrosen.net>
MIME-Version: 1.0
X-Mailer: Lotus Notes 652HF83 November 04, 2004
From: Janet P Gunn <jgunn6@csc.com>
Message-ID: <OFCDA82F52.1CB83B62-ON85257507.005AA5D9-85257507.005B4E0E@csc.com>
Date: Thu, 20 Nov 2008 11:37:15 -0500
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF427|August 01, 2008) at 11/20/2008 11:39:53 AM, Serialize complete at 11/20/2008 11:39:53 AM
Cc: Ecrit@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="===============1998818205=="
Sender: ecrit-bounces@ietf.org
Errors-To: ecrit-bounces@ietf.org
Brian, I need to understand this better. Exactly what are the constraints of the "emergency services IP network"? Is this a network in which EVERY call would have the RPH with the esnet namespace (just varying priority values),and there would be no "normal" calls? Or would their be a mixture of calls with and without RPH wit esnet? Janet "Brian Rosen" <br@brianrosen.net> wrote on 11/20/2008 11:16:39 AM: > A suggestion was made to me that we should define two namespaces. > > One would be used in public networks, and generally would be used to request > resource priority for citizen to authority and possibly authority to citizen > calls. This would have lower priority than ETS/WPS. > > The other would be for use within emergency services IP networks. It would > be unlikely that ETS/WPS would be used within those networks, but if it was, > some values within the namespace would need higher priority that ETS/WPS. > For example, a message which was an incident commanders “evacuate” message > would be higher than a ETS/WPS traffic. On the other hand, a citizen to > authority emergency call would have lower priority. > > I would be happier with one namespace and more values in that namespace for > all of this, but I was advised that two namespaces was a better choice. > > Brian > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Janet P Gunn > Sent: Thursday, November 20, 2008 11:00 AM > To: GOLDMAN, STUART O (STUART) > Cc: Ecrit@ietf.org > Subject: Re: [Ecrit] Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > Stu, > > I intended to say that the esnet namespace needs to be at a LOWER priority > than the ets and wps namespaces, in any network that recognizes ets and wps > as described in 10.5 and 10.6 of RFC4412. > > Janet > > "GOLDMAN, STUART O \(STUART\)" <sgoldman@alcatel-lucent.com> wrote on > 11/20/2008 10:22:49 AM: > > > Janet, > > > > With regard to you e-mail below, did you intend that esnet could be > > at the same level of priority as ETS & WPS, or that ETS & WPS need > > to be at an even higher priority than esnet? > > > > > > > > Stuart Goldman > > Alcatel-Lucent > > Stuart.Goldman@alcatel-lucent.com > > +1 602 493 8438 > > +1 480 414 1260 mobile > > P please save a tree by not printing this e-mail. > > > > > > > > > > Janet P Gunn/FED/CSC@CSC > > Sent by: ecrit-bounces@ietf.org > > 10/27/2008 11:45 PM > > > > > > > > To > > > > "James M. Polk" <jmpolk@cisco.com> > > > > cc > > > > "'ECRIT'" <ecrit@ietf.org>, ecrit-bounces@ietf.org > > > > Subject > > > > Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > Stuart Goldman > > Alcatel-Lucent > > Stuart.Goldman@alcatel-lucent.com > > +1 602 493 8438 > > +1 480 414 1260 mobile > > P please save a tree by not printing this e-mail. > > > > > > >
_______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit
- Re: [Ecrit] Ecrit] draft-ietf-ecrit-local-emergen… GOLDMAN, STUART O (STUART)
- Re: [Ecrit] Ecrit] draft-ietf-ecrit-local-emergen… Janet P Gunn
- Re: [Ecrit] Ecrit] draft-ietf-ecrit-local-emergen… Brian Rosen
- Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-… Janet P Gunn
- Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-… Brian Rosen
- Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-… Roger Marshall
- Re: [Ecrit] Ecrit] draft-ietf-ecrit-local-emergen… James M. Polk
- Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-… James M. Polk
- Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-… Janet P Gunn
- Re: [Ecrit] Ecrit] draft-ietf-ecrit-local-emergen… DRAGE, Keith (Keith)
- Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-… James M. Polk
- Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-… Janet P Gunn
- Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-… James M. Polk