This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information.

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review.

My summary of the review is that this document does not carry any concerns of particular interest to the transport area.

Coincidentally or not, I [completed a secdir review last week](https://datatracker.ietf.org/doc/review-ietf-i2nsf-nsf-facing-interface-dm-16-secdir-lc-rose-2021-11-22/) on a related document. In that review I had comments re: how YANG was used that may also apply here.

The data model in various areas makes assumptions about the systems being monitored. For instance, in section 6.2.1 ("Access Violation"), the identifying information for the attempted access violation is given as (user, group, IP address). Is this universal? What if the connection was NATed? You might need the port and/or a snapshot of the connection tracking state at the time. Or proxied? It feels like identifying information is highly context-dependent and should be parameterized in an extensible way.

Relatedly, the same schema for user identifying information is replicated elsewhere in the data model rather than being abstracted. Right after "Access Violation" comes "Configuration Change", which includes the same information.

One major nit (Is that like jumbo shrimp?): there are a lot of 32-bit counters employed in this data model, many of which will probably overflow quite quickly. While moving to 64-bit counters would probably address most such instances, I cannot find any discussion in the WG's other documents of how counter overflow should be managed.

Popping up a level, however, I question the utility of standardizing an interface to what the WG charter itself recognizes as a basic set of functions, as anything beyond these basic functions would need to be accessed via custom knobs. Even within flow-based security functions, it's unclear to me (for example) how extensibility for novel or more specific values (even within an existing category) is expected to work in a way that is compatible with the goal of creating a standard interface. If the motivation here is to prevent vendor lock-in, it's not clear to me that this approach will achieve that. If OTOH the goal is to fix an interface for a relatively stable set of functionality that is no longer expected to expand in scope, in a long-term effort (alongside development of a shared software ecosystem) to reduce maintenance costs for all players in that ecosystem, this might be the right direction. Standards almost always lag proprietary implementations, and for good reason.