Your proposals are acceptable for me. Regards,
Dan On Sat, Dec 7, 2024 at 1:00 AM Jeffrey Haas <jh...@pfrc.org> wrote: > Dan, > > On Sat, Dec 07, 2024 at 12:23:02AM +0200, Dan Romascanu wrote: > > On Fri, Dec 6, 2024 at 5:59 PM Jeffrey Haas <jh...@pfrc.org> wrote: > > > In other words, the implementations know the use cases best for their > > > deployments.. > > > > Maybe a short text would clarify. It was not obvious for me, but it may > be > > my lack of familiarity. > > SHOULD means you should do it. If you vary from it, you have your own > reasons for it. :-) > > My recommendation is that the text is fine. Throwing a number of contrived > or real examples to justify it doesn't help the clarity nor change the > level > from "a good idea, do it and we're not making variances from it > non-conformant". > > > > > Nits/editorial comments: > > > > > > > > 1. Section 4.2 > > > > > > > > 'Since the consideration is path MTU, BFD sessions using this feature > > > > only need to use a bfd.PaddedPduSize appropriate to exercise the > path > > > > MTU for the desired application. > > > [...] > > > > This sentence seems to need some syntax clean-up. > > > > > > FWIW, this looks clear to me. Did you have a specific bit of rewrite > you > > > thought appropriate? If not, I suspect this is something the RFC > editor > > > will help with as part of the final editing process. > > > > > > > 'use a bfd.PaddedPduSize appropriate' sounds bad grammar to me. Do you > > mean 'use an appropriate value of bfd.PaddedPduSize'? > > That's acceptable. > > > > > 2. I am not sure about Appendix A. If this is useful information, > why not > > > > include it in the body of the document. If not, eliminate it. > > > > > > It's information. It has been previously useful. It's been left in > because > > > a > > > regular occurence during this work is "this existing padding feature > exists > > > and solves your problem". It doesn't, but it's related. > > > > > > While I'm fine deleting it, the fact that this has conversational > point has > > > recurred so many times leaves me inclined to at least nod towards the > > > related functionality. > > > > > > > If it's useful, why not include this in the Introduction Section? > > Introduction: Path MTU is a problem. Oh, this ISIS feature exists and > people > keep saying it helps... well, it doesn't. It's not fast enough, and it's > single hop and doesn't run at the IP layer. People try padded pings. That > dosn't help either. Here's what we do instead! > > Nah. > > As I typed above, I'm fine deleting the appendix. It exists to head off > annoying recurrences of the same discussion. Once this is shipped as an > RFC > that small benefit is moot. > > -- Jeff > > >
_______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
