Hi All,

MIBs aren’t in my comfort zone and I’m having a hard time sussing this one out. 
I hope one of the authors, or someone with more clue than me, will take a look.

One point is that the DESCRIPTION says "bfdSessDiag MUST both be set equal to 
this new state (i.e., up(4)).” But if I track down what the defined values are 
for bfdSessDiag, what I find is 

bfdSessDiag OBJECT-TYPE
     SYNTAX     IANAbfdDiagTC

And if I track down IANAbfdDiagTC in RFC 7330, it doesn’t have up(4) as a 
defined value, rather we have forwardingPlaneReset(4).

If we want to set up(4), that’s defined in IANAbfdSessStateTC which maps to 
bfdSessState. 

But then the description goes on to talk about "The two instances of 
bfdSessDiag in this notification indicate the range of indexes that are 
affected”. which doesn’t appear to make sense either in the context of 
bfdSessDiag or bfdSessState, and I suppose is what led the submitter to propose 
bfdSessIndex.

Finally, if there is a bug to be fixed here at all, it presumably needs to be 
fixed in bfdSessDown too.

Thanks,

—John

> On Mar 13, 2025, at 2:45 AM, RFC Errata System <[email protected]> 
> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> The following errata report has been submitted for RFC7331,
> "Bidirectional Forwarding Detection (BFD) Management Information Base".
> 
> --------------------------------------
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid8327__;!!NEt6yMaO-gk!D_iMDlxy4oqn8tT63iTI91rt11QogYBd1SvYD64k21dU-XPJ_Rj68hov1XCDrjt96ZXOWCyCnfPbYfqUNWdHKg$
> 
> --------------------------------------
> Type: Technical
> Reported by: Goutham Jain <[email protected]>
> 
> Section: 5
> 
> Original Text
> -------------
> bfdSessUp NOTIFICATION-TYPE
>     OBJECTS {
>         bfdSessDiag, -- low range value
>         bfdSessDiag  -- high range value
>     }
>     STATUS     current
>     DESCRIPTION
>         "This notification is generated when the
>          bfdSessState object for one or more contiguous
>          entries in bfdSessTable are about to enter the up(4)
>          state from some other state.  The included values of
>          bfdSessDiag MUST both be set equal to this
>          new state (i.e., up(4)).  The two instances of
>          bfdSessDiag in this notification indicate the range
>          of indexes that are affected.  Note that all the indexes
>          of the two ends of the range can be derived from the
>          instance identifiers of these two objects.  For the
>          cases where a contiguous range of sessions
>          have transitioned into the up(4) state at roughly
>          the same time, the device SHOULD issue a single
>          notification for each range of contiguous indexes in
>          an effort to minimize the emission of a large number
>          of notifications.  If a notification has to be
>          issued for just a single bfdSessEntry, then
>          the instance identifier (and values) of the two
>          bfdSessDiag objects MUST be identical."
>     ::= { bfdNotifications 1 }
> 
> Corrected Text
> --------------
> bfdSessUp NOTIFICATION-TYPE
>     OBJECTS {
>         bfdSessIndex, -- low range value
>         bfdSessIndex-- high range value
>     }
>     STATUS     current
>     DESCRIPTION
>         "This notification is generated when the
>          bfdSessState object for one or more contiguous
>          entries in bfdSessTable are about to enter the up(4)
>          state from some other state.  The included values of
>          bfdSessIndex MUST both be set equal to this
>          new state (i.e., up(4)).  The two instances of
>          bfdSessIndex in this notification indicate the range
>          of indexes that are affected.  Note that all the indexes
>          of the two ends of the range can be derived from the
>          instance identifiers of these two objects.  For the
>          cases where a contiguous range of sessions
>          have transitioned into the up(4) state at roughly
>          the same time, the device SHOULD issue a single
>          notification for each range of contiguous indexes in
>          an effort to minimize the emission of a large number
>          of notifications.  If a notification has to be
>          issued for just a single bfdSessEntry, then
>          the instance identifier (and values) of the two
>          bfdSessIndex objects MUST be identical."
>     ::= { bfdNotifications 1 }
> 
> Notes
> -----
> The bfdSessUp and bfdSessDown must report the bfdSessIndex range for which 
> the Session State has changed and not the bfdSessDiag.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> will log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC7331 (draft-ietf-bfd-mib-22)
> --------------------------------------
> Title               : Bidirectional Forwarding Detection (BFD) Management 
> Information Base
> Publication Date    : August 2014
> Author(s)           : T. Nadeau, Z. Ali, N. Akiya
> Category            : PROPOSED STANDARD
> Source              : Bidirectional Forwarding Detection
> Stream              : IETF
> Verifying Party     : IESG

Reply via email to