Subject: [I2nsf] Éric Vyncke's Discuss on draft-ietf-i2nsf-nsf-monitoring-data-model-14: (with DISCUSS and COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 09 Feb 2022 02:56:52 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-i2nsf-nsf-monitoring-data-model-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-monitoring-data-model/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document. I really like the approach of
binding an information model to a data model even if the information model
looks more like a data dictionary.

Please find below some blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education), and some nits.

Please also check the Internet directorate review by Donald Eastlake (thank you
BTW) at:
https://datatracker.ietf.org/doc/review-ietf-i2nsf-nsf-monitoring-data-model-14-intdir-telechat-eastlake-2022-02-07/
NB: as you may notice, I have not followed Donald's recommendation to raise a
DISCUSS on one point, but Donald and I will appreciate an answer of the authors.

Special thanks to Linda Dunbar for the shepherd's write-up (even if dated one
year ago) including the section about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

While I trust the OPS AD for a final say, I am really surprised that the data
model does not re-use existing YANG modules (e.g., RFC 8632 and
<https://yangcatalog.org/yang-search/yang_tree/ietf-alarms@2019-09-11>).

## Section 6.2.4
About exporting the "traffic flows", a justification of not using IPFIX is
required IMHO.

Also missing the MAC address field as not all flows are IPv4 or IPv6 (LLDP,
IS-IS, ARP, ...).

## Section 6.3.2
Why is the geo-location not implied by the IP address ? Or rather, how can it
be derived if not based on the IP address ? Hence, why duplicating the
information which is always bad for data consistency?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

## Abstract
Unsure what a "YANG data diagram" is... Is it a well-known wording for YANG
experts or is it "YANG tree diagram"?

## Section 4.1
Suggestion to use "I2NSF gauge" rather than "I2NSF counter" to represent
processor temperature.

## Section 6.2.1
The use of "port" is unqualified and therefore ambiguous: is it a layer-4 port
? or an interface port ? Even if the reader may guess the former, let's remove
the ambiguity.

## Section 6.2.3
Is there a definition of "sessions" ? I.e., is it a data plane TCP/UDP
"connection" or a configuration plane connection ?

## Section 6.2.4
Here also, a qualification of the "port" is welcome.

On which interval are the rates computed ? Since the beginning of the flow ?
Last minute ? or ?

s/arrival-speed/arrival-throughput/ ?

Note: the above comments are also applicable in other places in the document.

## Section 6.3.1
Even if most (if not all) DoS are actually DDOS, would a section title of "DoS"
be more generic ?

## Section 6.3.2
Should this section be renamed in "malware" ?

As the 'virus' event can also be detected locally, is the IP flow information
required or even available? Or are NSF never implemented on host for local host
security ?

What is the "host" here ? In which case is the "host" neither the source nor
the destination IP ?

Is there a reason why the geo-location is not included in other events ? (see
also my DISCUSS point above as geo-location is probably derived from the IP
addresses).

## Section 6.4.2
Does the "traffic" include only the data plane or also control/management plane
? Does it count the layer-2 framing ?

s/disk-left/disk-space-left/ ?

## Section 6.5.1
Some explanations linking "deep packet inspection" to apparently local user
actions will be welcome. For most readers, DPI is for transit traffic not for
local actions.

## Section 6.6.1
Are the "drops" caused by policy ? or by hardware/resource error ?

As mentioned above, the "peak" and "average" should be qualified by the
measurement period.

## Section 8
s/identity ssl-flood/identity tls-flood/

Is there a reason to have a limited set of application protocol ? I.e., why
including FTP and not NTP ? Or why defining any at all .. (except perhaps
HTTP/HTTPS).

For many operators, having separate counters for IPv4/IPv6/non-IP will be
useful.

# NITS

## Section 1

s/denial of service attacks (DoS)/denial of service (DoS) attacks/ ?

## Section 6.2.3
s/The number of session table exceeded the threshold/The number of sessions
exceeded the table threshold/ ?

## Section 8
For "log-action", there is a mix of "action is block" and "action is discarded"
(i.e., different tenses).

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 16 Feb 2022 01:35:53 +0900

Hi Éric,
Here is the revised draft reflecting your comments:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-monitoring-data-model-15

I attach the revision letter to explain how the revision is done by Patrick
and me
for your comments.

[Review by Éric Vyncke and Response by Authors] starts from page 1 in the
revision letter.

Thanks for your valuable comments and help.

Best Regards,
Paul

On Wed, Feb 9, 2022 at 7:57 PM Éric Vyncke via Datatracker <[email-masked]>
wrote:

> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>