Skip to main content

Last Call Review of draft-ietf-babel-v4viav6-07
review-ietf-babel-v4viav6-07-intdir-lc-volz-2022-01-27-00

Request Review of draft-ietf-babel-v4viav6
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Internet Area Directorate (intdir)
Deadline 2022-02-08
Requested 2022-01-26
Requested by Éric Vyncke
Authors Juliusz Chroboczek
I-D last updated 2022-01-27
Completed reviews Rtgdir Last Call review of -07 by Himanshu C. Shah (diff)
Intdir Last Call review of -07 by Bernie Volz (diff)
Secdir Last Call review of -07 by Tero Kivinen (diff)
Tsvart Last Call review of -07 by Dr. Joseph D. Touch (diff)
Assignment Reviewer Bernie Volz
State Completed
Request Last Call review on draft-ietf-babel-v4viav6 by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/3HXA5jPPaCgKLnFHxfWebz7eLsw
Reviewed revision 07 (document currently at 08)
Result Ready w/nits
Completed 2022-01-27
review-ietf-babel-v4viav6-07-intdir-lc-volz-2022-01-27-00
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