Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00
"James M. Polk" <jmpolk@cisco.com> Thu, 20 November 2008 23:29 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 5503D3A6939; Thu, 20 Nov 2008 15:29:29 -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 51B173A6939 for <ecrit@core3.amsl.com>; Thu, 20 Nov 2008 15:29:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.559
X-Spam-Level:
X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, 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 zuCiERis3AtA for <ecrit@core3.amsl.com>; Thu, 20 Nov 2008 15:29:26 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C03AA3A6907 for <Ecrit@ietf.org>; Thu, 20 Nov 2008 15:29:25 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="28571337"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Nov 2008 23:29:24 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAKNTOHO003596; Thu, 20 Nov 2008 18:29:24 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAKNTOrM011217; Thu, 20 Nov 2008 23:29:24 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 18:29:24 -0500
Received: from jmpolk-wxp01.cisco.com ([10.82.218.221]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 18:29:23 -0500
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 20 Nov 2008 17:29:22 -0600
To: Janet P Gunn <jgunn6@csc.com>
From: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <OF3F6F10EF.707FA4AD-ON85257507.007F284F-85257507.007F4A9B@ csc.com>
References: <XFE-RTP-2028QVjp3b600001605@xfe-rtp-202.amer.cisco.com> <OF3F6F10EF.707FA4AD-ON85257507.007F284F-85257507.007F4A9B@csc.com>
Mime-Version: 1.0
Message-ID: <XFE-RTP-201EAOeIiGX000015b9@xfe-rtp-201.amer.cisco.com>
X-OriginalArrivalTime: 20 Nov 2008 23:29:23.0614 (UTC) FILETIME=[D2253BE0:01C94B67]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=22549; t=1227223764; x=1228087764; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20<jmpolk@cisco.com> |Subject:=20Re=3A=20[Ecrit]=20draft-ietf-ecrit-local-emerge ncy-rph-namespace-00 |Sender:=20 |To:=20Janet=20P=20Gunn=20<jgunn6@csc.com>; bh=eOpK6UUPQo2FAUmgDXsaWfjdjewbgcaRUHa63IeV4w0=; b=o0oV6imx6ibhskCg3TOjxVU6ibjfCGwOnvNs4RNp9WViSg+yqNMCh6ZeMW 7mdP2A+3EeChR5OLOORbmhMwQIF65ZP02dGW+KIYgRfvseALXXceBBYaKpya MjvB+bcRTT;
Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ecrit-bounces@ietf.org
Errors-To: ecrit-bounces@ietf.org
At 05:10 PM 11/20/2008, Janet P Gunn wrote: >Agree. >Just needs to be made clearer that "there is no guidance in this doc >to be given on local policy" it already does this - but I can look (seriously) at making is clearer >Janet > >"James M. Polk" <jmpolk@cisco.com> wrote on 11/20/2008 05:59:32 PM: > > > At 03:03 PM 11/20/2008, Janet P Gunn wrote: > > > > > > >"James M. Polk" <jmpolk@cisco.com> wrote on 11/20/2008 03:46:30 PM: > > > > > > > > > > > > > > Just to be clear, this discussion is NOT something my namespace ID > > > > should ever address. I have no issues with having this discussion - > > > > but I want to make clear that > > > > draft-ietf-ecrit-local-emergency-rph-namespace will NEVER make > > > > priority decisions or even recommendations in the text of the doc. > > > > > > > > This ID only creates the namespace *and* the probably scenario in > > > > which it is intended. > > > > > > >Agree > > > > > > > > >Public net: > > > > >P1. ets/wps? (PSAPs may not be so eager to agree) > > > > >P2. esnet > > > > >P3. <other/null> > > > > > > > > it's not as simple as that. > > > > > > > > each <namsepace.priority-value> gets its own slot in any relative > > > > priority order (per section 8 of RFC4412). > > > > > > > > With this in mind, it is *possible* to have a relative priority > > > > order like this > > > > > > > > P1. ets.4 > > > > P2. esnet.4 > > > > P3. ets.3 wps.4 > > > > P4. esnet.3 esnet.2 > > > > P5. wps.3 ets.2 > > > > P6. wps.2 ets.1 > > > > P7. esnet.1 > > > > P8. esnet.0 > > > > P9. ets.0 wps.0 > > > > > > > > notice that within each <namespace>, the numbering order is > > > > consistent, but that the order relative to the different namespaces > > > > is whatever the local operator wants to make them. > > > > > >At the risk of being a nitnoid, this would NOT be an RFC4412-legal > > >ordering,as it reverses the priority values of ets and wps (0 is > > the highest). > > > > shoot me for not remembering off the top of my pointy head the order > > of ets and wps > > > > ;-) > > > > the concept still holds though > > > > > > > > > I do show here > > > > that at each priority level (e.g., P3, P4, P5, P6 and P9) that there > > > > are more than one namespace.priority-value combination. This means, > > > > within this priority - it's a FIFO situation in which each of the > > > > namespace.priority-value combinations at this priority level compete > > > > (i.e., they are equivalent in priority). This is all a local decision. > > > > > > > > I think a way to address Brian's comment about preemption is also a > > > > local decision (because the local jurisdiction needs to live with the > > > > consequences). Here's how that can be addressed: > > > > > > > > - all these namespace.priority-value combinations *can* be preempted > > > > > >I have serious heartburn with this statement. > > > > this is a comment that is NOT tied to this ID, because there is no > > guidance in this doc to be given on local policy other that the > > concept of relative priority, just to be clear > > > > > > >In the circuit switched paradigm of preemption (MLPP and eMLPP), > > >only calls that are identified a-priori as "part of a preemption > > >domain (or similar term)" can be preempted. "Normal" (unmarked, as > > >opposed to marked "routine") calls cannot be preempted. I REALLY > > >don't think we should break that aspect of the paradigm without > > >investigating "unintended consequences" in great detail. > > > > > > > - only certain namespace.priority-value combinations *can* preempt > > > > another call. > > > > > > > > just a thought about how to solve this... > > > > > > > > James > > > > > > > > > > > > >Private net (ESInet): > > > > >(anything they want) > > > > > > > > > >Lastly, what kind of prioritization does a government official (a > > > > >servant of the people) get when they themselves initiate an emergency > > > > >call? esnet or ets/wps? (In a private ESInet, it may be to their > > > > >disadvantage to keep the wrong one.) > > > > > > > > > >-roger marshall. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > > > > > On Behalf Of Brian Rosen > > > > > > Sent: Thursday, November 20, 2008 9:01 AM > > > > > > To: 'Janet P Gunn' > > > > > > Cc: Ecrit@ietf.org > > > > > > Subject: Re: [Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > An "Emergency Services IP Network" is a private IP network to > > > > > > which, we hope, all public safety agencies are connected. It > > > > > > handles all the traffic of a public safety agency, which > > > > > > would include routine and priority citizen to authority, > > > > > > authority to authority and authority to citizen traffic. > > > > > > It's not entirely clear to me yet whether we can reuse a > > > > > > number of the existing name spaces as well as a new one. For > > > > > > example, some of the agency-agency traffic will require > > > > > > pre-emption, but the existing MLPP namespace may be quite > sufficient. > > > > > > > > > > > > It does occur to me that we could have ETS and possibly WPS > > > > > > traffic, in that if the normal access to public facilities > > > > > > traversed the ESInet towards some kind of gateway to a public > > > > > > network, then we would either have to have the ETS/WPS > > > > > > values, or remark them at the edge if a caller inside the > > > > > > ESInet needed to call someone outside the ESInet and needed > > > > > > ETS/WPS priority to do so. If we carried the priority > > > > > > marking across the ESInet, ETS/WPS would be lower priority > > > > > > than some other traffic, but higher than, for example, > > > > > > citizen to authority emergency calls. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > From: Janet P Gunn [mailto:jgunn6@csc.com] > > > > > > Sent: Thursday, November 20, 2008 11:37 AM > > > > > > To: Brian Rosen > > > > > > Cc: Ecrit@ietf.org; 'GOLDMAN, STUART O (STUART)' > > > > > > Subject: RE: [Ecrit] > draft-ietf-ecrit-local-emergency-rph-namespace-00 > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > >CONFIDENTIALITY NOTICE: The information contained in this message > > > > >may be privileged and/or confidential. If you are not the intended > > > > >recipient, or responsible for delivering this message to the > > > > >intended recipient, any review, forwarding, dissemination, > > > > >distribution or copying of this communication or any attachment(s) > > > > >is strictly prohibited. If you have received this message in error, > > > > >please notify the sender immediately, and delete it and all > > > > >attachments from your computer and network. > > > > >_______________________________________________ > > > > >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
- 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