Thanks for clarifying, Ismael and Rajini. And I'm sorry for reopenning a point that was clearly discussed already. I wouldn't be doing this if I didn't think my concerns are important and that the administrative aspect may have been ignored (or de-prioritize). In my view, we should prioritize simplicity for users over simplicity for developers, and I'm afraid we are doing the reverse here.
I agree that supporting extensible ports is a more significant change. There are two good reasons (and one weak reason) to put this effort in my opinion: 1) Having two different ways to decide on the protocol (port + negotiation) is needlessly confusing for administrators. Its just one more complexity to figure out when authentication using SASL is already the most complex administrative task one has in Kafka (judging by the number of questions we get). 2) Troubleshooting. Especially in customer-support (and mailing-list support) environment. Asking for two configuration files and two netstat results is a completely different story than using tcp dump (which requires root privileges), catching the correct negotiation packets and decoding them to figure out what went wrong. 3) (weak reason): When we first added the multiple ports, people wanted to make them more extensible for reasons other than security. For example, allowing the use of different networks for clients and inter-broker communication. So it may have other good uses. Can you point to some examples of how other systems (preferably distributed systems) support multiple SASL mechanisms? Gwen On Mon, Feb 1, 2016 at 1:25 AM, Ismael Juma <ism...@juma.me.uk> wrote: > Hi Gwen, > > On Mon, Feb 1, 2016 at 6:06 AM, Gwen Shapira <g...@confluent.io> wrote: > > > Could we support separate SASL mechanisms via separate ports? > > > > This option was also discussed in the KIP and there are some advantages as > you say. However, there are some drawbacks as well. > > This was the main reason we separated the ports in first place, to avoid > > adding protocol negotiation protocol and allow the server to expect the > > correct packets when they arrive to the correct listener. It will be nice > > if new additions could use existing design and code. > > > > Yes, but the current design and code are not actually extensible as we use > an enum for `SecurityProtocol` and the creation of `ChannelBuilder` is > hardcoded based on that enum. Mapping different SASL mechanisms to > different ports is actually a bigger change to how the existing code works > than the option Rajini favoured in his KIP. This is not to say that we > should not do it, just clarifying that it's not necessarily an advantage in > terms of code reuse. > > I would also like to point out that we do protocol negotiation in Kafka in > SSL/TLS today, so it is not totally without precedent. The server and > client negotiate an appropriate SSL/TLS version depending on options set by > both the client and server, not unlike what Rajini has proposed. Of course, > this is a more limited version as the protocols are related and the > negotiation is handled by the SSL/TLS libraries. > > Ismael >
