Hi TaiJuWu, Thanks for the kip. I have a few thoughts below.
mb-0 : I have gone through the rejected alternatives. If only configs which have validator are included, there are several configs which don't have a validator, true. For ex : replica.fetch.min.bytes has no validator (excluded) replica.fetch.max.bytes has a validator (included) replica.lag.time.max.ms has no validator, (excluded but HIGH importance) There are many examples like these. thinking what exactly controller needs to check or what could be the deciding factor for the config to be part of BrokerRegistrationRecord? mb-1 : If an author today adds a validator to an existing config, it silently ends up in controller. How about an opt-in flag (sendToController)? Many configs like ssl.* and sasl.* have no validator and they are excluded which is good. But if a future pr changes them like adding NonEmptyString, will end up in controller. mb-2 : Config like SSL_CLIENT_AUTH_CONFIG = "ssl.client.auth" have a validator. It is a BrokerSecurityConfig. I am not sure if it's considered into the push record? But kip mentions ... "this naturally excludes most security/SSL/SASL configs.". Thought of clarifying. Thanks, Murali On Thu, Apr 30, 2026 at 4:48 PM TaiJu Wu <[email protected]> wrote: > Hi all, > > I would like to discuss KIP-1326 > < > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1326%3A+Include+broker+static+configurations+in+BrokerRegistrationRequest > > > which > proposes that brokers report a subset of their static configuration values > to the controller as part of BrokerRegistrationRequest. > > WIKI: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1326%3A+Include+broker+static+configurations+in+BrokerRegistrationRequest > > Best, > TaiJuWu >
