Re: [Dime] Dime: Diameter Overload IETF requirements, review

[Eric McMurry <[e-mail]>]

On Dec 6, 2012, at 11:50 , [e-mail] wrote:

> Hi,
> 
> I think that we should not misuse "application" and "specification" here. The problem is not about change in the specification but about change in the Diameter application. 
> 
> In my understanding, the intention of the second sentence of REQ2 is to say that the support of OC mechanism must not imply major extensions of existing Diameter Applications, which would cause the definition of a new application and the allocation of a new Application-id, as per RFC6733.
> 
> But of course, if required, existing applications can be slightly enhanced to support OC without major impacts (e.g. using optional AVPs), and then no need for new Application-id, and then the related specification will have to be updated to describe how to support this new feature.
> 
> If my understanding is correct, would the following change be agreeable?
> 
> OLD:
> 
>  REQ 2:   The overload [control] mechanism MUST be useable with any existing or
>           future Diameter application.  It MUST NOT require
>           specification changes for existing Diameter applications.
> 
> NEW:
> 
>  REQ 2:   The overload [control] mechanism MUST be useable with any existing or
>           future Diameter application.  Support of this mechanism over existing
>           Diameter applications MUST NOT require major changes that would lead
>           to the need to define a new Diameter application.

sounds reasonable, but it's a bit less strong.  It would be good for the mechanism to work without requiring any changes to applications.  This is achievable and I think both proposed mechanisms could be used over, or alongside, existing applications without any changes to the applications.  Applications may provide additional specification on top of this, which the requirements do not at all prevent now.  I gather some would like additional language spelling this out though.

> 
> 
> By the way, I think that we are working on a mechanism to control overload and not a mechanism for overload, right. Should "overload mechanism" be replaced by "overload control mechanism" all over the document?
> 

I suppose we have plenty of mechanisms for overload already.

I think I had intended to do just this at one point, but it must have fallen out of my head.

> 

[...]