Early Review of draft-ietf-babel-mac-relaxed-02
review-ietf-babel-mac-relaxed-02-rtgdir-early-niven-jenkins-2022-10-26-00

Hello

I have been selected to do a routing directorate “early” review of this draft
https://datatracker.ietf.org/doc/draft-ietf-babel-mac-relaxed/

The routing directorate will, on request from the working group chair, perform
an “early” review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft’s lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

As this document is in working group last call, my focus for the review was to
determine whether the document is ready to be published. Please consider my
comments along with the other working group last call comments.

For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-babel-mac-relaxed-02.txt
Reviewer: Ben Niven-Jenkins
Review Date: 26 October 2022
Intended Status: Standards Track

Summary: This document is basically ready for publication, but has nits that
should be considered prior to being submitted to the IESG.

Comments: The document is well written, concise and easy to follow.

Nits:
1) Section 3.1 replaces the the last sentence of the fourth bullet point of
Section 4.3 of RFC8967. I am curious as to why it drops “(which already exists
in this case)” and “, and the packet is accepted” from the original sentence in
RFC8967?

While the proposed replacement sentence is clear in its meaning, I assume that
the omitted snippets above were included in the original sentence in RFC8967
for a reason (additional clarity?) and so I wonder if the replacement sentence
in draft-ietf-babel-mac-relaxed should continue to include them and read:

“””
If the packet contains a successful Challenge Reply, then the Index contained
in the PC TLV MUST be stored in the Index field of the Neighbour Table entry
corresponding to the sender (which already exists in this case), and the PC
contained in the TLV MUST be stored in both the PCm and PCu fields of the
Neighbour Table entry, and the packet is accepted. “””

2) Last bullet of section 3.1 s/compares the received PC with either PCm field
(if the packet/compares the received PC with either the PCm field (if the
packet/ (i.e. add a ‘the’ before ‘PCm’)

3) RFC8967 does not capitalise the term neighbour table except in the section
heading of section 3.2, whereas draft-ietf-babel-mac-relaxed consistently
capitalises neighbour table. Unless there is a reason otherwise, I would
suggest aligning with RFC8967 and leaving ‘neighbour table’ entirely in
lowercase.

--
Ben