Erik Kline has entered the following ballot position for draft-ietf-i2nsf-capability-data-model-12: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability-data-model/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [ general ] * At a high level, I'm slightly concerned about the state of the IP-geo aspects of this document. It's not obvious to me what's desired (nor what may be achievable) here. [1] RFC 8805 In section 5, there's a reference to 8805. This document is an Independent Stream Editor's document, and not an IETF standard. I don't know if that's technically disqualifying from being listed as a Normative reference or not. Regardless, it certainly does not represent any formal industry consensus. [2] ipv4-geo-ip This references draft-ietf-i2nsf-capability, but I cannot find any discussion of IPv4 address geolocation in that document (admittedly I have not read it thoroughly). [3] ipv6-geo-ip I did not find an analogous geo-ip element for IPv6. If there should be support for geolocation for one address family there should probably be support for the other. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ comments ]] [ section 1 ] * This document describes a YANG model outlining a few more I2NSF documents than just i2nsf-capability, including: - i2nsf-nsf-monitoring-data-model - i2nsf-sdn-ipsec-flow-protection Indeed, this is noted in section 5. I think it could help the reader when they get to section 4.1 if some earlier section also noted the more complete list of references that section 5 does. [ section 4.1 ] * ICMPv6 is notable by its absence from the list in the paragraph describing the "condition capabilities of generic network security functions". [ section 5 ] * The meaning of ipv6-protocol is not immediately obvious, and may be redundant with ipv6-next-header (the actual name of the header field). Or rather, does ipv6-protocol here mean IPv6 itself (as in the value "6" or "true" meaning 'is capable of')? Or does this mean the first non-IPv6-extension-header next-header value? [[ nits ]] [ section 1 ] * "As the industry becomes more sophisticated and network devices (...)," This is not a grammatically complete clause. Maybe just something like: "...and network devices (...) continue to proliferate, ..." or something. [ section 3 ] * "at a Developer's Management Systems" -> "at a Developer's Management System" * "managing the capabilities of NSFs in this document" -> "managing the capabilities of NSFs as described in this document"? * "network administrator ..., he sends" -> "network administrator ..., they send" * "sends that security policy rules" -> "sends that security policy rule" * "This lets an I2NSF User not consider NSFs where the rule is applied." I found this confusing. Does it mean to say something like "...where the rule is not applicable"? _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
