Hello Gaurav, I am not sure if I fully understand the motivation of the KIP. You are saying
> However, contributors run the risk of adopting an apKey that is subsequently > claimed by another proposal while they prototype their work. Can you elaborate? Sure, if two KIPs are in-flight in parallel, two KIPs might not know the available API keys yet, but PRs are merged one after each other, and whoever comes last would update the code and KIP accordingly. Most KIPs don't even specify the concrete API key number to begin with, as it's subject to "availability" when the corresponding PR gets merged. This approach did work in the past, so I am not sure if there is an actual problem to be solved, which would require your proposal? Maybe I am missing something. -Matthias -----Original Message----- From: Gaurav Narula <[email protected] <mailto:[email protected]>> Reply-To: <[email protected] <mailto:[email protected]>> Date: Thursday, July 16, 2026 at 8:39 AM To: <[email protected] <mailto:[email protected]>> Subject: [DISCUSS] KIP-1367: Reserve apiKey values for private use Hi Everyone! I’d like to start a discussion on a KIP for reserving apiKey values for private use. More details at: https://cwiki.apache.org/confluence/spaces/KAFKA/pages/440304597/KIP-1367+Reserve+apiKey+values+for+private+use <https://cwiki.apache.org/confluence/spaces/KAFKA/pages/440304597/KIP-1367+Reserve+apiKey+values+for+private+use> Looking forward to your comments! Regards, Gaurav Narula
