iSCSI version numbers

[Black_David@emc.com]

Let me also point out that Matt's expectation of
interoperability of implementations based on
Internet-Drafts is misplaced.  Vendors who ship
products based on I-Ds do so at their own risk -
there's more than enough warning that things are
subject to change in the standard Internet-Draft
boilerplate.

My preference would be to hold the version number
at 0 until the iSCSI spec is done.  This will give
vendors who have shipped to Internet-Draft versions
an incentive to promptly update their code.
If future plugfest events need to test multiple
implementation variants, they can do roughly what
was done this time - temporarily define the version
numbers that will distinguish the variants *for that
event only*.  I would suggest use of *large* numbers
for this purpose to avoid this sort of confusion
in the future.

Thanks
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From:	Robert D. Russell [SMTP:rdr@mars.iol.unh.edu]
> Sent:	Wednesday, July 18, 2001 8:23 PM
> To:	Matt Wakeley
> Cc:	ips
> Subject:	Re: London: Call for agenda items
> 
> Matt:
> 
> The problem is that there is no consensus version 1.
> Most current "draft 6" implementations are really implementing
> "draft 6+", where the "+" comes from the many corrections,
> additions, deletions, etc. that appeared on the mailing list after
> draft 6 was posted and that were necessary to make draft 6 workable.
> In particular, most are using the new opcodes
> because the opcodes published in draft 6 were a surprise, were widely
> disliked, and were replaced (twice) in subsequent mailings.
> There is no approved document that defines version 1.
> The best hope for interoperabilty is to produce a stable standard
> draft that can gain a reasonable consensus and then finalize the
> process.
> 
> Bob
> 
> On Wed, 18 Jul 2001, Matt Wakeley wrote:
> 
> > Robert,
> > 
> > Your idea kills any hope of interoperability if some vendors choose to
> ship
> > products based on certain revisions of the draft - the current "0 vs 6"
> case
> > in point.
> > 
> > -Matt
> > 
> > "Robert D. Russell" wrote:
> > > 
> > > Marjorie:
> > > 
> > > True there have been new opcodes, but there have been new opcodes
> > > before.  My point is why start changing the version number NOW
> > > when we haven't been doing it before?  By your reasoning, we should
> > > be up to version 7 now, not version 2.
> > > A problem with changing the version numbers is that the current
> > > scheme by which an initiator offers versions to a target is that
> > > there can be no holes in the offering.  If the version numbers
> > > change too quickly it will be a lot of work to track the
> > > intermediate versions.  A version change should be really significant,
> > > ie. at the IETF level, not at the draft level.  We are still at the
> > > draft level.
> > > Bob Russell
> > > 
> > > On Wed, 18 Jul 2001, KRUEGER,MARJORIE (HP-Roseville,ex1) wrote:
> > > 
> > > > >  My personal opinion is still that draft 7 is really just
> > > > > a refinement and clarification of ambiguities in draft 6, and does
> > > > > not add any major features that justify a version change. However,
> ...
> > > >
> > > > Not true, there are significant changes to opcodes and some change
> to header
> > > > fields between v6 and v7 - that should *at least* be a criteria for
> a
> > > > version number change!
> > > >
> > > > Marj
> > > >
> >