Subject: iSCSI: Some proposed vendor-specific (X-) keys

From: Ken Sandars <[email-masked]>
Date: Thu, 6 Jun 2002 15:43:09 +0000

Hi all,

Can all you implementers out there consider this proposal please? This is 
intended to be an aid to interoperability. Obviously once the spec is 
approved and everyone is fully complient there will be no need for this.

This proposal is in no means intended to go into the specification (unless 
people REALLY want it), so feel free to skip this message now ;-)

I suggest three vendor specific declarative keys which MAY/SHOULD be sent 
during the login phase (during the operational parameter negotiation stage):

X-vendor
X-product
X-revision

These all contains strings, eg:

X-vendor=fredsIscsiShop
X-product=YetAnotherIscsiTarget
X-revision=1.003

These keys follow the SCSI inquiry command fields in terms of names, and are 
used to identify the iSCSI node's information.

What does this achieve? I'm looking for an opportunity to provide automated 
interoperability between systems which are not yet fully complient.

But I hear you think, "But why don't they just fix them?", and I have to 
agree.

However, there are a number of iSCSI products which work wonderfully well 
already out there (as long as you don't excite one of their quirks). If you 
find out what you are connecting with during login, you can decide what 
things you should or shouldn't do with it.

-- 
Ken Sandars
Eurologic Systems Ltd
[email-masked]

---

From: "Bob Mastors" <[email-masked]>
Date: Thu, 6 Jun 2002 12:17:38 -0600

I like it.
Otherwise the user has to configure the initiator with the target type and
the target with the initiator type.
It is unlikely that this problem will disappear for a long time if ever.
As the threads on the C bit has shown there will be lots of ways to
implement the spec and probably no device will correctly support all possibilities.
I am already putting "if (vendor)" code in my implementation. Maybe in a few
years I will not need it. But until then it would be nice if I could dynamically determine
vendor information for iscsi so the user does not have to configure it.
Bob

---

From: Paul Koning <[email-masked]>
Date: Thu, 6 Jun 2002 16:06:02 -0400

>>>>> "Bob" == Bob Mastors <[email-masked]> writes:

 Bob> I like it.  Otherwise the user has to configure the initiator
 Bob> with the target type and the target with the initiator type.  It
 Bob> is unlikely that this problem will disappear for a long time if
 Bob> ever.  As the threads on the C bit has shown there will be lots
 Bob> of ways to implement the spec and probably no device will
 Bob> correctly support all possibilities.  I am already putting "if
 Bob> (vendor)" code in my implementation. Maybe in a few years I will
 Bob> not need it. But until then it would be nice if I could
 Bob> dynamically determine vendor information for iscsi so the user
 Bob> does not have to configure it. 

Oh boy, now I'm well and truly frightened.

I read your message as saying that there isn't going to be
interoperability for several years.  Sorather than create a serious
incentive for implementers to fix their defects, we should implement a
way to have them report which collection of defects they implement so
we can invoke workaround collection #42.  Of course, the larger the
collection of crocks we work around, the larger the number of bugs in
implementations that everyone else will have to work around.

In the words of a well known American, "Just Say NO".

     paul