Re: Comments on draft-ietf-bfd-mib-02.txt

["Thomas D. Nadeau" <[e-mail]>]

> MIBs make my head spin, but I noticed a few things based on  
> comments from Sankar.  These comments may be wildly off the mark,  
> as I don't really grok MIBs (an arcane art to be sure),

     Oh, its part of the Dark Arts (see Harry Potter) for sure. *)

> but not knowing what I was talking about has never stopped me in  
> the past.
>
>
> First, the document reference is incorrect; it refers to Version 0  
> and the 02 base spec, but the 02 base spec was Version 1 of the  
> protocol (and the current draft is 03, though that shouldn't have  
> any effect on the MIB as far as I can tell.)

     I published an -02 version yesterday before leaving for home
which does update the references, and straightened out a few
nits related to compliance with

http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review- 
guidelines-04.txt

> There is major confusion over the session state;  I'm guessing that  
> earlier versions of the MIB had a locally defined session state  
> variable, but when the session state became codified in the  
> protocol the state values all changed.  There are numerous  
> references of the form "up(1)" (and "up(2)" for that matter) for  
> all session state values that are incorrect and in some cases  
> contradictory.

     Will fix.

> The bfdSessUp and bfdSessDown notifications should presumably have  
> parameters of type bfdSessIndex.

     A little MIB voodoo here. We included the bfdSessDiag variable,
which does indeed include the bfdSessIndex as part of its OID that
will be generated when the notification is generated by the
agent. It is actually bad practice to include the indexes explicitly
within a notification for this very reason (its already part of
the variables included therein).

> The comments under them I don't understand at all (and were the  
> source of Sankar's concern.)  I'm guessing that the sentence "The  
> included values of bfdSessDiag MUST both be set equal to this new  
> state" is trying to say that all of the sessions indicated by the  
> index range must both be in Up state (which has nothing to do with  
> the diagnostic value), but I'm not sure what the point of that is

     The point of having both variables is to indeed indicate a
hi/lo range of the same type of notification for a set of
contiguous sessions if your implementation can handle this, otherwise
you an just generate one for each session and keep both
variables equal.  The choice of the bfdSessDiag variable was
simply to include additional information beyond indicating
which session was going up or down. If you or others feel that
we should include another value(s), then let us know.

> (and if the session entries are subsequently grabbed from the MIB,  
> there is a very good chance that the sessions will *not* be in the  
> specified state, as the notification will be stale.)

     That is okay. Their INDEX will remain, and so their actual state
can be examined.  The idea of the notification was to indicate that
a state had transitioned from the steady state to something else,  
possibly
indicating a failure/mis-config to an operator.

> In a related area, BfdDiag defines the diagnostic values, but  
> bfdSessDiag is defined as an opaque 32 bit value.  Shouldn't the  
> latter be defined in terms of the former?

     Yes, the MIB value needs to be adjusted to accurately reflect the
latest draft.

> The comment for bfdSessDiag is too restrictive, as the session  
> diagnostic has gotten a bit more flexible as the base spec  
> progressed.  The diagnostic is sometimes set in situations other  
> than a transition away from Up state.

     OK, will adjust.  If you have any suggested text, please send it
our way.

     --Tom


>
> --Dave
>