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

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

Comments on the new version

 
In the second paragraph of the Intro, I suggest changing "understandable" 
to "understood", to better parallel the wording in 4412. 

I am still concerned that the Introduction mentions ONLY "MLPP-like" 
behavior (and does not mention queuing AT ALL), when the namespace is 
being registered as "queue-based".  I have no problem with the discussion 
of MLPP-like behavior- but the Intro needs to mention queueing AS WELL. 

I also still think that "MLPP - like behavior without the prememption", 
and without queueing, is pretty useless.  It cannot "ensure more the 
important calls are established or retained" 

Furthermore, the second part of the sentence is a non sequitor - 
"THEREFORE (my caps) the "esnet" namespace is given 5 priority-levels". 
The need for 5 priority levels is orthogonal to whether it is MLPP-like or 
queue-based.  If you got rid of the "therefore", and made it two 
sentences, it would be fine. 

In section 2, I still have problems with this sentence 

  "The "esnet" namespace SHOULD only be used 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”? Is that the 
same as a PSAP? 

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


At the end of 3.2, 
  "The remaining rules originated in RFC 4412 apply with regard to an 
  RP actor, who understands more than one namespace, and MUST maintain 
  its locally significant relative priority order." 
is still awkwardly worded, but the content is OK. 


In section 5 I still have problems following this sentence 

"...the implications of using this 
  namespace within the field incorrectly can potentially cause a large 
  impact on a network, given that this indication is to give 
  preferential treatment of marked traffic great preference within the 
  network verses 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). 

I still prefer 

“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 over other 
traffic.” 

Finally, I think it would make sense to include an informative reference 
for "MLPP-like behavior"- perhaps 4411. 

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.