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

[Tom Taylor <[e-mail]>]

Ben, I think the problem is that a Diameter implementation can be 
thought of as a base part and an application-specific part. A message 
comes in, gets processed by the Diameter base part, then the application 
is passed the type of message and the parts not consumed by base. So 
some extra information is tacked on in that optional AVP part. Either 
the base recognizes it and deals with it, or the application does. If 
the application is to handle it, the application has to expect it -- 
that is, the specification of the application includes the additional data.

On 07/12/2012 11:19 AM, [e-mail] wrote:
>
>
> -----Message d'origine----- De : Ben Campbell
> [mailto:[e-mail]] Envoyé : vendredi 7 décembre 2012 16:47 À :
> MORAND Lionel OLNC/OLN Cc : Eric McMurry; THIEBAUT, LAURENT
> (LAURENT); [e-mail] Objet : Re: [Dime] Dime: Diameter Overload
> IETF requirements, review
>
>
> On Dec 7, 2012, at 9:24 AM, [e-mail] wrote:
>
>>> [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.
>>>
>>> [LM] It is exactly the issue for me! :) I think that you want to
>>> say that existing commands can be extended with changing the CCF
>>> specification and it is true. The application (and its related
>>> specification/documentation) using this command will change! And
>>> it is what I highlight in my comment and in the proposed change.
>>
...