iSCSI: Implementation identification keys

[Black_David@emc.com]

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
---------------------------------------------------