I am an assigned INT directorate reviewer for draft-ietf-babel-v4viav6-07. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/.

Based on my review, the document IS ready to go to IETF Last Call and therefore can be forwarded to the IESG.

The following are some nits:

In Abstract and Introduction, the "updates RFC 8966" is really that it extends RFC 8966 as this adds additional capabilities ("defines extensions"). This is probably a minor nit, but someone may be looking for explicit that "fixes" issues in RFC 8966 when there is really none and an implementation that adheres to RFC 8966 can continue to function as it has before. I also know that this is an open issue within the IETF as there aren't clear tags to distinguish these kinds of changes.

For section 2, I wonder whether "the fame format as the existing AE for IPv4 addresses" would benefit by calling that AE value (1) out (as is done in other places?

Section 2.3 says "Prefix and seqno requests" but RFC8966 does not appear to have a "Prefix request"? I think this should be "Route"?

For section 3 (last paragraph), does this imply that if the router has 127.0.0.1 assigned it can be used for ICMPv4 packets? Or is this not common for routers?

For section 4.2.2, would changing the title from "Other TLVs" to just "Route Request and Seqno Request" be useful (as these are the only other TLVs). And, would a reference back to section 2.3 be useful (as use of AE value 4 is SHOULD NOT).

For 6, this is usually a request to IANA to update - the RFC editor would change it to indicate the allocated value? (Minor as it could only be an issue if there were multiple documents trying to assign value 4.)

Thanks.

- Bernie Volz