Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt

On Dec 19, 2012, at 3:58 PM, "Mark Jones" <mark@azu.ca> wrote:

> Hi Ben, Tom,
> 
> That explanatory text helps a lot. I still think REQ 2 should be split into
> two requirements though. 
> 
> I could not find a definition of "default overload control" in the draft. In
> the context of REQ 2, I interpret it as the overload control mechanism
> without any application-specific extensions. If I'm right then I think it is
> safe to replace it with "the overload control mechanism". If I'm wrong,
> "default overload control" needs to be defined.

You are correct, and we can probably just say "the overload control mechanism"
> 
> Could you clarify the difference between the extensibility required by REQ 2
> and that required by REQ 34? I assumed the extensibility in REQ 34 was
> 'application-neutral' but I'd like to confirm.

Now that you point it out, I think 34 covers most of what I was trying to say about extensibility. I don't think anything in 34 prevents application-specific extensions. (nor does it prevent application-independent ones).

> 
> /Mark
> 
>> -----Original Message-----
>> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of
>> Ben Campbell
>> Sent: December-19-12 3:16 PM
>> To: Tom Taylor
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-
>> reqs-02.txt
>> 
>> WFM
>> 
>> On Dec 19, 2012, at 1:51 PM, Tom Taylor <tom.taylor.stds@gmail.com>
>> wrote:
>> 
>>> 
>>> 
>>> Just a one-word change.
>>> 
>>> On 19/12/2012 1:30 PM, Ben Campbell wrote:
>>>> Hi Tom,
>>>> 
>>>> I think that's on the right track. We've been too focused on
>>>> specification impact, when the root of the requirement is really a
>>>> combination of application-independent default behavior, along with
>>>> extensibility to allow application-specific behavior.
>>>> 
>>>> To put some finer points on it, how's this? I tried to take the
>>>> spirit of your proposed text, and added some non-normative
>>>> elaboration:
>>>> 
>>>> 
>>>> The mechanism MUST allow Diameter nodes to support default overload
>>>> control regardless of which Diameter applications they support. It
>>>> MUST provide sufficient extensibility to allow individual
>>>> applications to provide more refined overload control.
>>>> 
>>>> The basic mechanism is intended to be application-independent, that
>>>> is, a Diameter node can use it across any existing and future
>>>> Diameter applications and expect reasonable results. Certain Diameter
>>>> applications might, however, benefit from application-specific
>>>> behavior over and above the mechanism's defaults. For example, an
>>>> application         might specify relative priorities of
>>>             ^^^^^^^^
>>>> messages or selection of a specific overload control algorithm.
>>>> 
>> 
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
> 