Erik Kline has entered the following ballot position for draft-ietf-i2nsf-nsf-monitoring-data-model-14: No Objection
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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [S6.1.5; comment] * Possibly this set of "interface-state"s is sufficient for security monitoring, but I'm wondering if any of the additional "oper-status" states from RFC 8343 would be of interest (maybe, maybe not). [S8; comment] * Anywhere an inet:ip-address-no-zone is used I'm curious as to whether or not an optional associated interface might want to also be present. For example, in the case of "i2nsf-traffic-flows" there is no ingress nor egress interface. It's possible that with knowledge of the routing at the time the information was captured the ingress/egress interfaces could be reconstructed but that might also prove difficult unless that information is separately retained. This applies to the uses as well where the interface in question might want to be noted, either because it could change in the future or perhaps because an attack arrives via an unexpected interface. [S8; question] * Are all three "leaf language" definitions necessary, or can this be something shared, defined only once somewhere else? _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
