É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. ### 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/ ? ### 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 / ### Section 5 Which header in `If the Authentication Present (A) bit is set in the header` ? ### Section 6 s/When using MD5 or SHA authentication/When using MD5 or *SHA1* authentication/ ? ### 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 8 It is usually useful to provide the exact URI to existing registries when requesting changes in these registries. ### Appendix B.1 Thanks for the IPv6 example :-) Note: you may want to use more recent dates than 2016 ;-)
