Subject: [babel] Benjamin Kaduk's No Objection on draft-ietf-babel-rfc6126bis-14: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 22 Aug 2019 13:14:06 -0700

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

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

Thank you for addressing my Discuss points!
I am happy to see the expanded text on update representation and parser
state in Section 4.5 -- that's enough to clear my discuss point, though
I probably would have added even a bit more text if I was writing it
myself.

Section 4.5

   In addition to the above, an Update TLV can omit a prefix of the
   prefix being announced, which is then extracted from the preceding
   Update TLV in the same address family (IPv4 or IPv6).  Finally, as a

nit: from a rhetorical sense, I'd suggest "omit an initial portion of
the prefix", to avoid using the word "prefix" with two different
meanings in the same sentence.

Appendix B

      Link cost: estimated using ETX on wireless links; 2-out-of-3 with
      C=96 on wired links.

Perhaps "ETX as described in Appendix A.2.2".

Appendix C

   At a minimum, they discard routes with a destination prefix in
   fe80::/64, ff00::/8, 127.0.0.1/32, 0.0.0.0/32 and 224.0.0.0/8.

127.0.0.1/32 as opposed to /8?

Appendix F

   There are two optioal features that make the new protocol
   incompatible with its predecessor.  First of all, RFC 6126 did not

nit: "optional"

   Two changes need to be made to an implementation of RFCs 6126 and
   7557 so that it can safely interoperate in all cases with
   implementations of this protocol.  First, it needs to be modified to
   either ignore or process Unicast Hellos.  Second, it needs to be
   modified to parse sub-TLVs of all the TLVs that it understands and
   that allow sub-TLVs, and to ignore the TLV is an unknown mandatory
   sub-TLV is found.  It is not necessary to parse unknown TLVs, since

nit: "if an unknown"

   There are other changes, but these are not of a nature to prevent
   interoperability:
   [...]
   o  the compression state is now specific to an address family rather
      than an address encoding Section 4.5;

It seems like an old implementation that decompresses an update to
different contents than a new implementation does, would have some
effect on routing.  Am I missing something?