Mahesh, you are correct.
Regards,Reshad.
On Friday, August 1, 2025 at 06:54:41 PM GMT+2, Mahesh Jethanandani
<mjethanand...@gmail.com> wrote:
Hi Reshad,
One clarification. See below:
On Aug 1, 2025, at 9:06 AM, Reshad Rahman <res...@yahoo.com> 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
<ketant.i...@gmail.com> 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
<reshad=40yahoo....@dmarc.ietf.org> wrote:
Thanks Mahesh. Please see inline.
On Tuesday, July 22, 2025 at 09:14:46 AM EDT, Mahesh Jethanandani
<mjethanand...@gmail.com> wrote:
Hi Reshad,
See comments inline:
On Jul 14, 2025, at 10:53 PM, Reshad Rahman <res...@yahoo.com> 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 jethanandanimjethanand...@gmail.com
