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

Hi Bert,

Thanks for your reviews.  Here is my response to the first:

> 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

Done.

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

Done.

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

Section 5.3.3 of FC-SP restricts the length to 8 bytes, so I believe the
restriction is correct.  I will add section 5.3.3 to the REFERENCE clause.

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

I'm saying is that sysUpTime gets reset to zero in any MIB view which
includes this MIB whenever this Counter32 has a discontinutity. 
Yes, this can achieved by "a monolithic entity" and by "persistent
storage of the value" but it can also be achieved in other ways as
well.

The alternative is to define one or more additional discontinuity
timestamps.  The number (of these additional timestamps) required
is dependent on the architecture of the implementation.  One
possibility would be to add a TimeStamp object to fcmInstanceTable
(defined in RFC 4044), but if we were going to do that, I think we
should have done it three years ago, before RFCs 4438, 4439, 4625,
4626, 4747, 4935, 4936 and 4983 were approved without referencing such
a TimeStamp object.

Thanks,
Keith. 

PS. I'll make the updated document available after I've responded to
your other reviews.

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