Hi Jun, Thanks for the detailed review. Pl see the replies inline
> 101.2/101.3. Could we just remove owner and renewer from > DelegationTokenResponse if we don't have a use case? > > Removed owner/renewer fileds from DelegationTokenResponse. Updated the KIP. > 111. ExpireTokenResponse: Should we return the new expiration time in the > response? > > Yes. expiration time is also included in RenewToken response . > 112. DescribeTokenRequest: A common use case is probably to see a list of > tokens associated with a particular owner. Would it be useful to include a > list of owners in the request? We can use the same convention in other > requests such that if the list is set to null (i.e., length is -1), return > all tokens. > > Agree. Updated the KIP. > 113. delegation.token.master.key: It seems that needs to be the same across > brokers? Perhaps we can mention that in the wiki. > Updated the KIP. > > 114. Could we document the procedure of manually rotating the secret? Does > one have to do sth like: expire all existing tokens, rotate the secret, and > generate new tokens? > > Thanks for the suggestion. Updated the suggested steps. During rotation process, already connected clients may continue to work. But any new connection requests and renew/expire requests with old tokens can fail. 115. Could we also include in the command line the ability to describe > tokens? > Updated the KIP. > > 116. Could you document the ACL rules associated with those new requests? > For example, do we allow any one to create, delete, describe delegation > tokens? > > Currently we only allow a owner to create delegation token for that owner only. Any thing the owner has permission to do, delegation tokens should be allowed to do as well. We can also check renew and expire requests are coming from owner or renewers of the token. So we may not need ACLs for create/renew/expire requests. For describe, we can add DESCRIBE operation on TOKEN Resource. In future, when we extend the support to allow a user to acquire delegation tokens for other users, then we can enable CREATE/DELETE operations. Updated the KIP. Thanks, Manikumar > On Wed, Feb 8, 2017 at 1:35 AM, Manikumar <manikumar.re...@gmail.com> > wrote: > > > Hi Jun, > > > > > > > If a token expires, then every broker will potentially try to delete it > > > around the same time, but only one will succeed. So, we will have to > deal > > > with failures in that case? Another way is to let just one broker (say, > > the > > > controller) deletes expired tokens. > > > > > > > > Agree, we can run the token expiry check thread as part of controller > > broker. > > WIll update the KIP. > > > > > > Thanks, > > Manikumar > > > > > > > > > > On Sun, Feb 5, 2017 at 9:54 AM, Manikumar <manikumar.re...@gmail.com> > > > wrote: > > > > > > > Hi Jun, > > > > > > > > Please see the replies inline. > > > > > > > > > > > > > > > > > > > > Only one broker does the deletion. Broker updates the expiration > in > > > its > > > > > > local cache > > > > > > and on zookeeper so other brokers also get notified and their > cache > > > > > > statuses are updated as well. > > > > > > > > > > > > > > > > > Which broker does the deletion? > > > > > > > > > > > > > Any broker can handle the create/expire/renew/describe > delegationtoken > > > > requests. > > > > changes are propagated through zk notifications. Every broker is > > > > responsible for > > > > expiring the tokens. This check be can done during request handling > > time > > > > and/or > > > > during token authentication time. > > > > > > > > > > > > > > > > > > > > > > > 110. The diagrams in the wiki still show MD5 digest. Could you > change > > > it > > > > to > > > > > SCRAM? > > > > > > > > > > > > > > Updated the diagram. > > > > > > > > > > > > > > > > Thanks, > > > > Manikumar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks. > > > > > > Manikumar > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Dec 23, 2016 at 9:26 AM, Manikumar < > > > > manikumar.re...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I would like to initiate the vote on KIP-48: > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+ > > > > > > > > Delegation+token+support+for+Kafka > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Manikumar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
