Hi, Mani Thanks for the proposal. Looks good at the high level. A few comments below.
101. DelegationTokenRequest/DelegationTokenResponse 101.1 I am wondering if renewer should be principalType + name to match what we have in kafka-acls tool? 101.2 Do we need to return owner in DelegationTokenResponse? 101.3 Do we need to return renewer in DelegationTokenResponse? 102. RenewDelegationTokenRequest/RenewDelegationTokenResponse 102.1 In RenewDelegationTokenRequest, is the renewal time bounded by delegation.token.expiry.time.sec ? 102.2 Do we need to include TokenDetails in RenewDelegationTokenResponse? 103. Do we need a DescribeDelegationTokenRequest and a corresponding tool to list/describe existing delegation tokens? 104. KafkaConfig: Do we need a new config to disable/enable delegation tokens? 105. Could we be more consistent with the naming in configs, the request protocol fields and ZK structure with respect to time (e.g. delegation.token.max.lifetime.sec => delegation.token.max.lifetime.ms )? 106. Using SASL SCRAM for delegation token 106.1 What should be set for username? Does it matter? 106.2 Could you provide a bit more details on how to distinguish it from regular SASL SCRAM? 107. ZK structure 107.1 Could you provide more details on what SCRAM credentials are stored in ZK path /tokenauth/tokens/<tokenUID>? 107.2 Do we need to somehow normalize tokeUID before using it in /tokenauth/tokens/<tokenUID> (e.g., what happens if tokenUUID includes '/')? 107.3 How does each broker know about changes in tokens? Does each broker register a watcher for /tokenauth/tokens? 107.4 How is token deletion handled? Does every broker delete the same token independently or only one broker does the deletion? Thanks, Jun 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 >
