Subject: Gen-ART LC review of draft-kolkman-proposed-standards-clarified-03

From: Peter Yee <[email-masked]>
Date: Tue, 15 Oct 2013 19:48:55 -0700

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-kolkman-proposed-standards-clarified-03
Reviewer: Peter Yee
Review Date: Oct-15-2013
IETF LC End Date: Oct-16-2013
IESG Telechat date: TBD

Summary: This draft is basically ready for  publication, but has nits that
should be fixed before publication. [Ready with nits.]

This draft updates the description of the Proposed Standard maturity
level previously defined in RFC 2026.  The update reflects the reality
of greater maturity embodied in Proposed Standards than is given in
RFC 2026.

Page 1, Abstract, last sentence: insert "of" between "characterization"
and "Proposed".

Page 2, Section 2 title: change "Reveiew" to "Review".

Page 3, 1st paragraph, 5th sentence: insert "the" between "IESG at"
and "last stage".

Page 4, Acknowledgements: change "Jari Arko" to "Jari Arkko".

Page 4, Acknowledgements: append a comma after "input".

---

From: Peter Yee <[email-masked]>
Date: Wed, 16 Oct 2013 21:14:58 -0700

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Oct 2013 02:04:26 -0300

Hi, Peter,

Thanks so much for your feedback! Please find my comments in-line....

On 10/17/2013 01:14 AM, Peter Yee wrote:
> ones that are unfriendly to stateless packet filtering?

The later. (Yep, th wording could be improved). How about:

"  This document describes how undesirably-fragmented packets can
   prevent traditional stateless packet filtering."

> It seems

I deem this as a corner case that wasn't expected to happen, but yet was
allowed (other might correct me if I'm wrong).

> document.  Usage is inconsistent.

Remove or add?

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

Done.

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

Done.

> be implemented.  E.g., indicates an example of something.

mm.. not sure what you mean. Could you please elaborate?

> that the entire header chain be in the first fragment.

Done.

> statement and the "or not".  They are redundant.

Done.

> "requirement" for the same reason given above.

Done

> "requirement" for the same reason given above.
Done

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

Done.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 20 Oct 2013 08:42:01 +0900

> standard but has open issues, described in the review.

The draft is totally broken, because ICMPv6 PTB generated against
a 1280B packet, port numbers of which is located at very end
of the packet, lacks the port numbers, which makes transport
layer PMTUD fail.

If a firewall exists and the ICMPv6 is generated behind the
firewall, the firewall will likely drop the ICMPv6, because
it can not recognize the transport identity of the inner
packet, but that is a minor issue.

The essential problem is that transport layer PMTUD can not get
proper information from ICMPv6.

Though there are other causes to make PMTUD fail, which means
6man should obsolete PMTUD, they don't validate the draft.

						Masataka Ohta

PS

ICMPv6 error is, in a sense, IP over IP.

---

From: Peter Yee <[email-masked]>
Date: Wed, 23 Oct 2013 21:08:02 -0700

Document: draft-kolkman-proposed-standards-clarified-04
Reviewer: Peter Yee
Review Date: Oct-23-2013
IETF LC End Date: Oct-16-2013
IESG Telechat date: Oct-24-2013

Summary: This draft is ready for publication as a BCP. [Ready]