[imss] FW: MIB doctor review for T11-FC-SP-AUTHENTICATION-MIB

Forwarding to the list ...  --David

-----Original Message-----
From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net] 
Sent: Friday, December 28, 2007 10:29 AM
To: imss@ietf.org
Cc: Keith McCloghrie; Black, David; Dan Romascanu
Subject: MIB doctor review for T11-FC-SP-AUTHENTICATION-MIB

This is a review of the module as extracted from the
prelimenary draft-ietf-imss-fc-fcsp-mib-01.txt document

- I see
   t11FcSpAuthenticationMIB  MODULE-IDENTITY
       LAST-UPDATED  "200702190000Z"
       ORGANIZATION  "T11"

  I think that IOETF IMSS WG should be included as one of
  the ORGANIZATIONs that worked on this MIB module

- This is just a nit:

     t11FcSpAuMIBIdentities
                   OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 1 }
     t11FcSpAuMIBObjects
                   OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 2 }
     t11FcSpAuMIBConformance
                   OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 3 }
     t11FcSpAuMIBNotifications
                   OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 0 }

   Most MIB modules have MIBObjects as 1 and Conformace as 2.
   This MIB module has additional a set of Identities. SO I personally
   would do:

     t11FcSpAuMIBNotifications
                   OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 0 }
     t11FcSpAuMIBObjects
                   OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 1 }
     t11FcSpAuMIBConformance
                   OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 2 }
     t11FcSpAuMIBIdentities
                   OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 3 }

   But and OID is just an OID, so this is not a flaw. Just a consistency
thing
   that I personally would try to follow.

- It is unclear to me why
    t11FcSpAuEntityName OBJECT-TYPE
        SYNTAX     FcNameIdOrZero (SIZE (8))

  Has a fixed size of 8. I think I would have expected (8 | 16)
  You reference
           "fcmInstanceWwn & fcmSwitchWWN,
            'Fibre Channel Management MIB', RFC 4044, May 2005."
  And fcmInstanceWwn and fcmSwitchWWN there (as far as I can tell also
  allow 8 or 16.  In fact they even allows for zero, but I can see you
do
  (or may) not want to allow that here.

- So for my undestanding, when I see this:

    t11FcSpAuIfStatTimeouts OBJECT-TYPE
        SYNTAX       Counter32
        MAX-ACCESS   read-only
        STATUS       current
        DESCRIPTION
           "The number of FC-SP Authentication Protocol messages sent
           by the particular entity on the particular Fabric on the
           particular interface, for which no response was received
           within a timeout period.

           This counter has no discontinuities other than those
           which all Counter32's have when sysUpTime=0."

   Then I understand from that that the instrumentation code for this
MIB
   module will save these values in persistent storage, and so when it
   restarts it still knows the values?
   Or are you saying that the "master-agent" and "t11-subagent" are
always
   a monolithic entity and will die/restart together?

Bert Wijnen

_______________________________________________
imss mailing list
imss@ietf.org
https://www1.ietf.org/mailman/listinfo/imss