Re: [babel] Mirja Kühlewind's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)

[Juliusz Chroboczek <[e-mail]>]

Dear Mirja,

> 1) Let's move appendix B into the body of the document. I think these
> are important information for an implementer and therefore it needs more
> attention.

I am sorry, but I disagree.  The original document that I submitted for
IETF review back in 2009 had the structure that you suggest, but the
reviewer (Joel Halpern) convinced me to a adopt the following structure:

  - the body of the document describes the main algorithm, the parts that
    are required to enforce the strong guarantees that the protocol makes
    about lack of loops and forward progress;
  - the appendices describe algorithms that have been shown to be useful
    over some link layers but that might need to be tweaked when Babel is
    run over new, exciting link layers.

Since Joel did a good job convincing me, it will take some work to
convince me otherwise.

> 2) Maybe you can add something like: [...]  I’m sure you have a better
> wording. My intention is simply to add another warning, to think
> carefully instead of just pick some default.

I don't necessarily agree, but I've done as you request.

>>> Thanks. I was also hoping that you could make any recommendation on how
>>> to implement that e.g. a fixed delay of a certain (default) value or
>>> based on some other knowledge. [...]

>> You do realise it's a very high bar you're setting?

[...]

> I wasn’t looking for a tutorial for pacing but rather a reference to
> add. E.g. just naming different approaches for how to implement pacing
> and provide a reference would be a good thing I think. However, I will
> not block on this one thing. Your choice.

I am not aware of any good reference on packet pacing that covers IEEE
802.11 multicast (an important usecase for Babel).  After checking some
papers and scratching my head for a long time, I've just added another
sentence to Section 3.1; I'm afraid I'm not competent to do anything more.

> I just wondering why you don’t call them default value rather then
> examples. I think specifying default value normatively would be more
> clear and is what we usually do in specs. However, I think in this case
> it will not make a huge practical difference.

Great, let's agree that we're not in full agreement, then.

-- Juliusz