From: "bill" <bill@strahm.net>
To: <Black_David@emc.com>, <andre@linux-ide.org>, <ips@ece.cmu.edu>
Subject: RE: iSCSI Version Info: Version 1 and not 0
Date: Tue, 25 Feb 2003 11:21:18 -0800
Message-ID: <000001c2dd03$15e16a90$6701a8c0@mobilebill>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564C93B@corpmx14.us.dg.com>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

I'd agree with this David.  I would claim bumping the version number
would require a new Last Call (or at least a mini one)

I don't see a reason for bumping the version number, as there are no
previous versions of the protocol deployed... I am being strict on
purpose, people that implement drafts get what they deserve... (ok I
paraphrase the boilerplate)

The fastest way to an RFC is to stick with version 1.0 (ok 0.0)

Bill

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of
Black_David@emc.com
Sent: Tuesday, February 25, 2003 7:19 AM
To: andre@linux-ide.org; ips@ece.cmu.edu
Subject: RE: iSCSI Version Info: Version 1 and not 0
Importance: High


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.

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.

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.

> 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.

> 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.

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
----------------------------------------------------