Éric Vyncke has entered the following ballot position for draft-ietf-i2nsf-nsf-facing-interface-dm-21: 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-facing-interface-dm/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below one blocking DISCUSS points (mainly to start discussion), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Linda Dunbar for the shepherd's write-up including the section about the WG consensus. I hope that this helps to improve the document, Regards, -éric # DISCUSS 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: ## Section 3.3 Many security practitioners prefer to have a congruent condition part for IPv4 and IPv6, so, why having *TWO* conditions rather than one where the destination/source could be either IPv4 or IPv6. Separating the conditions can only make the authoring of policies more complex. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # COMMENTS ## Abstract The abstract mentions an information model but no reference is given. See also my comment on section 1 ## Section 1 There is a mention of an information model in I-D.ietf-i2nsf-capability-data-model but as mentioned in my IESG ballot on that document, it does not contain any information model... Strongly suggest removing all mentions of 'information model' in the abstract and in this section. ## Section 3.3 Is the use of "ethernet" as a generic term for layer 2 appropriate ? Many layer-2 networks do not use Ethernet (so many IEEE standards...). Suggest to rename into "layer2". Should other "ethernet" fields be used? Like the VLAN or CoS fields ? If the IPv4 and IPv6 conditions are kept separated (see my DISCUSS above), then please rename the IPv6 "ttl" into "hop-limit" and "protocol" into "next-header". More generally, and may be have I overlooked some previous explanations, is the cardinality of ethernet, ipv4, ipv6 the most suitable one ? Can't a condition have multiple IPv4 prefixes ? ## Section 4.1 Why is "session-aging-time" only a uint16 ? As its unit is "second", this represents roughly 18 hours and I am sure that some sessions are longer than 18 hours (I have many opened SSH sessions for days). In "identity reject", when mentioning the ICMP type and code, please specify whether it is ICMPv4 or ICMPv6 ;-) ## Section 5.1 Thank you for the IPv6 example :-) Same comment as Erik Kline on the IPv6 address, may I also suggest to use a more sensible prefix length ? /60 should be more representative. _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
