Re: [Dime] rfc3588bis version number

[Mark Jones <Mark.Jones at bridgewatersystems.com>]

> I fully support Sebastien. If bis is not given a new version number,
> there are different protocols in the wild which claim to be the very
> same protocol. These protocols are not interoperable with each other,
> and their differences are subtle. I suspect implementation nightmares
> dead ahead.
> 

Version 1 is already out in the wild and two independent implementations of RFC3588 may not interoperate. So we spent 18 months on bug fixes in 3588bis to greatly improve the odds that they can interoperate. Implementers finding contradictions or ambiguities in RFC3588 have been able to turn to 3588bis for clarification. Throughout that time Victor was strict in enforcing solutions that were backwards compatible.

Recently we discover two issues (TLS negotiation and capabilities update) and find we can not fix them without breaking backwards compatibility. Given that no one noticed these problems until now, I strongly suspect these are not critical features of the Diameter base protocol. For Capabilities Update, we chose to deprecate the feature in bis rather than fix it and Glen captured a solution in a separate draft. If offered the choice at that point, I believe the majority of delegates would have been preferred a similar approach for TLS negotiation rather than bump the version.

> I acknowledge that it's a pity that the plan not to introduce
> incompatible changes in bis couldn't be upheld. But 
> regardless of that:
> these *are* two different protocols, and they *really really 
> should* be
> easily distinguishable from each other.
> 

The original plan for 3588bis was sound and is still required. IMO the decision to address TLS negotiation in bis knowing that the fix was not backwards compatible was our error. I vote we deprecate this feature in 3588bis, move the proposed solution to a new draft (Diameter v2 if required) and get 3588bis out the door.

Regards
Mark