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

[<[e-mail]>]

I'm not really happy with the SHOULD. I think we are mixing two different things: priority and preservation. For example, a local policy that gives priority to BYE requests over any other request MUST always be honored even in case of severe overload. This does not imply that BYE requests MUST always be preserved; just that they MUST be given priority over other requests. 

I don't see any problem with using MUST for local policies that assign priorities to some requests. Use of MUST would of course be a problem if we were to define local policies about preserving some requests, but it's not what we are trying to do.

BC

> -----Message d'origine-----
> De : [e-mail] [mailto:sip-overload-
> [e-mail]] De la part de DRAGE, Keith (Keith)
> Envoyé : lundi 14 janvier 2013 18:28
> À : Charles Shen; Janet P Gunn
> Cc : [e-mail]; Hilt, Volker (Volker)
> Objet : Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-
> load-control-event-package-05.txt
> 
> I'm not convinced we have got to the bottom of the requirement yet.
> Writing SHOULD is not an excuse for writing a poor requirement, yet
> that seems currently to be the excuse for wring SHOULD instead of MUST.
> Ideally I should still be able to still identify conformance or no
> conformance to a SHOULD requirement.
> 
> I suspect what we need to do is find a more specific requirement and
> then cover the rest of the problem in more informative text, rather
> than trying to address everything in a single requirement sentence.
> 
> I agree that if we end up writing a SHOULD, then there should be
> associated informative text that identifies the example circumstances
> for ignoring the SHOULD. That has long been an unwritten rule, and
> without it the SHOULD always gets interpreted as a MAY.
> 
> Regards
> 
> Keith
> 
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]
> > On Behalf Of Charles Shen
> > Sent: 14 January 2013 17:03
> > To: Janet P Gunn
> > Cc: [e-mail]; Hilt, Volker (Volker)
> > Subject: Re: [sip-overload] Local Policy Re: I-D Action:
> > draft-ietf-soc- load-control-event-package-05.txt
> >
> > I am not in favor of opening up more cans of whatever at this stage :)
> >
> > I think we just need to define and clarify the line. At least "the
> > Overload
> >  Algorithm(s) in effect at that node" sounds much better than "the
> > Overload Algorithm(s)" alone. (Optionally) plus something like "the
> > interactions of those Overload Algorithms are out of scope".
> >
> > Thanks
> >
> > Charles
> >
> > On Mon, Jan 14, 2013 at 11:49 AM, Janet P Gunn <[e-mail]> wrote:
> > >
> > >
> > > My personal thought is that in each case, it would refer to the
> > > Overload
> > > Algorithm(s) in effect at that node.
> > >
> > > But that brings up a whole can of worms about interaction between
> > > algorithms..
> > >
> > > If the Event package has set up an a-priori Overload  Control, and
> > > then
> > an
> > > actual overload triggers a "feedback" Overload Control, how do they
> > > interact?  The max? the min? the "product"
> > >
> > > Is that a can of worms we want to open at this point?
> > >
> > > Janet
> > >
> > > [e-mail] wrote on 01/14/2013 11:36:34 AM:
> > >
> > >> From: Charles Shen <[e-mail]>
> > >> To: Volker Hilt <[e-mail]>om>, Janet P
> Gunn/USA/
> > >> CSC@CSC, "Vijay K. Gurbani" <[e-mail]>
> > >> Cc: [e-mail]
> > >> Date: 01/14/2013 11:37 AM
> > >> Subject: Re: [sip-overload] Local Policy Re: I-D Action:
> > >> draft-ietf- soc-load-control-event-package-05.txt
> > >> Sent by: [e-mail]
> > >>
> > >> Hi Volker, Janet and Vijay,
> > >>
> > >> Since we are talking about putting the same texts in the
> > >> overload-control and event-package draft, would it be better to
> > >> clarify a bit about "the SIP Overload Algorithm" in this sentence?
> > >>
> > >> "It is expected a SIP client will follow local policy as long as
> > >> the result is consistent with the SIP Overload Algorithm."
> > >>
> > >> Specifically, are we referring to mechanisms in both drafts (and
> in
> > >> that case, should we add cross reference to them?) as well as any
> > >> future Overload Algorithms?
> > >>
> > >> Thanks
> > >>
> > >> Charles
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Mon, Jan 14, 2013 at 11:15 AM, Volker Hilt
> > >> <[e-mail]> wrote:
> > >> > Vijay,
> > >> >
> > >> > the sentence Janet has proposed works for me. You can replace
> the
> > >> > sentence I had suggested after the first paragraph with Janets
> > >> > proposal.
> > >> >
> > >> > Cheers,
> > >> >
> > >> > Volker
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On 14.01.2013 17:15, Vijay K. Gurbani wrote:
> > >> >>
> > >> >> On 01/14/2013 10:09 AM, Volker Hilt wrote:
> > >> >>>
> > >> >>> That works for me!
> > >> >>
> > >> >>
> > >> >> Volker: Can either you or Janet please propose the exact
> > >> >> wordings to go into the modified text I proposed in [1]?  This
> > >> >> will avoid any guesswork and expedite the process of getting
> the drafts out.
> > >> >>
> > >> >> [1]
> > >> >> http://www.ietf.org/mail-archive/web/sip-
> > overload/current/msg00885.html
> > >> >>
> > >> >> Thanks,
> > >> >>
> > >> >> - vijay
> > >> >
> > >> > _______________________________________________
> > >> > 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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.