Subject: [babel] Mirja Kühlewind's No Objection on draft-ietf-babel-applicability-08: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Tue, 06 Aug 2019 04:32:29 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-babel-applicability-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-applicability/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for writing this document and the recent updates. While it is an easy
read, I agree with others that there might still be some case where maybe
benefits are overstated, e.g. sec 2.1 is not very objective and only provides
basically two anecdotes. Other examples are these sentences:

"In addition to the above, our implementation experience indicates
   that Babel tends to be robust with respect to bugs: more often than
   not, an implementation bug does not violate the properties on which
   Babel relies, and therefore slows down convergence or causes sub-
   optimal routing rather than causing the network to collapse."

or

"No other routing protocol known to us is similarly robust and
   efficient in this particular kind of topology."
(also still one "us" here)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 06 Aug 2019 14:45:25 +0200

Dear Mirja,

Thank you for your review.

> 2.1 is not very objective and only provides basically two anecdotes.

I would appreciate it if you could spell out what it is that you find
objectionable about Setion 2.1?  The intent of this section is to give the
reader actual empirical data, I'd be interested to know why you find that
objectionable.

>    optimal routing rather than causing the network to collapse."

Could you please spell out what it is that bothers you about this
paragraph?  The intent here is to share our implementation experience with
the reader.

>    efficient in this particular kind of topology."

Again, your objection is not clear to me.  Are you disagreeing with the
claim (e.g., because you know otherwise), or do you believe that this
statement doesn't belong in this document, and if so, why?

> (also still one "us" here)

Could you please suggest a better wording?

-- Juliusz

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 6 Aug 2019 14:55:56 +0200

Hi Juliusz,

These are all no big concerns, but rather comments on the style for an RFC (compared to a paper). See some examples below.

> On 6. Aug 2019, at 14:45, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Dear Mirja,
> 

15 minutes to explain really depends on the two people involved. Also implementing “over two nights” really doesn’t tell me much. I think it would be more useful to e.g. talk about the lines of code or number of components or whatever. 

It not a problem to have these anecdotes in the draft but I would not claim that these two experiences prove that the protocol is simple.

> paragraph?  The intent here is to share our implementation experience with

I think the “more often than not” is again very blurry. E.g. I would recommend to say instead: 
"In addition to the above, implementation experience indicates
  that Babel tends to be robust with respect to bugs: in various 
  cases implementation bugs did not violate the properties on which
  Babel relies, and therefore slowed down convergence or caused sub-
  optimal routing but did not cause the network to collapse."

> statement doesn't belong in this document, and if so, why?

I would rather suggest:

“Other widely deployed routing protocol are less robust and efficient in this particular kind of topology.”

I believe there are still more cases in the draft which could be toned down a bit to avoid overstating but make a more objective statement instead.

Mirja

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 06 Aug 2019 15:19:28 +0200

The changes below are in git, I'm not submitting a new revision yet.

> 15 minutes to explain really depends on the two people involved.

I'm speaking about giving a talk.  I've done it repeatedly, last time was
just two weeks ago.  I'll keep this bit, if that's okay with you.

> Also implementing “over two nights” really doesn’t tell me much. I think
> it would be more useful to e.g. talk about the lines of code or number
> of components or whatever.

I most humbly disagree.  Time required to do an independent reimplementation
is a much better indicator than mere lines of code.

>   optimal routing but did not cause the network to collapse."

Agreed.  I've put "in many cases".

> this particular kind of topology.”

I've removed this sentence completely.

> I believe there are still more cases in the draft which could be toned
> down a bit to avoid overstating but make a more objective statement
> instead.

Since I'm the original designer, I'm naturally biased.  I'd appreciate it
if you could specify exactly which bits you find objectionable.

Thanks,

-- Juliusz