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

From: "John Hufferd" <[email-masked]>
Date: Tue, 11 Jun 2002 22:26:16 -0700

Let me state again, this will not fly, please take it off this reflector
and take it to SNIA or any where else.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

Bill Studenmund <[email-masked]>@ece.cmu.edu on 06/11/2002
12:49:49 PM

Sent by:    [email-masked]

To:    Santosh Rao <[email-masked]>
cc:    <[email-masked]>
Subject:    Re: iSCSI: Some proposed vendor-specific (X-) keys

On Tue, 11 Jun 2002, Santosh Rao wrote:

> I don't see why this thread is going forever. There are other scsi
> transports that deal with these types of issues without having to define
> scsi transport protocol keys to indicate vendor_id, product_id and
> product_rev. You can do one of the following :
>
> a) Parse out the DNS name of the target device from the exchanged
> TargetName key, if you're an initiator. Similarly, parse out the DNS
> name of the initiator from the exchanged InitiatorName key, if you're a
> target. Use the DNS name as an indication of which device you're
> speaking to and add your device specific tweaks based on this.

That we can do. But that means that the system adminsitrator or a "smart
agent" has to correlate the info. And, if a device moves, it has to get
involved again to reconfigure.

It could be that this won't be a problem, but it could also be a hassle.

> If the InitiatorName or TargetName is in EUI-64 format, you can obtain
> the vendor_id information from the upper 3 bytes of the EUI-64 name.

That only gets you one of the three keys. :-) The product and revisions
are the ones that are more important if we are bug-compensating. :-)

> b) Send INQUIRY to LUN 0 to determine the vendor_id, product_id and
> product_revisison_level of the device. Use this data to perform any
> device specific tweaks in your software/firmware.

That assumes that the iscsi device is the same as the scsi device. In the
case of an iscsi->FC or iscsi->Parallel SCSI gateway, that's not going to
be the case.

> c) Provide out-of-band static configuration mechanisms in your initiator
> or target to assign a vendor specific identity to 1 or more initiators
> or targets. This allows the target configuration personnel to configure
> the device appropriately for the initiators it is speaking to.

That, like the first option above, involves correlating a lot of info, and
keeping it up to date. Sounds like turning a protocol mess into a
management mess.

> I don't see any need to be defining iscsi login keys to duplicate the
> vendor_id, product_id information.

Well, that's your opinion. Some of us feel that what you describe above is
a hassle we'd rather spare our customers. Especially since happy customers
spend more. :-)

Take care,

Bill

---

From: Bill Studenmund <[email-masked]>
Date: Wed, 12 Jun 2002 09:08:22 -0700 (PDT)

> and take it to SNIA or any where else.

John, would you please stop with these EMails telling people to be quiet?
Do you really think telling folks to hush is 1) polite, 2) something you
are in a position of authority to do, or 3) good for the spec?

I seem to recall at least one recent thread to which you sent out a, "can
we hush now," email that latter turned into a change to the spec. i.e.
because folks didn't hush, we now have a better spec.

So now which would you rather have, a silent list that leads to a flawed
spec, or a list that discusses things (even if the don't fly) and leads to
a better spec?

Take care,

Bill