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

["Bert Wijnen - IETF" <[e-mail]>]

Thanks Keith. ALso for the explanation on the
discontinuity question I had. I am OK with it

Bert Wijnen

> -----Oorspronkelijk bericht-----
> Van: Keith McCloghrie [mailto:[e-mail]]
> Verzonden: maandag 31 december 2007 17:50
> Aan: Bert Wijnen - IETF
> CC: [e-mail]; Keith McCloghrie; Black_David; Dan Romascanu
> Onderwerp: 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/imss