Please go back and R E A D S L
O W L Y. You have missed the point on many of my comments.
For instance -
1) Do you REALLY think
"...this
namespace is to be to provide an explicit priority indication facilitates
treatment..."
makes sense? What is the subject
of the verb "facilitates"?
2) I agree that
4412 says "do not modify or delete, just ignore
if you don't like it" FOR SIP ACTORS THAT DO NOT UNDERSTAND
THE NAMESPACE.
There is NO SUCH PROHIBITION in 4412
for SIP Actors that DO UNDERSTAND the namespace, which is what is being
discussed here.
3) Yes, it is just my opinion that "preempting
normal calls" is a bad idea.
But it is WRITTEN IN 4412 (not just
my opinion) that only calls "with a valid namespace and a lower priority
value" can be preempted.
And furthermore it is a fact that for
both the MLPP and eMLPP , the protocol standards are very clear that you
can't preempt calls that don't have a priority value, in the same preemption
domain. I have no idea how they do it in Japan, but if they are using
MLPP, then the "normal" calls must be in the same preemption
domain as the "911" calls, with a lower priority. Hence
not "normal calls" in the usual sense of the word
4) Your replies contradict each other.
When I say that "ets and wps don't have a 'routine' or 'normal'
value", you say that esnet is different because "here
there is no routine esnet calls, every one is an emergency call, and likely
every
call will be an emergency."
A- That is equally true of ets and wps. There
are no routine NS/EP calls. Every call with the ets or wps namespace is
an NS/EP (hence special) call.
B - If you mean that the esnet namespace will ONLY
be used in networks where EVERY relevant SIP message uses the esnet RPH,
then -Yes, it is different
from ets and wps -BUT if this is
the case, there are no "normal" calls to preempt -If this is the
case, you need to state clearly that esnet will only be used in networks
where everything is marked esnet.
But I don't think that is what you mean (at least
based on the diagram you presented today).
C - I think you mean that esnet will be used
in some networks where there are both esnet and non esnet messages (as
well as some where all are marked esnet) - If this is the
case, then it is EXACTLY the same as ets and wps, and no change from 4412
And so on.
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>
02/26/2009 02:39 PM
To
Janet P Gunn/FED/CSC at CSC
cc
"'ECRIT'" <ecrit at ietf.org>,
ecrit-bounces at ietf.org
>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