Re: [Dime] rfc3588bis version number
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.