RE: iSCSI Version Info: Version 1 and not 0

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

Two corrections:

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

Should be:

Parse RFC, Draft 20, 19, 18, 16, 13, 12

> failure to support interoperability, keeping version 0 is just like craps

Should be:

failure to support interoperability, keeping version 0 is just like crabs


Apology for the two errors.

Andre Hedrick
LAD Storage Consulting Group

On Tue, 25 Feb 2003, Andre Hedrick wrote:

> 
> 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.
> > > 
> > > 
> > 
>