Re: [imss] FW: MIB Doctor review draft-ietf-imss-fc-fam-mib-01.tx

[Keith McCloghrie <[e-mail]>]

I've put a new version at:

   ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-fam-mib-02.txt

> Keith, I also did a quick check on rev 02 that you pointed to.
> Here are some additional nits that I found, and that you might
> as well tidy up while working on it:
> 
> - issues with citations/references:
>   !! Missing Reference for citation: [RFC2741]
>   P005 L031:    single SNMP agent having multiple AgentX [RFC2741] sub-agents, with
 
I have removed "[RFC2741]".

>   !! Missing Reference for citation: [RFC2863]
>   P004 L044:    extensions to the standard IF-MIB [RFC2863] for Fibre Channel
>   (you seem to be using [IF-MIB] and also [RFC2863]. I prefer the latter)
 
I have changed "[RFC2863]" to "[IF-MIB]"

> - I would change (2 times):
>     REVISION    "200510070000Z"
>     DESCRIPTION
>            "Initial version of this MIB module."
>   into:
>     REVISION    "200510070000Z"
>     DESCRIPTION
>            "Initial version of this MIB module, published as RFCyyyy."
>            -- RFC-Editor, pls fill in xxxx for RFCyyyy
   
How is the RFC Editor going to know what "xxxx" is ??   I have changed it
to :

  -- RFC Editor: replace yyyy with actual RFC number & remove this note

> - For consistency, I think I would change 
>      t11FabricAddrMgrMIB MODULE-IDENTITY
>   into
>      t11FamMIB MODULE-IDENTITY
>   but as I said, it is a nit.
 
Thanks for catching this, but I believe that consistency requires it to be:

  t11FcFabricAddrMgrMIB MODULE-IDENTITY

> - indentation for various MIB objects and descriptions is inconsistent
 
I've fixed those that I could find.

> Could you also comment on:
> 
>    W: f(t11fc.mi2), (699,13) Row "t11FamIfEntry" does not have a consistent indexing
>       scheme - cannot specify an index item from additional "base row" fcmInstanceEntry,
>       since can have only one "base row" which is ifEntry
> 
> I think it is OK, but would like to hear/read your comments.
 
Dave Perkins suggested (about seven or eight years ago) that this be
included in RFC 2578, but the WG rejected it.  It is still in SMICng,
but there a switch to ignore this "warning".  I forget which switch it is.

> Further, I have these somehwat more serious comments:
> 
> 1. I see in the t11FamTable a number of writable objects, but I seem to be
>    missing any writeup as to what the expected persistency behaviour is
>    for these objects. Am I not looking at the correct place?
>    Same for t11FamIfTable. Maybe other places as well, pls check.

I have inserted into the MODULE-IDENTITY's DESCRIPTION

           After an agent reboot, the values of read-write objects
           defined in this MIB module are implementation-dependent.

and near the end of each read-write object's DESCRIPTION:

           For the persistence of values across reboots, see the
           MODULE-IDENTITY's DESCRIPTION clause."

> 2. In that same table, I see Counter32 objects, but nothing about possible
>    discontinuities and if any, which is the discontinuity timer.

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

Note:  "... at other times as specified in the description ...".  RFC 4181
does not alter this because it says:

     It is OK to use Counter32/64 for counters that may/will be reset
     when the management subsystem is re-initialized or when other
     unusual/irregular events occur ...    However, if it is
     possible for such other unusual/irregular events to occur, the
     DESCRIPTION clause MUST state that this is so and MUST describe
     those other unusual/irregular events in sufficient detail that it
     is possible for a management application to determine whether a
     reset has occurred since the last time the counter was polled.  The
     RECOMMENDED way to do this is to provide a discontinuity indicator
     as described in RFC 2578 Sections 7.1.6 and 7.1.10.

Thus, the DESCRIPTION clause is required to mention discontinuities and have
a discontinuity indicator *if* they can occur, not just at reboot, but at
other times as well.

So, it is appropriate for you to ask the question, but my answer is:
no, there are no discontinuities other than at reboot, and thus, the text
I have is fine.

> 3. For t11FamIfRowStatus, I think you need to state if other writable column(s)
>    can be changed or not when in active state.
 
The rule in RFC 4181 is broken -- it says:

       The DESCRIPTION clause of the status column MUST specify whether
       or not it is possible to modify other columns in the same
       conceptual row when the status value is active(1).  Note that in
       many cases it will be possible to modify some writable columns
       when the row is active but not others.  In such cases, the
       DESCRIPTION clause for each writable column SHOULD state whether
       or not that column can be modified when the row is active, and
       the DESCRIPTION clause for the status column SHOULD state that
       modifiability of other columns when the status value is active(1)
       is specified in the DESCRIPTION clauses for those columns (rather
       than listing the modifiable columns individually).

Note that the first sentence says what MUST be in the DESCRIPTION clause.
The second and third sentences give an example of when the first sentence
is *wrong*, and a SHOULD applies instead.

Further, it is possible for any table, T, defined in any MIB module, that
a future MIB module could define new read-write objects in a new table which
AUGMENTS T.  Thus, the "In such cases" in third sentence above is a future
possibility for all tables in all MIB modules.  So, *all* RowStatus objects:

       ... SHOULD state that modifiability of other columns when the status
       value is active(1) is specified in the DESCRIPTION clauses for
       those columns (rather than listing the modifiable columns
       individually).

i.e., this is boilerplate, and effectively redundant.  Why do we require
redundant text in DESCRIPTIONs ??

Furthermore, in this MIB, the MODULE-COMPLIANCE clause says that the
MIN-ACCESS for both t11FamIfRcfReject and t11FamIfRowStatus is
read-only, i.e., the implementation gets to choose whether write
access is to be supported: a) at all times, b) at some times but not
other times, or c) never.  Thus, the OBJECT-TYPE cannot require that
writable columns be change-able/not change-able at any specific times.

In light of the above arguments, I propose to add:

           Implementations which support write-access to this object
           can do so under whatever conditions they choose."

to the t11FamIfRcfReject's DESCRIPTION.

Keith.

_______________________________________________
imss mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/imss