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

[Bill Studenmund <wrstuden@wasabisystems.com>]

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