Hi Reshad, One clarification. See below:
> On Aug 1, 2025, at 9:06 AM, Reshad Rahman <[email protected]> wrote: > > Hi Ketan, > > I have updated the shepherd write-ups for all 3 docs. The docs are in good > state but the following changes should be made, your call whether they should > be done before initiation of IETF LC: > - In optimized-authentication there is one instance of "important BFD state > transition": 'important' should be removed Rather than dropping “important’, I think it should use the term “significant change” defined in the terminology section. Cheers. > - Some nits on secure-sequence-numbers > > Regards, > Reshad. > > On Sunday, July 27, 2025 at 04:14:22 PM GMT+2, Ketan Talaulikar > <[email protected]> wrote: > > > Hi Reshad/Authors, > > I saw an update posted and I believe there were offline discussions. > > Please let me know if the document is ready for IETF LC initiation? > > Mahesh, please do post the editorial nits and other such fixes on the next > update so they don't catch further directorate and IESG reviews. > > Thanks, > Ketan > > > On Tue, Jul 22, 2025 at 3:49 PM Reshad Rahman > <[email protected] <mailto:[email protected]>> wrote: > Thanks Mahesh. Please see inline. > > On Tuesday, July 22, 2025 at 09:14:46 AM EDT, Mahesh Jethanandani > <[email protected] <mailto:[email protected]>> wrote: > > > Hi Reshad, > > See comments inline: > >> On Jul 14, 2025, at 10:53 PM, Reshad Rahman <[email protected] >> <mailto:[email protected]>> wrote: >> >> BFD Auth authors, BFD WG, Ketan, >> >> Thanks to the authors for addressing the comments which came from AD-review. >> I have gone through all 3 documents, concentrating on the changes made since >> WGLC completed, and the documents are all aligned with each other. >> >> Here are some comments/questions (and a few small nits I noticed). >> >> draft-ietf-bfd-optimizing-authentication >> >> Comments/questions: >> - Intro: "whereby only important BFD state transitions require strong >> authentication" (this seems to be new text). I thought all state transitions >> required strong authentication? > > There are certain state transitions that like DOWN to INIT and INIT to DOWN > that do not need strong authentication. Maybe we can use the term > “significant change” that we have defined in the document that lists the > state transitions that need stronger authentication. > > Looking at the current definition of "significant change" in section 2, it > says "State change, a demand mode change...". Are you suggesting to change > that definition to "important state changes"? > > JTBC my recollection is that all state changes require strong auth. This is > the table present in older revs of this doc. > Read : On state change from <column> to <row> > Auth : Authenticate BFD control packet > NULL : No Authentication. Use NULL AUTH Type. > n/a : Invalid state transition. > Select : Most packets NULL AUTH. Selective (periodic) > packets authenticated. > +--------+--------+--------+--------+ > | | DOWN | INIT | UP | > +--------+--------+--------+--------+ > | DOWN | NULL | Auth | Auth | > +--------+--------+--------+--------+ > | INIT | Auth | NULL | n/a | > +--------+--------+--------+--------+ > | UP | Auth | Auth | Select | > +--------+--------+--------+--------+ > > BTW I missed the fact that the abstract also says "important BFD state > transitions", that was added in rev-24. My recommendation, as shepherd, is to > do "strong auth" for all state transitions which is what IIRC the document > had until recently. If the authors have justification to do "strong auth" for > important state transitions only, you need to define what are the important > state transitions (I'm assuming it'd be from/to Up state). And change the > following in section 3 to say "important BFD state changes": > The intention of these optimized procedures is to permit strong > authentication for BFD state changes > > Regards, > Reshad. > Mahesh Jethanandani [email protected]
