Comments:

- The document is well-written and easy to read.

- Section 6 is really nice and helpful!

Issues:

- The way an implementation understands the TCP ExIDs may benefit from slightly more explanation:
  -- In 4.2 and 4.3, is the idea that the implementation is just sampling the 16 or 32 bits following the experimental option kind being indicated, and assuming those 2 or 4 bytes to be ExIDs?  From Section 6.2, I got the sense that the implementation is aware of particular ExID values specifically, to know if they should be reported as 2 or 4 byte values.
  -- Will any values present be reported, or only those which show up in the IANA registry?  I assume any values will be reported, even if they are not registered ExIDs, since the registry changes over time, and implementations probably don't grab periodic updates of it.

Questions:

- This may be alright, but it seemed to me like for interoperability there should be some way to indicate what an implementation of this IE is doing with regard to this text in Section 3.1 (where maybe "may" should be "MAY"?):

      Several extension header chains may be observed in a Flow.  These
      extension headers may be aggregated in one single
      ipv6ExtensionHeadersFull Information Element or be exported in
      separate ipv6ExtensionHeadersFull IEs, one for each extension
      header chain.

- In Section 3.3, it seems backwards to me that this Limit IE being True means that no limitation was applied, whereas False means that it was limited.  If the WG and implementers are okay with this, I'm not questioning it, but it seems odd, so I just wanted to make sure this was the intention.

Nits:

- The first paragraph in section 1 should probably mention the specific RFC(s) for the specified IEs with the noted problems, since it sounds from the beginning paragraphs of section 3 and 4 like some of those are already being addressed by the separate ipfix-fixes document.

- Section 1.1, "do no correspond" -> "do not correspond"