Thanks for the review, Becket. (1) After comparing the two approaches, I still feel the current writeup is a little better. a. The current writeup asks for an explicit endpoint while reusing the existing "inter.broker.listener.name" with the exactly same semantic, and your proposed change asks for a new listener name for controller while reusing the existing "advertised.listeners" config with a slight semantic change since a new controller endpoint needs to be added to it. Hence conceptually the current writeup requires one config change instead of two. Also with one listener name, e.g. INTERNAL, for inter broker traffic, instead of two, e.g. "INTERNAL" and "CONTROLLER", if an operator decides to switch from PLAINTEXT to SSL for internal traffic, chances are that she wants to upgrade both controller connections and data connections, she only needs to update one line in the "listener.security.protocol.map" config, and avoids possible mistakes.
b. When this KIP is picked up by an operator who is in a hurry without reading the docs, if she sees a new listener name for controller is required, and chances are there is already a list of listeners, it's possible for her to simply choose an existing listener name, without explicitly creating the new CONTROLLER listener and endpoints. If this is done, Kafka will be run with the existing behavior, defeating the purpose of this KIP. In comparison, if she sees a separate endpoint is being asked, I feel it's unlikely for her to copy and paste an existing endpoint. Please let me know your comments. (2) Good catch, it's a typo, and it's been fixed. Thanks, Lucas
