Subject: Re: [Tsv-art] [I2nsf] Tsvart last call review of draft-ietf-i2nsf-nsf-monitoring-data-model-12

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 26 Jan 2022 19:57:58 +0900

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-masked]>
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-masked] 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-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 26 Jan 2022 20:07:35 +0900

Hi Kyle,
I send you the revision letter for I2NSF Monitoring Interface:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-model-13

Thanks.

Best Regards,
Paul

On Wed, Jan 26, 2022 at 7:57 PM Mr. Jaehoon Paul Jeong <
[email-masked]> wrote:

>> My summary of the review is that this document does not carry any
>> concerns of
>> on a related document. In that review I had comments re: how YANG was
>> used that
>> may also apply here.
>>
>> proxied? It feels like identifying information is highly
>> context-dependent and
>> vendor lock-in, it's not clear to me that this approach will achieve
>> that. If