Telechat Review of draft-ietf-6man-oversized-header-chain-08
review-ietf-6man-oversized-header-chain-08-genart-telechat-yee-2013-12-10-00

Request Review of draft-ietf-6man-oversized-header-chain
Requested rev. no specific revision (document currently at 09)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-11-19
Requested 2013-11-08
Draft last updated 2013-12-10
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-telechat-yee-2013-12-10
Reviewed rev. 08 (document currently at 09)
Review result Ready with Issues
Review completed: 2013-12-10

Review
review-ietf-6man-oversized-header-chain-08-genart-telechat-yee-2013-12-10

This review seems to have bounced, although I sent it separately to Jari.
I'm submitting into the mailing list so that it can be closed in the review
management tool.

			-Peter

-----Original Message-----
From: Peter Yee [

mailto:peter

 at akayla.com] 
Sent: Monday, November 18, 2013 10:07 AM
To: 'draft-ietf-6man-oversized-header-chain.all at tools.ietf.org'
Cc: 'gen-art at ietf.org'; 'ietf at ietf.org list'
Subject: Gen-ART Telechat review of
draft-ietf-6man-oversized-header-chain-08

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>

Please wait for direction from your document shepherd or AD before posting a
new version of the draft.

Document: draft-ietf-6man-oversized-header-chain-08
Reviewer: Peter Yee
Review Date: Oct-16-2013 (minor updates: Nov-18-2013) IETF LC End Date:
Oct-16-2013 IESG Telechat date: Nov-21-2013

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.

The suggested replacement text from the co-author, "This document describes
how undesirably-fragmented packets can prevent traditional stateless packet
filtering" works for me since the document does then explain the issues that
make up undesirable fragmentation, if not precisely using that term.

Nits:

General: use a comma after the terms "e.g." or "i.e." throughout the
document.  Usage is inconsistent.   Traditional usage is to add a comma
after these Latin abbreviations.

Page 3, 3rd paragraph: insert "the" between "from" and "IPv6".  I understand
that this item has already been dealt with and should appear in a revision
of the document before publication.

Page 8, 1st paragraph: replace "a" with "an" before "IPv6 datagram".  This
comment has also been dealt with but I'm leaving it and the rest of the
resolved comments in this message since a revised draft isn't available at
this time.

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.  The text leading up to the parenthetical example is " A host
that receives a first-fragment that does not satisfy the above-stated
requirement SHOULD discard the packet".  The parenthetical statement then
reads "(e.g., including  a configuration option that allows such fragments
to be accepted for backwards compatibility)".  So the text is the
parenthetical example is not an example of a host discarding a
first-fragment that fails to meet the requirements, it's a statement of
something else the host might want to do in cases where backwards
compatibility is desired.  In other words, it's sort of the opposite of the
clause that proceeded it.

The co-author has indicated that the remaining comments have been addressed,
so again they only appear for the record.

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".