[Last-Call] Re: Genart last call review of draft-ietf-bfd-large-packets-13

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux