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

[Suresh Krishnan <[e-mail]>]

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

Cheers
Suresh

On 12/04/2011 03:56 PM, [e-mail] wrote:
> 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]."
> 
> 
> 
>