RE: iscsi: version number in draft 11

[Eddy Quicksall <Eddy_Quicksall@ivivity.com>]

I agree. One thing we could do is to all agree to a "vendor specific" key
that is used during our testing. Being vendor specific, it could still be
used in the future.

I suggest something like:

X-draft=11

or

X-draft=9,11

(that is assuming that no one will have a company called "draft") :-)

Eddy

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Wednesday, February 27, 2002 6:13 PM
To: rdr@io.iol.unh.edu; ips@ece.cmu.edu
Subject: RE: iscsi: version number in draft 11


Folks, 

I've warned in the past that this use of version numbers
is going to cause problems, as it encourages the longevity
of obsolete implementations that don't interoperate.  Version
numbers should NEVER have been used for identification of
draft versions - in 20/20 hindsight a text key that could
have been dropped from the final RFC would have been better.

Prior guidance from the ADs has been that a version number
change from 0 to 1 in going to RFC would be ok.  Let's
reset the version number to 0, and anyone still using
something based on a draft from back when the version number
was still 0 has something truly ancient and is SOL.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From: Robert D. Russell [mailto:rdr@io.iol.unh.edu]
> Sent: Wednesday, February 27, 2002 2:36 PM
> To: ips@ece.cmu.edu
> Subject: iscsi: version number in draft 11
> 
> 
> Julian:
> 
> The version number in draft 10-94 is still 0x3,
> the same as it was in draft 9 and draft 10.
> 
> Would you please change it to 0x4 for draft 11.
> 
> Of course these numbers still need to be taken with
> a grain of salt, but testing is considerably
> simpler and more robust when one side identifies the
> draft it intends to conform to in a manner that can
> be checked by the other side.
> 
> Thanks,
> 
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774
>