RE: iSCSI: Implementation identification keys

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

David,
Thanks for the concise summary.  

I have been silent on this thread hoping it would die it's own death, since
we long ago agreed not to add any more gratuitous keys that weren't required
for protocol functionality (see the old threads on "TargetAlias" and
"SendTargets").  Otherwise, the list of things "it would be nice to have"
will never end.

Some posters seem to think that a lack of comment indicates support, so I'd
like to add my voice to Pat's against the proposed vendor/product/rev keys
for all the reasons that have been sited so many times on this list.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Wednesday, June 12, 2002 5:37 PM
> To: ips@ece.cmu.edu
> Subject: iSCSI: Implementation identification keys
> 
> 
> The signal to noise ratio on the X-keys thread is getting rather low,
> hence the deliberate change of subject.
> 
> A major problem is that there are two motivations for the proposed
> keys, as Bill Studenmund summarized:
> 
> > A) makes it easy to identify vendor/product/rev. All you 
> have to do is
> > capture a session (tcpdump/ethereal), and you have it. Info 
> is in one
> > place.
> > 
> > B) Identify system on other side of connection/session to 
> turn on/off
> > quirk support.
> 
> A) is a fine motivation, but B) is problematic, and it 
> appears to be the
> more important one from discussion on the list.  I'm rather 
> uncomfortable
> surrendering to this motivation this early in the game.  This position
> is similar to the reason why we had to stop the practice of 
> incrementing
> the iSCSI version number every time the revision number of the draft
> changed -- I think it's still the case that the right thing 
> to do in the
> IETF process is to aim for interoperability in the standard 
> rather than
> put in support for divergent implementations.
> 
> That said, the "quirk support" may be inevitable, and the quirks are
> hard to stamp out once one goes down that path.  For example, EMC's
> support matrix (published on our web site) includes quirk support for
> SCSI and Fibre Channel (and yes, there are a number of parallel SCSI
> quirks, even though parallel SCSI has been around for a very 
> long time).
> 
> I think the use of X- keys and shoehorning this into the main 
> iSCSI draft
> at this late stage is inappropriate - IMHO, this should be 
> done right or not
> at all.  I believe the best course of action would be for 
> those interested
> in this sort of feature (and you know who you are from the 
> list discussion)
> to write up a separate draft introducing new keys that we can consider
> separately.  At this juncture, it appears to me that 
> insisting on having
> this in the main iSCSI draft is likely to result in delay - based on
> the list discussion, I think rough consensus is going to be 
> hard to reach
> on this one, hence the desire for a second draft that can 
> take as long as
> it needs.
> 
> This gets to the next point I wanted to get to.  IETF process does not
> require rewriting an entire RFC in order to make changes - a 
> new RFC can
> update an existing RFC, and hence it's possible to make small changes
> fairly quickly (without reopening everything in the RFC for changes).
> Of course "fairly quickly" depends on there being rough consensus for
> the changes ... but there's no need to go through resolution 
> of everything
> that anyone might want to change/improve/remove/etc. in the main iSCSI
> document just to make minor changes (e.g., for 
> interoperability problems),
> and iSCSI was designed so that logon negotiation would be extensible.
> 
> 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
> ---------------------------------------------------
>