Éric Vyncke has entered the following ballot position for draft-ietf-i2nsf-nsf-facing-interface-dm-23: Abstain
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/about/groups/iesg/statements/handling-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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document and for acting on most of my comments on revision -21. As written in a separate email, I am clearing my previous DISCUSS position but I am balloting ABSTAIN as the IPv6 support in this document is really too low. I understand that authors rely on the YANG modules of RFC 8519 which is clearly not enough for IPv6. About my own DISCUSS, the change to a "choice layer-3" is still a XOR: either IPv4 or IPv6 and this is not what security practitioners want to do as they do want congruent security policies. As we are kind of circling and not really reaching a final agreement, I will change my ballot from DISCUSS to ABSTAIN. Special thanks to Linda Dunbar for the shepherd's write-up including the section about the WG consensus. Special thanks as well to Jean-Michel Combes for his INT directorate review. Regards, -éric # DISCUSS (only kept for archiving) 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. # COMMENTS (only kept for archiving) ## 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
