|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI Version Info: Version 1 and not 0On 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.
Home Last updated: Tue Feb 25 20:19:23 2003 12368 messages in chronological order |