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

["DRAGE, Keith \(Keith\)" <[e-mail]>]

1)	Remember that the relationship between namespaces is entirely up to the agreements with the network operator. So referring to something as required to be higher priority is invalid for two reasons:

-	the standards simply will not cover this

-	priority is not simply a matter of servicing all messages in one namespace before another. There may be undertakings to process a certain number of such messages from any namespace within any time period, or any of a host of other conditions. Look at it more as a way of dividing the traffic into separate queues where the queues are serviced by an algorithm which is not standardised but is based on agreements made with the namespace owner. That does not prevent certain namespaces being addressed before anything else.

Certainly with emergency calls, it is common that the traffic can be handled separately, but I believe it is rare that emergency calls take total priority over even normal traffic.

I do agree that callbacks need to be handled separately from citizen to authority calls. I would also suggest that if a call has reached an answer point and is now being redirected to a first responder, that is yet another classification (if such traffic appears on a common network). To distinguish them the appropriate way to to this is to give them different namespaces.

The immediate need in my view is to address the citizen to authority case.

regards

Keith



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Brian Rosen
> Sent: Thursday, November 20, 2008 4:17 PM
> To: 'Janet P Gunn'; GOLDMAN, STUART O (STUART)
> Cc: [e-mail]
> Subject: Re: [Ecrit] Ecrit] 
> draft-ietf-ecrit-local-emergency-rph-namespace-00
> 
> A suggestion was made to me that we should define two namespaces.
> 
> One would be used in public networks, and generally would be 
> used to request resource priority for citizen to authority 
> and possibly authority to citizen calls.  This would have 
> lower priority than ETS/WPS.
> 
> The other would be for use within emergency services IP 
> networks.  It would be unlikely that ETS/WPS would be used 
> within those networks, but if it was, some values within the 
> namespace would need higher priority that ETS/WPS.
> For example, a message which was an incident commanders 
> "evacuate" message would be higher than a ETS/WPS traffic.  
> On the other hand, a citizen to authority emergency call 
> would have lower priority.
> 
> I would be happier with one namespace and more values in that 
> namespace for all of this, but I was advised that two 
> namespaces was a better choice.
> 
> Brian
> 
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Janet P Gunn
> Sent: Thursday, November 20, 2008 11:00 AM
> To: GOLDMAN, STUART O (STUART)
> Cc: [e-mail]
> Subject: Re: [Ecrit] Ecrit]
> draft-ietf-ecrit-local-emergency-rph-namespace-00
> 
> 
> 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
> 
_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit