SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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.
    
    


Home

Last updated: Tue Feb 25 20:19:23 2003
12368 messages in chronological order