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

[Volker Hilt <[e-mail]>]

That works for me!

Volker



On 14.01.2013 17:04, Janet P Gunn wrote:
>
> 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
>
>
> _______________________________________________
> sip-overload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload
>