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

From: Dave Katz <[email-masked]>
Date: Fri, 5 Aug 2005 09:53:29 -0700

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

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.

The bfdSessUp and bfdSessDown notifications should presumably have  
parameters of type bfdSessIndex.  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 (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.)

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?

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.

--Dave

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 5 Aug 2005 16:33:08 -0400

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

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

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

> latter be defined in terms of the former?

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

> 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

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 8 Aug 2005 15:40:56 +0200

Looking at BfdDiag Textual Convention, I wonder if there is a better way of
doing this.  I suspect that this is a list of diagnostic values that will evolve
faster than the rest of the MIB module so rather than updating the RFC every
time, or letting it get out of date, you could extract the Textual Convention
from the normative part of the MIB and put it under IANA control with whatever
rules you consider suitable for updating it.

This approach has been sucessfully adopted by disman with Alarm MIB (RFC3877
s.5), inter alia.

Tom Petch

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 8 Aug 2005 16:01:28 -0400

This is along the lines of what Katz was suggesting
earlier WRT updating the diag section. I like the IANA
control idea.

     --Tom