Re: [Dime] [SPAM] RE: rfc3588bis version number

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

> This is how I think that it would work:
>   
[...]

Well, if the bis describes how to handle the interoperability with
"pure" rfc3588, and the solution is not very very dirty, then I'd agree
for this type of solution ^^
But I'd prefer to see the actual description, before saying it's
possible... To me it looks complex, especially for the initiator's side.

>> I think that we *will* end up with different implementations of
> I'd be very surprised if that wasn't true in any case.
>   
But if at least we don't know it before releasing the new specification,
it's better... Isn't it? ^^'

> I would prefer to increment the version number, too; I'm just trying to
> break the log jam here.
>   
Well, not pushing the change to TLS into the Bis version seemed a good
approach to me.
If the implementation must be backward-compatible with 3588, it will
remain open to the security vulnerability anyway...

I'd also rather see a *clean* version 2 where this vulnerability is
fixed; even if this version comes later with a new re-chartering or
i-don-t-know-what process to fix a vulnerability....

Best regards,
Sebastien.

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