Pete, thanks for your review. Tom, thanks for your response. I entered a DISCUSS ballot to get the maturity level fixed.
Best, Alissa > On Mar 5, 2020, at 2:17 PM, Tom Herbert <t...@quantonium.net> wrote: > > Hi Pete, > > Thanks for the review. Comments inline. > > On Mon, Feb 17, 2020 at 11:02 AM Pete Resnick via Datatracker > <nore...@ietf.org <mailto:nore...@ietf.org>> wrote: >> >> 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 >> >> <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. > > Thanks! > >> >> 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. ;-) ) > > Will fix. > >> >> 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. > > Yes, I would expect these are most useful for offline diagnostics at > least at the beginning. Will mention that. >> >> Section 1.3: You should probably update to the RFC 8174 text. >> > Okay. > >> 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. > > Will fix, thanks for being pedantic! > >> >> > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org <mailto:Gen-art@ietf.org> > https://www.ietf.org/mailman/listinfo/gen-art > <https://www.ietf.org/mailman/listinfo/gen-art>
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
