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

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Fri, 7 Jun 2002, Robert Snively wrote:

> > Regarding the management component, it is very useful to
> > have the vendor product name and revision number available
> > as part of the iSCSI login negotiation, this would allow
> > the developer/administrator to save the login trace to syslog
> > or something similar for immediate or future analysis or
> > bug reporting.  Without this information embedded in the trace,
> > it would be very difficult to go back to the old log and
> > know for sure which revision of the product you were dealing
> > with.
>
> Not a function of the login.  This is a function of the
> MIB at the management level and of the SCSI Inquiry at
> the driver level.  Unless of course you don't believe in
> standard internet and storage management protocols :-)

No one is saying take this info out of the MIB, just that we see a value
for having the info available in another place as well.

We're defining the iSCSI protocol, and if we feel it needs to do
something, we certainly can (and IMHO should) add it.

And we already have added convenience keys, namely initiator and target
alias.

> > Accessing iSCSI MIB requires a separate step, path, management
> > tool.  Some low end products may not provide it at all.
> > And most importantly, it won't help you if you have to analyze
> > some old traces.
> >
>
> Are there actually devices in an iSCSI environment that will
> have no MIB?

Yes, there most certainly WILL be devices in an iSCSI environment w/o SNMP
support. Any device running a general-purpose OS can't be depended on to
have SNMP support. For Linux and the *BSDs, there is no guarantee that the
snmp support will be running, nor that it has support for the iSCSI MIB.
For Windows, I expect the same will be true (well, we can't depend on the
snmp agent running).

Given that there are a number of admins who consider SNMP to be a pox and
a security liability (doesn't matter if you or I agree or not, they don't
like it), depending on SNMP being around seems an un-robust thing to do.

> > Think of this scenario, suppose you are building an iSCSI HBA
> > and you need to do login interoperability testings with 10
> > different iSCSI targets, wouldn't it be nice that all you have
> > to do is to run the tests and save the login traces, knowing that
> > the product id and revision is embedded in the trace.
>
> Nope.  I know who they are by their MIB or CIM information.

The customer-relations side of me immediately thinks, "that's nice, but
will my customers do that?" While getting the vendor and product might not
be hard, I have little confidence in them getting the revision.

> > I feel that this kind of information should definitely be there,
> > if X key is not appropriate, I would suggest to use regular key.
>
> I feel that this information is already there and creating
> a redundant and non-standard mechanism for replicating this
> information is a real problem.

Why? Well, I get the non-standard part. But what is the problem with
duplicating the information? Especially in a manner that those
implementations that don't like it can ignore it?

Take care,

Bill