Last Call Review of draft-ietf-6man-icmp-limits-07

Request Review of draft-ietf-6man-icmp-limits
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-02-25
Requested 2020-02-11
Authors Tom Herbert
Draft last updated 2020-02-17
Completed reviews Genart Last Call review of -07 by Pete Resnick (diff)
Tsvart Last Call review of -07 by Bernard Aboba (diff)
Assignment Reviewer Pete Resnick 
State Completed
Review review-ietf-6man-icmp-limits-07-genart-lc-resnick-2020-02-17
Posted at
Reviewed rev. 07 (document currently at 08)
Review result Ready with Nits
Review completed: 2020-02-17


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 of.

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.