Skip to main content

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

Request Review of draft-ietf-6man-icmp-limits
Requested revision 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
I-D last updated 2020-02-17
Completed reviews Genart Last Call review of -07 by Pete Resnick (diff)
Tsvart Last Call review of -07 by Dr. Bernard D. Aboba (diff)
Assignment Reviewer Pete Resnick
State Completed
Request Last Call review on draft-ietf-6man-icmp-limits by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 07 (document currently at 08)
Result Ready w/nits
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

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.