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

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

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" <jmpolk at cisco.com>
wrote on 11/20/2008 05:59:32 PM:

> At 03:03 PM 11/20/2008, Janet P Gunn wrote:
> 
> 
> >"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).
> 
> 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: 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