Hi Kuan-Po Tseng, This is probably going to be a tricky KIP. Trying to resolve historical behaviour is always painful.
I think the key here is to realise that this KIP is for listing the resources which have configuration, and that's not the same as listing the resources. The user is going to need DESCRIBE_CONFIGS on the specific topics and groups in order to discover the configuration values themselves, so if this RPC requires the same permission in order to list the resources for which they can describe the configs, that seems OK to me. In KIP-1000, we require DESCRIBE_CONFIGS on the CLUSTER to find a list of the client-metrics configs. In KIP-1142, there was no change and it's necessary to have DESCRIBE_CONFIGS on the CLUSTER to list the resources of all supported types. If you look at the ListGroups RPC, the user can list all groups if they have DESCRIBE on the CLUSTER. If they do not, they can only see the groups for which they have DESCRIBE on the GROUP. For this KIP, why couldn't we do a similar thing? If the user has DESCRIBE_CONFIGS on the CLUSTER, they can see all of the resources which have configs. If they do not, they can only see the resources for which they have specific DESCRIBE_CONFIGS. Thanks, Andrew On 2026/04/06 15:28:17 Chia-Ping Tsai wrote: > hi Viquar > > Thanks for updating the KIP numbers. This helps keep things organized. > > Best, > Chia-Ping > > On 2026/04/06 05:53:06 vaquar khan wrote: > > Hi Chia-Ping , > > > > As discussed I have updated my KIP with 1316 and 1317. > > > > Regards, > > Viquar Khan > > > > On Mon, 6 Apr 2026 at 00:32, Chia-Ping Tsai <[email protected]> wrote: > > > > > hi Viquar > > > > > > > It is each owner’s responsibility to ensure their KIP number does not > > > override an existing one. > > > > > > Just a gentle reminder that the process mentions we should "Update the > > > next > > > available KIP number below". You can find the details here: > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=50859233#KafkaImprovementProposals-Process > > > > > > It is totally fine to have an occasional conflict with one KIP. However, > > > it > > > seems several KIPs were created without incrementing the number, which has > > > unfortunately caused conflicts for several other contributors. > > > > > > Would you mind updating your KIP numbers instead? If you have any > > > questions > > > or concerns, please let me know. > > > > > > Best, > > > Chia-Ping > > > > > > vaquar khan <[email protected]> 於 2026年4月6日週一 下午12:49寫道： > > > > > > > Hi Kaun, > > > > > > > > Please search(search box) the current KIP list to verify that your > > > > assigned number does not already exist. If you find a conflict, check > > > > the > > > > creation dates; if your KIP was created later, please update it to a > > > > unique, available number. > > > > > > > > It is each owner’s responsibility to ensure their KIP number does not > > > > override an existing one. > > > > > > > > > > > > Regards, > > > > > > > > Viquar Khan > > > > > > > > > > > > On Sun, Apr 5, 2026, 11:24 PM Chia-Ping Tsai <[email protected]> wrote: > > > > > > > > > hi all, > > > > > > > > > > Just a gentle reminder: please remember to increment the "Next KIP > > > > Number" > > > > > after taking a number. This will help avoid potential conflicts. > > > > > > > > > > Best, > > > > > Chia-Ping > > > > > > > > > > Kuan-Po Tseng <[email protected]> 於 2026年4月6日週一 下午12:18寫道： > > > > > > > > > > > Hi Vaquar — I checked the Kafka Improvement Proposals > > > > > > < > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals > > > > > > > > > > > > > page and don't see another KIP using 1298. > > > > > > Could you pick the next available KIP number and update accordingly? > > > > > > > > > > > > On Mon, Apr 6, 2026 at 12:10 PM vaquar khan <[email protected]> > > > > > wrote: > > > > > > > > > > > > > Could you please correct Kip 1298 , we already have same no , I > > > > created > > > > > > few > > > > > > > weeks back. > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > Viquar Kha > > > > > > > > > > > > > > On Sun, Apr 5, 2026, 10:34 PM Kuan Po Tseng <[email protected]> > > > > > > wrote: > > > > > > > > > > > > > > > Thanks again for the input! > > > > > > > > > > > > > > > > chia_01: Sure, we can add a debug message on the server side > > > > > > > > when > > > > > > > response > > > > > > > > is empty and using v2 with only DESCRIBE_CONFIGS on CLUSTER and > > > > > > DESCRIBE > > > > > > > on > > > > > > > > CLUSTER not set. Additionally, I think it would be helpful to > > > add a > > > > > > > warning > > > > > > > > message in ConfigCommand when the LIST_CONFIG_RESOURCE API > > > response > > > > > is > > > > > > > > empty, to let users know they may need to update their ACL. > > > > > > > > > > > > > > > > On 2026/04/05 08:55:06 Chia-Ping Tsai wrote: > > > > > > > > > chia_01: Regarding the migration plan, I have a concern about > > > > > > potential > > > > > > > > user confusion. Since clients using v2 with only > > > > > > > > DESCRIBE_CONFIGS > > > > > will > > > > > > > > receive an empty response rather than an authorization error, > > > this > > > > > > silent > > > > > > > > failure might be very hard to debug. Should we consider logging > > > > > > > > a > > > > > > warning > > > > > > > > message in this specific scenario to help users identify the > > > > missing > > > > > > > > DESCRIBE ACL? > > > > > > > > > > > > > > > > > > On 2026/04/05 03:48:16 Kuan-Po Tseng wrote: > > > > > > > > > > Thanks for the feedback, Chia-Ping! > > > > > > > > > > > > > > > > > > > > chia_00: That's a fair point. I'm a bit hesitant to handle > > > > > > > > DESCRIBE_CONFIGS > > > > > > > > > > in handleTopicMetadataRequest and handleListGroupsRequest, > > > > > > > > > > since those APIs return more than just names. Exposing > > > > > topic/group > > > > > > > > names > > > > > > > > > > based on a config-oriented permission feels semantically > > > > > > misaligned, > > > > > > > > > > and I'm not sure it adds much value. > > > > > > > > > > Another approach worth considering: we could bump the API > > > > version > > > > > > of > > > > > > > > > > LIST_CONFIG_RESOURCES and switch to DESCRIBE instead of > > > > > > > > > > DESCRIBE_CONFIGS, aligning it with other resource-related > > > APIs. > > > > > > > > > > > > > > > > > > > > I’ll update the KIP later, and would love to hear others' > > > > > thoughts > > > > > > on > > > > > > > > this! > > > > > > > > > > > > > > > > > > > > On Sun, Apr 5, 2026 at 12:52 AM Chia-Ping Tsai < > > > > > > [email protected]> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > chia_00: For the sake of consistency, if we permit > > > > > > DESCRIBE_CONFIGS > > > > > > > > to > > > > > > > > > > > expose topic and group names in LIST_CONFIG_RESOURCES, > > > should > > > > > we > > > > > > > > also align > > > > > > > > > > > handleTopicMetadataRequest and handleListGroupsRequest? > > > > > > Currently, > > > > > > > > they > > > > > > > > > > > strictly require DESCRIBE. > > > > > > > > > > > > > > > > > > > > > > On 2026/04/04 16:40:08 Kuan-Po Tseng wrote: > > > > > > > > > > > > Hello everyone, > > > > > > > > > > > > > > > > > > > > > > > > I would like to start a discussion thread on KIP-1298 > > > which > > > > > > fixes > > > > > > > > an > > > > > > > > > > > > authorization inconsistency in LIST_CONFIG_RESOURCES. > > > Today > > > > > the > > > > > > > RPC > > > > > > > > > > > > requires DESCRIBE_CONFIGS on CLUSTER for all resource > > > > types, > > > > > > > which > > > > > > > > is > > > > > > > > > > > > stricter than comparable RPCs like LIST_GROUPS and > > > > METADATA. > > > > > > The > > > > > > > > > > > practical > > > > > > > > > > > > impact is that `kafka-configs.sh --describe > > > > > > > > > > > > --entity-type > > > > > > groups` > > > > > > > > > > > silently > > > > > > > > > > > > returns incomplete results for users holding DESCRIBE > > > > > > > > > > > > but > > > > not > > > > > > > > > > > > DESCRIBE_CONFIGS on CLUSTER. > > > > > > > > > > > > > > > > > > > > > > > > More details, please check > > > > > > > > > > > > https://cwiki.apache.org/confluence/x/ZJI8G > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Kuan-Po Tseng > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
