Subject: [I2nsf] Francesca Palombini's Discuss on draft-ietf-i2nsf-nsf-monitoring-data-model-15: (with DISCUSS and COMMENT)

From: Francesca Palombini via Datatracker <[email-masked]>
Date: Wed, 16 Feb 2022 12:46:32 -0800

Francesca Palombini has entered the following ballot position for
draft-ietf-i2nsf-nsf-monitoring-data-model-15: 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 on this document.

Many thanks to Valery Smyslov for his review:
https://mailarchive.ietf.org/arch/msg/art/2XuRUuQaI8ZrVSyuWQn1SHi5dEY/, and to
the authors for partially addressing his comments. I am following up on his
review about the language tag -  thank you for adding that - with a DISCUSS
point. I also have a question about the Web Attack Alarm, more general than
Ben, but on the same line.

I also have a number of minor COMMENTs and suggestions, which I hope will
improve the document.

Francesca

1. -----

FP: Regarding the language tag description in Section 5 is missing a pointer to
RFC 5646 and a default value. The following text could be added:

 The attribute is encoded following the rules in Section 2.1 of
      [RFC5646].  The default language tag is "en-US".

I'd also like some stronger text about the tag being required if any of the
textual fields are present. In particular, I do not think this text is good
enough:

                        This field is mandatory only
            when the implementation provides more than one human
            language for the human-readable string fields.

I believe that the field should be sent any time any human readable string
field is used. I believe all of the human readable fields are optional, so it
is ok that language is also optional.

I would also have appreciated more precision about what fields are covered by
this language tag (message, output? any other?) in the description in Section 5
and in the YANG module.

Additionally, and this is just a comment as I am not sure if this is already
covered by the YANG syntax, I would have expected to see the language leaf
under the grouping common-monitoring-data, because that is where message is
(assuming that is the only human readable field). Here is an example of another
YANG module using the language tag "description-lang" for the "attack-detail"
grouping: https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-23.
Please do correct me if this is already covered.

2. -----

Section 6.3.4.

FP: It is not clear to me why these specific header fields (and these fields
only) are selected to be part of the information about Web Attack Alarm -
req-user-agent, cookies. I agree with Ben's DISCUSS point 1. and would even add
to that that more motivation around which header fields are included and why,
would help. I'd also like to know if the HTTPBIS working group has been
involved in the discussion, and if not, if they could be to give their expert
opinion.

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

3. -----

      interval (e.g., 1 second).  This interval is defined as dampening-
      period in [RFC8641].  The dampening-period is configurable.  The

FP: RFC 8641 has the following:

                    +--rw yp:dampening-period?   centiseconds

which indicates the unit of the dampening period, while this document contains:

        |     +--rw dampening-period?   uint32

My preference would be to align the two. I do note this is clarified in the
YANG module, where the unit is centiseconds as well, but it would be good to
have this clarity in the text in Section 6 as well.

4. -----

FP: On the same note, I would have liked to see the unit stated for other
fields in subsections of Section 6: usage, threshold, cpu-usage, disk-usage,
disk-left etc. Analogously, a pointer to Section 5.6 of RFC 3339 every time a
timestamp is mentioned in subsections of Section 6: start-time, end-time,
discontinuity-time, operation-time etc would have been appreciated. Again, I
know this is clear in the YANG module, but I do think the descriptive text
would have benefitted from the clarifications.