Address review comments from Paul

Signed-off-by: Gantigmaa Selenge <[email protected]>

Author: tinaselenge

1xx-reauth-config-for-scram-listener.md

@@ -1,20 +1,23 @@
-# Support `connections.max.reauth.ms` configuration for SCRAM listeners
+# Add support `connections.max.reauth.ms` configuration for SCRAM listeners
+This proposal adds support for configuring the Kafka `connections.max.reauth.ms` parameter at the listener level for SCRAM authentication in Strimzi.
 
 ## Current situation
 
 Apache Kafka provides the [`connections.max.reauth.ms`](https://kafka.apache.org/documentation/#brokerconfigs_connections.max.reauth.ms) configuration parameter which can be set at broker level for all listeners or a specific listener.
 
-Currently, Strimzi doesn't have support for specifying such a parameter at both broker or listener level because the `listener.` prefix is part of the list of the forbidden configurations for the `spec.kafka.config` section.
+Currently, Strimzi supports setting `connections.max.reauth.ms` broker-wide through `spec.kafka.config`. Per-listener settings cannot be configured this way, because `listener.` properties are forbidden.
 
-However, this configuration is already supported for [OAuth](https://strimzi.io/docs/operators/latest/full/configuring.html#type-KafkaListenerAuthenticationOAuth-reference) at listener level under `authentication` field and can be set for [`custom` type authentication](https://strimzi.io/docs/operators/latest/full/configuring.html#type-KafkaListenerAuthenticationCustom-schema-reference) under `listenerConfig` field. 
+The configuration is already supported at the listener level for [OAuth](https://strimzi.io/docs/operators/latest/full/configuring.html#type-KafkaListenerAuthenticationOAuth-reference) through the  `authentication` field, and for [`custom` type authentication](https://strimzi.io/docs/operators/latest/full/configuring.html#type-KafkaListenerAuthenticationCustom-schema-reference) through the `listenerConfig` field.
+
+Note: OAuth configuration through `type: oauth` is planned to be deprecated. Future configurations would use `type: custom` with the appropriate OAuth settings instead.
 
 ## Motivation
 
-The `connections.max.reauth.ms` is a useful configuration for SCRAM authentications enabled on a specific listener to define the maximum lifetime of a client connection before re-authentication is required. This ensures that clients with long lived connections periodically re-authenticate in case passwords already changed and reduces the risk of having connections with expired or compromised credentials. Since this is already supported/can be set for both OAuth and `custom` type authentications, it makes sense to support it for SCRAM authentications too.
+The `connections.max.reauth.ms` is a useful configuration for SCRAM authentications enabled on a specific listener to define the maximum lifetime of a client connection before re-authentication is required. This ensures that clients with long lived connections periodically re-authenticate in case passwords already changed and reduces the risk of having connections with expired or compromised credentials. Since this configuration is already supported for OAuth and `custom` type authentications, it makes sense to support it for SCRAM authentications too.
 
 ## Proposal
 
-`maxSecondsWithoutReauthentication` field already exists for `KafkaListenerAuthenticationOAuth` class, so for consistency, the same field will be added `KafkaListenerAuthenticationScramSha512` class. User can set the configuration shown in the following example:
+The `maxSecondsWithoutReauthentication` field already exists for `KafkaListenerAuthenticationOAuth` class, so for consistency, the same field will be added to the `KafkaListenerAuthenticationScramSha512` class. Users can set the configuration as shown in the following example:
 
 ```yaml
 apiVersion: kafka.strimzi.io/v1beta2
@@ -41,6 +44,10 @@ spec:
 
 ## Compatibility
 
-As this is a new configuration, there is no backwards compatibility issues relating to this proposal.
+As this is a new configuration, there are no backwards compatibility issues relating to this proposal.
 
 ## Rejected alternatives
+
+- Allow users configure per-listener options in `.spec.kafka.config` instead of adding a new API field. This will help avoid ending up with too many various options like OAuth authentication, which is one of the reason it is getting deprecated. To implement this, one way would be to add this field to the [`FORBIDDEN_PREFIX_EXCEPTIONS`](https://github.com/strimzi/strimzi-kafka-operator/blob/main/api/src/main/java/io/strimzi/api/kafka/model/kafka/KafkaClusterSpec.java#L70) with some form of regular expression, however, this could be quite an expensive check to do for all configurations. Given that there is not many other configurations that can be configured at listener level for SCRAM authentication, I think the risk of ending up with too many API fields like OAuth is small.
+
+- This field can be already configured for `type: custom` authentication so we don't need to add support for it. However, if existing users of SCRAM authentication, want to set this field, they would have to reconfigure their entire authentication section in their Kafka CR to change it from `type: scram` to `type: custom` and then change/set all the neccessary fields for `type: custom`.