Hi Eric, Thanks for your review. See responses inline.
> On Aug 27, 2025, at 12:09 AM, Éric Vyncke via Datatracker <nore...@ietf.org> > wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-bfd-stability-19: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfd-stability/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > # Éric Vyncke, INT AD, comments for draft-ietf-bfd-stability-19 > CC @evyncke > > Thank you for the work put into this document. I find the idea simple but > useful. > > Please find below some non-blocking COMMENT points/nits (replies would be > appreciated even if only for my own education). > > Special thanks to Reshad Rahman for the shepherd's detailed write-up including > the WG consensus and the *some* justification of the intended status. I am > puzzled though by `No implementations and no known plans to implement.` ... > > I hope that this review helps to improve the document, > > Regards, > > -éric > > ## COMMENTS (non-blocking) > > ### No implementation plans ? > > [This is the same comment as for draft-ietf-bfd-secure-sequence-numbers-23, > but > as there is no crypto at all and the mechanism is different, I fail to see why > there are no implementations planned] > > Per shepherd's write-up: `No implementations and no known plans to implement.` > ... This is rather sad for a set of 3 I-Ds. Duly noted. And I believe that a good portion of the response Jeff gave for that review applies here, including the fact that while the motivations to deploy these measures immediately may not be present, it made sense to complete the work for the time when it will be needed. Publishing this as an RFC also gives operators a stronger reason to go ask the vendors to implement it. While crypto is not in use, the requirement for a method that provides for a meticulously increasing sequence number is needed, something ISAAC is able to provide. > > ### Stability or reliability ? > > No need to reply but I would have expected this work be around "reliability" > (i.e., packet loss rate) rather than "stability" (i.e., whether the link flips > up/down). > > ### Section 1 > > s/it receives at least one packet/it receives at least one *BFD* packet/ ? Will fix. > > ### Section 4 > > I am puzzled as it appears that this mechanism can only be configured via a > YANG data model ? I.e., no PCEP, no GUI, no CLI ? Text should probably be more > open than only YANG. E.g., s/*is* achieved by configuring /*may be* achieved > by > configuring / <warning, rant coming through> YANG does not mean no CLI or no GUI. YANG is only a data modeling language. Whether it gets used to generate the CLI, or create a GUI using the API calls that are generated using the YANG models is up to the implementation. YANG does not preclude that. </warning, rant coming through> But your point is taken that CLI, or GUI are not the only methods through which this could be configured. > > ### Section 5 > > Which header in `If the Authentication Present (A) bit is set in the header` ? We can add a reference to Section 4 of RFC 5880 which defines the A bit. > > ### Section 6 > > s/When using MD5 or SHA authentication/When using MD5 or *SHA1* > authentication/ > ? Will fix. > > ### Section 5 > > The end of the section is about the operations to be done by the receiver. > Isn't this redundant with section 6 ? Suggest to remove the last 3 paragraphs > of this section to avoid redundancy. Section 5 is introducing and defining the new AuthType (NULL), much like each AuthType are defined in RFC 5880. Section 6 on the other hand is “Theory of Operations” for all AuthType that provide the meticulously increasing sequence number and is not specific to the NULL AuthType. > > ### Section 8 > > It is usually useful to provide the exact URI to existing registries when > requesting changes in these registries. Did not see it in any of RFCs that were either initializing the registry, or updating it. But more than happy to add the following: https://www.iana.org/assignments/bfd-parameters/bfd-parameters.xhtml#bfd-parameters-2 <https://www.iana.org/assignments/bfd-parameters/bfd-parameters.xhtml#bfd-parameters-2> > > ### Appendix B.1 > > Thanks for the IPv6 example :-) > > Note: you may want to use more recent dates than 2016 ;-) Tells you how long the draft has been in the works :-). Cheers. Mahesh Jethanandani mjethanand...@gmail.com
