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