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

[Robert Snively <rsnively@Brocade.COM>]

Ken,

In my experience, "vendor specific" is a synonym for
"non-interoperable".  Realistically, if there is any tuning
to be done with respect to the iSCSI transport behavior, then
it should be done through standardized mechanisms during
the login, not through vendor specific mechanisms.

The management component already has standard mechanisms
for determining such information, including MIBs and CIM
objects.  The operational components already have standard
mechanisms for determining such information, including
SCSI INQUIRY commands.  I cannot see how this additional
(non-standard) mechanism for capturing this information is
going to help iSCSI achieve its goals.

Those legacy devices that are being supported by non-standard
programs and non-standard protocol events are simply NOT
compliant iSCSI devices.  If anyone cares about using them
in an iSCSI environment, they must be upgraded to iSCSI
compliance.

Bob



> -----Original Message-----
> From: Ken Sandars [mailto:ksandars@eurologic.com]
> Sent: Friday, June 07, 2002 4:20 AM
> To: Robert Snively; Ips Reflector (E-mail)
> Subject: Re: iSCSI: Some proposed vendor-specific (X-) keys
> 
> 
> Hi Bob,
> 
> No, that's not what I'm suggesting. I was not looking at 
> affecting anything 
> at the SCSI layer. This proposal is purely communicating 
> information between 
> the iSCSI (transport) layers. I wouldn't expect this information to 
> necessarily be passed to the SCSI layer on either target or initiator.
> 
> This information was intended to be used at the iSCSI layer 
> to "tune" iSCSI 
> behaviour, and to provide additional information to the 
> management component 
> of each implementation. The latter reason is more important 
> as it can assist 
> in maintaining an iSCSI SAN, and this is where I'd like to 
> see this end up.
>