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
ecrit-bounces at ietf.org 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" <jmpolk at cisco.com>
> Sent by: ecrit-bounces at ietf.org
> 10/27/2008 08:32 PM
>
> To
>
> "'ECRIT'" <ecrit at ietf.org>
>
> 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
> Ecrit at ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
> _______________________________________________
> Ecrit mailing list
> Ecrit at ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit