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

[Janet P Gunn <jgunn6 at csc.com>]

"James M. Polk" <jmpolk at cisco.com>
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: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
> > > On Behalf Of Brian Rosen
> > > Sent: Thursday, November 20, 2008 9:01 AM
> > > To: 'Janet P Gunn'
> > > Cc: Ecrit at ietf.org
> > > 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:jgunn6 at csc.com]
> > > Sent: Thursday, November 20, 2008 11:37 AM
> > > To: Brian Rosen
> > > Cc: Ecrit at ietf.org; '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" <br at brianrosen.net> 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: ecrit-bounces at ietf.org
> > > [mailto:ecrit-bounces at ietf.org] On Behalf Of
> > > > Janet P Gunn
> > > > Sent: Thursday, November 20, 2008 11:00 AM
> > > > To: GOLDMAN, STUART O (STUART)
> > > > Cc: Ecrit at ietf.org
> > > > 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\)"
> > > <sgoldman at alcatel-lucent.com> 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
> > > > > Stuart.Goldman at alcatel-lucent.com
> > > > > +1 602 493 8438
> > > > > +1 480 414 1260 mobile
> > > > > P please save a tree by not printing this e-mail.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Janet P Gunn/FED/CSC at CSC
> > > > > Sent by: ecrit-bounces at ietf.org
> > > > > 10/27/2008 11:45 PM
> > > > >
> > > > >
> > > > >
> > > > > To
> > > > >
> > > > > "James M. Polk" <jmpolk at cisco.com>
> > > > >
> > > > > cc
> > > > >
> > > > > "'ECRIT'" <ecrit at ietf.org>, ecrit-bounces at ietf.org
> > > > >
> > > > > 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" <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
> > > > >
> > > > >
> > > > > Stuart Goldman
> > > > > Alcatel-Lucent
> > > > > Stuart.Goldman at alcatel-lucent.com
> > > > > +1 602 493 8438
> > > > > +1 480 414 1260 mobile
> > > > > P please save a tree by not printing this e-mail.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > Ecrit at ietf.org
> > > 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
> >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