Hi all, On Wed, Oct 16, 2024 at 12:28:46PM -0400, Jeffrey Haas wrote: > > On Oct 16, 2024, at 1:31 AM, Brian Trammell (IETF) <ietf@xxxxxxxxxxx> wrote: > > > > Thanks for the clarifications. Xiao, please take this reply as a > > reply to your own request for an amendment to this review; tl;dr the > > recommendations to the authors, WG, and IESG change in their details > > but my headline opinion (“Not Ready”) stands until the document > > is revised. > > FWIW, I agree with Xiao that Erik's analysis is well considered. > He saved me from writing a large amount of similar tax, and did so > with less frustrated sarcasm. Thanks, Jeff! I agree with your analysis in this email. I'll trim it from my reply to present an additional viewpoint that I hope is helpful: Every described abuse scenario that works with Unaffiliated BFD Echo also works without it. The abuse is possible already. It is built into the very foundation of the Internet. The Unaffiliated BFD Echo draft describes how to make use of an existing aspect of IP forwarding without harming the Internet. The BFD specification describes, e.g., how to avoid ICMP unreachables from the tested gateway, i.e., useless additional CPU load. It also describes, e.g., how to limit the sending rate without compromising detection time. The Unaffiliated BFD Echo draft, together with the BFD RFCs, provides a well considered specification everyone is free to implement. To me, this is much better than hoping that everybody wanting such functionality implements something that works as well without causing problems. > > [...] Best regards, Erik -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
