Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-6man-mtu-option-12

From: Lars Eggert <[email-masked]>
Date: Tue, 5 Apr 2022 17:42:49 +0300

Paul, thank you for your review. I have entered a No Objection ballot for this document.

Lars

On 2022-2-4, at 19:54, Paul Kyzivat <[email-masked]> wrote:
> 
> 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-mtu-option-12
> Reviewer: Paul Kyzivat
> Review Date: 2022-02-04
> IETF LC End Date: 2022-02-10
> IESG Telechat date: ??
> 
> Summary:
> 
> This draft is ready for publication as an Experimental RFC.
> 
> Comments and Questions:
> 
> I didn't attempt to evaluate the security considerations as it is totally outside my scope. I trust this will be dealt with by a security review.
> 
> I have the following questions about the draft. (I don't think they even rise to the level of nits.)
> 
> 1) Regarding PMTU range in section 5:
> 
> Was any consideration given to supporting PMTUs greater than 2^16?
> 
> 2) Regarding multiplexing of Rtn-PMTU and R-Flag in section 5:
> 
> Min-PMTU is permitted to be odd, but Rtn-PMTU is forced to be even to allow room for the R-Flag. Hence, if the Min-PMTU ends up odd, then it will be rounded down in Rtn-PMTU.
> 
> Why not restrict Min-PMTU to be even as well? This would provide consistency and make clear that MTUs need to be even? This could be done by reducing Min-PMTU to 15 bits, adding a 1-bit reserved field, and a few explanatory words to the text.
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art