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

[Volker Hilt <[e-mail]>]

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