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

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

Stu,

I intended to say that the esnet namespace needs to be at a LOWER priority 
 than the ets and wps namespaces, in any network that recognizes ets and 
wps as described in 10.5 and 10.6 of RFC4412.

Janet

"GOLDMAN, STUART O \(STUART\)" <[e-mail]> wrote on 
11/20/2008 10:22:49 AM:

> 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-rph-namespace-00.txt
> >
> >
> >
> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ecrit-local-
> emergency-rph-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