Last Call Review of draft-ietf-6man-oversized-header-chain-08
review-ietf-6man-oversized-header-chain-08-genart-lc-yee-2013-10-17-00

Request Review of draft-ietf-6man-oversized-header-chain
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-10-16
Requested 2013-10-03
Draft last updated 2013-10-17
Completed reviews Genart Last Call review of -08 by Peter Yee (diff)
Genart Telechat review of -08 by Peter Yee (diff)
Secdir Last Call review of -08 by Tobias Gondrom (diff)
Assignment Reviewer Peter Yee
State Completed
Review review-ietf-6man-oversized-header-chain-08-genart-lc-yee-2013-10-17
Reviewed rev. 08 (document currently at 09)
Review result Ready with Issues
Review completed: 2013-10-17

Review
review-ietf-6man-oversized-header-chain-08-genart-lc-yee-2013-10-17

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Document: draft-ietf-6man-oversized-header-chain-08
Reviewer: Peter Yee
Review Date: Oct-16-2013
IETF LC End Date: Oct-16-2013
IESG Telechat date: TBD

Summary: This draft is almost ready for publication as a proposed
standard but has open issues, described in the review.
[Ready with issues]

This draft attempts to overcome a potential problem caused by the
fragmentation of IPv6 header chains by limiting such chains to
fitting within the first fragment.  This permits stateless
packet filtering firewalls to make an appropriate decision based
on a single fragment rather than having to rely on incomplete
information that might be present in a first fragment if the
header were split across more than one fragment.

Major issues: None

Minor issues:

Page 10, 1st paragraph: the term "improperly-fragmented" is
used.  Are these truly improperly-fragmented packets or simply
ones that are unfriendly to stateless packet filtering?  It seems
more like the lengthy headers were within spec to date and are now
being prohibited to solve a specific problem.

Nits:

General: use a comma after the terms "e.g." or "i.e" throughout the
document.  Usage is inconsistent.

Page 3, 3rd paragraph: insert "the" between "from" and "IPv6".

Page 8, 1st paragraph: replace "a" with "an" before "IPv6
datagram".

Page 8, 2nd paragraph: the parenthetical example does not appear
to be a good match for the preceding text.  It is written as a
mechanism that allows the possible maintenance of the status quo
rather than giving an example of how the preceding SHOULD might
be implemented.  E.g., indicates an example of something.

Page 8, paragraph 3, 1st sentence: change "requirements" to
"requirement".  Only one requirement was given and that was
that the entire header chain be in the first fragment.

Page 8, 3rd paragraph, 2nd sentence: delete the parenthetical
statement and the "or not".  They are redundant.

Page 8, 4th paragraph, 1st sentence: change "requirements" to
"requirement" for the same reason given above.

Page 8, 5th paragraph, 1st sentence: change "requirements" to
"requirement" for the same reason given above.

Page 10, 1st paragraph: append a comma after "traditional".