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. _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
