Subject: [Gen-art] Gen-Art review of draft-ietf-6man-exthdr-05

From: <[email-masked]>
Date: Sun, 4 Dec 2011 15:56:28 -0500

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-6man-exthdr-05
Reviewer: Kathleen Moriarty
Review Date: 12/04/2011
IETF LC End Date: 12/05/2011
IESG Telechat date: (if known)

Summary:  The draft is ready with nits.
This document describes the issues that can arise when defining new extension headers and discusses the alternative extension mechanisms in IPv6.  It also provides a format for defining new IPv6 extension headers that would allow implementations to process past unknown extension headers.

Major issues:

Minor issues:

Nits/editorial comments:
Abstract, third sentence: Unless 'alternative' is an official term used for the purpose described, the word 'alternate' would read better.

Introduction: Last sentence of 1st paragraph:  Consider removing the word 'intends'.  Since this defines the extension, you can just state that.
Change to:  "This document defines a standard format for IPv6 extension headers."

Second paragraph: Consider removing the word "Also" at the start of the sentence.  The transition is not needed.

Third paragraph, consider adding a couple of commas in the first sentence, it reads better:
Change to: "Any IPv6 header or option that has hop-by-hop behavior, and is
   intended for general use in the public IPv6 Internet, could be
   subverted to create an attack on IPv6 routers processing packets
   containing such a header or option."

Section 3, third paragraph:
Remove the word "So" at the start of the sentence.
Change to; "New IPv6 Extension
   Header(s) having hop-by-hop behaviour MUST NOT be created or
   specified."
Third sentence: consider changing to (add a word after alternative, perhaps solution?):
"New options for the existing Hop-by-Hop Header
   SHOULD NOT be created or specified unless no alternative solution is feasible.

Section 4, first sentence:
It could read better, consider changing it to the following suggestion:
"Any IPv6 Extension Headers are defined in future MUST use the consistent format defined
   in Figure 1, including the restrictions specified in Section 3 and in [RFC2460]."

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 5 Dec 2011 17:58:57 -0500

Hi Kathleen,
  Thanks for the review and the text suggestions. I will fix these nits
in the next rev.

Cheers
Suresh