A Uniform Format for IPv6 Extension Headers
draft-ietf-6man-exthdr-06

abstract: s/past/beyond/
	(past can also mean previous; the intro has more context for the usage)

intro:
s/absolutely essential in the Internet-Draft proposing the new option with hop-by-hop behavior./absolutely essential./

My colleagues have raised a well-rounded set of questions about this document. In addition, I think it could say more about the impact on interoperability and Internet operations (these issues are mentioned in the introduction but not described in detail).

  The Gen-ART Review by Kathleen Moriarty on 4-Dec-2011 suggested some
  editorial changes, and the author agreed to make them.  However, the
  changes have not been made yet.

1) s4: Contains the following:

 Next Header     8-bit selector.  Identifies the type of header
                 immediately following the Extension header.
                 Uses the same values as the IPv4 Protocol
                 field.

Don't you need a reference for the values?  Maybe:

 [IANA_IP_PARAM]
              IANA, "IP Parameters",
              <http://www.iana.org/assignments/ip-parameters>.

2) Where do I get a ticket for the "doesn't this update 2460" bandwagon?

- Doesn't this update rfc 2460?

Extension headers are sensitive to ordering, partial deployment, and other issues.  I don't think the guidelines in this document mitigate these in a meaningful way (e.g. due to the fact that it remains unknown the intermediate nodes whether unrecognized extensions earlier in the chain should alter later extension header or upper layer protocol processing), HOWEVER, I don't think the guidelines are harmful either, and can see that it's desirable to have a recommended base extension header format.

For some time, high-rate DPI that I have seen has used heuristics rather than actual protocol processing.  I do not think adoption of the guidelines in this document will alter that, though "helping" such devices seems to be a goal for this work.  It seems undesirable to me, in general, to restrict protocol formats in order to aid layer violations ... but in the case of this particular document, I believe no harm is done.