Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-6man-oversized-header-chain-08

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Nov 2013 08:59:25 -0300

Not sure this mail made it to the appropriate parties (Peter reported some e-mail issue with the list). However, many thanks for the review, Peter, appreciated!

I do agree with the minor issue that Peter raises and the suggested text from Fernando. I don't see a new document revision yet, however. I assume you Fernando and Brian have the token to ensure that the resolution and the resolutions for the nits gets into the document before it is shipped to the RFC Editor.

Thanks again, and thank you for writing this document.

Jari

> -----Original Message-----
> From: Peter Yee [mailto:[email-masked]] 
> Sent: Monday, November 18, 2013 10:07 AM
> To: [email-masked]'
> Cc: [email-masked]'; [email-masked] 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".
> 
>

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 21 Nov 2013 14:52:05 +0000

Hi Jari,

We would be glad to spin a new version addressing the minor issues. We could do it either before or during AUTH48, as you please.

                                                  Ron

> From: Jari Arkko [mailto:[email-masked]]
> Sent: Thursday, November 21, 2013 6:59 AM
> To: Peter Yee; Fernando Gont; Brian Haberman
> Cc: [email-masked]; gen-
> [email-masked] Team ([email-masked])
> Subject: Re: Gen-ART Telechat review of draft-ietf-6man-oversized-
> header-chain-08
> 
> Not sure this mail made it to the appropriate parties (Peter reported
> some e-mail issue with the list). However, many thanks for the review,
> Peter, appreciated!
> 
> I do agree with the minor issue that Peter raises and the suggested
> text from Fernando. I don't see a new document revision yet, however. I
> assume you Fernando and Brian have the token to ensure that the
> resolution and the resolutions for the nits gets into the document
> before it is shipped to the RFC Editor.
> 
> > Please wait for direction from your document shepherd or AD before
> > posting a new version of the draft.
> >
> > Review Date: Oct-16-2013 (minor updates: Nov-18-2013) IETF LC End
> > Date: Oct-16-2013 IESG Telechat date: Nov-21-2013
> >
> 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.
> >
> > 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.
> >
> > "requirement".  Only one requirement was given and that was that the
> > entire header chain be in the first fragment.
> >