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 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-02-04
Completed reviews Opsdir Last Call review of -12 by Sheng Jiang (diff)
Genart Last Call review of -12 by Paul Kyzivat (diff)
Secdir Last Call review of -12 by Charlie Kaufman (diff)
Artart Last Call review of -13 by Dr. Bernard D. Aboba (diff)
Tsvart 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 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.