[Tsv-art] Tsvart early review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05

[Wesley Eddy via Datatracker <[e-mail]>]

Reviewer: Wesley Eddy
Review result: Ready with Issues

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"