Skip to main content

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

Request Review of draft-ietf-i2nsf-nsf-monitoring-data-model
Requested revision No specific revision (document currently at 20)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2021-12-01
Requested 2021-11-17
Authors Jaehoon Paul Jeong , Patrick Lingga , Susan Hares , Liang Xia , Henk Birkholz
I-D last updated 2021-11-30
Completed reviews Yangdoctors Early review of -04 by Andy Bierman (diff)
Yangdoctors Last Call review of -06 by Andy Bierman (diff)
Genart Last Call review of -12 by Dale R. Worley (diff)
Artart Last Call review of -12 by Valery Smyslov (diff)
Secdir Last Call review of -12 by Melinda Shore (diff)
Tsvart Last Call review of -12 by Kyle Rose (diff)
Secdir Telechat review of -14 by Melinda Shore (diff)
Intdir Telechat review of -14 by Donald E. Eastlake 3rd (diff)
Assignment Reviewer Kyle Rose
State Completed
Request Last Call review on draft-ietf-i2nsf-nsf-monitoring-data-model by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/bVyOnvbqnNCi1cTd-QCnq8Ql73Y
Reviewed revision 12 (document currently at 20)
Result Ready w/nits
Completed 2021-11-30
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.