Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt

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

I agree, except I would say 

"It is expected a SIP client will follow local policy 
 as long as the result is consistent with the SIP Overload Algorithm."

Janet

Volker Hilt <[e-mail]> wrote on 01/14/2013 10:23:16 AM:

> From: Volker Hilt <[e-mail]>
> To: Janet P Gunn/USA/CSC@CSC
> Cc: <[e-mail]>rg>, <[e-mail]>
> Date: 01/14/2013 10:23 AM
> Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-
> soc-load-control-event-package-05.txt
> 
> Janet,
> 
> the root of this discussion is probably that there is no definition of 
> what local policies can be and what a valid local policy would be. I 
> also don't think we should open this can worms right now, which is I 
> think what you are suggesting also.
> 
> I do think, however, that it is useful to provide explanation to a 
> developer why we used a SHOULD here.
> 
> We could say that it is expected a SIP client will follow local policy 
> as long as the result leads to an acceptable load under current 
conditions.
> 
> This way we're not giving an example for a bad policy.
> 
> Thanks,
> 
> Volker
> 
> 
> 
> On 14.01.2013 16:09, Janet P Gunn wrote:
> > No, I don't like your added sentence.
> >
> > A VALID local policy prioritizes within the volume of messages 
permitted
> > by the algorithm.   A VALID local policy doe not attempt to send more
> > messages than permitted by the Overload algorithm.
> >
> > A Local policy that attempts to override teh Overload Control 
Algorithm
> > is not permitted
> >
> > That is pretty clear in the wording of Req 13.
> >
> >
> > If you are going to say "MUST", then you must also define what
> > constitutes a VALID local policy, in some detail.
> >
> > If you are going to say "SHOULD", then you do not need to define a 
VALID
> > local  policy in detail
> >
> > But the way you have written it implies that it is permissible to have
> >   a Local Policy that  attempts to override the Overload control
> > algorithm, and so must, in turn  be over ridden by the Overload 
Algorithm.
> >
> > I don't even what to suggest that such a case would occur.    I DO NOT
> > WANT TO MENTION IT.
> >
> > The SHOULD takes care of it.
> >
> > Janet
> >
> > [e-mail] wrote on 01/14/2013 09:21:34 AM:
> >
> >  > From: Volker Hilt <[e-mail]>
> >  > To: <[e-mail]>
> >  > Date: 01/14/2013 09:22 AM
> >  > Subject: Re: [sip-overload] Local Policy Re: I-D Action: 
draft-ietf-
> >  > soc-load-control-event-package-05.txt
> >  > Sent by: [e-mail]
> >  >
> >  > I think SHOULD would, in fact, be the more appropriate wording 
here.
> >  > There may be reasons why a local policy cannot be kept: a conflict 
with
> >  > another policy, legal requirements, or very high levels of 
overload.
> >  >
> >  > In the end, the local policy will be a local matter including its
> >  > enforcement. In other words, if a service provider has a SIP server 
that
> >  > ignores his policies, I'm sure the service provide will know who to 
call.
> >  >
> >  > I've added a short explanatory sentence to the first paragraph:
> >  >
> >  > A SIP client SHOULD honor the local policy for prioritizing SIP 
requests
> >  > such as policies based on message type, e.g., INVITEs vs. requests
> >  > associated with existing sessions. A SIP client is expected 
generally to
> >  > honor local policy except for very rare occasions when, for 
example,
> >  > overload is so severe that messages, which should be preserved 
according
> >  > to local policy, need to be discarded or local policies are in 
conflict.
> >  >
> >  > A SIP client SHOULD honor the local policy for prioritizing SIP 
requests
> >  > based on the content of the Resource-Priority header (RPH, RFC4412
> >  > [RFC4412]).  Specific (namespace.value) RPH contents may indicate 
high
> >  > priority requests that should be preserved as much as possible 
during
> >  > overload.  The RPH contents can also indicate a low-priority 
request
> >  > that is eligible to be dropped during times of overload.
> >  >
> >  > A SIP client SHOULD honor the local policy for prioritizing SIP 
requests
> >  > relating to emergency calls, as identified by the SOS URN [RFC5031]
> >  > indicating an emergency request.
> >  >
> >  > Thanks,
> >  >
> >  > Volker [as individual]
> >  >
> >  >
> >  >
> >  >
> >  > On 14.01.2013 13:56, Salvatore Loreto wrote:
> >  > > my reading of the mailing list is that the question of using 
SHOULD
> >  > > versus MUST
> >  > > is being decided in favor of MUST
> >  > >
> >  > > however it would be great to also address the Valker concerns
> >  > > inserting a caveat/constraints explaining that the local policy 
can not
> >  > > override the overload mechanism/algorithm
> >  > >
> >  > > can someone propose text ?
> >  > >
> >  > > note this is the only remaining issue that we have to address in 
this
> >  > > event-package draft
> >  > > before we can ship to the IESG
> >  > >
> >  > > /Salvatore
> >  > >
> >  > >
> >  > > On 1/11/13 4:25 PM, Janet P Gunn wrote:
> >  > >>
> >  > >> Good point
> >  > >>
> >  > >> If you say it MUST honor "local policy", then you  need 
constraints
> >  > >> on what the local policy can do (e.g., it can only prioritize 
within
> >  > >> the number of messages permitted by the overload algorithm, it 
can't
> >  > >> over ride the overload mechanism/algorithm)
> >  > >>
> >  > >> Janet
> >  > >>
> >  > >>
> >  > >>
> >  > >> [e-mail] wrote on 01/11/2013 09:06:58 AM:
> >  > >>
> >  > >> > From: Volker Hilt <[e-mail]>
> >  > >> > To: <[e-mail]>
> >  > >> > Date: 01/11/2013 09:07 AM
> >  > >> > Subject: Re: [sip-overload] Local Policy Re: I-D Action: 
draft-ietf-
> >  > >> > soc-load-control-event-package-05.txt
> >  > >> > Sent by: [e-mail]
> >  > >> >
> >  > >> > Janet, All,
> >  > >> >
> >  > >> > while this sounds good in most cases, the concern I have is 
that
> > there
> >  > >> > may be situation where a proxy is forced to violate local
> > policy. E.g.,
> >  > >> > a policy "emergency calls can never be dropped" will have to 
be
> >  > >> violated
> >  > >> > eventually if overload reaches levels where only 
emergencycalls are
> >  > >> left.
> >  > >> >
> >  > >> > Maybe this boils down to formulating policies in a reasonable
> > way. It
> >  > >> > has to be made clear, however, that not all policies call be
> > kept under
> >  > >> > all circumstances.
> >  > >> >
> >  > >> > A SHOULD would imply this to the developer. With a MUST, 
Ithink one
> >  > >> > would have to add explanatory text.
> >  > >> >
> >  > >> > Thanks,
> >  > >> >
> >  > >> > Volker [with individual contributor hat on]
> >  > >> >
> >  > >> >
> >  > >> >
> >  > >> > On 03.01.2013 18:52, Janet P Gunn wrote:
> >  > >> > > I prefer MUST to SHOULD.
> >  > >> > >
> >  > >> > > The original wording was based on Req 13 of RFC 5390:
> >  > >> > > " REQ 13:  The mechanism must not dictate a specific 
algorithm for
> >  > >> > >        prioritizing the processing of work within a proxy 
during
> >  > >> times of
> >  > >> > >        overload*.  It must permit a proxy to prioritize 
requests
> >  > >> based on*
> >  > >> > > *      any local policy*, so that certain ones (such as a 
call for
> >  > >> > >        emergency services or a call with a specific value of 
the
> >  > >> > >        Resource-Priority header field [RFC4412]) are given
> >  > >> preferential
> >  > >> > >        treatment, such as not being dropped, being given
> > additional
> >  > >> > >        retransmission, or being processed ahead of others."
> >  > >> > >
> >  > >> > > which has a lower case "must".
> >  > >> > >
> >  > >> > > If we are going to say "MUST honor" (rather than "must 
permit"), I
> >  > >> think
> >  > >> > > we need to change "any" to "the" . (you can permit many
> > alternatives,
> >  > >> > > but you can really only honor one).  I think this also
> > reflects the
> >  > >> > > intent of Martin's  comment
> >  > >> > >
> >  > >> > > So I would prefer
> >  > >> > >
> >  > >> > >
> >  > >> > >    A SIP client MUST honor *the *local policy for 
prioritizing SIP
> >  > >> > >    requests such as policies based on message type, e.g.,
> > INVITEs vs.
> >  > >> > >    requests associated with existing sessions.
> >  > >> > >
> >  > >> > >    A SIP client MUST honor *the *local policy for 
prioritizing SIP
> >  > >> > >    requests based on the content of the Resource-Priority
> > header (RPH,
> >  > >> > >    RFC4412 [RFC4412]).  Specific (namespace.value) RPH
> > contents may
> >  > >> > >    indicate high priority requests that should be preserved 
as
> > much as
> >  > >> > >    possible during overload.  The RPH contents can also 
indicate a
> >  > >> > >    low-priority request that is eligible to be dropped 
during
> > times of
> >  > >> > >    overload.
> >  > >> > >
> >  > >> > >    A SIP client MUST honor *the *local policy for 
prioritizing SIP
> >  > >> > >    requests relating to emergency calls, as identified by 
the SOS
> >  > >> > >    URN [RFC5031] indicating an emergency request.
> >  > >> > >
> >  > >> > >
> >  > >> > > 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.
> >  > >> > >
> >  > >> > >
> >  > >> > >
> >  > >> > > From: "Vijay K. Gurbani" <[e-mail]>
> >  > >> > > To: Charles Shen <[e-mail]>
> >  > >> > > Cc: "DRAGE, Keith (Keith)" <[e-mail]>om>,
> > Janet P
> >  > >> > > Gunn/USA/CSC@CSC, "[e-mail]" 
<[e-mail]>rg>,
> >  > >> Arata
> >  > >> > > Koike <[e-mail]>jp>, "NOEL, ERIC (ERIC C)"
> >  > >> > > <[e-mail]>om>, Henning Schulzrinne <[e-mail]>
> >  > >> > > Date: 01/03/2013 11:42 AM
> >  > >> > > Subject: Re: [sip-overload] Local Policy Re: I-D Action:
> >  > >> > > draft-ietf-soc-load-control-event-package-05.txt
> >  > >> > >
> >  > >>
> > 
------------------------------------------------------------------------
> >  > >> > >
> >  > >> > >
> >  > >> > >
> >  > >> > > On 01/03/2013 07:34 AM, Charles Shen wrote:
> >  > >> > >  > Sounds good, I can update the wording in the event 
package
> >  > >> draft, if
> >  > >> > >  > Vijay is OK with the other one.
> >  > >> > >
> >  > >> > > I just want to make sure we are all agreeing to the same 
thing.
> >  > >> > >
> >  > >> > > It seems to me that the question of using SHOULD versus MUST
> > is being
> >  > >> > > decided slightly in favour of a MUST.  Martin and Bruno 
prefer
> > a MUST,
> >  > >> > > Janet is okay with, although her original text used a 
SHOULD; and
> >  > >> Keith
> >  > >> > > could go either way.
> >  > >> > >
> >  > >> > > Is the consensus, then, that the text on honoring local 
policy
> >  > >> contains
> >  > >> > > MUST?  If so, the text to be inserted would be the 
following:
> >  > >> > >
> >  > >> > >    A SIP client MUST honor any local policy for prioritizing 
SIP
> >  > >> > >    requests such as policies based on message type, e.g.,
> > INVITEs vs.
> >  > >> > >    requests associated with existing sessions.
> >  > >> > >
> >  > >> > >    A SIP client MUST honor any local policy for prioritizing 
SIP
> >  > >> > >    requests based on the content of the Resource-Priority
> > header (RPH,
> >  > >> > >    RFC4412 [RFC4412]).  Specific (namespace.value) RPH
> > contents may
> >  > >> > >    indicate high priority requests that should be preserved 
as
> > much as
> >  > >> > >    possible during overload.  The RPH contents can also 
indicate a
> >  > >> > >    low-priority request that is eligible to be dropped 
during
> > times of
> >  > >> > >    overload.
> >  > >> > >
> >  > >> > >    A SIP client MUST honor any local policy for prioritizing 
SIP
> >  > >> > >    requests relating to emergency calls, as identified by 
the SOS
> >  > >> > >    URN [RFC5031] indicating an emergency request.
> >  > >> > >
> >  > >> > > Yes?
> >  > >> > >
> >  > >> > > Thanks,
> >  > >> > >
> >  > >> > > - vijay
> >  > >> > > --
> >  > >> > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> >  > >> > > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 
(USA)
> >  > >> > > Email: vkg@{bell-labs.com,acm.org} /
> > [e-mail]
> >  > >> > > Web: http://ect.bell-labs.com/who/vkg/
> >  > >> > >
> >  > >> > >
> >  > >> > >
> >  > >> > > _______________________________________________
> >  > >> > > sip-overload mailing list
> >  > >> > > [e-mail]
> >  > >> > > https://www.ietf.org/mailman/listinfo/sip-overload
> >  > >> > >
> >  > >> > _______________________________________________
> >  > >> > sip-overload mailing list
> >  > >> > [e-mail]
> >  > >> > https://www.ietf.org/mailman/listinfo/sip-overload
> >  > >>
> >  > >>
> >  > >> _______________________________________________
> >  > >> sip-overload mailing list
> >  > >> [e-mail]
> >  > >> https://www.ietf.org/mailman/listinfo/sip-overload
> >  > >
> >  > >
> >  > > --
> >  > > Salvatore Loreto, PhD
> >  > > www.sloreto.com
> >  > >
> >  > >
> >  > >
> >  > > _______________________________________________
> >  > > sip-overload mailing list
> >  > > [e-mail]
> >  > > https://www.ietf.org/mailman/listinfo/sip-overload
> >  > >
> >  > _______________________________________________
> >  > sip-overload mailing list
> >  > [e-mail]
> >  > https://www.ietf.org/mailman/listinfo/sip-overload