Re: iSCSI version info

[julian_satran@il.ibm.com]

Steph,

I think that there things in iSCSI for which speed is  only marginally
critical, are bound to be implemented in some form of software always and
will evolve.  Examples that keep coming back to us are  authentication,
key-exchange for security, some name mapping.
For those it does no harm to have a version number specified at login.
For the rest it will be painful if we keep revving numbers - so no version
numbers in
regular headers.

Regards,
Julo

Stephen Bailey <steph@cs.uchicago.edu> on 07/09/2000 02:36:07

Please respond to Stephen Bailey <steph@cs.uchicago.edu>

To:   ips@ece.cmu.edu
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  Re: iSCSI version info




> A version negotiation scheme was suggested by Mark Bakke's 29 Jun
> 2000 e-mail.
>
> Is there any plans to support a mechanism like this in the next iSCSI
draft?

I can never figure out which side of this argument to be on.

The basic version idea seems sound, but the problem is that for
various reasons, the version number never ends up getting moved.  For
example, if I recall, FC-PH seemed to go through many version numbers
long before it was ever widely implemented, and now it's stabilized at
version 4.3.  I have never known any implementations that did anything
other than 4.3.

In ST, we went back and forth numerous times.  We ultimately decided
that we were going to stipulate that a reved protocol was a new
protocol, so no version negotiation would be necessary.  The logic for
ST went that hardware accelerated protocols are on thin ice if they
think they can rev.  You're almost always going to work around
existing protocol bugs before you ever `fix' the protocol, so the
standards committees better be sure of themselves before they forward.
I think iSCSI is in this same position.

FWIW

Steph