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
