Gunter, Note: All edits to date are covered here:
https://github.com/bfd-wg/optimized-auth/pull/75 > On Sep 8, 2025, at 11:41 PM, Gunter van de Velde (Nokia) > <[email protected]> wrote: > > [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/ I'm aware of, and have a low opinion of that document's recommendations even if I'm sympathetic with the criteria it asks authors to consider. I can easily expand the text of this draft to 150% of its current size bloviating on the various properties cited in that opsarea draft. This will not increase the quality of this document nor will it substantively improve operations for it. This draft documents an authentication mode for an existing protocol. The use cases for this draft are already covered to justify when an operator may choose to use it in place of other existing mechanisms. A YANG model is provided to cover examples about how the extension may be enabled and managed within the abstract framework we provide in the IETF model for managing BFD. Management of an implementation outside of the IETF YANG model will be implementation specific and unworthy of comment. Security impacts are addressed, including an already overweight bit of text for managing YANG. A significant number of items in the opsarea review checklist are excessively out of scope for most of our protocol documents. The IETF has struggled over the years what to do about use and problem case documents, and often thrashes working groups through "this is required work to get started", and then usually throws the documents to the side without publication as an RFC because it's decided that they don't have sufficient worth. Similarly, significant effort is spent by ADs excising non-protocol details from the drafts on the claims that it reduces clarity. If there are specific items from the opeational considerations you consider unaddressed, enumerate them and we'll consider appropriate text. Otherwise, it's my opinion that the critical portions seem to be covered in the document. > > >> >> # 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". Did you intend to address this point? > >> >> 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/ I've made this change to silence the AD warning. > 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). I hope it has occurred to you that "state" encompasses protocol behavior such as its variables along with the variable explicitly labeled "state". The fact that we have such an explicitly labeled entity seems to cause most of the issues here. -- Jeff
