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."
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.
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.
Note that "do not have the need
for priority treatment" is not correct. 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..."
I don't understand the "can be
achieved". Do you mean "MLPP-like behavior may be desired"?
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."
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. "
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."
(same comment applied to 00)
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.
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."
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]".
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.
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).
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.)
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").
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.
Furthermore, RFC4411 (which focuses
on "preemption") repeatedly refers to the pre-empted
call/session having an RPH with a lower
priority value.
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.
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.
"
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. 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
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