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]." _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
