[RTG-DIR] Rtgdir early review of draft-ietf-babel-mac-relaxed-02
Ben Niven-Jenkins via Datatracker <noreply@ietf.org> Wed, 26 October 2022 21:12 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE31C14CE2B; Wed, 26 Oct 2022 14:12:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Niven-Jenkins via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
Cc: babel@ietf.org, draft-ietf-babel-mac-relaxed.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166681875569.48302.18297861870805105409@ietfa.amsl.com>
Reply-To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Date: Wed, 26 Oct 2022 14:12:35 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/ilzmanO9BZapxLGmiSMgNnYvgUk>
Subject: [RTG-DIR] Rtgdir early review of draft-ietf-babel-mac-relaxed-02
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Oct 2022 21:12:35 -0000
Reviewer: Ben Niven-Jenkins Review result: Has Nits 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
- [RTG-DIR] Rtgdir early review of draft-ietf-babel… Ben Niven-Jenkins via Datatracker
- Re: [RTG-DIR] Rtgdir early review of draft-ietf-b… Juliusz Chroboczek