[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted

At 03:10 PM 2/24/2009, Janet P Gunn wrote:


James
Some of this is editorial, some is substantive and technical, and some repeats my comments on 00 that do not seem to have been addressed. 

2nd paragraph of section 1, this sentence doesn't make sense.
"   Within controlled environments, such as an IMS infrastructure or
   Emergency Services network (ESInet), where misuse can be reduced to
   a minimum where possible, this namespace is to be to provide an
   explicit priority indication facilitates treatment of emergency SIP
   messages according to local policy."


I think this makes perfect sense as written



Perhaps you mean
"   Within controlled environments, such as an IMS infrastructure or
   Emergency Services network (ESInet), where misuse can be reduced to
   a minimum, this namespace is expected to be used to provide an
   explicit priority indication, facilitating treatment of emergency SIP
messages according to local policy." But I am not sure if that is what you meant. 

that's another way of saying the same thing



Same para
"This indication is used to
   differentiate SIP requests, or dialogs, from other requests or
   dialogs that do not have the need for priority treatment."
sounds as if you are differentiating SIP requests form non-SIP requests. Perhaps what you mean is 
"This indication is used to
differentiate Emergency Services related SIP requests, or dialogs, from other (non Emergency 
Services related) SIP requests or  dialogs.


again -- this appears to be two ways of saying the same thing.



Note that "do not have the need for priority treatment" is not correct.
it applies to other traffic that does not need priority treatment. In other words, the traffic that doesn't need priority treatment -- because there will be some traffic that does not need priority treatment within the ESInet (as well as an esnet namespace capable VSP) 


The esnet RPH would
distinguish ES related messages from GETS related messages (ets and wps namespaces), but they 
would each get their own particular flavor of "priority treatment".


5th para of section 1

"From this fact about RFC 4412, and the possibility that within
   emergency services networks, a Multilevel Precedence and Preemption
   (MLPP)-like behavior can be achieved - ensuring more important calls
   are established or retained, the "esnet" namespace is given 5
   priority-levels."
What is "this fact"?  Perhaps "Because we can't add new values later..."


the fact is right above this sentence
I don't understand the "can be achieved". Do you mean "MLPP-like behavior may be desired"?
it can be, which is all that I'm offering -- but I'm not recommending or stipulating or demanding or anything else... I'm just saying that with more than 2 levels, a natural hierarchy _can_ be configured.
I fully agree with assigning 5 levels, and the underlying logic. It is only the description that is problematic. 

Perhaps
"Because we can't add new values later, and because Multilevel Precedence and Preemption (MLPP)-like behavior may be desired the "esnet" namespace is given 5 priority-levels." 

that is within 4412



2nd to last paragraph of section 1
"Within the ESINet, there will be emergency calls requiring different
   treatments, according to the type of call. "
We don't know if they will require different treatment or not.

I would prefer
"Within the ESINet, there may be emergency calls requiring different
   treatments, according to the type of call. "

or if the use of "may" will be confused with normative language,
"Within the ESINet, there could be emergency calls requiring different
   treatments, according to the type of call. "


I'm ok with this


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")


fair



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."
(same comment applied to 00)


I'll back off this even more - to

"This document IANA registers the "esnet"
RPH namespace for use within emergency services networks, not just for calls or sessions 
  towards PSAPs."





Section 2  first para 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.
but either (ets or wps) can simply not be used. here there is no routine esnet calls, every one is an emergency call, and likely every call will be an emergency.
Every use of the wps and ets namespaces will have priority over calls without RPH. 

Suggest changing text to say
"   Like the ets and wps namespaces defined in [RFC4412], 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."


see comment above




Section 2, para immediately below Figure 1
"   Because the more important usage of the
   "esnet" namespace occurs within the ESInet, the edge proxy, called
   an Emergency Services Routing Proxy (ESRP) can modify or delete this
   namespace. This is a normative change to the allowed behavior within
   [RFC4412], but MUST only be considered valid in this usage at the
   ESInet boundary for this one RP namespace (and associated
   priority-value). "
I have major (content, not editorial) concerns with this, more for what it says about 4412 than about esnet
First of all, it is not clear to me why this is "a normative change to the allowed behavior within [RFC4412]". 

because 4412 says "do not modify or delete, just ignore if you don't like it"

this doc changes that for esnet only.
For one thing I see nothing in 4412 that would prohibit a "SIP actor that understands the name space" 
from modifying or deleting the namespace.




4.6.2.  No Known Namespace or Priority Value
If an RP actor does not understand any of the resource values in the request, the treatment depends on the presence of the Require 'resource-priority' option tag:
1. Without the option tag, the RP actor treats the request as if it contained no 'Resource-Priority' header field and processes it with default priority. Resource values that are not understood MUST NOT be modified or deleted. 


so, evidence to the contrary (from your statement above)
It is certainly anticipated that at least some of the namespaces described in 4412 will be modified or deleted, (e.g., when there is reason to believe it is unauthorized). 

no, just ignored
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". "
What about SIP entities that not only understand RPH, but understand the "esnet" namespace - yet have an incorrect priority-value for that call? 

That's a problem that needs to be fixed in the ESInet (with use of the esnet).
But I do not see anywhere that is says that a UAS that DOES understand the namespace is 
forbidden from deleting it.


see 4.6.2 (quoted above)


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.) 

I would suggest rewording this to say
"   Because the more important usage of the
   "esnet" namespace occurs within the ESInet, the edge proxy, called
   an Emergency Services Routing Proxy (ESRP) can modify or delete this
   namespace. This is consistent with [RFC4412]. "




Section 3.2,para after the relative priority order.

"  The "esnet" namespace will be assigned into the priority queuing
   algorithm (Section 4.5.2 of [RFC4412]) from the public user to the
   PSAP.  This does not limit its usage to only the priority queue
   algorithm; meaning the preemption algorithm can be used where the
   local jurisdiction preferred to preempt normal calls in lieu of
   completing emergency calls.  This document is not RECOMMENDING this
   usage, merely pointing out those behaviors are a matter of local
   policy."
My concern here is the reference to "preempt normal calls". Since you have already said that there is no "normal" level in the esnet priority value set, I have to assume that you mean "preempt calls with no RPH" (or perhaps "preempt calls with a different RPH namespace").
no, I'm leaving open the possibility that perhaps one local jurisdiction wants to use preemption -- kinda like the country of Japan does today (therefore... it needs to be possible, *and* mentioned). 




This WOULD BE a normative change to 4412, which says in 4.7.2.1
"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."
Note that the only sessions that can be preempted are ones "with a valid namespace and a lower priority value". A "normal" call has neither a "valid namespace", nor a "priority value" 
(higher or lower), and thus cannot be preempted under 4412.
we are not private ESInet network police -- and we shouldn't be so firm in deciding normal calls aren't preempted in one or more local configurations within jurisdictions.
Furthermore, RFC4411 (which focuses on "preemption") repeatedly refers to the pre-empted 
call/session having an RPH with a lower priority value.
4411 is how to indicate to a preempted caller their session has been preempted. I see no reason at this point to include any 4411 reference. For example, if NENA wanted to allow preemption (which I am NOT suggesting), their docs should include this reference and usage of 4411.
The circuit switched versions of preemption ( both MLPP for landlines, and 3GPP e-MLPP for GSM) are even more restrictive. In those schemes, a call can only preempt a lower priority call IN THE SAME PREEMPTION DOMAIN (there is a rough correspondence between "preemption domain" and "RPH namespace"). 

So I take serious objection to any suggestion of preempting "normal" calls.
respectfully, that's a personal opinion that I question the universal applicability of. Especially given that Japan currently preempts normal calls in lieu of 911 calls. 

Other jurisdictions *may* have similar or future plans
If you want to have high priority esnet calls preempt low priority esnet calls, I don't object as 
strenuously. (But no preempting "normal" calls.)


Section 5, 3rd para
"  A simple means of preventing this usage is to not allow marked
   traffic preferential treatment unless the destination is towards the
   local/regional ESInet. "
neither of the quotes below talk about granting preferential treatment across the ESInet ESRP boundary. This comment does. But I can expand on this sentence to clarify this meaning. 



This seems to contradict the text in section 1
"This new namespace can
   be used for inbound calls to PSAPs, between PSAPs, and between a
   PSAP and first responders and their organizations."
and section 3
" This namespace will also be used
   for communications between emergency authorities, and MAY be used
   for emergency authorities calling public citizens.  An example of
   the later is a PSAP operator calling back someone who previously
   called 9111/112/999 and the communication was terminated before it
   should have been (in the operator's judgment)."
Finally, at IETF 73 you assured me that you would insert strong language pointing to section 8 of RFC4412 addressing the relative priority of the different namespaces. This is to eliminate any possible suggestion (that some people - not me- read into the 00 version) that an esnet 
namespace would have higher priority than an ets namespace.
well... I agree I haven't emphasized section 8 of 4412, and can mention this in a generic form when other namespaces are present.
Secondly, this document should never insist that esnet is above or below ets or wps. that's a matter of local policy, for example - to within NENA/APCO for whether they believe (and are going to implement to) this. That's for an operational doc that this ID isn't. 


 I find no such reference to section
8 of 4412.
Thanks, and please note that I strongly support the creation of the esnet namespace. None of my comment should be interpreted as being "against" esnet. 

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 at cisco.com>
Sent by: ecrit-bounces at ietf.org

02/19/2009 09:32 PM
To
"'ECRIT'" <ecrit at ietf.org>
cc
Subject
[Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-01 submitted




ECRIT

I've just submitted a rev of the "esnet" Resource-Prioriy header draft.

I've removed all mention of UAs from the draft, but leave in the
possibility for adjacent VSPs to have a trust relationship with the
local ESInet and mark these SIP requests accordingly through the
VSP's domain.  I offer that the ESRP at the ESInet edge will be
tasked with mapping the esnet.priority-values from outside the ESInet
to the indications used inside the ESInet.  The ID gives no guidance
on what the priority-values should be in either case - as that is a
matter for other documents (and I'd argue - for other SDOs or
consortia such as NENA and EENA, though I don't mention either
organization in the ID).

Comments are welcome

James

>From: IETF I-D Submission Tool <idsubmission at ietf.org>
>To: jmpolk at cisco.com
>Subject: New Version Notification for
>          draft-ietf-ecrit-local-emergency-rph-namespace-01
>Date: Thu, 19 Feb 2009 18:24:27 -0800 (PST)
>
>
>A new version of I-D,
>draft-ietf-ecrit-local-emergency-rph-namespace-01.txt has been
>successfuly submitted by James Polk and posted to the IETF repository.
>
>Filename:       draft-ietf-ecrit-local-emergency-rph-namespace
>Revision:       01
>Title:          IANA Registering a SIP Resource Priority Header
>Namespace for Local Emergency Communications
>Creation_date:  2009-02-19
>WG ID:          ecrit
>Number_of_pages: 7
>
>Abstract:
>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.
>
>
>
>
>The IETF Secretariat.

_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit