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

[<[e-mail]>]

Hi Eric,

It is where I'm lost in your argumentation. If the specification of the application is not updated at all, how do you want to reflect that the OC mechanism is now supported over this application?

Again, I think that the requirement is that any agent supporting the existing application should not have to be forced to be upgraded when introducing the new OC mechanism. Only the client, server and/or dedicated proxies have to be upgraded to support the new functionality.

And how to document that is out of scope. It could be a reference to a companion document, addition of extra informative text, etc. But we should not mix both aspects here. Only the requirements at the protocol level are relevant in this draft.

Lionel

De : Eric McMurry [mailto:[e-mail]]
Envoyé : mardi 11 décembre 2012 16:40
À : MORAND Lionel OLNC/OLN
Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); [e-mail]
Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review


Hi Lionel,

Please see inline.

Thanks,

Eric


On Dec 11, 2012, at 9:06 , [e-mail]<mailto:[e-mail]> wrote:


Hi Eric,

The way to document the support of the OC mechanisms in existing applications is up to the people managing the document defining the given application (IETF, 3GPP, other SDOs, vendors, etc.) and this can be done in various ways. They can even decide to create a completely new application if it is preferred. For me, it is out of the scope of the definition of the mechanism itself and then not part of the requirement.


of course.  I am not proposing any restrictions on how application specifications are updated.


>From a Diameter point of view, the important point is that the foreseen solution has to be designed to be used along or over existing applications. And when used over existing applications, the required changes must not imply the creation of a new application (as clarified in the proposal). The solution designers can rely on the RFC 6733 and the draft Diameter Applications Design Guidelines<http://tools.ietf.org/html/draft-ietf-dime-app-design-guide-16> to see if the solution meets this requirement.


I am not making my point clear.  I see the important point being that the specification of  existing applications do not have to be updated at all.  This includes your point, but is a stricter requirement.  It would be possible to design an OC mechanism that met your requirement that still required changes to the specification of existing applications.


_________________________________________________________________________________________________________________________

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.