Last Call Review of draft-ietf-i2nsf-nsf-monitoring-data-model-12
review-ietf-i2nsf-nsf-monitoring-data-model-12-tsvart-lc-rose-2021-11-30-00

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.