Skip to main content

Early Review of draft-ietf-opsawg-ipfix-tcpo-v6eh-05
review-ietf-opsawg-ipfix-tcpo-v6eh-05-tsvart-early-eddy-2024-01-02-00

Request Review of draft-ietf-opsawg-ipfix-tcpo-v6eh
Requested revision No specific revision (document currently at 18)
Type Early Review
Team Transport Area Review Team (tsvart)
Deadline 2024-01-22
Requested 2023-12-18
Requested by Joe Clarke
Authors Mohamed Boucadair , Benoît Claise
I-D last updated 2024-01-02
Completed reviews Genart Last Call review of -11 by Joel M. Halpern (diff)
Secdir Last Call review of -11 by Tero Kivinen (diff)
Tsvart Last Call review of -11 by Wesley Eddy (diff)
Intdir Last Call review of -11 by Dirk Von Hugo (diff)
Secdir Last Call review of -15 by Tero Kivinen (diff)
Tsvart Early review of -05 by Wesley Eddy (diff)
Opsdir Early review of -05 by Yingzhen Qu (diff)
Intdir Early review of -05 by Dirk Von Hugo (diff)
Assignment Reviewer Wesley Eddy
State Completed
Request Early review on draft-ietf-opsawg-ipfix-tcpo-v6eh by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/NDL6YlleUpUT3GYxqc2n8vMvxog
Reviewed revision 05 (document currently at 18)
Result Ready w/issues
Completed 2024-01-02
review-ietf-opsawg-ipfix-tcpo-v6eh-05-tsvart-early-eddy-2024-01-02-00
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"