Re: [Dime] rfc3588bis version number

[<lionel.morand at orange-ftgroup.com>]

Diameter is not anymore only an academic topic as we used to hear in the recent past.
There are existing implementations running the Diameter base protocol and "introducing" a new version of the protocol is not as simple as just incrementing only the value of the version field in the message header. If a v2 is created, what should we do with existing v1 implementations? Upgrade any Diameter existing implementation to v2? Any v2 implementation will have to support both v1 and v2? And so on...

Recent discussions in other fora about version handling for different protocols (including protocols based on Diameter applications for instance) showed that issues with versioning and interworking are often reasons good enough to be stuck with the previous version and postpone (forever?) the migration to the new version. At this stage, what it is required is not a new version of the protocol. It is just a version of the protocol that is good enough to remove any existing open issue with the current specification. Having a new document describing the correct implementation of the Diameter base protocol doesn't require a v2. The new document can just make obsolete the previous document.

And again, going for a v2 without a clear pre-existing requirement definition phase and deciding the version update at the latest stage would be counterproductive and an open door for a v3 discussion, even maybe before the effective deployment of the v2, without collecting feedback from the operational field. Having a long-term stable base protocol should be our goal, to ensure a successful deployment of any application running on top of the base protocol. Especially for a protocol used over interfaces between different administrative domains.

BR,

Lionel

> -----Message d'origine-----
> De : dime-bounces at ietf.org [mailto:dime-bounces at ietf.org] De 
> la part de Sebastien Decugis
> Envoyé : jeudi 2 avril 2009 03:03
> À : dime at ietf.org
> Objet : Re: [Dime] rfc3588bis version number
> 
> Hello all,
> 
> I would like to comment on this "version 2" change.
> 
>  I think that incrementing the version number in the header 
> does not mean we have to redesign and improve the whole 
> protocol. It does not mean a "major update". It is simply a 
> hint for implementations indicating what behavior is expected 
> (state machine, ...)
> 
> >> * The version number in the diamter header may not help the TLS 
> >> negotiation anyway because we only see the version number 
> after the 
> >> first diameter message. So a bis implementation and an 
> original 3588 
> >> may not be able to inter operate regardless of whether the version 
> >> number is reved-up.
> >>     
> This is true for some situations, but there are also cases 
> where a different version number would be very useful for an 
> implementation that tries to be compatible with both specifications.
> 
> On a technical point of view, changing the version number in 
> the code is a trivial change, especially compared with all 
> the other changes that are in the "bis" document. I don't see 
> a reason why an implementor would complain about having to do 
> this change on the version number -- if they are willing to 
> deploy the changes from this revision, at least. On the 
> contrary, on a marketing point of view, "We support Diameter 
> 2" is more attractive IMO :)
> 
> In any case, we will have to distinguish between the original 
> Diameter or the revised version. Talking about "version 1" 
> and "version 2" is more convenient and less error-prone.
> In my opinion, not incrementing the version number will add 
> even more complexity to the protocol and implementations, 
> leading to even less people understanding it and wanting to use it...
> 
> Thank you for reading.
> 
> Sebastien.
> 
> --
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)
> 
> _______________________________________________
> DiME mailing list
> DiME at ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>