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

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

Since we are now actively talking about this document, I am resending my 
earlier comments.  I expect they were missed because everyone was in the 
middle of meeting the ID dead line.

Janet


[e-mail] wrote on 10/27/2008 11:45:43 PM:

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

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