Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id h1P7KIX18779
	for ips-outgoing; Tue, 25 Feb 2003 02:20:18 -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 h1P7KFW18772;
	Tue, 25 Feb 2003 02:20:15 -0500 (EST)
Received: from localhost (andre@localhost)
	by master.linux-ide.org (8.9.3/8.9.3) with ESMTP id XAA05893;
	Mon, 24 Feb 2003 23:18:21 -0800
Date: Mon, 24 Feb 2003 23:18:21 -0800 (PST)
From: Andre Hedrick <andre@linux-ide.org>
To: Paul Koning <pkoning@equallogic.com>
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
In-Reply-To: <15961.30603.666000.163887@gargle.gargle.HOWL>
Message-ID: <Pine.LNX.4.10.10302242315050.5729-100000@master.linux-ide.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

On Sun, 23 Feb 2003, Paul Koning wrote:

> >>>>> "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.

Not a valid reason in life, "just because", don't do it.
The possible rational for not boosting the rev during the drafts was to
preserve the version 1 for the RFC.

Maybe someone else will will have a valid reason based on IETF history to
not change the version, but the one presented as "no" is far to weak.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

