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

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

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 emergency calls 
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, I think 
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