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

[Ken Sandars <ksandars@eurologic.com>]

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.


Cheers,
Ken


On Thursday 06 June 2002 4:32 pm, Robert Snively wrote:
> I am not in favor of replicating a standard
> SCSI function that is not part of the link
> protocol outside the SCSI command set.  What this
> does is fragment the driver designs in a way that
> might prevent the usual SCSI driver interoperation with
> parallel SCSI, SBP, FC, and SRP SCSI devices.
> You would then need non-standard SCSI drivers for
> iSCSI devices.
>
> Bob
>
> > -----Original Message-----
> > From: Ken Sandars [mailto:ksandars@eurologic.com]
> > Sent: Thursday, June 06, 2002 8:43 AM
> > To: Ips Reflector (E-mail)
> > 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
> > ksandars@eurologic.com

-- 
Ken Sandars
Eurologic Systems Ltd
ksandars@eurologic.com