Re: [Gen-art] Genart last call review of draft-ietf-6man-icmp-limits-07

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 <tom@quantonium.net> wrote:
> 
> Hi Pete,
> 
> Thanks for the review. Comments inline.
> 
> On Mon, Feb 17, 2020 at 11:02 AM Pete Resnick via Datatracker
> <noreply@ietf.org <mailto:noreply@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>