Dan, Version -14 incorporates the two changes below, updates Albert's email address, and adds instructions to IANA as flagged during their review. -- Jeff On Sat, Dec 07, 2024 at 01:08:39AM +0200, Dan Romascanu wrote: > Your proposals are acceptable for me. > > Regards, > > Dan > > > On Sat, Dec 7, 2024 at 1:00 AM Jeffrey Haas <jhaas@xxxxxxxx> 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 <jhaas@xxxxxxxx> 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 > > > > > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
