Re: SCSI MIB: Open Issues

[Keith McCloghrie <kzm@cisco.com>]

I've been reminded that I haven't responded on this thread (from last month).

> Attempting to push this draft forward, Michelle listed three issues that she
> was looking for guidance on before publishing a new draft:
> 
> > "   scsiLuOutQueueFullStatus   OBJECT-TYPE 
> >
> > [... snip ...]
> >
> > COMMENT: There is no QUEUE FULL in SCSI-3; that's a SCSI-2 term.  Use
> > "TASK SET FULL".
> > 
> > MHS>>>>>>>>>> Knowing that we are SCSI-2 compliant and not 
> > SCSI-3, how should we call this MIB object?
> 
> As has been pointed out, just to keep us all on our toes, the
> current versions are SAM-2 and SCSI-3, with SAM-3 being a work
> in progress, so this change should be made.
 
Right.  The MIB includes SAM-2 in its References section, and so I
looked it up in SAM-2, and found section 5.3.1 which says that "TASK
SET FULL" is a Status Code which is:

  "... sent from the device server to the application client whenever 
   a command ends with a service response of TASK COMPLETE or LINKED
   COMMAND COMPLETE."

Assuming this is indeed what this object counts, then I think its
definition should be something like this:

scsiLuOutTaskSetFulls   OBJECT-TYPE
     SYNTAX         Counter32
     MAX-ACCESS     read-only
     STATUS         current
     DESCRIPTION
          "This object represents the number of times that a Status
           code of 'TASK SET FULL' has been sent at the completion
           of a command for this logical unit."
     ::= { scsiLuEntry 14 }

> > 6)scsiInstAlias, scsiDeviceAlias, etc -why are these admin strings 
> > limited to 79 characters?  IMO, these SYNTAX should just be 
> > SnmpAdminString w/no additional size limitation.
> > 
> > MHS>>>>>>>>>> I would like to hear other opinions.
>
> Unless there's a better reason than "fits conveniently on one line",
> I believe Marj is correct that this restriction should be removed.

I agree.  For the read-only objects, it's up to the agent as to how
long they are), and there are only two such objects which are read-write
(scsiInstAlias and scsiDeviceAlias).

> > 8) scsiDscLunLun - the discovered LUN number is a natural index for this
> > table, there is no need for another artificial index.  So this table 
> > should look like: ......
> > 
> > MHS>>>>>>>>>>> LUN is generally an 8-bytes integer that can be 0:
> > 1. To have it as an index looks heavy from my point of view.
> > 2. It is generally not recommended to have 0 as an index.
> > I would like to get other opinions before doing the changes.
> 
> I'm going to refer this issue to Keith for his opinion.
 
Neither side of the argument seems to me to have a very strong case.

scsiDscLunLun in the scsiDscLunTable, and thus I presume Marjorie's
proposal was for it to have:

     INDEX { scsiInstIndex, scsiDeviceIndex, scsiDscTgtIntrPortIndex,
     scsiDscTgtIndex, scsiDscLunLun }

On the one hand, the argument about "0 as an index" doesn't apply here
(as Marjorie indicated), and having an 8-byte variable in an INDEX
clause is not that much "heavier" than having INDEX clauses
containing five or six variables (of which there are several in this
MIB).

On the other hand, the benefit of having a table's "natural index" in
its INDEX clause is so that an NMS application can query the table to
retrieve the information in a particular row directly without having to
search through the table for it.  Well, in this case, there are no
other columns in the table.  So, the only information available is the
fact that the row is present in the table, i.e., that the SCSI client
(local to the SNMP agent) has discovered this LUN at the remote
target.  Since this table is about "discovering LUNs", it seems to me
that the most likely situation is that an NMS application will *not*
know (a priori) what LUNs to look for in the table, and if this is
true, then there is no benefit in having scsiDscLunLun in the INDEX
clause.

So, if I have to choose, I'd probably choose to leave it as-is, since 
a) a strong enough case has not been made to change, and b) having an
integer rather than a variable-length string in the INDEX clause means
the OIDs in the varbindlist will be a little shorter which will
slightly more efficient.

Keith.