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

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

"James M. Polk" <[e-mail]> wrote on 11/20/2008 03:46:30 PM:


> 
> Just to be clear, this discussion is NOT something my namespace ID 
> should ever address.  I have no issues with having this discussion - 
> but I want to make clear that 
> draft-ietf-ecrit-local-emergency-rph-namespace will NEVER make 
> priority decisions or even recommendations in the text of the doc.
> 
> This ID only creates the namespace *and* the probably scenario in 
> which it is intended.
> 
Agree
> 
> >Public net:
> >P1. ets/wps? (PSAPs may not be so eager to agree)
> >P2. esnet
> >P3. <other/null>
> 
> it's not as simple as that.
> 
> each <namsepace.priority-value> gets its own slot in any relative 
> priority order (per section 8 of RFC4412).
> 
> With this in mind, it is *possible* to have a relative priority 
> order like this
> 
> P1. ets.4
> P2. esnet.4
> P3. ets.3  wps.4
> P4. esnet.3  esnet.2
> P5. wps.3  ets.2
> P6. wps.2  ets.1
> P7. esnet.1
> P8. esnet.0
> P9. ets.0  wps.0
> 
> notice that within each <namespace>, the numbering order is 
> consistent, but that the order relative to the different namespaces 
> is whatever the local operator wants to make them. 

At the risk of being a nitnoid, this would NOT be an RFC4412-legal 
ordering,as it reverses the priority values of ets and wps (0 is the 
highest).


 I do show here 
> that at each priority level (e.g., P3, P4, P5, P6 and P9) that there 
> are more than one namespace.priority-value combination.  This means, 
> within this priority - it's a FIFO situation in which each of the 
> namespace.priority-value combinations at this priority level compete 
> (i.e., they are equivalent in priority). This is all a local decision.
> 
> I think a way to address Brian's comment about preemption is also a 
> local decision (because the local jurisdiction needs to live with the 
> consequences).  Here's how that can be addressed:
> 
> - all these namespace.priority-value combinations *can* be preempted

I have serious heartburn with this statement. 

In the circuit switched paradigm of preemption (MLPP and eMLPP), only 
calls that are identified a-priori as "part of a preemption domain (or 
similar term)" can be preempted.  "Normal" (unmarked, as opposed to marked 
"routine") calls cannot be preempted. I REALLY don't think we should break 
that aspect of the paradigm without investigating "unintended 
consequences" in great detail.

> - only certain namespace.priority-value combinations *can* preempt 
> another call.
> 
> just a thought about how to solve this...
> 
> James
> 
> 
> >Private net (ESInet):
> >(anything they want)
> >
> >Lastly, what kind of prioritization does a government official (a
> >servant of the people) get when they themselves initiate an emergency
> >call?  esnet or ets/wps?  (In a private ESInet, it may be to their
> >disadvantage to keep the wrong one.)
> >
> >-roger marshall.
> >
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> > > On Behalf Of Brian Rosen
> > > Sent: Thursday, November 20, 2008 9:01 AM
> > > To: 'Janet P Gunn'
> > > Cc: [e-mail]
> > > Subject: Re: [Ecrit] 
draft-ietf-ecrit-local-emergency-rph-namespace-00
> > >
> > > An "Emergency Services IP Network" is a private IP network to
> > > which, we hope, all public safety agencies are connected.  It
> > > handles all the traffic of a public safety agency, which
> > > would include routine and priority citizen to authority,
> > > authority to authority and authority to citizen traffic.
> > > It's not entirely clear to me yet whether we can reuse a
> > > number of the existing name spaces as well as a new one.  For
> > > example, some of the agency-agency traffic will require
> > > pre-emption, but the existing MLPP namespace may be quite 
sufficient.
> > >
> > > It does occur to me that we could have ETS and possibly WPS
> > > traffic, in that if the normal access to public facilities
> > > traversed the ESInet towards some kind of gateway to a public
> > > network, then we would either have to have the ETS/WPS
> > > values, or remark them at the edge if a caller inside the
> > > ESInet needed to call someone outside the ESInet and needed
> > > ETS/WPS priority to do so.   If we carried the priority
> > > marking across the ESInet, ETS/WPS would be lower priority
> > > than some other traffic, but higher than, for example,
> > > citizen to authority emergency calls.
> > >
> > > Brian
> > >
> > >
> > >
> > > From: Janet P Gunn [mailto:[e-mail]]
> > > Sent: Thursday, November 20, 2008 11:37 AM
> > > To: Brian Rosen
> > > Cc: [e-mail]; 'GOLDMAN, STUART O (STUART)'
> > > Subject: RE: [Ecrit] 
draft-ietf-ecrit-local-emergency-rph-namespace-00
> > >
> > >
> > > Brian,
> > >
> > > I need to understand this better.
> > >
> > > Exactly what are the constraints of the "emergency services
> > > IP network"?  Is this a network in which EVERY call would
> > > have the RPH with the  esnet namespace (just varying priority
> > > values),and there would be no "normal" calls?  Or would their
> > > be a mixture of calls with and without RPH wit esnet?
> > >
> > > Janet
> > >
> > > "Brian Rosen" <[e-mail]> wrote on 11/20/2008 11:16:39 AM:
> > >
> > > > 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
> > >
> >
> >CONFIDENTIALITY NOTICE: The information contained in this message 
> >may be privileged and/or confidential. If you are not the intended 
> >recipient, or responsible for delivering this message to the 
> >intended recipient, any review, forwarding, dissemination, 
> >distribution or copying of this communication or any attachment(s) 
> >is strictly prohibited. If you have received this message in error, 
> >please notify the sender immediately, and delete it and all 
> >attachments from your computer and network.
> >_______________________________________________
> >Ecrit mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ecrit
> 

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