Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id h1Q8hda03025 for ips-outgoing; Wed, 26 Feb 2003 03:43:39 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from master.linux-ide.org (astound-64-85-224-253.ca.astound.net [64.85.224.253]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h1Q8hXW03013 for ; Wed, 26 Feb 2003 03:43:37 -0500 (EST) Received: from localhost (andre@localhost) by master.linux-ide.org (8.9.3/8.9.3) with ESMTP id AAA10211; Wed, 26 Feb 2003 00:28:34 -0800 Date: Wed, 26 Feb 2003 00:28:34 -0800 (PST) From: Andre Hedrick To: Eddy Quicksall cc: "Mallikarjun C." , ips@ece.cmu.edu Subject: RE: iSCSI Version Info: Version 1 and not 0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk 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" > > To: > > Cc: "Andre Hedrick" ; > > 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. > > > > > > > > >