Re: [babel] draft-ietf-babel-applicability WG Last Call

["Adrian Farrel" <[e-mail]>]

Hi,

Thanks for a balanced assessment of Babel. I have a few minor comments
on the current revision.

Cheers,
Adrian

===

The Abstract could usefully say what this document is and does.
The first paragraph of the introduction might serve.

---

The use of the first person plural is not usual in RFCs largely because
it begs the question of who "we" are. Better to use "This document..."

---

1.1
s/traditional distance-vector protocol/distance-vector protocol/

---

1.1
s/two obvious extensions/two extensions/

---

2.1

Suggest to strike the following.

   Given a sufficiently friendly audience, the principles
   behind Babel can be explained in 15 minutes, and a full description
   of the protocol can be done in 52 minutes (one microcentury).

---

2.1

   While
   Babel is a young protocol, there exist four independent
   implementations, including one that was reportedly written and
   debugged in just two nights.

While an RFC is in some sense a snapshot in time, people will read
this document for years to come. You need to reword this accordingly.

It might also benefit from a citation or two.

---

2.2.

   o  strict monotonicity of the metric: M < C + M;

   o  left-distributivity of the metric: if M <= M', then
      C + M <= C + M'.

These may be true statements, but what are M and C and M' ?

---

2.2
OLD
   in contrast to traditional link-state routing protocols
NEW
   in contrast to link-state routing protocols

---

2.2
   This is in contrast to traditional link-state routing
   protocols such as OSPF [RFC5340] or IS-IS [RFC1195], which are
   layered over a reliable flooding algorithm and make stronger
   requirements on the underlying network and metric.

Are OSPF and IS-IS really layered over a flooding algorithm or do they
incorporate the flooding algorithm?

---

The three examples in 2.2 all say "does most probably not". In principle
this is a reasonable thing to say, but it is subjective. It would be
nice to scope "probably" in some way.

I'm personally a little sceptical about the first example because my
experience suggests that coders are fiendishly capable of constructing
bugs that do all manner of unexpected things.

---

2.3

   Remarkably enough, all of the extensions designed to date
   interoperate with the base protocol and with each other.  This,
   again, is a consequence of the protocol design

Then it is not remarkable, then, is it? :-)

---

2.4.1
    a protocol that relies a reliable transport (such as OSPF, IS-IS

I don't think that either OSPF or IS-IS rely on a reliable transport.
Rather, I think they incorporate mechanisms to mitigate or overcome the
effects of an unreliable network.

---

It might be good to discuss the manageability of the protocol

---

Isn't [RFC6126bs] really a normative reference?

> -----Original Message-----
> From: babel [mailto:[e-mail]] On Behalf Of Donald Eastlake
> Sent: 11 April 2018 15:10
> To: Babel at IETF
> Cc: [e-mail]
> Subject: [babel] draft-ietf-babel-applicability WG Last Call
> 
> This message starts a two week Working Group Last Call on
> draft-ietf-babel-applicability-03.txt. The several endorsements posted
> in the last 24 hours will also be considered responses to this call.
> :-)
> 
> Thanks,
> Donald