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

[<[e-mail]>]

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"

> 	 
> 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.

> 

[...]

_________________________________________________________________________________________________________________________

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.