On Fri, Jul 10, 2020, at 10:55, Boyang Chen wrote: > Hey Colin, thanks for the KIP. One question I have about AlterScramUsers > RPC is whether we could consolidate the deletion list and alteration list, > since in response we only have a single list of results. The further > benefit is to reduce unintentional duplicate entries for both deletion and > alteration, which makes the broker side handling logic easier. Another > alternative is to add DeleteScramUsers RPC to align what we currently have > with other user provided data such as delegation tokens (create, change, > delete). >
Hi Boyang, It can't really be consolidated without some awkwardness. It's probably better just to create a DeleteScramUsers function and RPC. I've changed the KIP. > > For my own education, the salt will be automatically generated by the admin > client when we send the SCRAM requests correct? > Yes, the client generates the salt before sending the request. best, Colin > Best, > Boyang > > On Fri, Jul 10, 2020 at 8:10 AM Rajini Sivaram <rajinisiva...@gmail.com> > wrote: > > > +1 (binding) > > > > Thanks for the KIP, Colin! > > > > Regards, > > > > Rajini > > > > > > On Thu, Jul 9, 2020 at 8:49 PM Colin McCabe <cmcc...@apache.org> wrote: > > > > > Hi all, > > > > > > I'd like to call a vote for KIP-554: Add a broker-side SCRAM > > configuration > > > API. The KIP is here: https://cwiki.apache.org/confluence/x/ihERCQ > > > > > > The previous discussion thread is here: > > > > > > > > https://lists.apache.org/thread.html/r69bdc65bdf58f5576944a551ff249d759073ecbf5daa441cff680ab0%40%3Cdev.kafka.apache.org%3E > > > > > > best, > > > Colin > > > > > >
