Skip to main content

Last Call Review of draft-ietf-6man-mtu-option-12
review-ietf-6man-mtu-option-12-genart-lc-kyzivat-2022-02-04-00

Request Review of draft-ietf-6man-mtu-option
Requested revision No specific revision (document currently at 15)
Type IETF Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2022-02-10
Requested 2022-01-27
Authors Bob Hinden , Gorry Fairhurst
I-D last updated 2022-08-29 (Latest revision 2022-05-10)
Completed reviews Opsdir IETF Last Call review of -12 by Sheng Jiang (diff)
Genart IETF Last Call review of -12 by Paul Kyzivat (diff)
Secdir IETF Last Call review of -12 by Charlie Kaufman (diff)
Artart IETF Last Call review of -13 by Dr. Bernard D. Aboba (diff)
Tsvart IETF Last Call review of -12 by Olivier Bonaventure (diff)
Opsdir Telechat review of -13 by Sheng Jiang (diff)
Tsvart Telechat review of -13 by Olivier Bonaventure (diff)
Assignment Reviewer Paul Kyzivat
State Completed
Request IETF Last Call review on draft-ietf-6man-mtu-option by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/cSJ1VnpREVnAknRj_ANN0QFRdA0
Reviewed revision 12 (document currently at 15)
Result Ready
Completed 2022-02-04
review-ietf-6man-mtu-option-12-genart-lc-kyzivat-2022-02-04-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-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.