Hi Mickael, Thanks for the reply.
Thanks for the KIP. Is this meant to superseed KIP-170 ? > If so, one of our key requirements was to be able to access the > topics/partitions list from the policy, so an administrator could > enforce a partition limit for example. > It's not meant to replace KIP-170 because there are things in KIP-170 which aren't purely about policy (the change in requests and responses, for example), which KIP-201 doesn't propose to implement. Obviously there is overlap when it comes to policies, and both KIPs start with different motivations for the policy changes they propose. I think it makes sense for a single KIP address both sets of use cases if possible. I'm happy for that to be KIP-201 if that suits you. I think the approach taken in KIP-170, of a Provider interface for obtaining information that's not intrinsic to the request and a method to inject that provider into the policy, is a good one. It retains a clean distinction between the request metadata itself and the wider cluster metadata, which I think is a good thing. If you're happy Mickael, I'll update KIP-201 with something similar. > Also instead of simply having the Java Principal object, could we have > the KafkaPrincipal ? So policies could take advantage of custom > KafkaPrincipal object (KIP-189). > Certainly.
