Hi Éric, Thanks for your response. I put my answers below. On Wed, Apr 6, 2022 at 5:14 PM Éric Vyncke via Datatracker <[email protected]> wrote:
> É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. > => [PAUL] I will address the extension of the support of IPv6 extension headers after the publication of this document as an RFC and through the revision of the RFC during the 2nd phase of I2NSF WG. I2NSF WG is now discussing the re-chartering including this extension for the support of new protocols such IPv6 extension headers, QUIC, and HTTP/3. > > 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. > => [PAUL] This XOP approach of "choice layer-3" is done by RFC 8519 as follows: --------------------------------------------------------------------------------------------------- container matches { ... choice l3 { container ipv4 { when "derived-from-or-self(/acls/acl/type, " + "'acl:ipv4-acl-type')"; if-feature "match-on-ipv4"; uses pf:acl-ip-header-fields; uses pf:acl-ipv4-header-fields; description "Rule set that matches IPv4 headers."; } container ipv6 { when "derived-from-or-self(/acls/acl/type, " + "'acl:ipv6-acl-type')"; if-feature "match-on-ipv6"; uses pf:acl-ip-header-fields; uses pf:acl-ipv6-header-fields; description "Rule set that matches IPv6 headers."; } description "Choice of either IPv4 or IPv6 headers"; } ... --------------------------------------------------------------------------------------------------- Éric, Could you consider this convention of l3 handling in ACL in RFC8519 to determine your ballot? Otherwise, we authors need another "Yes" or "No Objection" from the following ADs: Andrew Alston, John Scudder, Lars Eggert, and Paul Wouters Thanks. Best Regards, Paul > 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 >
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
