Hi Goutham, It sounds as though you’re saying you wish the document didn’t say what it does, and that it would be more valuable if it had been written differently. If so, irrespective of the merits of your position, it’s beyond the scope of an erratum [1] —
"Errata are items that were errors at the time the document was published -- things that were missed during the last call, approval, and publication process. If new information, new capabilities, or new thinking has come up since publication, or if you disagree with the content of the RFC, that is not material for an errata report. Such items are better brought to relevant working groups, technical area discussions, or the IESG.” In order to verify a technical erratum it has to be established there’s a bug in the document. The conversation so far doesn’t lead me to think that is the case, other than possibly the DESCRIPTION text is incorrect. —John [1] https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/ On Mar 16, 2025, at 12:15 PM, .Goutham V Jain <[email protected]> wrote: Hi All, The current issue with using SessDiag or SessState as the objects in the notification, we would only know the state of the session. But It will not help the trap receiver identify the exact session which has seen a transition in state. With Session Index in the trap object, the trap receiver will be free to fetch the specific OID or the complete row to indicate the current status of the BFD Session to the end user. Thanks Goutham On Sat, Mar 15, 2025 at 5:11 PM Jeffrey Haas <[email protected]<mailto:[email protected]>> wrote: On Thu, Mar 13, 2025 at 01:48:57PM +0000, John Scudder wrote: > 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. I think there's an error here, but the fix is not correct. > 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. Correct. You've divined part of the problem. > 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. The thing that isn't intuitively obvious here is that SNMP objects are key/value sets. The indices for a bfdSessState, Diag, etc. are: bfdSessEntry OBJECT-TYPE SYNTAX BfdSessEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The BFD Session Entry describes the BFD session." INDEX { bfdSessIndex } ::= { bfdSessTable 1 } This means that two instances for the corrected sessState, or even the old buggy sessDiag will contain different indices in their OID which define the range. > Finally, if there is a bug to be fixed here at all, it presumably needs to be > fixed in bfdSessDown too. That'd be correct. Now, to read deeply between the lines to see if the intention was really to use sessDiag or sessState in the objects. > > 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 As you note above, up isn't a valid value for sessDiag, but for sessState. A motivation for wanting the Diag value is it gives you some contents of what is in the protocol's Diag field during the transition. This is far more valuable for Down than Up. Additionally, inlcuding sessState in the objects doesn't add any additional value in the notification because the notification itself is of a type indicating that we're going up/down. So, what I think is we have a pair of issues but I'd prefer more input from the other authors of the MIB: 1. sessDiag is probably correct for the reasons above. 2. The text shouldn't be talking about the values of sessDiag being Up. However, insisting that the sessions tied to the sessIndex values reported in both instances being Up is appropriate. It'd probably also be useful to survey current implemenations to see what objects are included. My bet would be the sessDiag is what is done even if the description is off. -- Jeff
