RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (1)

RFC 4455, "Definition of Managed Objects for Small Computer System Interface (SCSI) Entities", April 2006

Source of RFC: ips (tsv)

Errata ID: 83

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Verifier Name: Keith McCloghrie
Date Verified: 2006-07-10

Page 66 says:

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

It should say:

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

Notes:

There are two issues here:

1) a typo in the ASN.1 comments. The correct OID is { scsiMIB 0 } because
that's what the MIB compiler will process, i.e., the MIB compiler will
not process the ASN.1 comment. It is not too late to correct the typo
in the ASN.1 comment.

2) In the development of the MIB, the change to use the OID structure
recommended by Appendix D of RFC 4181 caused the use of
scsiNotificationsPrefix (as the means to include zero in the OIDs of
the notifications) to become no longer necessary, and it would have
been better if it had been removed. But, it is now too late to remove
scsiNotificationsPrefix.

Status: Rejected (1)

RFC 4455, "Definition of Managed Objects for Small Computer System Interface (SCSI) Entities", April 2006

Source of RFC: ips (tsv)

Errata ID: 82

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-07-08
Rejected by: Keith McCloghrie
Date Rejected: 2007-07-10

 

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

Notes:

Notes from Keith:
I think the only one of your corrections which is needed to avoid the
possibility of causing confusion to a reader is the one regarding the
OID of scsiNotifications. If an RFC Errata Note is created because
of that one, and all the other typos that you have found are also
included in the same RFC Errata Note, then my fear is that the one
which could be important will get buried in the triviality of the
others. Thus, I suggest that an RFC Errata Note, if created, should
only mention the OID of scsiNotifications.

I don't believe there are any items which need to be considered by the
WG for a future update to the MIB module.

from pending

Report New Errata