Subject: RFC 4455 (SCSI MIB) errata and issues

From: Alfred Hönes <[email-masked]>
Date: Sat, 8 Jul 2006 11:49:19 +0200 (MESZ)

Hello,
triggered by the recent publication of the iSCSI MIB RFC, I have
also studied the earlier RFC 4455 (SCSI MIB) authored by you.
I would like to submit a bunch of comments on this RFC as well,
pointing out some issues I found with the RFC text, and supplying
material for an appropriate RFC Errata Note.

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

(1)  typo

Section 3.5 of RFC 4455, on page 11, says:

   The management of SCSI commands is beyond the scope of this MIB
|  module.  Future SCSI Command MIB module can link to this MIB module,
   through the use of Object Identifiers (OIDs) or INDEX values of
   appropriate tables.

It should say:
                                          v
   The management of SCSI commands is beyond the scope of this MIB
|  module.  Future SCSI Command MIB modules can link to this MIB module,
   through the use of Object Identifiers (OIDs) or INDEX values of
   appropriate tables.

(2)  typo

Section 4.1 of RFC 4455, on page 11, says:

   The scsiDeviceGroup group contains the objects general to each SCSI
   instance: instance, device, and port objects.  It contains also the
   objects referring to the transport(s) used by those SCSI instances.
|  This group is mandatory for all SCSI managed system.

It should say:

   The scsiDeviceGroup group contains the objects general to each SCSI
   instance: instance, device, and port objects.  It contains also the
   objects referring to the transport(s) used by those SCSI instances.
|  This group is mandatory for all SCSI managed systems.
                                                      ^

(3)  word omission

The second paragraph of Section 4.7, on page 12, says:

   Managed systems acting as a SCSI target device and port and running
|  at high speed supporting should implement this group.

It should say:

   Managed systems acting as a SCSI target device and port and running
|  at high speed supporting statistics should implement this group.
                           ^^^^^^^^^^^

(4)  word omission

The second paragraph of Section 4.11, on page 13, says:

   Managed systems acting as a SCSI initiator device and port and
   running at high speed supporting should implement this group.

It should say:

   Managed systems acting as a SCSI initiator device and port and
|  running at high speed supporting statistics should implement this
   group.
                                   ^^^^^^^^^^^

(5)  text truncation

The DESCRIPTION clause of the scsiTransportFCP OBJECT-IDENTITY,
on page 24, says:

        "This identity identifies a Fibre Channel Protocol for SCSI,
        Second Version."

This sentence omits the most significant word, "transport".
It should say:

        "This identity identifies a Fibre Channel Protocol for SCSI,
|       Second Version, transport."
                      ^^^^^^^^^^^
or:
                                 vvvvvvvvvvvvvvvvvvv
|       "This identity identifies transport via the Fibre Channel
        Protocol for SCSI, Second Version."

(6)  incomplete description, and incomplete functionality ??

The DESCRIPTION clause of the scsiPortBusyStatuses OBJECT-TYPE,
on page 30, says:

        [...]
        Discontinuities in the value of this counter can occur at re-
        initialization of the management system."

Admittedly, this is true, but more importantly, the counter can
wrap back from 2^32-1 to 0 !!!
That should be noted there, and it should be detectable by means
of some 'discontinuity time stamp' object in the MIB module.

(7)  as (6) above

The same issue as stated in item (6) above also holds for the
scsiIntrDevOutResets OBJECT-TYPE, on page 33.

(8)  as (6) above

The same issue as stated in item (6) above also holds for all
counters in the SCSI Initiator Port Table, i.e. the DESCRIPTIONs
of the scsiIntrPortOutCommands, scsiIntrPortWrittenMegaBytes,
scsiIntrPortReadMegaBytes, and scsiIntrPortHSOutCommands
OBJECT-TYPEs, on page 35.

(9)  typo

The ASN.1 comment on top of page 36,

   -- SCSI target device discovered or authorized to attach each of the
   -- SCSI initiator ports of each SCSI initiator device of each
   -- instance.

should say:
                        v
|  -- SCSI target devices discovered or authorized to attach each of the
   -- SCSI initiator ports of each SCSI initiator device of each
   -- instance.

(10)  typo (spurious word)

The DESCRIPTION clause of the scsiDscTgtIndex OBJECT-TYPE, on page 37,
says:

        "This object is an arbitrary integer used to uniquely identify
        a particular SCSI target device either discovered by, or
|       configured for use with, one or more ports scsiDscTgtName of
        a particular device within a particular SCSI instance."

The spurious word "scsiDscTgtName" should be deleted.
Thus, it should say:

        "This object is an arbitrary integer used to uniquely identify
        a particular SCSI target device either discovered by, or
|       configured for use with, one or more ports of a particular
        device within a particular SCSI instance."

(11)  typo (spurious word)

The DESCRIPTION clause of the scsiDscTgtDevOrPort OBJECT-TYPE,
on page 37, says:

        "This object indicates whether this entry describes a
|       configured SCSI target device name (and applies to all ports
        on the identified SCSI target device) or an individual SCSI
        target port."

The spurious word "name" should be deleted.
Thus, it should say:

        "This object indicates whether this entry describes a
|       configured SCSI target device (and applies to all ports
        on the identified SCSI target device) or an individual SCSI
        target port."

(12)  similar to (6), and semantic overloading

The DESCRIPTION clause of the scsiDscTgtInCommands OBJECT-TYPE,
on page 38, says:

         [...]
         Discontinuities in the value of this counter can occur at re-
         initialization of the management system, and at other times as
         indicated by the value of scsiDscTgtLastCreation."

The literally same wording is repeated on page 39 in the DESCRIPTION
clauses of the OBJECT-TYPEs
-  scsiDscTgtWrittenMegaBytes,
-  scsiDscTgtReadMegaBytes, and
-  scsiDscTgtHSInCommands.

See the explanations for item (6) above.

The DESCRIPTION clause of the scsiDscTgtLastCreation OBJECT-TYPE,
at the bottom of page 39, says:

        "This object represents the value of sysUpTime when this row
|       was created."

Counter wrap-around isn't table row creation.
Thus, isn't the above referral heavy semantic overloading of
"Last Creation" time ??

(13)  typo

The ASN.1 comment near the bottom of page 43,

|  --***** Table of SCSI Target Device Attached to local SCSI
   --***** Initiator Ports

should say:
                                      v
|  --***** Table of SCSI Target Devices Attached to local SCSI
   --***** Initiator Ports

(14)  as (6) above

The DESCRIPTION clauses, on page 49, of the OBJECT-TYPEs
-  scsiTgtPortInCommands,
-  scsiTgtPortWrittenMegaBytes,
-  scsiTgtPortReadMegaBytes, and
-  scsiTgtPortHSInCommands
contain the sentence,

        Discontinuities in the value of this counter can occur at re-
        initialization of the management system."

the explanations given for item (6) above apply here as well.

(15)  improper wording

The DESCRIPTION clause of the scsiTgtPortHSInCommands OBJECT-TYPE,
on page 49, says:

        "This object represents the number of commands received.  This
|       object provides support for systems that can quickly generate a
        large number of commands because they run at high speed.
        [...]

Because this object counts *incoming* commands, the word "generate"
is considered improper and should be replaced by "accept" (or similar):

        "This object represents the number of commands received.  This
|       object provides support for systems that can quickly accept a
        large number of commands because they run at high speed.
        [...]

(16)  like (12) above

The SCSI Authorized Initiator table suffers from the same problems
as the Target Device Discovered Table (Item (12) above):

The DESCRIPTION clauses (on pages 52/53) of the OBJECT-TYPEs
-  scsiAuthIntrAttachedTimes,
-  scsiAuthIntrOutCommands,
-  scsiAuthIntrReadMegaBytes,
-  scsiAuthIntrWrittenMegaBytes, and
-  scsiAuthIntrHSOutCommands
each contain the identical sentence:

        Discontinuities in the value of this counter can occur at re-
        initialization of the management system, and at other times as
        indicated by the value of scsiAuthIntrLastCreation."

and the DESCRIPTION clause of the scsiAuthIntrLastCreation OBJECT-TYPE,
on page 53, says:

        "This object indicates the value of sysUpTime when this row was
        last created."

Counter wrap-around isn't table row creation.
Thus, isn't the above referral heavy semantic overloading of
"Last Creation" time ??

(17)  again, like (12) above

The SCSI LU table suffers from the same problems as above:

The DESCRIPTION clauses (on pages 60..62) of the OBJECT-TYPEs
-  scsiLuInCommands,
-  scsiLuReadMegaBytes,
-  scsiLuWrittenMegaBytes,
-  scsiLuInResets,
-  scsiLuOutTaskSetFullStatus, and
-  scsiLuHSInCommands
each contain the identical sentence:

        Discontinuities in the value of this counter can occur at re-
        initialization of the management system, and at other times as
        indicated by the value of scsiLuLastCreation."

while the DESCRIPTION clause of the scsiLuLastCreation OBJECT-TYPE,
on page 62, says:

        "This object indicates the value of sysUpTime when this row was
        last created."

Again, counter wrap-around isn't table row creation.
Thus, isn't the above referral heavy semantic overloading of
"Last Creation" time ??

(18)  MIB structure inconsistency ???

On page 66, RFC 4455 says:

   --********************** Notifications ******************************
|  -- scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB  2 }
                                                        ^^^

   scsiNotificationsPrefix OBJECT IDENTIFIER
                                ::= { scsiNotifications 0 }

This is very notable, since on page 23, the same RFC has
specified:

   --****************** Structure of the MIB **************************
|  scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB 0 }
   [...]
                                                    ^^^

At least, giving different values for the same object name
(though one instance is in an ASN.1 comment) is irritating.

The trailing OID component '0' is required for SNMPv1 backwards
compatibility.  Since it is already contained in the effective
'scsiNotifications' OID (as specified on page 23), the additional
introduction of 'scsiNotificationsPrefix' seems to be very
redundant.  Its use could be easily substituted by the use of
'scsiNotifications' in the two NOTIFICATION-TYPE invocations
on page 66, which would have resulted in the OID assignments,

   scsiTgtDeviceStatusChanged NOTIFICATION-TYPE
      [...]
   ::= { scsiNotifications 1 }

and

   scsiLuStatusChanged NOTIFICATION-TYPE
      [...]
   ::= { scsiNotifications 2 }

as usual in IETF MIBs.

That is now too late to be corrected, but the misleading ASN.1 comment
on page 66 of the RFC, as noted above, should be corrected to say:

   --********************** Notifications ******************************
|  -- scsiNotifications OBJECT IDENTIFIER ::= { scsiMIB  0 }
                                                        ^^^

(19)  typo

The ASN.1 comment on page 67,

      -- Conditionally mandatory groups to be included with
      -- the mandatory groups when the implementation has
|     -- SCSI target device.

should say:

      -- Conditionally mandatory groups to be included with
      -- the mandatory groups when the implementation has
|     -- SCSI target devices.
                           ^

(20)  typo

The DESCRIPTION clause of the scsiInitiatorDeviceGroup OBJECT-GROUP
invocation, on page 71, says:

        "This group is relevant for s SCSI initiator device and port."

should say:
                                    v
|       "This group is relevant for a SCSI initiator device and port."

or even better:

|       "This group is relevant for SCSI initiator devices and ports."

(21)  duplicate / redundant text

Section 10, on page 76, contains the 5th paragraph:

   We assume an HBA as the SCSI initiator device and a disk as the SCSI
   target device.  We assume that the SCSI target device has one logical
   unit, addressed by Logical Unit Number set to 0 (LUN0), which is the
   default LUN.  Parallel SCSI has only port identifiers, no port names.
   The transport pointer for parallel SCSI is set to 0 since there is no
   reference transport (SPI) MIB module.

This text is a slightly modified restatement of what is said in the
directly preceeding paragraph.
Thus, this paragraph should be deleted.

Please comment.

Apparently, many of the items above should be addressed by an
RFC Errata Note.  Other items should be considered in your WG
for a future update to the MIB module.

Preferrably, you should submit an Author's Errata Note to the
RFC Editor's RFC Errata web pages, making freely use of the
material supplied above.  But if you like, I can formally
submit an Errata Note on my own, with your consent.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+