Éric Vyncke has entered the following ballot position for draft-ietf-netmod-acl-extensions-15: 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/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-netmod-acl-extensions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-netmod-acl-extensions-15 CC @evyncke Thank you for the work put into this document. It is easy to read and add real value to ACL. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Lou Berger for the shepherd's write-up including the WG 'limited' interest/consensus and the justification of the intended status. Other thanks to Tim Wicinski, the Internet directorate reviewer, please consider this int-dir last-call review: https://datatracker.ietf.org/doc/review-ietf-netmod-acl-extensions-11-intdir-lc-wicinski-2024-11-17/ (status "ready") I hope that this review helps to improve the document, Regards, -éric ## COMMENTS (non-blocking) ### Abstract s/This document discusses a set of extensions/This document specifies a set of extensions/ after all, its intended status is proposed standard. ### Section 1 Humm... I understand what is meant but this paragraph appears to be self-contradicting `Network operators maintain sets of IP prefixes ... These lists are maintained and manipulated by security expert teams` (suggest adding "of the network operators"). It took me a while to parse `supporting means to easily map to the filtering rules conveyed in messages triggered by these tools is valuable from a network operation standpoint` mainly because the subject of "is valuable" is too long. ### Section 2 In `IP address, IP prefixes,` any reason why the plural form is used for "IP prefixes" ? ### Section 3.2 Where are the names defined in ` A protocol can be identified either by a number (e.g., 17) or a name (e.g., UDP).` Should the example for aliases be dual-stack ? I.e., having both an IPV6 address and an IPv4 one ? Same comment for section D.1 I was about the ballot a DISCUSS on `beyond just the header information` which header is it ? Layer-2 ? IP ? Based on `identity offset-type` appearing later, I am balloting NoObjection but the clarification should already be in this section. ### Section 3.6 Related to my near-DISCUSS on section 3.2, `data offset` from which start ? ### Section 4 Generic comment: why next-header-set for IPv4 and not protocol-set as in IPv6 as they refer to the same identities ? Or even having protocol subtree to be version agnostic (like TCP), i.e., some operators would probably like to allow protocol == 50 (ESP) on both IPv6 and IPv4. Like Erik Kline, I think that `identity layer4` for offset is not correct and Erik's suggestion is correct. `The offset start right after the end of the transport payload.`, I think that the authors mean "transport header". Rather than defining identities for all TCP flags (e.g., `identity ack`), why not using the same technique as for ICMP type, i.e., rely on the https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-header-flags IANA registry? ### Section 6.3 Several IANA instructions are similar to `"enum": Replicates the name from the registry with all spaces striped.`, I am unsure whether the result will be readable and useful, it there a reason why the spaces must be removed ? The "(deprecated)" and "(obsolete)" status appears only in the ICMPv4 registry, unsure whether they are applicable to ICMPv6 and extension headers registries. I will trust IANA review on this section. ### Section 7.2 As some IANA registries are used as input by the XSLT in appendix A, I wonder whether they should be normative references. ### Section E.3 Should there also be a match on the 'protocol' ? I.e., do not match for TCP packets having "2001:db8::1" Moreover, I guess that the payload match is a binary comparison so it will never match the ASCII "2001:db8::1", suggest using an hexadecimal string in this example. ## NITS (non-blocking / cosmetic) s/transpot/transport/ (saw it at least once) _______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
