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

[Janet P Gunn <[e-mail]>]

Here are my comments on -local-emergency-rph-namespace (from last August), 
 which apparently did not get incorporated.

Mostly nits, but a couple of  comments on content.
--
First comment on content

At the end of section 2 it says
“   To be clear, specifically for the use of an edge proxy in any 
   network, because the "esnet" namespace is allowed to be modified or 
   deleted at the edge proxy of the ESInet does not allow any edge 
   proxy to modify or delete any other Resource-Priority namespace.”

First of all, this is a long and awkward sentence, and a little bit 
awkward to understand.  But you SEEM to be saying that an “edge proxy on 
any network” is not allowed to  modify or delete any OTHER R-P namespace.

If that is NOT what you are trying to say, then you need to reword it to 
make it clear that you are only referring to modifying or deleting the 
esinet header.

If that IS what you are trying to say, then I take strong objection to the 
ESINET Namespace ID (and later RFC) proscribing what other network’s edge 
proxies can do with/to other namespace headers, and even what the ESInet 
proxies can do with/to other namespace headers.

Perhaps what you mean is 
“   To be clear, even though an edge proxy  of the ESInet may modify or 
delete an R-P Header with the  ESINET namespace, this has no bearing on 
whether or not a given proxy (on ESInet or elsewhere) is allowed to modify 
an R-P Header with a different namespace.”

Remember that 4412 says that ANY proxy can remove or modify ANY R-P Header 
(amdr in table 2)
--

The second comment on content is about the “intended algorithm”.

RFC4412  says that “Both algorithms can sometimes be combined in
   the same element, although none of the namespaces described in this
   document do this.” (e.g., both “preemption” and “queue”).”
  But the IANA registration requires you to chose one or the other – you 
chose “queue”.

It seems that you want to permit “both algorithms combined in the same 
element”, but the actual text switches back and forth in a very confusing 
way.

First you say
“There is the possibility that within emergency services networks - 
   provided local policy supports enabling this function - a Multilevel
   Precedence and Preemption (MLPP)-like behavior can be achieved 
   (likely without the 'preemption' part, which will always be a matter
   of local policy, and defined here) “

-Mentioning MLPP/Preemption before mentioning Queuing implies that MLPP is 
the dominant algorithm

-“MLPP-like behavior without the preemption part”  is pretty ineffective 
for anything.  But a combination of MLPP and queuing (as in 3GPP eMLPP) 
can be effective.

-What does “and defined here” refer to? MLPP without preemption? “local 
policy”? In either case I don’t find it “defined here”. 

Then on the next page you say
“The "esnet" namespace has 5 priority-values, in a specified relative 
   priority order, and is a queue-based treatment namespace [RFC4412]. 
   Individual jurisdictions MAY configure their SIP entities for 
   preemption treatment. This is OPTIONAL, subject to local policy 
   decisions.”

-it would be a lot clearer  if you replaced the earlier reference to 
MLPP without preemption with something like-
“Within an Emergency Services Network, it is possible that local policy 
will involve a combination of “preemption” and “queuing” algorithms, as 
permitted by RFC4412, though queuing is expected to be the dominant 
algorithm, and is selected in the IANA registration.  This combination can 
ensure that more important calls are established or retained. The "esnet" 
namespace is given 5 priority-levels, analogous to other Prememption based 
and Queue based namespaces.  The MLPP-like SIP signaling needed for the 
preemption side of a combined algorithm is not defined in this document 
for 911/112/999 style emergency calling, but it is not prevented either.”

And then the second becomes-
“The "esnet" namespace has 5 priority-values, in a specified relative 
   priority order, and is a registered as a queue-based treatment 
namespace [RFC4412]. 
  However, as permitted in RFC4412, individual jurisdictions MAY configure 
their SIP entities for a combination of queuing and preemption treatment, 
or even a preemption only treatment. This selection of the treatment 
algorithm is OPTIONAL, subject to local policy decisions.”


Now to the nits.

In the introduction, you say :
“This new namespace is to be used within public safety answering 
   point  (PSAP) networks.”

But this appears to be an over-simplification, as elsewhere you say that 
(dependant, of course, on the proper business and policy agreements):
“Adjacent ASPs to the ESInet MAY have a 
   trust relationship that includes allowing this/these neighboring 
   ASP(s) to use the "esnet" namespace to differentiate SIP requests 
   and dialogs within the ASP's network.” (more on other concerns with 
this sentence later).
Perhaps reword the sentence in the Intro to say :
“This new namespace is to be used within, or in conjunction with, public 
safety answering 
   point  (PSAP) networks.”


Later on in the Intro, you say:
“This indication is 
   used solely to differentiate SIP requests, transactions or dialogs, 
   from other requests, transactions or dialogs that do not have the 
   need for priority treatment.”

The way it is worded sounds as if you are distinguishing “SIP requests”, 
from “non-SIP requests”, but I do not think that is what you mean.  I 
think you mean:
“This indication is 
   used solely to differentiate PSAP-related SIP requests, transactions or 
dialogs, 
   from other, non PSAP-related, SIP  requests, transactions or dialogs, 
that do not have the 
   need for priority treatment.”

Next sentence says:
“If there are differing, yet still 
   valid Resource-Priority header values between SIP requests in a 
   network, then this indication can be used by local policy to 
   determine which SIP request, transaction or dialog receives which 
   treatment (likely better or worse than another).”

Going back to the wording of 4412, the point is whether or not the 
namespaces are “understood”, not just whether the values are valid.

But I don’t understand why you say “between” in this context.

Suggest:
“As described in section 8 of RFC4412, other namespaces, not understood by 
the SIP actor are ignored.  If multiple RPH namespaces are understood by 
the SIP actor, it must create a local total ordering across all resource 
values from the namespaces it understands. This will determine the 
relative priority with which each message, request, transaction or dialog 
is treated.”

In section 2, you say:
“Every use of this namespace will be in times of an emergency, where 
   at least one end of the signaling is within a local emergency 
organization.”

This, of course, begs the question -what is the definition of a “time of 
emergency”?  Does some authority have to formally declare a “time of 
emergency”?  It would seem that, by definition, every 911/112/999 call 
represents a “time of emergency”, at least for the caller.

And what do you mean by “one end of signaling? Is a B2BUA an “end”?

What is the definition of “a local emergency organization”?

If a PSAP is directly connected to the (public) Service Provider network, 
without a separate “ESI network”, is it allowed to use this namespace?

I am confused by the relationship between the terminology in Figure 1 and 
the terminology in the text.

The text refers to “Application Service Providers (ASP) directly attached 
to an ESInet” (which may have a trust relationship with the ESInet, and 
thus may use the esinet namespace).  But the figure does not show an ASP, 
it shows something called a “Service Network”.  Is the “Service Network” 
supposed to be the “ASP”?

This sentence in sec 3.2 is rather awkward:
“The rules originated in RFC 4412 remain with regard to an RP actor, 
   who understands more than one namespace, MUST maintain its locally 
   significant relative priority order.”

Perhaps 
 “The rules originated in RFC 4412 , that an RP actor, 
   who understands more than one namespace, MUST maintain its locally 
   significant relative priority order, remain in effect.”

In section 6, this sentence is ambiguous:
“   The implications of using this namespace within the 
   Resource-Priority header field incorrectly can cause a large impact 
   on a network - given that this indication is to give preferential 
   treatment of marked traffic great preference within the network than
   other traffic.”

First, “marked” could mean many different things.  Second, given that you 
have 5 different priority levels, it is unlikely that they ALL “give 
preferential    treatment of marked traffic great preference” (which is 
also redundant).

Suggest:
“Incorrectly using this namespace within the 
   Resource-Priority header field can cause a large impact 
   on a network.  For some priority values,  this namespace can give great 
preference within the network
   to marked traffic over other traffic.”

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.



From:
Robert Sparks <[e-mail]>
To:
Janet P Gunn/USA/CSC@CSC
Date:
04/07/2011 01:42 PM
Subject:
Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace



Hi Janet -

I'm picking this back up (it fell between some cracks). Did you get a 
chance to review it last year?

RjS

On Aug 5, 2010, at 6:17 AM, Janet P Gunn wrote:


I plan to review it, but not until the second half of August. 

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. 


From: 
Marc Linsner <[e-mail]> 
To: 
"'ecrit'" <[e-mail]> 
Date: 
08/03/2010 03:04 PM 
Subject: 
[Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace




All,

As you all know, RPH namespace is an ECRIT draft without a milestone.  At
the meeting last week Robert Sparks announced he is willing to AD sponsor
this draft.

Robert asks everyone to read the draft and comment on it to this list.

Thanks,

-Marc-


_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit


_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit