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

[<[e-mail]>]

Hi Ben, see below.

Regards,

Lionel

-----Message d'origine-----
De : Ben Campbell [mailto:[e-mail]] 
Envoyé : vendredi 7 décembre 2012 16:04
À : MORAND Lionel OLNC/OLN
Cc : Eric McMurry; THIEBAUT, LAURENT (LAURENT); [e-mail]
Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review

H Lionel, see comments inline:

On Dec 7, 2012, at 3:42 AM, [e-mail] wrote:

> Hi Eric,
> 
> I think that I understand the misunderstanding. Please see below
> 
>>> 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.  
> 
> [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.

I'm not sure what you mean by the application changing in the piggyback case. Assuming the application specification uses the * [ AVP ] construct, an _implementation_ can add the OC AVPs without a change in the specification of specification. Yes, the implementation changes, but the spec doesn't have to. Given, there might be benefit to updating the spec, particularly if you want to describe application-specific behaviors rather than accepting the base behavior. But that's not a _requirement_, right?

What are we missing?

[LM] it is not the application specification that "uses the *[AVP]" but the CCF specification of a given command. And an application is not only defined by the command code format specifications. Set of AVP, error codes and so on are also part of the application. So adding new AVP to existing application IS a change of the application and related application specification, even if this addition is compliant with the CCF specification of the given command. You will have to describe at least that these new AVPs have to be carried in a specific set of commands when considering existing applications. I think that it the use of "specification" that causes problems here. And it is why I've proposed the change in REQ2.

> 
> 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. 
> 
> [LM] So the second sentence will be always true i.e. no impact at all on existing 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.
> 
> [LM] I hope that clarifies my point... that is not (so) different from yours and Laurent's one! 
> 
> 
> [...]
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 


_________________________________________________________________________________________________________________________

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.