Subject: RE: iSCSI Version Info: Version 1 and not 0
From: "Nicholas A. Bellinger" <nick@pyxtechnologies.com>
To: Black_David@emc.com
Cc: Andre Hedrick <andre@linux-ide.org>, ips@ece.cmu.edu
In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C93B@corpmx14.us.dg.com>
References: <277DD60FB639D511AC0400B0D068B71E0564C93B@corpmx14.us.dg.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 25 Feb 2003 10:15:24 -0800
Message-Id: <1046196928.2720.66.camel@subjekt>
Mime-Version: 1.0
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

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.