Subject: RFC 4438 (FC NS MIB) errata and issues

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

Hello,
after studying the recently published Fibre Channel MIB RFCs,
I would like to submit a few comments on RFC 4438 authored by you,
pointing out the 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)  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.

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

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

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

Please comment.

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]                     |
+------------------------+--------------------------------------------+