Re: [Dime] rfc3588bis version number

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

Hi Lionel,

> 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...
>   
How is it different with the bis version? Regardless of the header in
the message, we *are* introducing a new version of the protocol, since
it is not interoperable with original RFC3588. The exact same questions
apply. At least by bumping the version number, the situation is easier
to manage, IMHO.


> 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.
>   
Ok, you obsolete the original document. What about existing
implementations of this original 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.
>   
Now, if 3588 and 3588bis protocols *were* interoperable, I totally
support that we should not bump the version number and save the
not-interoperable changes to a v2 version later, following the whole
clean process.

I guess I did not make my point very clear. What I want to enforce is
that if we are introducing changes that make original and revised RFCs
not interoperable, then the version number MUST be bumped. I have no
problem with saving these changes for a future revision (a real v2) and
going with an interoperable version in rfc3588bis. I think this is the
reasonable approach that everyone supports in the WG.

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)