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

From: Bill Studenmund <[email-masked]>
Date: Thu, 6 Jun 2002 16:23:37 -0700 (PDT)

On Thu, 6 Jun 2002, Dennis Young wrote:

> I think this is useful besides run time interoperability purpose
> (this is a hot button and can be argued either way, just like the
> version # of the draft), such as for reporting problems on a remote
> device to the device manufacturer.

I agree with Dennis.

I think though that Paul is right that these keys should NOT be used as an
excuse to permit interoperability problems. They can though be
informative. If a customer has problems with my code, I'd love to have
revision info, which could be conveniently conveyed with these keys.

As to the poster this morning (whose message I deleted too fast) who said
this is wrong because the info should be available in SCSI sense data, I
disagree. Consider the case of an iscsi->parallel scsi gateway (a box that
has a traditional scsi drive, and exports it over iSCSI). There the scsi
sense data & mode pages are (well might be) those of the attached drive,
which can be from a different vendor than the iscsi device.

Also, don't forget we're talking about an optional thing (they are X-keys
after all). :-)

Take care,

Bill

---

From: Dennis Young <[email-masked]>
Date: Thu, 6 Jun 2002 14:35:18 -0700

-Dennis

>-----Original Message-----
>From: Bob Mastors [mailto:[email-masked]]
>Sent: Thursday, June 06, 2002 11:18 AM
>To: Ken Sandars; Ips Reflector (E-mail)
>Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys
>
>
>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
>
>----- Original Message ----- 
>From: "Ken Sandars" <[email-masked]>
>To: "Ips Reflector (E-mail)" <[email-masked]>
>Sent: Thursday, June 06, 2002 9:43 AM
>Subject: iSCSI: Some proposed vendor-specific (X-) keys
>
>
>> 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]
>