Hi Kyle, Here is the revised draft of I2NSF Monitoring Interface: https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-model-13
Parick and I have addressed your comments from page 2 in the attached revision letter. Thanks for your help to improve our draft. Best Regards, Paul On Wed, Dec 1, 2021 at 6:13 AM Kyle Rose via Datatracker <[email protected]> wrote: > Reviewer: Kyle Rose > Review result: Ready with Nits > > 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 > [email protected] 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. > > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf >
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
