Hi, Thanks for the KIP. Just a few comments:
MM1: Typically in a KIP we are not really interested in the actual code changes but in the APIs and behavior changes. MM2: If I understand correctly an ACL with a CIDR block should behave exactly the same way as if you create an ACL for each address that matches the CIDR block For example if I create an ACL for "1.2.3.4/30", it's like if I create 4 ACLs for 1.2.3.4, 1.2.3.5, 1.2.3.6 and 1.2.3.7. So using CIDR blocks allows to reduce the potential number of ACLs users have to create and manage. MM3: In the Downgrades safety section you mention some introducing some new validation logic. You define the new metadata version with didMetadataChange set to true, so I believe downgrade is currently not possible> MM4: In the IPv4-mapped IPv6 address section it's stated that IPv4-mapped IPv6 addresses are not going to be supported. Are they just ignored? Could we catch these addresses when they are parsed and reject the request if we detect one? Thanks, Mickael On Thu, Feb 19, 2026 at 5:10 PM Federico Valeri <[email protected]> wrote: > > Hi Maros, thanks for the KIP. > > It would be very convenient to have the possibility to use CIDR > notation when adding ACL rules, but I think we miss quite a few > details. > > FV1: The proposal does not specify what happens when multiple ACLs > with overlapping CIDR ranges apply to the same request. CIDR > introduces a new dimension: subnet specificity. The KIP should clarify > whether longest-prefix match apply, or whether CIDR ranges are treated > like wildcards. Without this, users will create overlapping rules with > unpredictable results. > > For example: > - ALLOW 10.0.0.0/8 on topic foo > - DENY 10.0.1.0/24 on topic foo > > Does a client at 10.0.1.5 get allowed or denied? > > FV2: How does the proposed matching logic handle IPv4-mapped IPv6 > addresses? For example, if a DENY ACL is set for 192.168.0.0/24, does > it match a client whose address is reported as ::ffff:192.168.0.5? > > FV3: Kafka's existing ACL evaluation has precedence rules (DENY wins > over ALLOW, explicit match over wildcard). How does CIDR matching fit > into the existing precedence rules? > > FV4: I agree that we need a new metadata version because the CIDR host > is stored there (AccessControlEntryRecord). What happens if a > controller with CIDR support writes these records, then a downgrade > occurs before all CIDR ACLs are removed? > > FV5: You imply that commons-net library needs to be added to the > existing set of dependencies, but I think it is better to mention > explicitly. Also, is it really worth adding this full networking > protocol library for just one unreleased utility class? Have you > looked at KIP-7 approach? > > FV6: It looks like we miss a test plan and maybe some performance analysis. > > Cheers > Fede > > > On Thu, Jan 29, 2026 at 11:18 AM Maroš Orsák <[email protected]> wrote: > > > > Hi everyone, > > > > > > I would like to start a discussion about CIDR-based host patterns for ACLs. > > Details can be found in the cwiki [1]. > > > > > > [1] - > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1276%3A+CIDR-based+Host+Patterns+for+ACLs > > > > > > Best regards, > > > > > > Maros Orsak
