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

From: [email-masked]
Date: Mon, 10 Jun 2002 14:00:37 -0600

Bill,

It is the place of MIBs and CIM objects to cover items like this. For
diagnostic problems, these are more useful because they are available to
management systems as well as at the two ends of the link. 

Generally, building a duplicate capability to exchange management objects in
protocols adds cost without benefit.

Regards,
Pat

-----Original Message-----
From: Bill Studenmund [mailto:[email-masked]]
Sent: Friday, June 07, 2002 10:27 AM
To: Robert Snively
Cc: 'Ken Sandars'; Ips Reflector (E-mail)
Subject: RE: iSCSI: Some proposed vendor-specific (X-) keys

On Fri, 7 Jun 2002, Robert Snively wrote:

> 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.

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

---

From: Bill Studenmund <[email-masked]>
Date: Mon, 10 Jun 2002 13:57:21 -0700 (PDT)

> management systems as well as at the two ends of the link.

Then why do we have a SendTargets command? Can't that information be
obtained from the MIBs? Isn't it the place of MIBs and CIM objects to
cover items like that too?

I mean, come on, SendTargets has had much more impact on iSCSI than the
three keys we're talking about. It is, as I understand it, the main reason
the text negotiation code supports responses over multiple PDUs. Yes, we
found a lot more uses for this, but SendTargets was (AFAICT) the
instigator.

To answer my own question, I think we have a SendTargets command because
the WG thought the information was useful and didn't want to have to go to
SNMP to get it. Which is a fine reason (and one I agree with).

But to say we shouldn't echo things in the MIB in a way we find useful
when we have opened the door with SendTargets is hypocritical.

> protocols adds cost without benefit.

For the general case, I agree. But last I understood of this thread, we
were not talking about exchanging arbitrary management objects, we were
talking about a key for the vendor, a key for the product name, and a key
for the revision. These are static text strings exchanged once at login.

What is so onerous about them?

They strike me as as useful as aliases, which we permit.

Also, why do you assume that the iSCSI MIBs will be available? While I
expect product vendors will support them, 1) I don't think we can depend
on it being available for iSCSI entities on general-purpose computers
(like things running Windows, Linux, or any of the *BSDs), 2) what about
sites where admins don't like SNMP, and so they either turn it off or
firewall it?

Finally, what about multi-vendor situations? Say I want to run target code
from two vendors on the same box at once? Great for a head-to-head
comparison. I fire one up on a different port (not 3260), and away I go.
While I find it reasonable that each vendor will supply SNMP bits, I find
it unlikely that they will work together. So you get one or the other
showing up in SNMP. While I agree this isn't the common case, I mention it
because it illustrates a case where, "It's available in the MIB," isn't
true.

Take care,

Bill