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

[Eric McMurry <[e-mail]>]

Thanks Lionel.  comments inline.

Eric


On Dec 6, 2012, at 12:32 , [e-mail] wrote:

> Hi Eric,
> 
> Please see below.
> 
> Regard,
> 
> Lionel
> 
> -----Message d'origine-----
> De : Eric McMurry [mailto:[e-mail]] 
> Envoyé : jeudi 6 décembre 2012 19:13
> À : MORAND Lionel OLNC/OLN
> Cc : Ben Campbell; THIEBAUT, LAURENT (LAURENT); [e-mail]
> Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review
> 
> 
> 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.
> 
> [LM] Both solutions consider "piggybacking" and piggybacking of any new info over existing commands is actually a change into the Diameter application. But what we want is to make this change as smooth as possible for existing application. And it is the requirement that I read in REQ2.
> 
> Now if it is about "alongside" i.e. with no protocol change at all on existing application, the second sentence REQ2 would be anyway irrelevant because you could say that for any other protocol e.g. "this mechanism MUST NOT require specification changes for existing SIP or HTTP or whatever"

[em] One solution uses existing messages as a carrier, piggybacking on them.  This can be done by an implementation without any change in the specification of the messages that are being used.  The other solution uses a separate application that does not use, or alter, any existing messages.  This could also be done without any change in the specification of other applications.  I'm confused as to what changes would be required in any applications for an element to use either of the mechanisms?  Desired, yes (as Laurent was pointing out), but not required.


[...]