MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15961.30603.666000.163887@gargle.gargle.HOWL>
Date: Sun, 23 Feb 2003 20:38:19 -0500
From: Paul Koning <pkoning@equallogic.com>
To: andre@linux-ide.org
Cc: Ranga.Sankar@netapp.com, Julian_Satran@il.ibm.com,
   David.Wysochanski@netapp.com, ips@ece.cmu.edu, owner-ips@ece.cmu.edu,
   dl-iscsi-eng@netapp.com
Subject: RE: iSCSI: version number
References: <B80BB115B1994D4BABC1B81FFFA1CAC71A8595@rtpexc01.hq.netapp.com>
	<Pine.LNX.4.10.10302221858060.19800-100000@master.linux-ide.org>
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

>>>>> "Andre" == Andre Hedrick <andre@linux-ide.org> writes:

 Andre> Ranga:

 Andre> Applying your logic against the success of the "Plugfests",
 Andre> the version is a formality ?  This formality logically defines
 Andre> the difference between Draft and RFC, otherwise how will the
 Andre> customer know the reported feature sets.  This is a
 Andre> distinction which allows people to make decisions.  Without
 Andre> the forcing the version to 1, there is no way to tell the
 Andre> difference in products.  

Then again, drafts have no status, so the protocol version field that
was used in drafts, or a desire to be different from drafts, isn't a
particularly good argument.  You may recall that some people asked for
version numbers to go up as new drafts were issued, and they were told
"no".  

I'd suggest leaving the version number alone.

    paul