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

[Volker Hilt <[e-mail]>]

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 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