Genart last call review of draft-ietf-6man-icmp-limits-07

Pete Resnick via Datatracker <> Mon, 17 February 2020 19:01 UTC

Return-Path: <>
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id F409E120866; Mon, 17 Feb 2020 11:01:59 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Pete Resnick via Datatracker <>
To: <>
Subject: Genart last call review of draft-ietf-6man-icmp-limits-07
X-Test-IDTracker: no
X-IETF-IDTracker: 6.117.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Pete Resnick <>
Message-ID: <>
Date: Mon, 17 Feb 2020 11:01:59 -0800
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Feb 2020 19:02:00 -0000

Reviewer: Pete Resnick
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-6man-icmp-limits-07
Reviewer: Pete Resnick
Review Date: 2020-02-17
IETF LC End Date: 2020-02-25
IESG Telechat date: Not scheduled for a telechat


Nice simple document, easy to read, and pretty much ready to go. The one
"issue" I have listed below is a process nit, but one that should be taken care

Major issues:


Minor issues:

The tracker and the shepherd writeup say that the status of the document is
"Proposed Standard", but the header of the document says "Standard". That's why
the nits checker is complaining about downrefs; it thinks that this is going
for Full Standard. The header should either say "Standards Track" (which is
normal) or "Proposed Standard". (I hereby give Bob crap for missing that one as
shepherd, and I think he should owe me a beer. ;-) )

Nits/editorial comments:

The Abstract and 1.1 both indicate that a source host that receives such an
ICMPv6 error may be able to modify what it sends, which sounds to me like it
means "on the fly". While that might be true, it seems more likely to me that
it will be used for diagnostics to modify future behavior of either the sender
or the receiver at a later date, as mentioned in 4.2. I think it's worth
mentioning up at the top.

Section 1.3: You should probably update to the RFC 8174 text.

Section 5.1: "RECOMMENDS" isn't one of the keywords. It's not a problem in
itself, but if people search the document for the keywords (and they do),
they'll miss this one. Suggest reformulating the sentence to use RECOMMENDED.