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

From: Robert Snively <[email-masked]>
Date: Fri, 7 Jun 2002 08:31:45 -0700

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:[email-masked]]
> 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.
>

---

From: Bill Studenmund <[email-masked]>
Date: Fri, 7 Jun 2002 10:27:25 -0700 (PDT)

> going to help iSCSI achieve its goals.

Question about the operational components being able to determine this
info. iSCSI is, in terms from SAM-2, a Service Delivery Subsystem (SDS).
While many implementations act as scsi servers (disks & tapes, etc.),
that's not part of the spec.

So I'm confused how an SDS answers a SCSI INQUIRY. I thought that was the
domain of the device(s) at the other end of the connection, not the domain
of the connection itself.

Take care,

Bill