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

["GOLDMAN, STUART O \(STUART\)" <[e-mail]>]

Janet,

 

With regard to you e-mail below, did you intend that esnet could be at
the same level of priority as ETS & WPS,  or that ETS & WPS need to be
at an even higher priority than esnet?

 

 

 

Stuart Goldman

Alcatel-Lucent 

[e-mail]

[phone]

[phone] mobile

P please save a tree by not printing this e-mail.

 

 

 

Janet P Gunn/FED/CSC@CSC 
Sent by: [e-mail] 

10/27/2008 11:45 PM 

 

To

"James M. Polk" <[e-mail]> 

cc

"'ECRIT'" <[e-mail]>, [e-mail] 

Subject

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


  

 

  

 






I apologize for not tracking this as closely as I meant to, as these
comments apply to  earlier versions as well. 


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

Section 2 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. 

You say "This 
 namespace, therefore, MAY be overwritten or deleted, contrary to the 
 rules of RFC 4412 [RFC4412]." 

It is not clear to me why this is "contrary to the rules of 4412".  It
is certainly anticipated 
that other RPH will be overwritten or deleted, when the UAS understands
the namespace. 

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) 

Immediately following these statements, you give 3 options- 
"These proxies in the service provider 
 MAY either 

 o  accept the existing RPH value with "esnet" in it, if one is 
    present, and grant relative preferential treatment to the request 
    when forwarding it to the ESINet. 

 o  replace any existing RPH value, if one is present, and insert an 
    "esnet" namespace and give relative preferential treatment to the 
    request when forwarding it to the ESINet. 

 o  insert an "esnet" namespace in a new RPH and give relative 
    preferential treatment to the request when forwarding the SIP 
    request towards the ESINet." 

Why do you exclude the possibility of adding the esnet RPH value without
"replacing" an existing RPH value? 

Finally, there is another point that  needs to be made clear.  At least
one person has contacted me expressing concern that this ID implied that
the esnet namespace would  have priority over other namespaces (in
particular wps and ets).  I assured him that this was not the case, that
there was nothing prevent the expected behavior - that the ets and wps
namespaces would be prioritized ahead of esnet in GETS Service Provider
networks. 

However, since the question has already arisen, it would be a good idea
to clarify  this, perhaps in  section 3, where you discuss  the other
namespaces.  In particular, it needs to be made clear in section 3.2
that, even if  "the   local jurisdiction preferred to preempt normal
calls in lieu of 
 completing emergency calls. ", esnet calls will NOT preempt wps or ets
calls. 

By the way, I think you mean "the   local jurisdiction preferred to
preempt normal calls in order to complete emergency calls. "  - not "in
lieu of".  Or perhaps "the   local jurisdiction preferred to preempt
normal calls in lieu of  dropping emergency calls. " 

In fact, it is not clear to me that 4412 permits a call with an RPH
(e.g., esnet)  to preempt a "normal" call (with no RPH namespace).
Section 4.7.2.1 of 4412 says 
"4.7.2.1.  User Agent Servers and Preemption Algorithm 

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

It doesn't say anything about preempting a call with no RPH 

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. 

"James M. Polk" <[e-mail]> 
Sent by: [e-mail] 

10/27/2008 08:32 PM 

  

 

To

"'ECRIT'" <[e-mail]> 

cc

  

Subject

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


  

 

  

 






ECRIT WG

Here is a update to a ID I think is pretty near done, given that this 
is merely an IANA registration ID of an existing mechanism.

Comments are wanted

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Emergency Context Resolution with 
>Internet Technologies Working Group of the IETF.
>
>
>         Title           : IANA Registering a SIP Resource Priority 
> Header Namespace for Local Emergency Communications
>         Author(s)       : J. Polk
>         Filename        : 
> draft-ietf-ecrit-local-emergency-rph-namespace-00.txt
>         Pages           : 9
>         Date            : 2008-10-27
>
>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.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rp
h-namespace-00.txt
>
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rp
h-namespace-00.txt>

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

 

 

Stuart Goldman

Alcatel-Lucent 

[e-mail]

[phone]

[phone] mobile

P please save a tree by not printing this e-mail.

 

 

 

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