Re: [Dime] rfc3588bis version number

[Sebastien Decugis <sdecugis at nict.go.jp>]

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)