I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-opsawg-rfc7125-update-??
Reviewer: Elwyn Davies
Review Date: 2023-10-27
IETF LC End Date: 2023-10-26
IESG Telechat date: 2023-11-30

Summary:

The data specification is good to go, but there are some difficulties (in my view) with status and the nature of some text that is intended to be a data description but actually provides normative rules for a protocol using the data.  Looking at the IPFIX IANA record, it may be worth checking that there are not additional entries that could be vulnerable in a similar way to the Control Flags.  I also noted that there are some references to RFCs in the record that could do with added RFC numbers.

Major issues:

Status of documents:  I note that this is intended to be a standards track document that obsoletes an informational document (RFC 7125)  which in turn updated a standards track document (RFC 5102) which has in turn been sort of 'obsoleted'  by RFC 7012.  Since RFC 5102 remains as a historic reference and is mentioned in RFC 7012, I think this draft should specify that it updates RFC 7012 since someone using the IPFIX data structures etc should be aware of this.  Also I would say that this draft goes further than making RFC 7125 obsolete - RFC 7125 should become Historic.  I take it this could be specifed in this document. 

S3: In essence this document contains a data description intended to update a part of the data description in the IANA record of "IP Flow Information Export (IPFIX) Entities".   However, the four paragraphs of Description in S3 starting  at para 4 ("As the most significant...") contain prescriptive normative  language that purports to affect the behaviour of the protocol that is intending to use this data description (e.g., para 5 says

All TCP control bits (including those unassigned) MUST be exported
      as observed in the TCP headers of the packets of this Flow. )

Is this a legitimate usage?   I note that this language is (I think) the 'stronger requirement language' mentioned in s5, para 1.  This issue is closely tied to the document status issue above.

Minor issues: None

Nits/Editorial comments:

s1, para 3
OLD:
   However, that update is still problematic for interoperability
   because a value was deprecated since then (Section 7 of [RFC8311])
   and, therefore, [RFC7125] risks to deviate from the authoritative TCP
   registry [TCP-FLAGS].
NEW:
   However, that update may still be problematic for interoperability
   because a flag value was added prior to the release of [RFC9293] for experimental
   purposes but has since been deprecated (see Section 7 of [RFC8311]).
   [RFC7125] pre-dates this deprecation and explicitly mentions the deprecated
   flag hence deviating from the authoritative TCP registry [TCP-FLAGS].  Any
   future changes to the control flags would risk additional deviations unless
   [RFC7125] were updated in the same way.
END

s4: IANA should also add a reference to this document.