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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
