[Deleted the items that are resolved] Look for GV2>
> On Sep 8, 2025, at 7:39 AM, Gunter Van de Velde via Datatracker > <[email protected]> wrote: > # I am missing an operational guidance section to help operators to > operate optimized bfd. The operational consideration is "you select this mode in preference to another mode". This document may provide some pointers: https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/ > > # comments > # ======== > > 17 Abstract > 18 > 19 This document describes an experimental optimization to BFD > 20 Authentication. It provides a procedure where BFD state > transitions > 21 require strong authentication and permits the majority of BFD > Control > 22 Packets to use a less computationally intensive authentication > 23 mechanism. This enables BFD to scale better when there is a desire > 24 to use strong authentication. > > GV> This draft seems to suggest updating the procedures of RFC5880. > GV> Should that > not be mentioned in some form or embodiment within the abstract? > demand mode changes GV2>This is being published as experimental. As noted previously, figure out the consensus among the IESG whether experiments get to update RFCs. I suspect the answer is "no". > > 143 | significant | State change, a demand mode change (to | > 144 | change | D bit) or a poll sequence change (P or | > 145 | | F bit). Changes to BFD control packets | > 146 | | that do not require a poll sequence, | > 147 | | such as bfd.DetectMult are also | > 148 | | considered as a significant change. | > > GV> The abstract mentions only state transitions, but with this > GV> definition of > "significant change" there may be more included as just state change. > Is my assumption correct? The significant change is the normative procedure being protected. Defining that requires a forward reference that has otherwise been problematic in abstracts. What text do you suggest instead to resolve that conflicting requirement against forward references without pulling in the entirety of the description of "significant change"? Note that this point has already been thrashed about a bit. The muddled clarity is the result of too many fingers in this pie. GV2> in the abstract s/BFD state transitions/BFD significant change/ GV2> reasoning is that from your definition significant change is described as a superset of state change (State change, a demand mode change (to D bit) or a poll sequence change (P or F bit). > > 418 8.1. Data Model Overview > > GV> Some of the default values for this experimental draft are already > GV> defined > in the YANG model. But for the purpose of making things easier to > follow, wouldn’t it be helpful to also mention them explicitly in an > operational guidance section? That way, readers working with optimized > BFD don’t have to go digging through the model just to figure out what > defaults they’re expected to use. Aside from the exemplary reauth interval, what did you have in mind? GV2> correct. That was the value I had my eyeballs upon. When scanning through the model I didn't see others, and assumed I may of missed some, but seems I was not. G/
