Re: [Dime] rfc3588bis version number

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

Hi Stephan, Sebastien,

The proposed changes are there BECAUSE there are issues with the current Diameter implementation. What you are saying is that the RFC3588 would remain with open issues (from the standard point of view) that would be fixed by some vendor-specific solutions in the operational network or not solved at all. So basically, how will the interoperatbility with a v1 implementation be properly ensured if you don't even know how excatly the remote v1 AAA entity behave?

I prefer to find some texts saying:
"sorry guys! Some mistakes were present in the first edition of the spec and here is the correct version of the specification, with the correct implementation!"

Instead of something like:
"The RFC3588 had some problems and a new version was created. But of course, you can still use the old version version and you are free to interwork with" 

The industry and other fora uses to handle protocol issues in that way. The version update is not the ONLY solution to fix protocol issues. Version update is always consider a carefully thought-out plan and a last resort solution.

BR,

Lionel

> -----Message d'origine-----
> De : Stefan Winter [mailto:stefan.winter at restena.lu] 
> Envoyé : vendredi 3 avril 2009 08:15
> À : Sebastien Decugis
> Cc : MORAND Lionel RD-CORE-ISS; dime at ietf.org
> Objet : Re: [Dime] rfc3588bis version number
> 
> Hi,
> 
> > 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.
> >   
> [...]
> > 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.
> >   
> 
> 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.
> 
> 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.
> 
> Giving bis the version number 2 doesn't at all prevent future 
> backwards-incompatible cleanups (those that were rejected 
> earlier for bis, and others) from happening: such a revision 
> simply can get version 3. The Version field is 8 bits - It's 
> not like we're running short of integers.
> 
> Greetings,
> 
> Stefan Winter
> 
> P.S.: Why am I reminded of the subtle differences of 
> MS-CHAPv2 in EAP-FAST vs. elsewhere, and the confusion and 
> fuss that was generated by the two having the same EAP type. 
> I'd prefer things like that not to happen yet another time.
> 
> --
> Stefan WINTER
> Ingenieur de Recherche
> Fondation RESTENA - Réseau Téléinformatique de l'Education 
> Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
> 
> Tel: +352 424409 1
> Fax: +352 422473
> 
>