Last Call Review of draft-ietf-6man-icmp-limits-07
review-ietf-6man-icmp-limits-07-genart-lc-resnick-2020-02-17-00
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 | https://mailarchive.ietf.org/arch/msg/gen-art/_5m-tkxSageb_T_S5UG3kkFsCUc | |
Reviewed revision | 07 (document currently at 08) | |
Result | Ready w/nits | |
Completed | 2020-02-17 |
review-ietf-6man-icmp-limits-07-genart-lc-resnick-2020-02-17-00
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 <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. 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 Summary: 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: None. 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.