[babel] Benjamin Kaduk's No Objection on draft-ietf-babel-applicability-09: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-babel-applicability-09: 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:
----------------------------------------------------------------------

When a use case calls for all nodes to participate in the IGP (as
opposed to just connecting to a local point of access and letting that
router run the IGP, there may be privacy considerations regarding the
mobility/connectivity of individual nodes in the information conveyed
over the routing protocol.  It would be good to acknowledge that such
use cases may exist (or disclaim applicability to them) in this
document.

Section 1.1

It's probably worth expanding DSDV on first use.

Section 2.2

(side note: this is probably just me coming from an abstract
math/topology background and not a routing background, but the term
"non-transitive link" puzzles me a little bit.  My understanding of the
non-transitivity property is that if A has a link to B, and B has a link
to C, then it's not necessarily the case that A can get traffic to/from
C via B.  But that seems like more of a property of the node policy or
other constraints on B than of any particular link.  I can live with
being puzzled, here, but if there's a quick explanation, I'd be
interested in hearing it.)

Section 2.3

   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: in order to check that two extensions to the Babel
   protocol are interoperable, it is enough to verify that the
   interaction of the two does not violate the base protocol's
   assumptions.

As another reviewer noted, "interoperable" doesn't seem like quite the
right word; "compatible" seems potentially more appropriate, or perhaps
"usable with each other".

Section 2.4.3

   Babel's loop-avoidance mechanism relies on making a route unreachable
   after a retraction until all neighbours have been guaranteed to have
   acted upon the retraction, even in the presence of packet loss.
   Unless the optional algorithm described in Section 3.5.5 of
   [RFC6126bis] is implemented, this entails that a node is unreachable
   for a few minutes after the most specific route to it has been
   retracted.  [...]

Section 3.5.5 of draft-ietf-babel-rfc6126bis-07 seems to discuss two
different mechanismis to guarantee that no neighbor is using the current
node as next-hop for prefix P.  (1) is that the operation being referred
to here, and (2) if so, should this be "one of the mechanisms"?
Basically, I'm not sure I'm chasing the reference in the way intended.

Section 5

I think we need to couch the "most deployments" language with something
like "at the time of this writing" -- there's no guarantee that it will
remain true in perpetuity.

Given, e.g., https://www.krackattacks.com/, it's unclear to me that it's
reasonable to continue to claim that WPA2 provides a way to secure a
link layer.  (WPA3 is not shaping up to do much better, given
https://www.schneier.com/blog/archives/2019/04/vulnerabilities_7.html .)