Subject: Re: RFC 4455 (SCSI MIB) errata and issues

From: Keith McCloghrie <[email-masked]>
Date: Mon, 10 Jul 2006 06:37:45 -0700 (PDT)

Alfred,

Thanks for your message.

First, your errata wrt. typos/missing/extraneous words appears
to me to be correct.  However, I'm not sure that any of them will
cause any confusion to a reader, and thus I'm not sure that that they,
by themselves, justify the generation of an RFC Errata.

Second, wrt. Counter32's, ...

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

No.

a) It is not necessary for this DESCRIPTION to specify that the
object's value can wrap from 2^32-1 to 0 -- that is required behaviour
for any object with Counter32 as its SYNTAX, as specified by section
7.1.6 of RFC 2578, which is referenced by section 1 of this RFC.

b) It would be tediously repetitive if every MIB object which has
Counter32 as its syntax had to repeat the whole definition of a
Counter32 in its DESCRIPTION.  The reason why we have Counter32 as a
syntax is to avoid such tedious repetition.  Further, the whole concept
of Textual Conventions is based on including syntax and semantics
via the SYNTAX clause, without having to repeat it.

Instead, the DESCRIPTION needs to focus on what is unique about this
MIB object's behaviour as compared to other Counter32 objects.

c) Regarding this text:

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

Further, section 7.1.6 of RFC 2578 also says:
                                             ...  Discontinuities
   in the monotonically increasing value normally occur at re-
   initialization of the management system, and at other times as
   specified in the description of an object-type using this ASN.1 type.

so one can argue that this text:

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

is also rendundant.  However, since RFC 2578 uses the word "normally",
having this sentence here emphasizes that this object has the "normal"
behaviour.

d) The 'discontinuity time stamp' for re-initialization of the management
system is sysUpTime.  Section 7.1.6 of RFC 2578 continues from the above
quote as follows:

   If such other times can occur, for example, the creation of an object
   instance at times other than re-initialization, then a corresponding
   object should be defined, with an appropriate SYNTAX clause, to
   indicate the last discontinuity. 

So, since no "such other times" have been identified, there is no need
to define an additional 'discontinuity time stamp' object.

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

No.  Table row creation causes a disontinuity in the value of the table.
Thus, the "Last Creation" time is required (see above quotes from RFC 2578)
as a discontinuity timestamp.

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

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

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.

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 10 Jul 2006 06:41:03 -0700 (PDT)

Alfred,

Thanks for your message.

>(1)  outdated DESCRIPTION, inconsistent with introduction
>
>On page 6, Section 5.3 of RFC 4438 says:
>
>   The [FC-SW-3] standard for an interconnecting Fabric consisting of
>   multiple Fabric Switch elements describes the operation of a single
>   Fabric in a physical infrastructure.  The current [FC-SW-4] standard
>   also supports the operation of multiple Virtual Fabrics operating
>   within one (or more) physical infrastructures.  In such a scenario,
>   each Fabric has, of course, its own management instrumentation.  In
>   order to accommodate this scenario, this MIB module defines all
>   Fabric-related information in tables that are INDEXed by an arbitrary
>   integer, named a "Fabric Index".  In a Fabric that is conformant to
>   [FC-SW-3], the value of this Fabric Index will always be 1.
>
>Contrary to that, the DESCRIPTION clause of the t11NsRegFabricIndex
>OBJECT-TYPE, on top of page 16, says:
>
>           However, it is possible that future standards will define
>           how multiple Fabrics, each with its own management
>           instrumentation, could operate within one (or more) physical
>           infrastructures.  To allow for this future possibility, this
>           index value is used to uniquely identify a particular
>           Fabric within a physical infrastructure."
>
>Apparently, the latter text is outdated.
>Please revise this text for an Errata Note.

If this MIB had not yet been published as an RFC, I would make the
change you suggest.  However, a) both paragraphs were correct at the
times they were written, and b) both paragraphs will be out-of-date
as and when FC-SW-5 becomes the current standard.  Thus, I don't
think it is necessary to generate an RFC Errata Note which is
scheduled to itself become out-of-date in 18 months.

>(2)  improper DESCRIPTION text
>
>The DESCRIPTION clause of the t11NsRegClassOfSvc OBJECT-TYPE,
>on page 16/17, says:
>
>           "The class of service indicator.  This object is an
>           array of bits that contain a bit map of the classes of
>           service supported by the associated port.  If a bit in
><< page break >>
>           this object is 1, it indicates that the class of
>           service is supported by the associated port.  When a
>|          bit is set to 0, it indicates that no class of service
>|          is supported by this Nx_Port.
>
>|          If this object has not been not registered for a port,
>           then the instance for that port is not instantiated."
>
>This is partially wrong or misleading.
>Perhaps, this text should be corrected to say:
>
>           "The class of service indicator.  This object is an
>           array of bits that contain a bit map of the classes of
>           service supported by the associated port.  If a bit in
><< page break >>
>           this object is 1, it indicates that the class of
>           service is supported by the associated port.  When a
>|          bit is set to 0, it indicates that the corresponding class
>|          of service is not supported by this Nx_Port.
>
>|          If this object has not been registered for a port,
>           then the instance for that port is not instantiated."

Actually, I think it was intended to be:

          When all bits are set to 0, it indicates that no class of
          service is supported by this Nx_Port.

>(3)  typo (word omission)
>
>The DESCRIPTION clause of the t11NsRegHardAddress OBJECT-TYPE,
>on page 19, contains the bullet:
>
>             - the 8-bit AL-PA (Arbitrated Loop Physical Address)
>|              which an NL_Port attempts acquire during FC-AL
>               initialization in the least significant byte.
>
>It should say:
>
>             - the 8-bit AL-PA (Arbitrated Loop Physical Address)
>|              which an NL_Port attempts to acquire during FC-AL
>               initialization in the least significant byte.

Yes, but the meaning is clear even though there is a grammatical error.

>(4)  inappropriate application of boilerplate text
>
>The text of Section 11, on page 33, begins with the sentence:
>
>            vvvvvvvvvvvvvvvvvvvvv
>   There is one management object defined in this MIB module with a
>|  MAX-ACCESS clause of read-write and/or read-create.  [...]
>                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>This is quite silly -- "and/or" does not make any sense here.
>The single object that falls within this boilerplate category
>can either have a MAX-ACCESS clause of read-write *or* it has
>a MAX-ACCESS clause of read-create (the former is true, as can
>be seen on page 14).  Using "or" instead of "and/or" might be
>aceeptible, but I propose to simplify the sentence further.
>
>The above sentence should be corrected to say:
>
>   There is one management object defined in this MIB module with a
>|  MAX-ACCESS clause of read-write.  [...]
>
>Also, the subsequent boilerplate text,
>
>   Such objects may be considered sensitive or vulnerable in some
>|  network environments.  For example, the ability to change network
>|  topology or network speed may afford an attacker the ability to
>|  obtain better performance at the expense of other network users.  The
>   support for SET operations in a non-secure environment without proper
>   protection can have a negative effect on network operations.
>
>seems rather inappropriate in this case -- [not] sending of
>notifications will rarely "change network topology or network speed".

My co-authors and I have no control over the content of the boilerplate.
Please take up this point with the IETF AD for Network Management.

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

I believe the only above item for which the benefit of an RFC Errata is
worth the cost, is for your item #2 above.  I think the appropriate
action on my part is to submit the correction to the IETF WG first, and
if there are no objections, then to submit it as an RFC Errata.

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 10 Jul 2006 06:41:49 -0700 (PDT)

Alfred,

Thanks for your message.  Two of your suggested changes are
inappropriate:

>(3)  "s/e\.g\./i\.e\./"
>
>On page 19, the t11FamAvailableFcIds OBJECT-TYPE DESCRIPTION clause
>says:
>
>           "The number of Fibre Channel Address Identifiers that are
>           unassigned and currently available for immediate assignment
>|          on the Fabric, e.g., with the 'Clean Address' bit set to 1."
>                          ^^^^
>It should say:
>
>           "The number of Fibre Channel Address Identifiers that are
>           unassigned and currently available for immediate assignment
>|          on the Fabric, i.e., with the 'Clean Address' bit set to 1."
>                          ^^^^

No.  The REFERENCE clause refers to FC-FS, section 15.6.2.4.2 which says:

                              ...  If this bit is set to zero, the
      assigned address may or may not have been used by a previous
      device within R_A_TOV.

Thus, an Address Identifier can be unassigned and currently available
even though it's 'Clean Address' bit is set to 0.

>(4)  redundant text
>
>The DESCRIPTION clauses for t11FamRestart, t11FamRcFabricNotifyEnable,
>t11FamEnable, and t11FamFabricName (on pages 22..24) all contain the
>same phrase:
>
>           For the persistence of values across reboots, see the
>           MODULE-IDENTITY's DESCRIPTION clause."
>
>This is a very complicated way to say nothing.  (The named
>clause says: the behaviour is implementation dependent.)
>Perhaps it would have been better to omit this phrase in all
>instances.

This text was required to be added by the MIB Doctor review, based
on the last paragraph on page 20 of RFC 4181.

The other changes you suggested are typos which, even though your
suggestions would be a grammatical improvement, there is no danger
of any reader being confused by them.  Thus, I do not think that
the cost of having an RFC Errata is justified for this document.

Keith.