RE: iSCSI Version Info: Version 1 and not 0

[Andre Hedrick <andre@linux-ide.org>]

It is a way to fast path login and know without having to play the draft
game.  My group can deal with the draft game, and splitting the paths to
have obsolete_login and rfc_login means a bunch.  Regardless if it is the
initiator or target who is suffering the burden.

Version 0

Parse RFC, Draft 20, 19, 18, 16, 13, 12, 11, 9, 8

Version 1

RFC

Ditto for targets having the play games.

In the past the version was boosted to force adoption and to place notice
of extinction/termination of the drafts.  Now step up and apply the same
rules now, and force the extinction/termination of older products which
jumped the gun, got it wrong, were useful to show the WG got it wrong and
move forward.

The Storage Industry is the ultimate game of last man standing, prior to
iSCSI the SAN was ruled by few and splintered-broken protocol in terms of
failure to support interoperability, keeping version 0 is just like craps
in a bucket.  Version 1 allows everyone to escape the bucket.

The big scream over "plugfests" for version 0 is still valid.
By allowing two versions everyone's requirements are met.
If nothing else it will force another "plugfest", but now it can be done
over the open internet where iSCSI rocks.

I have had two targets on the open internet since draft 13 for testing.
This is where the new plugfest should be executed.  Remember "plugfests"
are for interoperability not for bragging rights of who is the fastest,
but for who is the most compatable.  I doubt there is anyone willing to
step up and toe this line, but I will.

Regards,

Andre Hedrick
LAD Storage Consulting Group

On Tue, 25 Feb 2003, Eddy Quicksall wrote:

> I don't think changing the version number will help that. Because if any
> current software also talks to the early drafts, they have already figured
> out how to distinguish the difference in drafts.
> 
> Eddy
> 
> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com] 
> Sent: Tuesday, February 25, 2003 7:45 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI Version Info: Version 1 and not 0
> 
> > > number - if anyone other than Andre wants it changed now, please
> > > post to the list and explain why.
> 
> As much as I do not want to consume more list bandwidth on this issue...
> 
> > By having the version number 0x00,  there is a hole left for assuming
> > that either side is compliant to somewhere between v12 and RFC.
> 
> I have a mild preference for changing the version to 0x1 for this very
> reason.
> Bumping the version number should help iSCSI nodes when they are 
> talking with one of those "Early Access" iSCSI devices in the field.
> ---
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions
> Hewlett-Packard MS 5668 
> Roseville CA 95747
> cbm@rose.hp.com
> 
> 
> ----- Original Message ----- 
> From: "Nicholas A. Bellinger" <nick@pyxtechnologies.com>
> To: <Black_David@emc.com>
> Cc: "Andre Hedrick" <andre@linux-ide.org>; <ips@ece.cmu.edu>
> Sent: Tuesday, February 25, 2003 10:15 AM
> Subject: RE: iSCSI Version Info: Version 1 and not 0
> 
> 
> > On Tue, 2003-02-25 at 07:18, Black_David@emc.com wrote:
> > > I'm going to put a stop to this here.  The only voice I see for
> > > changing the version number is Andre Hedrick's, hence I believe
> > > there is rough consensus in the IPS WG for not changing the version
> > > number - if anyone other than Andre wants it changed now, please
> > > post to the list and explain why.
> > >
> > 
> > I as well would like to see version 0x01 as the final draft.
> > 
> > > As for specific issues about reasons involved in changes or lack
> > > thereof ...
> > > 
> > > > Considering the handful of changes just related to various parameters
> > > > since the premature changing of the version code to 0x00 after the
> > > > release of the v12 specification in April of 2002.  These alone should
> > > > warrant a final RFC version number.
> > > 
> > > That's not correct - the reset to 0x00 was late, not premature.  The
> > > version number should not have been incremented as it had been several
> > > times prior to then, and was set back to zero to encourage the premature
> > > extinction of implementations that did not match the specification.
> > > Keeping obsolete implementations of old Internet-Drafts alive is
> > > something the IETF discourages - see the standard I-D boilerplate.
> > 
> > Following the previous rule of incrementing the version to encourage the
> > premature extinction of implementations,  would this logic not be the
> > most important when a RFC is finalized?  I do not enjoy kicking a dead
> > horse,  but nontheless it has been 8 draft revisions since the version
> > was incremented to 0x00 in April of 2002.
> > 
> > > 
> > > As for "warrant a final RFC version number" - we missed the train on
> > > that one (partly my fault).  The point in time to change that number
> > > would have been completion of WG Last Call.  As of now when there is
> > > no technical change allowed between IESG approval and RFC publication,
> > > changing the version number to indicate that the document is a published
> > > RFC makes little sense.
> > >
> > 
> > I think this would be an issue for the UNH folks,  who I believe would
> > also would like to see a different version number for RFC compliant
> > implementations.
> > 
> > 
> > > > This also shows how difficult it is to be backwards compatible with
> all
> > > > parameter changes since version 0x00 was set almost 11 months ago
> > > 
> > > That was deliberate.  The goal is that any implementation that is based
> > > on an old version of the iSCSI draft get updated or retired forthwith.
> > > The alternative of having a dozen different version numbers and
> expecting
> > > implementers to implement a dozen different versions of backwards
> > > compatibility based on the version number is unreasonable.  The
> > > development of this belief that the version number would allow detection
> > > and preservation of old implementations is evidence that the reset to
> > > 0x00 was late, not premature.  Any implementation that doesn't comply
> > > to the latest -20 draft is obsolete and needs to be fixed, ASAP.
> > > See the Internet-Draft boilerplate.
> > > 
> > 
> > Then lets make it official as the same point applies here as above.
> > By having the version number 0x00,  there is a hole left for assuming
> > that either side is compliant to somewhere between v12 and RFC.
> > 
> > Again,  is not the extinction on pre-RFC implementations with a final
> > version number most important now?
> >   
> > > > Congrats!  You have pointed to a justified reason to never change the
> > > > version from 0.  Since changing the "wire format" seems unrealistic,
> > > > and this denotes the protocol, it looks like version 0 is glued and
> > > > tatoo'd.
> > > 
> > > That's a bit extreme.  Any serious incompatible protocol change would be
> > > grounds to change the version number, not just a "wire format" change,
> > > but it is (at least my) strong intention (and hope) that there be no
> > > such changes anytime soon.
> > > 
> > > > Applying your logic against the success of the "Plugfests", the
> version is
> > > > a formality ?  This formality logically defines the difference between
> > > > Draft and RFC, otherwise how will the customer know the reported
> feature
> > > > sets.
> > > 
> > > Saying that an implementation complies with the final IESG-approved
> > > version of iSCSI or the RFC when the implementation doesn't is usually
> > > called "fraud".  Customers have more than adequate recourse (legal and
> > > otherwise) to deal with vendors who behave in such a fashion.
> > >
> > 
> > As far as legal ramifications are concerned,  a final RFC version number
> > would solidify the argument for non-interoperable implementations to be
> > held accountable.  By not discerning between v12 and RFC with a version
> > number, one (a lawyer) could argue that any side brandishing a version
> > code, the most distinguishing value of an implementation, of 0x00, 
> > should be considered a compliant RFC version.
> > 
> > Of course this is a stretch of the imagination,  but it still does
> > demonstrate how the change of one bit that is perhaps the most important
> > bit for a valid implementation to carry, is in this case is reasonable
> > concern.   
> >  
> > > Thanks,
> > > --David
> > > ----------------------------------------------------
> > > David L. Black, Senior Technologist
> > > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > > black_david@emc.com        Mobile: +1 (978) 394-7754
> > > ----------------------------------------------------
> > > 
> > 
> > Thanks,
> > 
> > Nicholas A. Bellinger
> > PyX Technologies, Inc.
> > 
> > 
>