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

[<[e-mail]>]

The problem I have with SHOULD is that it just means "RECOMMENDED". It implies that a server that handle all requests the same way despite a local policy giving priority to BYE requests can still claim conformance to the RFC.

So I would just replace SHOULD with MUST in the following text since it makes already clear that we are talking about prioritization, not preservation.

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

///

BC

> -----Message d'origine-----
> De : [e-mail] [mailto:sip-overload-
> [e-mail]] De la part de Volker Hilt
> Envoyé : mardi 15 janvier 2013 10:59
> À : [e-mail]
> Objet : Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-
> load-control-event-package-05.txt
> 
> I think my general concern is that we are creating a MUST for something
> that we haven't even defined. I'm not sure what MUST means in this
> context. I think without such a specification SHOULD and some
> explanatory text seems appropriate.
> 
> Either way, let's try to close this one remaining issue and wrap up the
> draft.
> 
> Thanks,
> 
> Volker
> 
> 
> 
> 
> On 15.01.2013 08:33, Salvatore Loreto wrote:
> >
> > I do like the distinction between prioritization  and preservation,
> > maybe we need clearly distinguish the two cases in the draft
> >
> > for prioritization a MUST could by reasonable indeed a statement like:
> > - "It *MUST* honor the local policy for *prioritizing* SIP
> requests..."
> > tell that the SIP element has to prioritize requests following the
> > policy but has still the possibility to discard in case of severe
> > overload
> >
> > while for preserving a SHOULD seems to be more appropriate indeed a
> > statement like this:
> > - "It *SHOULD* honor the local policy for *preserving* SIP
> requests..."
> > tell that SIP element will follow local policy as long as the result
> > does not produce a severe overload (i.e. "the result is consistent
> > with the SIP Overload Algorithm)
> >
> >
> > /Salvatore
> >
> > On 1/14/13 8:08 PM, [e-mail] wrote:
> >> 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.
> >>
> >> _______________________________________________
> >> 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.