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

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

Agree.
Just needs to be made clearer that "there is no guidance in this doc to be 
given on local policy"
Janet

"James M. Polk" <[e-mail]> wrote on 11/20/2008 05:59:32 PM:

> At 03:03 PM 11/20/2008, Janet P Gunn wrote:
> 
> 
> >"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).
> 
> shoot me for not remembering off the top of my pointy head the order 
> of ets and wps
> 
> ;-)
> 
> the concept still holds though
> 
> 
> 
> >  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.
> 
> this is a comment that is NOT tied to this ID, because there is no 
> guidance in this doc to be given on local policy other that the 
> concept of relative priority, just to be clear
> 
> 
> >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