Hi, Andrew, Thanks for the reply.
JR39. There is still some inconsistency. For clientInstanceID, we reject any subsequent requests which specify a different value for the client instance ID. But for clientID, we reject subsequent requests if the client ID is specified (request header v3 or later). Jun On Thu, Aug 6, 2026 at 12:47 AM Andrew Schofield <[email protected]> wrote: > Hi Jun, > Thanks for your reply. > > JR39: KIP description tightened up. That should do the trick. > > Thanks, > Andrew > > On 2026/08/05 17:28:34 Jun Rao via dev wrote: > > Hi, Andrew, > > > > Thanks for the reply. > > > > JR39. For clientInstanceID, we have: "If a client specifies a reserved > > client instance ID (zero or one), the request will be rejected with error > > code INVALID_REQUEST ." > > For clientId, we have: "After this KIP, the broker will assume that the > > client ID from the initial request applies to all subsequent requests > > on a connection, > > and it will ignore the client ID specified on any subsequent requests." > > Could we make the behavior consistent between these two? > > > > Jun > > > > > > On Tue, Aug 4, 2026 at 1:05 PM Andrew Schofield <[email protected]> > > wrote: > > > > > Hi Jun, > > > Thanks for the reply. > > > > > > JR37: It had escaped me that ClientInstanceId is a tagged field, so > you're > > > absolutely right. (I am not an AI.) I'll update the KIP. > > > > > > Thanks, > > > Andrew > > > > > > On 2026/08/04 18:24:19 Jun Rao via dev wrote: > > > > Hi, Andrew, > > > > > > > > Thanks for the reply. > > > > > > > > JR37. UUID is 16 bytes. If it's omitted in subsequent requests, we > save > > > 16 > > > > bytes, right? > > > > > > > > Jun > > > > > > > > > > > > > > > > On Tue, Aug 4, 2026 at 5:47 AM Andrew Schofield < > [email protected]> > > > > wrote: > > > > > > > > > Hi Jun, > > > > > Thanks for your reply. > > > > > > > > > > JR37: Unlike with clientId where space is saved by not > transmitting it > > > on > > > > > every request, there's nothing to be gained by omitting > > > clientInstanceId on > > > > > later requests. I prefer to leave it as is. > > > > > > > > > > JR38: OK, I've updated those paragraphs in the KIP to exclude the > > > reserved > > > > > UUIDs. > > > > > > > > > > Thanks, > > > > > Andrew > > > > > > > > > > On 2026/08/03 20:23:39 Jun Rao via dev wrote: > > > > > > Hi, Andrew, > > > > > > > > > > > > Thanks for the reply. > > > > > > > > > > > > JR37. Will it be better to require ClientInstanceId only on the > first > > > > > > request, to be consistent with clientId? > > > > > > > > > > > > JR38. "must specify a non-zero client instance ID". one_uuid is > also > > > a > > > > > > reserved one in the Uuid class. Should we exclude that one too? > > > > > > > > > > > > Jun > > > > > > > > > > > > On Fri, Jul 31, 2026 at 9:10 AM Andrew Schofield < > > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > Hi Jun, > > > > > > > Thanks for the reply and sorry for the delay. Lots of 4.4 stuff > > > got in > > > > > the > > > > > > > way. > > > > > > > > > > > > > > JR34: EligibleLeaderReplicasVersion and KRaftVersion also use > > > > > ApiVersion > > > > > > > to negotiate the RPC versions. I do not believe we need to > bump up > > > > > other > > > > > > > feature versions as a result of the RPC version bumps in this > KIP. > > > > > > > > > > > > > > JR35: Yes, good catch. In order to handle client ID-based > quotas > > > for > > > > > > > forwarded requests, it will be necessary to populate the > client ID > > > in > > > > > the > > > > > > > forwarded request header. KIP updated. > > > > > > > > > > > > > > JR36: I hadn't considered MV to be a feature version, but I > > > understand. > > > > > > > KIP updated. > > > > > > > > > > > > > > Thanks, > > > > > > > Andrew > > > > > > > > > > > > > > On 2026/06/29 16:23:09 Jun Rao via dev wrote: > > > > > > > > Hi, Andrew, > > > > > > > > > > > > > > > > Thanks for the reply. > > > > > > > > > > > > > > > > JR34. Transaction coordinator uses ApiVersion to negotiate > the > > > PRC > > > > > > > > versions. Therefore, if there is no functional change, there > is > > > no > > > > > need > > > > > > > to > > > > > > > > bump the TV version. I am not sure about > > > > > EligibleLeaderReplicasVersion > > > > > > > > and KRaftVersion. > > > > > > > > It would be useful to have the experts chime in. > > > > > > > > > > > > > > > > JR35. Envelope/forwarding interaction: When a broker > forwards a > > > > > client > > > > > > > > request to the controller via EnvelopeUtils > > > > > > > (parseForwardedRequestHeader), > > > > > > > > the inner header may have its clientId optimized to null. > Some > > > quota > > > > > > > > enforcement (e.g. controller mutation) may depend on the > non-null > > > > > > > clientId. > > > > > > > > The per-connection caching occurs on the original > client↔broker > > > > > > > connection, not > > > > > > > > the broker↔controller one. Should the forwarded request > preserve > > > the > > > > > > > > non-null resolved (cached) client.id? > > > > > > > > > > > > > > > > JR36. "This KIP does not need to introduce any feature > version > > > > > bumps." > > > > > > > This > > > > > > > > is not very accurate since MV is a feature version and is > bumped. > > > > > > > > > > > > > > > > Jun > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 26, 2026 at 12:42 AM Andrew Schofield < > > > > > [email protected] > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Hi Jun, > > > > > > > > > I've updated the KIP. > > > > > > > > > > > > > > > > > > JS34: I don't believe that we need to introduce any new > feature > > > > > > > versions > > > > > > > > > for this KIP. For example, we do not need a new > ShareVersion > > > since > > > > > that > > > > > > > > > enabled share groups (SV_1) and controls the versioning of > the > > > > > records > > > > > > > on > > > > > > > > > the internal topics (SV_2). I think the same applies for > the > > > > > others. I > > > > > > > > > understand GroupVersion and StreamsVersion, and I think > they > > > > > follow the > > > > > > > > > same reasoning as ShareVersion. I don't know > > > TransactionVersion or > > > > > > > > > EligibleLeaderReplicasVersion, so let me know whether > those are > > > > > > > different > > > > > > > > > in this regard. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > On 2026/06/25 21:32:27 Andrew Schofield wrote: > > > > > > > > > > Hi Jun, > > > > > > > > > > Thanks for the reply. > > > > > > > > > > > > > > > > > > > > JR27: Yes, makes sense. So request header v3 is > > > binary-compatible > > > > > > > with > > > > > > > > > request header v2. > > > > > > > > > > > > > > > > > > > > JS34: Yes, I think so. > > > > > > > > > > > > > > > > > > > > I'll update the KIP tomorrow morning. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > On 2026/06/25 20:23:57 Jun Rao via dev wrote: > > > > > > > > > > > Hi, Andrew, > > > > > > > > > > > > > > > > > > > > > > Thanks for the reply. > > > > > > > > > > > > > > > > > > > > > > JR27. I was thinking of the following, which is > slightly > > > > > different > > > > > > > from > > > > > > > > > > > what you described. > > > > > > > > > > > * Bump RequestHeader to v3, and introduce > ClientInstanceId > > > as a > > > > > > > tagged > > > > > > > > > > > field for versions 3+ and change the semantic of the > > > existing > > > > > field > > > > > > > > > > > clientId (only need to be populated by the first > request). > > > > > > > > > > > * Bump the request versions for all RPCs including > > > ApiVersion > > > > > and > > > > > > > map > > > > > > > > > to > > > > > > > > > > > the new version to use v3 of RequestHeader. > > > > > > > > > > > * On the server side, when a new request version is > seen, > > > we > > > > > > > enforce > > > > > > > > > the > > > > > > > > > > > presence of ClientInstanceId and reject the request if > it > > > is > > > > > > > missing. > > > > > > > > > > > Essentially, treat it as a required field. We also > cache > > > the > > > > > > > clientId > > > > > > > > > from > > > > > > > > > > > the first request and ignore it from subsequent ones. > > > > > > > > > > > * We would introduce OffsetDelete v1 as the first > flexible > > > > > version > > > > > > > so > > > > > > > > > that > > > > > > > > > > > it uses the v3 request header. > > > > > > > > > > > * We would update PushTelemetry and > > > GetTelemetrySubscriptions > > > > > as > > > > > > > > > described > > > > > > > > > > > in the KIP and the ClientInstanceId would move to the > > > request > > > > > > > header. > > > > > > > > > > > > > > > > > > > > > > In the future, if we want to add a new truly optional > > > field to > > > > > > > > > > > RequestHeader, we can continue adding it as a tagged > field > > > > > without > > > > > > > > > bumping > > > > > > > > > > > up the request version. To add a required field, we > will > > > add > > > > > it as > > > > > > > a > > > > > > > > > tagged > > > > > > > > > > > field but force a version bump to all requests. > > > > > > > > > > > > > > > > > > > > > > The benefit of this approach is that (1) it's > compatible > > > with > > > > > the > > > > > > > > > format of > > > > > > > > > > > the old request header; (2) it avoids duplicating new > > > fields; > > > > > and > > > > > > > (3) > > > > > > > > > there > > > > > > > > > > > is no constraint on deprecating the old request header. > > > It's > > > > > > > slightly > > > > > > > > > weird > > > > > > > > > > > to bump up the version when adding a tagged field. But > it > > > still > > > > > > > seems > > > > > > > > > > > better than the alternatives. > > > > > > > > > > > > > > > > > > > > > > JR34. Since we now have different feature versions > gating > > > > > different > > > > > > > > > RPCs, > > > > > > > > > > > should we bump up GV, TV, etc., too? > > > > > > > > > > > > > > > > > > > > > > Jun > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 25, 2026 at 10:37 AM Andrew Schofield < > > > > > > > > > [email protected]> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Hi Jun, > > > > > > > > > > > > Thanks for the reply. > > > > > > > > > > > > > > > > > > > > > > > > JR27.1: What if we want to add non-optional fields > to the > > > > > request > > > > > > > > > header > > > > > > > > > > > > in the future? I think that such fields would be by > > > > > definition > > > > > > > future > > > > > > > > > > > > fields which would not be understood by existing > > > brokers. For > > > > > > > > > serialization > > > > > > > > > > > > reasons, I think we would use version 2+ tagged > fields > > > and > > > > > the > > > > > > > > > requirement > > > > > > > > > > > > for non-optionality would be enforced by code, rather > > > than > > > > > by the > > > > > > > > > protocol > > > > > > > > > > > > schema. This avoids the field duplication. > > > > > > > > > > > > > > > > > > > > > > > > JR27.2: Yes, I don't like it, but when we inevitably > do > > > > > another > > > > > > > > > KIP-896 to > > > > > > > > > > > > remove support for ancient parts of the protocol, > it's > > > going > > > > > to > > > > > > > be > > > > > > > > > another > > > > > > > > > > > > KIP. That's all I meant. > > > > > > > > > > > > > > > > > > > > > > > > If I understand your proposal correctly compared > with the > > > > > > > existing > > > > > > > > > KIP > > > > > > > > > > > > text, it would look like this: > > > > > > > > > > > > * Remove RequestHeader v3, and introduce > > > ClientInstanceId as > > > > > a > > > > > > > tagged > > > > > > > > > > > > field for versions 2+. > > > > > > > > > > > > * Bump the request versions for all RPCs. We'd > update the > > > > > request > > > > > > > > > JSON > > > > > > > > > > > > schemas with something like > "ClientInstanceIdVersions": > > > "X+". > > > > > > > This > > > > > > > > > would > > > > > > > > > > > > mean that the request would only be properly formed > if it > > > > > had the > > > > > > > > > > > > ClientInstanceId present, and would also mean that > > > ClientId > > > > > > > could be > > > > > > > > > null > > > > > > > > > > > > for non-initial requests on each connection. > > > > > > > > > > > > * We would create ApiVersions v6, simply as a matter > of > > > the > > > > > > > bumping > > > > > > > > > of > > > > > > > > > > > > request versions for all RPCs, but its schema would > be > > > > > unchanged > > > > > > > > > from v5. > > > > > > > > > > > > * We would introduce OffsetDelete v1 as the first > > > flexible > > > > > > > version > > > > > > > > > so that > > > > > > > > > > > > it uses the v2 request header. > > > > > > > > > > > > * We would update PushTelemetry and > > > > > GetTelemetrySubscriptions as > > > > > > > > > described > > > > > > > > > > > > in the KIP and the ClientInstanceId would move to the > > > request > > > > > > > header. > > > > > > > > > > > > > > > > > > > > > > > > I think that works roughly the same as what we have > > > today. I > > > > > > > don't > > > > > > > > > really > > > > > > > > > > > > like the mandatory nature of the tagged field, but > then I > > > > > don't > > > > > > > > > really like > > > > > > > > > > > > the way that ApiVersions is pegged on a historical > > > request > > > > > header > > > > > > > > > version. > > > > > > > > > > > > > > > > > > > > > > > > Do I have this correct? If so, I can update the KIP > > > > > accordingly. > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > On 2026/06/24 23:40:06 Jun Rao via dev wrote: > > > > > > > > > > > > > Hi, Andrew, > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the reply. > > > > > > > > > > > > > > > > > > > > > > > > > > JR27.1 What if we want to add non-optional fields > to > > > the > > > > > > > request > > > > > > > > > header > > > > > > > > > > > > in > > > > > > > > > > > > > the future? The choice I see is duplicating the > field > > > in > > > > > the > > > > > > > new > > > > > > > > > request > > > > > > > > > > > > > header and the new ApiVersion request. But it's not > > > very > > > > > clean. > > > > > > > > > > > > > JR27.2 Requiring a major version API compatibility > KIP > > > is > > > > > also > > > > > > > a > > > > > > > > > bit > > > > > > > > > > > > > awkward. > > > > > > > > > > > > > > > > > > > > > > > > > > Here is yet another proposal. We add the > > > ClientInstanceId > > > > > to > > > > > > > the > > > > > > > > > request > > > > > > > > > > > > > header as a tagged field and also bump up all > request > > > > > versions. > > > > > > > > > This > > > > > > > > > > > > avoids > > > > > > > > > > > > > the header compatibility issue in SocketServer. The > > > > > bumped-up > > > > > > > > > version > > > > > > > > > > > > > signals that the new field is actually required. > On the > > > > > server > > > > > > > > > side, when > > > > > > > > > > > > > receiving the new version of a request, we verify > that > > > the > > > > > > > > > > > > ClientInstanceId > > > > > > > > > > > > > field exists. If it's not present, we reject the > > > request. > > > > > This > > > > > > > > > will be > > > > > > > > > > > > the > > > > > > > > > > > > > convention for adding future required fields to the > > > header. > > > > > > > > > Compared to > > > > > > > > > > > > the > > > > > > > > > > > > > current proposal, this avoids duplicating the field > > > between > > > > > > > request > > > > > > > > > > > > header > > > > > > > > > > > > > and ApiVersionRequest, and it provides a path for > > > > > deprecating > > > > > > > the > > > > > > > > > older > > > > > > > > > > > > > version of the request header. What do you think? > > > > > > > > > > > > > > > > > > > > > > > > > > Jun > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 24, 2026 at 2:15 AM Andrew Schofield < > > > > > > > > > [email protected]> > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Jun, > > > > > > > > > > > > > > Thanks for the reply. > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR27: Yes, I enhanced that section of the KIP. > > > > > > > > > > > > > > JR27.1: This KIP was unusual because we wanted to > > > add a > > > > > > > concept > > > > > > > > > which > > > > > > > > > > > > > > existed in the KIP-714 RPCs to the request > header, > > > > > > > complicating > > > > > > > > > the > > > > > > > > > > > > > > behavior of those RPCs, AND we wanted to change > the > > > > > handling > > > > > > > of > > > > > > > > > client > > > > > > > > > > > > ID > > > > > > > > > > > > > > without breaking older brokers. If we simply > wanted > > > to > > > > > add a > > > > > > > > > brand new > > > > > > > > > > > > > > field to the request header, we can do it as a > tagged > > > > > field > > > > > > > in > > > > > > > > > request > > > > > > > > > > > > > > header versions 2+. > > > > > > > > > > > > > > JR27.2: Covered this too. We'd need a major > version > > > API > > > > > > > > > compatibility > > > > > > > > > > > > KIP. > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR31: Yes. KIP updated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR32: Yes. This is a minor inconvenience I feel. > KIP > > > > > updated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR33: I don't see the value of a string > comparison > > > here. > > > > > > > > > Personally, > > > > > > > > > > > > I'm > > > > > > > > > > > > > > happy with "assume". > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2026/06/23 22:52:15 Jun Rao via dev wrote: > > > > > > > > > > > > > > > Hi, Andrew, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the reply. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR27. The code that changed the request header > > > parsing > > > > > was > > > > > > > > > > > > introduced in > > > > > > > > > > > > > > > 2019 ( > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://github.com/apache/kafka/pull/7372__;!!Ayb5sqE7!scbWbTEEm2o-Y3MBGi829H2cpMWPRyrF9g2CW3lmRHyRmgBU2MyoRif2mFJpnfmvQ2x7fF4LrAJXdwH86ERR$ > > > > > > > > > > > > > > ). I agree that fixing it > > > > > > > > > > > > > > > now is too late. We should document the path > > > forward > > > > > for > > > > > > > > > ApiVersion. > > > > > > > > > > > > > > Could > > > > > > > > > > > > > > > we answer at least the following questions in > the > > > > > > > > > Compatibility, > > > > > > > > > > > > > > > Deprecation, and Migration Plan section? > > > > > > > > > > > > > > > JR27.1 What happens to ApiVersion if we change > the > > > > > request > > > > > > > > > header in > > > > > > > > > > > > the > > > > > > > > > > > > > > > future? > > > > > > > > > > > > > > > JR27.2 What happens if we ever want to > deprecate > > > v2 of > > > > > the > > > > > > > > > request > > > > > > > > > > > > > > header? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR28. The new MV needs to be covered in the > > > > > Compatibility, > > > > > > > > > > > > Deprecation, > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > Migration Plan section. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR31. "If a connection uses the v3 request > header > > > in > > > > > its > > > > > > > first > > > > > > > > > > > > request, > > > > > > > > > > > > > > it > > > > > > > > > > > > > > > must specify a non-zero client instance ID and > it > > > must > > > > > > > specify > > > > > > > > > the > > > > > > > > > > > > same > > > > > > > > > > > > > > > client instance ID for all subsequent > requests." > > > > > > > > > > > > > > > Do we do the same if the first request is v6 of > > > > > ApiVersion? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR32. "For subsequent requests using an earlier > > > > > version of > > > > > > > the > > > > > > > > > > > > request > > > > > > > > > > > > > > > header, the client sends the client ID". This > means > > > > > that > > > > > > > > > subsequent > > > > > > > > > > > > > > > ApiVersion V6 requests will carry the non-null > > > clientID > > > > > > > > > > > > unnecessarily. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR33. "After this KIP, the broker will assume > that > > > the > > > > > > > client > > > > > > > > > ID > > > > > > > > > > > > from the > > > > > > > > > > > > > > > initial request applies to all subsequent > requests > > > on a > > > > > > > > > connection, > > > > > > > > > > > > and > > > > > > > > > > > > > > it > > > > > > > > > > > > > > > will ignore the client ID specified on any > > > subsequent > > > > > > > > > requests." > > > > > > > > > > > > > > > Should the broker verify that the clientId from > > > > > subsequent > > > > > > > > > request > > > > > > > > > > > > match > > > > > > > > > > > > > > > the first cached one, if not null? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jun > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 23, 2026 at 6:05 AM Andrew > Schofield < > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Jun, > > > > > > > > > > > > > > > > Thanks for your reply. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR27: Unfortunately, I don't think this is > > > > > acceptable. We > > > > > > > > > would be > > > > > > > > > > > > > > saying > > > > > > > > > > > > > > > > that AK 4.5 clients can only connect to AK > 4.5 or > > > > > later > > > > > > > > > brokers, > > > > > > > > > > > > and > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > we'd create patch release for AK 4.0.x to AK > > > 4.4.x. > > > > > so > > > > > > > AK 4.5 > > > > > > > > > > > > clients > > > > > > > > > > > > > > could > > > > > > > > > > > > > > > > connect to those too. We'd be preventing > > > connection > > > > > to > > > > > > > AK 3.x > > > > > > > > > > > > brokers > > > > > > > > > > > > > > by AK > > > > > > > > > > > > > > > > 4.5 clients. I don't see how we can break > > > > > compatibility > > > > > > > in a > > > > > > > > > minor > > > > > > > > > > > > > > release. > > > > > > > > > > > > > > > > Here's the existing compatibility table: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://kafka.apache.org/41/getting-started/compatibility/__;!!Ayb5sqE7!ppWU_jI9f7EY9DYwcbiOESSBG2TmPn9CHfLnVM5TaIMwWqHUbUbIiGre1GGKMr-HmelQlyP6ibUSyORCAgte$ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR29: OK, makes sense to me. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2026/06/22 21:50:43 Jun Rao via dev wrote: > > > > > > > > > > > > > > > > > Hi, Andrew, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the reply. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR27. I am not sure I like the approach of > > > pinning > > > > > the > > > > > > > > > header to > > > > > > > > > > > > v2 > > > > > > > > > > > > > > for > > > > > > > > > > > > > > > > > ApiVersionsRequest. This means that in the > > > future, > > > > > each > > > > > > > > > change > > > > > > > > > > > > to the > > > > > > > > > > > > > > > > > request header must be duplicated in the > > > request > > > > > > > itself. > > > > > > > > > Here is > > > > > > > > > > > > an > > > > > > > > > > > > > > > > > alternative. Note that to detect an > unsupported > > > > > > > > > > > > ApiVersionRequest, we > > > > > > > > > > > > > > > > don't > > > > > > > > > > > > > > > > > need to parse the full v2 request header. > > > Parsing > > > > > the > > > > > > > > > first two > > > > > > > > > > > > > > fields > > > > > > > > > > > > > > > > > ApiKey and ApiVersion is enough. So, we > could > > > > > patch all > > > > > > > > > the 4.x > > > > > > > > > > > > > > releases > > > > > > > > > > > > > > > > > with a change that short-circuits parsing > the > > > full > > > > > > > request > > > > > > > > > header > > > > > > > > > > > > > > based > > > > > > > > > > > > > > > > on > > > > > > > > > > > > > > > > > the first two fields. Then, we recommend > > > upgrading > > > > > > > from the > > > > > > > > > > > > latest > > > > > > > > > > > > > > 4.x > > > > > > > > > > > > > > > > > releases to future releases. This way, we > can > > > > > still let > > > > > > > > > > > > > > > > ApiVersionsRequest > > > > > > > > > > > > > > > > > depend on the request header for current > and > > > future > > > > > > > > > changes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR29. The simplest thing is to upgrade the > > > KRaft > > > > > RPCs > > > > > > > too > > > > > > > > > to be > > > > > > > > > > > > > > > > consistent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jun > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Jun 20, 2026 at 3:38 AM Andrew > > > Schofield < > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Jun, > > > > > > > > > > > > > > > > > > Thanks for these insightful comments. I > did > > > > > > > prototype the > > > > > > > > > > > > earlier > > > > > > > > > > > > > > v2 > > > > > > > > > > > > > > > > > > request header with tagged fields > variant. I > > > > > have now > > > > > > > > > > > > prototyped > > > > > > > > > > > > > > the v3 > > > > > > > > > > > > > > > > > > request header variant. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR27: You were of course entirely correct > > > that a > > > > > new > > > > > > > > > version of > > > > > > > > > > > > > > > > > > ApiVersions request cannot use a request > > > header > > > > > > > which is > > > > > > > > > not > > > > > > > > > > > > > > > > > > binary-compatible with what has gone > before. > > > As a > > > > > > > > > result, I > > > > > > > > > > > > have > > > > > > > > > > > > > > > > introduced > > > > > > > > > > > > > > > > > > a new version of ApiVersions request > which > > > > > includes > > > > > > > > > > > > > > ClientInstanceId > > > > > > > > > > > > > > > > in the > > > > > > > > > > > > > > > > > > request body but continues to use the v2 > > > request > > > > > > > header. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR28: Yes, we need a new metadata > version, > > > which > > > > > is > > > > > > > > > > > > provisionally > > > > > > > > > > > > > > > > > > IBP_4_5_IV0. I'll update the KIP with the > > > final > > > > > value > > > > > > > > > when it > > > > > > > > > > > > is > > > > > > > > > > > > > > > > assigned. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR29: I don't have any strong feelings on > > > this. I > > > > > > > > > suppose for > > > > > > > > > > > > each > > > > > > > > > > > > > > > > inter > > > > > > > > > > > > > > > > > > broker RPC version that is bumped, we > need to > > > > > > > introduce > > > > > > > > > an MV > > > > > > > > > > > > > > check. We > > > > > > > > > > > > > > > > > > cannot avoid this for RPCs which are also > > > used by > > > > > > > > > clients such > > > > > > > > > > > > as > > > > > > > > > > > > > > > > Fetch. > > > > > > > > > > > > > > > > > > For purely inter-broker RPCs, we could > just > > > > > exempt > > > > > > > them > > > > > > > > > from > > > > > > > > > > > > the > > > > > > > > > > > > > > > > version > > > > > > > > > > > > > > > > > > bump. What do you recommend here? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR30: Done. INVALID_REQUEST. I did > consider > > > > > > > permitting > > > > > > > > > zero > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > instance ID for inter-broker connections, > > > but I > > > > > > > decided > > > > > > > > > that I > > > > > > > > > > > > > > > > preferred > > > > > > > > > > > > > > > > > > not creating another rule. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2026/06/17 22:45:07 Andrew Schofield > > > wrote: > > > > > > > > > > > > > > > > > > > Hi Jun, > > > > > > > > > > > > > > > > > > > Thanks for your response. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR27: I am familiar with KIP-511 and > the > > > > > oddness of > > > > > > > > > > > > ApiVersions. > > > > > > > > > > > > > > You > > > > > > > > > > > > > > > > > > make an excellent point. I suspect that > > > > > > > > > ApiVersionsRequest will > > > > > > > > > > > > > > have > > > > > > > > > > > > > > > > to be > > > > > > > > > > > > > > > > > > limited to the v2 request header, just > as it > > > is > > > > > > > > > restricted to > > > > > > > > > > > > the > > > > > > > > > > > > > > v0 > > > > > > > > > > > > > > > > > > response header. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'll do some experimentation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2026/06/17 17:35:17 Jun Rao via dev > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi, Andrew, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the reply. A few more > > > comments. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR27. It seems that we have a > > > compatibility > > > > > issue > > > > > > > > > with > > > > > > > > > > > > > > > > > > ApiVersionRequest v6 > > > > > > > > > > > > > > > > > > > > depending on RequestHeader v3. This > > > happens > > > > > when > > > > > > > a > > > > > > > > > new > > > > > > > > > > > > client > > > > > > > > > > > > > > > > issues > > > > > > > > > > > > > > > > > > > > ApiVersionRequest v6 to an old broker > > > (one > > > > > that > > > > > > > only > > > > > > > > > > > > supports > > > > > > > > > > > > > > > > > > > > ApiVersionRequest v5). The > SocketServer > > > in > > > > > the > > > > > > > > > broker will > > > > > > > > > > > > > > first > > > > > > > > > > > > > > > > try to > > > > > > > > > > > > > > > > > > > > read the request header. It tries to > > > find the > > > > > > > header > > > > > > > > > > > > version > > > > > > > > > > > > > > from > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > request version. Since the broker > doesn't > > > > > know > > > > > > > > > > > > > > ApiVersionRequest > > > > > > > > > > > > > > > > v6, it > > > > > > > > > > > > > > > > > > > > uses v2 to parse the request header. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The v2's wire format for the request > > > header > > > > > is: > > > > > > > > > ApiKey | > > > > > > > > > > > > > > > > ApiVersion | > > > > > > > > > > > > > > > > > > > > CorrelationId | ClientId | > > > > > tagged-fields-varint > > > > > > > > > > > > > > > > > > > > The v3's wire format for the request > > > header > > > > > is: > > > > > > > > > ApiKey | > > > > > > > > > > > > > > > > ApiVersion | > > > > > > > > > > > > > > > > > > > > CorrelationId | ClientId | > > > > > ClientInstanceId(16 > > > > > > > > > bytes) | > > > > > > > > > > > > > > > > tagged-fields > > > > > > > > > > > > > > > > > > varint > > > > > > > > > > > > > > > > > > > > The first 4 fields are identical, > > > allowing > > > > > the > > > > > > > > > broker to > > > > > > > > > > > > parse > > > > > > > > > > > > > > > > them. > > > > > > > > > > > > > > > > > > The > > > > > > > > > > > > > > > > > > > > broker then tries to read the > > > > > > > tagged-fields-varint > > > > > > > > > using > > > > > > > > > > > > the > > > > > > > > > > > > > > > > serialized > > > > > > > > > > > > > > > > > > > > bytes intended for ClientInstanceId. > This > > > > > could > > > > > > > lead > > > > > > > > > to a > > > > > > > > > > > > > > parsing > > > > > > > > > > > > > > > > > > error and > > > > > > > > > > > > > > > > > > > > raise an invalid request error. The > > > broker > > > > > will > > > > > > > > > close the > > > > > > > > > > > > > > > > connection > > > > > > > > > > > > > > > > > > > > instead of sending a v0 response for > > > > > > > > > ApiVersionRequest. > > > > > > > > > > > > Then > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > > > will never be able to detect > supported > > > API > > > > > > > versions > > > > > > > > > on the > > > > > > > > > > > > old > > > > > > > > > > > > > > > > broker. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The same problem didn't exist when > > > > > > > ApiVersionRequest > > > > > > > > > > > > changed > > > > > > > > > > > > > > from > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > v1 > > > > > > > > > > > > > > > > > > > > request header to v2 because the wire > > > format > > > > > for > > > > > > > v1 > > > > > > > > > is a > > > > > > > > > > > > > > prefix of > > > > > > > > > > > > > > > > v2. > > > > > > > > > > > > > > > > > > This > > > > > > > > > > > > > > > > > > > > problem exists for this KIP because > the > > > wire > > > > > > > format > > > > > > > > > of v2 > > > > > > > > > > > > is no > > > > > > > > > > > > > > > > longer > > > > > > > > > > > > > > > > > > a > > > > > > > > > > > > > > > > > > > > prefix of v3. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR28. Since we are bumping up the > > > version of > > > > > > > inter > > > > > > > > > broker > > > > > > > > > > > > > > > > requests, we > > > > > > > > > > > > > > > > > > need > > > > > > > > > > > > > > > > > > > > to gate them by introducing a new MV. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR29. Could you specify whether the > > > version > > > > > for > > > > > > > > > KRaft PRCs > > > > > > > > > > > > > > will be > > > > > > > > > > > > > > > > > > bumped > > > > > > > > > > > > > > > > > > > > too? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR30. "If a connection uses the v3 > > > request > > > > > > > header in > > > > > > > > > its > > > > > > > > > > > > first > > > > > > > > > > > > > > > > > > request, it > > > > > > > > > > > > > > > > > > > > must specify a non-zero client > instance > > > ID" > > > > > > > > > > > > > > > > > > > > Could we define the broker's behavior > > > when a > > > > > v3 > > > > > > > > > request > > > > > > > > > > > > header > > > > > > > > > > > > > > > > > > contains a 0 > > > > > > > > > > > > > > > > > > > > client instance ID? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jun > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 16, 2026 at 1:25 AM > Andrew > > > > > Schofield > > > > > > > < > > > > > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Jun, > > > > > > > > > > > > > > > > > > > > > Thanks for your response. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR26: Yes, I was considering > open-ended > > > > > version > > > > > > > > > ranges. > > > > > > > > > > > > I've > > > > > > > > > > > > > > > > updated > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > KIP. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Now that we have a new request > header > > > > > version, > > > > > > > I > > > > > > > > > think > > > > > > > > > > > > it's > > > > > > > > > > > > > > safe > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > > reintroduce the client ID > optimisation. > > > > > I've > > > > > > > added > > > > > > > > > that > > > > > > > > > > > > into > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > KIP > > > > > > > > > > > > > > > > > > also. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Let me know what you think. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2026/06/15 17:46:00 Jun Rao via > dev > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hi, Andrew, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the reply. Just a > minor > > > > > comment. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR26. "The keys of the map are > either > > > > > single > > > > > > > > > versions > > > > > > > > > > > > like > > > > > > > > > > > > > > "0" > > > > > > > > > > > > > > > > or > > > > > > > > > > > > > > > > > > closed > > > > > > > > > > > > > > > > > > > > > > version ranges like "1-2"." > > > > > > > > > > > > > > > > > > > > > > It will be useful to support > > > open-ended > > > > > > > > > versions. That > > > > > > > > > > > > way, > > > > > > > > > > > > > > > > "3": > > > > > > > > > > > > > > > > > > "3" > > > > > > > > > > > > > > > > > > > > > could > > > > > > > > > > > > > > > > > > > > > > be "3+": "3". This part won't > need to > > > > > change > > > > > > > in > > > > > > > > > the > > > > > > > > > > > > future > > > > > > > > > > > > > > > > when we > > > > > > > > > > > > > > > > > > bump > > > > > > > > > > > > > > > > > > > > > up > > > > > > > > > > > > > > > > > > > > > > the request version without > changing > > > the > > > > > > > header. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jun > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 12, 2026 at 2:12 PM > > > Andrew > > > > > > > Schofield > > > > > > > > > < > > > > > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Jun, > > > > > > > > > > > > > > > > > > > > > > > Thanks for your response. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR25: I agree. I've changed to > a > > > > > > > > > headerVersions map > > > > > > > > > > > > in > > > > > > > > > > > > > > both > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > request > > > > > > > > > > > > > > > > > > > > > > > and response schemas. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Let me know what you think. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2026/06/12 03:39:39 Jun Rao > via > > > dev > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi, Andrew, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the updated KIP. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > JR25. I have some concerns > about > > > > > adding > > > > > > > the > > > > > > > > > > > > > > > > > > clientInstanceIdVersions > > > > > > > > > > > > > > > > > > > > > > > field > > > > > > > > > > > > > > > > > > > > > > > > to the schema. First of all, > it > > > only > > > > > > > applies > > > > > > > > > to > > > > > > > > > > > > > > requests, > > > > > > > > > > > > > > > > but > > > > > > > > > > > > > > > > > > not > > > > > > > > > > > > > > > > > > > > > > > > responses. So, it's a bit > weird > > > to > > > > > add > > > > > > > it to > > > > > > > > > the > > > > > > > > > > > > > > general > > > > > > > > > > > > > > > > > > schema. > > > > > > > > > > > > > > > > > > > > > > > Secondly, > > > > > > > > > > > > > > > > > > > > > > > > it's very specific to the new > > > field > > > > > > > added to > > > > > > > > > the > > > > > > > > > > > > > > request > > > > > > > > > > > > > > > > > > header. If > > > > > > > > > > > > > > > > > > > > > we > > > > > > > > > > > > > > > > > > > > > > > > change the request header > again > > > in > > > > > the > > > > > > > > > future, we > > > > > > > > > > > > need > > > > > > > > > > > > > > > > another > > > > > > > > > > > > > > > > > > way > > > > > > > > > > > > > > > > > > > > > to map > > > > > > > > > > > > > > > > > > > > > > > > request versions to the new > > > header > > > > > > > version. > > > > > > > > > > > > Ideally, we > > > > > > > > > > > > > > > > should > > > > > > > > > > > > > > > > > > have a > > > > > > > > > > > > > > > > > > > > > > > > generic way to map request > > > versions > > > > > to > > > > > > > all > > > > > > > > > future > > > > > > > > > > > > > > header > > > > > > > > > > > > > > > > > > versions. > > > > > > > > > > > > > > > > > > > > > One > > > > > > > > > > > > > > > > > > > > > > > > possibility is to introduce a > > > > > > > headerVersion > > > > > > > > > field > > > > > > > > > > > > in > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > schema. > > > > > > > > > > > > > > > > > > > > > Then, > > > > > > > > > > > > > > > > > > > > > > > each > > > > > > > > > > > > > > > > > > > > > > > > request/response can use this > > > field > > > > > to > > > > > > > map > > > > > > > > > its > > > > > > > > > > > > > > versions to > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > header > > > > > > > > > > > > > > > > > > > > > > > > versions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jun > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 9, 2026 at > 4:55 AM > > > Andrew > > > > > > > > > Schofield < > > > > > > > > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Matthias, > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for your response. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have change the version > > > property > > > > > for > > > > > > > > > > > > introducing > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > instance > > > > > > > > > > > > > > > > > > > > > ID > > > > > > > > > > > > > > > > > > > > > > > into > > > > > > > > > > > > > > > > > > > > > > > > > the request headers to be > > > > > > > > > > > > `clientInstanceIdVersions` > > > > > > > > > > > > > > > > which > > > > > > > > > > > > > > > > > > is now > > > > > > > > > > > > > > > > > > > > > an > > > > > > > > > > > > > > > > > > > > > > > > > open-ended range, such as > "3+", > > > > > more > > > > > > > > > closely > > > > > > > > > > > > matching > > > > > > > > > > > > > > > > what > > > > > > > > > > > > > > > > > > we have > > > > > > > > > > > > > > > > > > > > > for > > > > > > > > > > > > > > > > > > > > > > > > > flexible versions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I also added a change to > the > > > > > > > > > > > > > > > > > > RebalanceConsumer.clientInstanceId > > > > > > > > > > > > > > > > > > > > > method > > > > > > > > > > > > > > > > > > > > > > > > > introduced in KIP-1306. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2026/06/03 18:31:06 > > > "Matthias J. > > > > > > > Sax" > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks Andrew. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From a KIP-714 > perspective, > > > > > this is > > > > > > > a > > > > > > > > > great > > > > > > > > > > > > > > change, > > > > > > > > > > > > > > > > as it > > > > > > > > > > > > > > > > > > make > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > new > > > > > > > > > > > > > > > > > > > > > > > > > > RPCs and client/broker > > > > > cross-version > > > > > > > > > > > > compatibility > > > > > > > > > > > > > > > > clean. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One question about your > > > > > > > `DeleteGroups` > > > > > > > > > RPC > > > > > > > > > > > > example. > > > > > > > > > > > > > > > > Should > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > new > > > > > > > > > > > > > > > > > > > > > > > > > > version of the RPC say > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "clientInstanceIdVersion": > > > > > "3+", > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ie, 3+ instead of 3? > Similar > > > for > > > > > > > other > > > > > > > > > request, > > > > > > > > > > > > > > which > > > > > > > > > > > > > > > > > > don't use > > > > > > > > > > > > > > > > > > > > > `+` > > > > > > > > > > > > > > > > > > > > > > > on > > > > > > > > > > > > > > > > > > > > > > > > > > `clientInstanceIdVersion` > > > field. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Matthias > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 6/2/26 7:42 AM, Andrew > > > > > Schofield > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > Following on from the > > > > > discussion > > > > > > > in the > > > > > > > > > > > > > > community, > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > difficulty > > > > > > > > > > > > > > > > > > > > > > > > > of trying to accommodate > the > > > client > > > > > > > > > instance ID > > > > > > > > > > > > in a > > > > > > > > > > > > > > > > tagged > > > > > > > > > > > > > > > > > > field > > > > > > > > > > > > > > > > > > > > > with > > > > > > > > > > > > > > > > > > > > > > > > > acceptable complexity, I > have > > > made > > > > > a > > > > > > > > > significant > > > > > > > > > > > > > > change > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > the KIP. > > > > > > > > > > > > > > > > > > > > > > > Now, it > > > > > > > > > > > > > > > > > > > > > > > > > introduces v3 of the > request > > > header > > > > > > > > > containing > > > > > > > > > > > > the > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > instance > > > > > > > > > > > > > > > > > > > > > ID > > > > > > > > > > > > > > > > > > > > > > > as a > > > > > > > > > > > > > > > > > > > > > > > > > proper field. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/KAFKA/KIP-1313*3A*Client*instance*ID*in*all*request*headers__;JSsrKysrKys!!Ayb5sqE7!pUZS25PuTKdhiqvTGcwDKbclqpG8dFOzw2Ax9WxVM6Sb09PVQ0gl1i0gjlr2_Krr66agbuVC2qLGgUcg7vrW$ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please review and let > me > > > know > > > > > what > > > > > > > you > > > > > > > > > think. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2026/05/28 21:51:01 > > > > > "Matthias J. > > > > > > > > > Sax" > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > >> Thanks Andrew. I > agree to > > > the > > > > > > > issue > > > > > > > > > that > > > > > > > > > > > > tagged > > > > > > > > > > > > > > > > fields > > > > > > > > > > > > > > > > > > are > > > > > > > > > > > > > > > > > > > > > > > optional. > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> Nevertheless, I find > the > > > > > proposed > > > > > > > > > > > > compatibility > > > > > > > > > > > > > > > > > > protocol too > > > > > > > > > > > > > > > > > > > > > > > complex > > > > > > > > > > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > > > > > > > > > >> unnecessary, and would > > > still > > > > > > > prefer a > > > > > > > > > > > > version > > > > > > > > > > > > > > bump > > > > > > > > > > > > > > > > for > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > `GetTelemetrySubscriptionsRequest/Reponse` > > > > > > > > > > > > to > > > > > > > > > > > > > > clean > > > > > > > > > > > > > > > > it > > > > > > > > > > > > > > > > > > all > > > > > > > > > > > > > > > > > > > > > up. -- > > > > > > > > > > > > > > > > > > > > > > > For > > > > > > > > > > > > > > > > > > > > > > > > > > >> > `PushTelemetryRequest` the > > > > > > > argument > > > > > > > > > from > > > > > > > > > > > > above > > > > > > > > > > > > > > > > applies, > > > > > > > > > > > > > > > > > > so > > > > > > > > > > > > > > > > > > > > > > > leaving it > > > > > > > > > > > > > > > > > > > > > > > > > > >> untouched is ok. > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> I don't see why > > > > > > > > > > > > > > `GetTelemetrySubscriptionsRequest` > > > > > > > > > > > > > > > > > > would need > > > > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > > > > > > encode > > > > > > > > > > > > > > > > > > > > > > > > > > >> the `clientInstandId` > in > > > it's > > > > > > > request > > > > > > > > > body. > > > > > > > > > > > > > > Given > > > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId` is > a > > > random > > > > > > > UUID, > > > > > > > > > the > > > > > > > > > > > > > > returned > > > > > > > > > > > > > > > > > > subscription > > > > > > > > > > > > > > > > > > > > > > > cannot > > > > > > > > > > > > > > > > > > > > > > > > > > >> really depend on it. > So > > > why > > > > > would > > > > > > > we > > > > > > > > > need to > > > > > > > > > > > > > > send > > > > > > > > > > > > > > > > it to > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > broker? > > > > > > > > > > > > > > > > > > > > > > > > > > >> Right now, it's set to > > > ZERO > > > > > only > > > > > > > for > > > > > > > > > the > > > > > > > > > > > > > > purpose to > > > > > > > > > > > > > > > > get > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > broker to > > > > > > > > > > > > > > > > > > > > > > > > > > >> assign a new UUID. > But it > > > has > > > > > > > nothing > > > > > > > > > to do > > > > > > > > > > > > > > with the > > > > > > > > > > > > > > > > > > actual > > > > > > > > > > > > > > > > > > > > > "what > > > > > > > > > > > > > > > > > > > > > > > > > > >> metrics should I send" > > > > > question. > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> To be fair, KIP-714 > lists > > > > > > > > > > > > `client_instance_id` > > > > > > > > > > > > > > as a > > > > > > > > > > > > > > > > > > field that > > > > > > > > > > > > > > > > > > > > > > > can be > > > > > > > > > > > > > > > > > > > > > > > > > > >> used to define a > > > subscription. > > > > > > > But it > > > > > > > > > seems > > > > > > > > > > > > > > rather > > > > > > > > > > > > > > > > > > useless in > > > > > > > > > > > > > > > > > > > > > > > practice > > > > > > > > > > > > > > > > > > > > > > > > > > >> to me? I a user > defines a > > > > > > > > > subscription, they > > > > > > > > > > > > > > cannot > > > > > > > > > > > > > > > > > > know the > > > > > > > > > > > > > > > > > > > > > UUID. > > > > > > > > > > > > > > > > > > > > > > > > > Thus, > > > > > > > > > > > > > > > > > > > > > > > > > > >> I think we should > actually > > > > > drop > > > > > > > > > supporting > > > > > > > > > > > > > > > > > > > > > `client_instance_id` > > > > > > > > > > > > > > > > > > > > > > > as a > > > > > > > > > > > > > > > > > > > > > > > > > > >> "subscription matching > > > > > > > parameter"? Of > > > > > > > > > > > > course, > > > > > > > > > > > > > > there > > > > > > > > > > > > > > > > is a > > > > > > > > > > > > > > > > > > > > > backward > > > > > > > > > > > > > > > > > > > > > > > > > > >> compatibility > question, > > > but I > > > > > > > think > > > > > > > > > we can > > > > > > > > > > > > > > address > > > > > > > > > > > > > > > > > > this: if > > > > > > > > > > > > > > > > > > > > > > > brokers > > > > > > > > > > > > > > > > > > > > > > > > > are > > > > > > > > > > > > > > > > > > > > > > > > > > >> upgraded and they > have an > > > > > existing > > > > > > > > > > > > > > > > `client_instance_id` > > > > > > > > > > > > > > > > > > based > > > > > > > > > > > > > > > > > > > > > > > > > > >> subscription defined, > they > > > > > could > > > > > > > > > advertise > > > > > > > > > > > > to > > > > > > > > > > > > > > only > > > > > > > > > > > > > > > > > > support > > > > > > > > > > > > > > > > > > > > > v0, and > > > > > > > > > > > > > > > > > > > > > > > > > they > > > > > > > > > > > > > > > > > > > > > > > > > > >> should log a warning > that > > > this > > > > > > > > > feature is > > > > > > > > > > > > > > > > deprecated. > > > > > > > > > > > > > > > > > > New > > > > > > > > > > > > > > > > > > > > > brokers > > > > > > > > > > > > > > > > > > > > > > > > > would > > > > > > > > > > > > > > > > > > > > > > > > > > >> also not allow to use > > > > > > > > > `client_instance_id` > > > > > > > > > > > > any > > > > > > > > > > > > > > > > longer to > > > > > > > > > > > > > > > > > > > > > define a > > > > > > > > > > > > > > > > > > > > > > > > > > >> subscription. > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> Similarly, for > > > > > > > > > > > > > > `GetTelemetrySubscriptionsResponse`, > > > > > > > > > > > > > > > > we > > > > > > > > > > > > > > > > > > only > > > > > > > > > > > > > > > > > > > > > need > > > > > > > > > > > > > > > > > > > > > > > > > > >> `clientInstanceId` if > the > > > > > broker > > > > > > > > > computes > > > > > > > > > > > > the > > > > > > > > > > > > > > UUID. > > > > > > > > > > > > > > > > But > > > > > > > > > > > > > > > > > > if we > > > > > > > > > > > > > > > > > > > > > let > > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > > >> client compute it, > this > > > field > > > > > is > > > > > > > not > > > > > > > > > needed > > > > > > > > > > > > any > > > > > > > > > > > > > > > > longer. > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> -Matthias > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> On 5/28/26 1:21 AM, > Andrew > > > > > > > Schofield > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Hi Jun, > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Thanks for your > response. > > > > > > > > > > > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>> JR24: I'll update > the KIP > > > > > > > shortly. > > > > > > > > > Here's a > > > > > > > > > > > > > > > > summary. > > > > > > > > > > > > > > > > > > The > > > > > > > > > > > > > > > > > > > > > various > > > > > > > > > > > > > > > > > > > > > > > > > modern group protocol > heartbeat > > > > > > > requests > > > > > > > > > encode > > > > > > > > > > > > the > > > > > > > > > > > > > > > > member > > > > > > > > > > > > > > > > > > ID as a > > > > > > > > > > > > > > > > > > > > > > > string > > > > > > > > > > > > > > > > > > > > > > > > > for historical reasons, > even > > > though > > > > > > > it's in > > > > > > > > > > > > practice > > > > > > > > > > > > > > a > > > > > > > > > > > > > > > > UUID. > > > > > > > > > > > > > > > > > > The > > > > > > > > > > > > > > > > > > > > > Apache > > > > > > > > > > > > > > > > > > > > > > > > > Kafka Java client happens > to > > > use > > > > > > > > > > > > > > > > > > org.apache.kafka.common.Uuid to > > > > > > > > > > > > > > > > > > > > > > > create the > > > > > > > > > > > > > > > > > > > > > > > > > member ID and convert it > into a > > > > > string. > > > > > > > > > This > > > > > > > > > > > > means > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > when > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > clientInstanceId is > converted > > > into > > > > > a > > > > > > > > > string, its > > > > > > > > > > > > > > encoding > > > > > > > > > > > > > > > > > > matches > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > member ID and it all lines > up. > > > > > However, > > > > > > > > > there are > > > > > > > > > > > > > > other > > > > > > > > > > > > > > > > ways > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > > encode > > > > > > > > > > > > > > > > > > > > > > > a > > > > > > > > > > > > > > > > > > > > > > > > > UUID into a string and I > know > > > for a > > > > > > > fact > > > > > > > > > that the > > > > > > > > > > > > > > > > librdkafka > > > > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > > > > > > does it > > > > > > > > > > > > > > > > > > > > > > > > > differently. > > > > > > > > > > > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>> On 2026/05/27 > 17:11:25 > > > Jun > > > > > Rao > > > > > > > via > > > > > > > > > dev > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> Hi, Andrew, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> Thanks for the > reply. > > > One > > > > > more > > > > > > > > > comment. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> JR24. "The > alignment of > > > > > other > > > > > > > > > identifiers > > > > > > > > > > > > is > > > > > > > > > > > > > > by > > > > > > > > > > > > > > > > > > convention > > > > > > > > > > > > > > > > > > > > > (and > > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > Java > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> client will follow > the > > > > > > > convention) > > > > > > > > > rather > > > > > > > > > > > > than > > > > > > > > > > > > > > > > > > mandate." > > > > > > > > > > > > > > > > > > > > > Could > > > > > > > > > > > > > > > > > > > > > > > you > > > > > > > > > > > > > > > > > > > > > > > > > describe > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> the convention to > > > convert a > > > > > > > > > > > > clientInstanceId > > > > > > > > > > > > > > > > (UUID) > > > > > > > > > > > > > > > > > > to a > > > > > > > > > > > > > > > > > > > > > > > memberId > > > > > > > > > > > > > > > > > > > > > > > > > (String)? > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> Jun > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> On Tue, May 19, > 2026 at > > > > > 2:36 AM > > > > > > > > > Andrew > > > > > > > > > > > > > > Schofield < > > > > > > > > > > > > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> Hi Jun, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> Thanks for your > > > response. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> JR23: You are > > > absolutely > > > > > > > correct. > > > > > > > > > It > > > > > > > > > > > > seems > > > > > > > > > > > > > > to me > > > > > > > > > > > > > > > > > > that not > > > > > > > > > > > > > > > > > > > > > > > sending a > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> clientInstanceId > in the > > > > > header > > > > > > > and > > > > > > > > > > > > explicitly > > > > > > > > > > > > > > > > > > sending a > > > > > > > > > > > > > > > > > > > > > zero > > > > > > > > > > > > > > > > > > > > > > > UUID > > > > > > > > > > > > > > > > > > > > > > > > > as the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> clientInstanceId > in the > > > > > header > > > > > > > can > > > > > > > > > be > > > > > > > > > > > > > > treated as > > > > > > > > > > > > > > > > > > > > > semantically > > > > > > > > > > > > > > > > > > > > > > > > > equivalent. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> I've tweaked the > words > > > > > > > slightly. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> On 2026/05/19 > 03:42:16 > > > Jun > > > > > Rao > > > > > > > via > > > > > > > > > dev > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> Hi, Andrew, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> Thanks for the > reply. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> JR23. Our message > > > > > protocol doc > > > > > > > > > says "Any > > > > > > > > > > > > > > fields > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > message > > > > > > > > > > > > > > > > > > > > > > > > > object > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> that > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> are not present > in the > > > > > version > > > > > > > > > that you > > > > > > > > > > > > are > > > > > > > > > > > > > > > > > > deserializing > > > > > > > > > > > > > > > > > > > > > > > will be > > > > > > > > > > > > > > > > > > > > > > > > > reset > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> default values. > > > Unless a > > > > > > > custom > > > > > > > > > > > > default has > > > > > > > > > > > > > > > > been > > > > > > > > > > > > > > > > > > set:". > > > > > > > > > > > > > > > > > > > > > Uuid > > > > > > > > > > > > > > > > > > > > > > > > > fields > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> default to zero > uuid. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> So if the server > gets > > > > > > > > > > > > > > header.clientInstanceId=0 > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > deserialized > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> header, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> could it > distinguish > > > > > between > > > > > > > the > > > > > > > > > ID not > > > > > > > > > > > > > > being > > > > > > > > > > > > > > > > > > present > > > > > > > > > > > > > > > > > > > > > (since > > > > > > > > > > > > > > > > > > > > > > > > > client is > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> old) > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> and the ID being > > > > > explicitly > > > > > > > set > > > > > > > > > to 0 by > > > > > > > > > > > > the > > > > > > > > > > > > > > > > client? > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> Jun > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> On Mon, May 18, > 2026 > > > at > > > > > > > 7:45 PM > > > > > > > > > Andrew > > > > > > > > > > > > > > > > Schofield < > > > > > > > > > > > > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> Hi Jun, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> Thanks for your > > > reply. > > > > > It's > > > > > > > > > tricky > > > > > > > > > > > > > > squaring a > > > > > > > > > > > > > > > > > > circle. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> JR23: For > > > > > > > > > GetTelemetrySubscriptions, I > > > > > > > > > > > > have > > > > > > > > > > > > > > > > > > changed it so > > > > > > > > > > > > > > > > > > > > > > > that a > > > > > > > > > > > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> which omits the > > > > > > > ClientInstanceId > > > > > > > > > from > > > > > > > > > > > > the > > > > > > > > > > > > > > > > request > > > > > > > > > > > > > > > > > > header > > > > > > > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > > > > > > > > > > > permitted > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> specify a zero > > > > > > > ClientInstanceId > > > > > > > > > in the > > > > > > > > > > > > > > request > > > > > > > > > > > > > > > > > > body, > > > > > > > > > > > > > > > > > > > > > > > following > > > > > > > > > > > > > > > > > > > > > > > > > original > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> KIP-714 > precedent. > > > > > However, a > > > > > > > > > client > > > > > > > > > > > > which > > > > > > > > > > > > > > > > > > specifies a > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> ClientInstanceId in > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> the request > header > > > MUST > > > > > > > specify > > > > > > > > > the > > > > > > > > > > > > same > > > > > > > > > > > > > > > > > > > > > ClientInstanceId in > > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> request > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> body. This > ensures > > > that > > > > > the > > > > > > > > > header and > > > > > > > > > > > > > > > > telemetry > > > > > > > > > > > > > > > > > > UUIDs > > > > > > > > > > > > > > > > > > > > > are > > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > same. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> On 2026/05/12 > > > 17:48:23 > > > > > Andrew > > > > > > > > > Schofield > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>> Hi Jun, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>> Thanks for the > > > reply and > > > > > > > > > digging into > > > > > > > > > > > > the > > > > > > > > > > > > > > > > details. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>> JR23: Correct. > The > > > > > client > > > > > > > > > telemetry > > > > > > > > > > > > > > component > > > > > > > > > > > > > > > > > > will use > > > > > > > > > > > > > > > > > > > > > > > UUID-B > > > > > > > > > > > > > > > > > > > > > > > > > as the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> client instance > ID. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>> JR23.1: Yes, I > > > agree. > > > > > It's > > > > > > > not > > > > > > > > > ideal. > > > > > > > > > > > > > > When I > > > > > > > > > > > > > > > > was > > > > > > > > > > > > > > > > > > > > > drawing up > > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> tables, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> I was thinking > that > > > this > > > > > > > might > > > > > > > > > be a > > > > > > > > > > > > > > > > possibility, > > > > > > > > > > > > > > > > > > but I'm > > > > > > > > > > > > > > > > > > > > > less > > > > > > > > > > > > > > > > > > > > > > > > > convinced > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> now. I think > that I > > > > > should > > > > > > > > > mandate > > > > > > > > > > > > that if > > > > > > > > > > > > > > a > > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > > > > specifies > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> > > > header.ClientInstanceId > > > > > on > > > > > > > > > > > > > > > > > > GetTelemetrySubscriptions > > > > > > > > > > > > > > > > > > > > > request, > > > > > > > > > > > > > > > > > > > > > > > > > then > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> > > > request.ClientInstanceId > > > > > must > > > > > > > > > either be > > > > > > > > > > > > > > zero or > > > > > > > > > > > > > > > > > > equal to > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> > > > header.ClientInstanceId. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>> JR23.2: This is > > > perhaps > > > > > the > > > > > > > > > > > > interesting > > > > > > > > > > > > > > one. > > > > > > > > > > > > > > > > From > > > > > > > > > > > > > > > > > > its > > > > > > > > > > > > > > > > > > > > > > > original > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> intent, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> it should be > UUID-B > > > (the > > > > > > > > > telemetry > > > > > > > > > > > > UUID), > > > > > > > > > > > > > > but > > > > > > > > > > > > > > > > then > > > > > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > > > > > > > > > > contradicts the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> change in > signature > > > to > > > > > > > remove the > > > > > > > > > > > > timeout. > > > > > > > > > > > > > > > > Unless > > > > > > > > > > > > > > > > > > I make > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > change > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> above, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> in which case it > > > will be > > > > > > > UUID-H. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>> Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>> Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>> On 2026/05/12 > > > 17:23:58 > > > > > Jun > > > > > > > Rao > > > > > > > > > via dev > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> Hi, Andrew, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> Thanks for the > > > reply. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> JR23. In the > new > > > > > client -> > > > > > > > old > > > > > > > > > broker > > > > > > > > > > > > > > case, > > > > > > > > > > > > > > > > we > > > > > > > > > > > > > > > > > > have > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> > > > > > > > header.ClientInstanceId=UUID-H > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> > > > > > > > request.ClientInstanceId=UUID-B > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> > > > > > response.ClientInstanceId=0 > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> On the server > > > side, I > > > > > > > guess the > > > > > > > > > > > > telemetry > > > > > > > > > > > > > > > > > > component > > > > > > > > > > > > > > > > > > > > > will > > > > > > > > > > > > > > > > > > > > > > > use > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> UUID-B as > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> > clientInstanceId? > > > This > > > > > has > > > > > > > a > > > > > > > > > couple > > > > > > > > > > > > of > > > > > > > > > > > > > > > > > > implications. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> JR23.1 On the > > > server > > > > > side, > > > > > > > we > > > > > > > > > have > > > > > > > > > > > > two > > > > > > > > > > > > > > > > different > > > > > > > > > > > > > > > > > > > > > > > > > clientInstanceIds > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> used in > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> different > places, > > > > > UUID-H > > > > > > > for > > > > > > > > > request > > > > > > > > > > > > > > logging > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > > > > UUID-B in > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> telemetry. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> This > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> seems confusing > > > since > > > > > we > > > > > > > can't > > > > > > > > > > > > uniquely > > > > > > > > > > > > > > > > identify > > > > > > > > > > > > > > > > > > a > > > > > > > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > > > > > > on > > > > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> server > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> side. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> JR23.2 On the > > > client > > > > > side. > > > > > > > > > what uuid > > > > > > > > > > > > does > > > > > > > > > > > > > > > > > > > > > > > > > clientInstanceId(Duration > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> timeout) > return? > > > If it > > > > > > > returns > > > > > > > > > > > > UUID-H, it > > > > > > > > > > > > > > > > will be > > > > > > > > > > > > > > > > > > > > > confusing > > > > > > > > > > > > > > > > > > > > > > > > > since > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> it > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> doesn't match > the > > > ID > > > > > used > > > > > > > for > > > > > > > > > > > > telemetry > > > > > > > > > > > > > > on > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > server. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> Jun > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> On Tue, May 12, > > > 2026 at > > > > > > > > > 12:58 AM > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > Schofield < > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> > > > [email protected]> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> Hi Jun, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> Thanks for > your > > > > > response. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> JR20: I have > > > improved > > > > > (I > > > > > > > > > hope) the > > > > > > > > > > > > > > wording. > > > > > > > > > > > > > > > > The > > > > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > > > > > > sends > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> > > > > > request.clientInstanceId > > > > > > > = 0 > > > > > > > > > and > > > > > > > > > > > > > > > > > > > > > header.clientInstanceId = > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> UUID-H, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> and the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> broker > responds > > > > > > > > > > > > > > > > > > response.clientInstanceId=UUID-H. In > > > > > > > > > > > > > > > > > > > > > this > > > > > > > > > > > > > > > > > > > > > > > way, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> broker > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> will have > taken > > > the > > > > > UUID-H > > > > > > > > > from the > > > > > > > > > > > > > > header, > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > told > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> to > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> use it > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> for client > > > telemetry > > > > > also. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> JR21: Done. > Look > > > for > > > > > > > > > "henceforth". > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> JR22: Summary > > > table > > > > > added. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> On 2026/05/11 > > > > > 19:18:24 Jun > > > > > > > > > Rao via > > > > > > > > > > > > dev > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> Hi, Andrew, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> Thanks for > the > > > reply. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> JR20. "If the > > > client > > > > > > > > > requests a new > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > instance > > > > > > > > > > > > > > > > > > > > > ID > > > > > > > > > > > > > > > > > > > > > > > on its > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> initial > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > GetTelemetrySubscriptions > > > > > > > > > request > > > > > > > > > > > > and > > > > > > > > > > > > > > it > > > > > > > > > > > > > > > > > > sends a > > > > > > > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> instance > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> ID in > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> request > header, > > > the > > > > > > > broker > > > > > > > > > will > > > > > > > > > > > > send > > > > > > > > > > > > > > back > > > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > > > > > > > > instance > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> ID > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> rather > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> than > generating > > > a new > > > > > > > UUID. > > > > > > > > > This > > > > > > > > > > > > will > > > > > > > > > > > > > > > > > > automatically > > > > > > > > > > > > > > > > > > > > > > > align the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> UUID > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> in the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> request > headers > > > and > > > > > > > client > > > > > > > > > > > > telemetry." > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> This seems > > > > > inconsistent > > > > > > > with > > > > > > > > > > > > what's in > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > table. In > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> table, for > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> example, if > the > > > > > client > > > > > > > has > > > > > > > > > the > > > > > > > > > > > > > > following: > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > GetTelemetrySubscriptions v0 > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > header.ClientInstanceId = > > > > > > > > > UUID-H > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > request.ClientInstanceId > > > > > > > = > > > > > > > > > UUID-H > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> or > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > GetTelemetrySubscriptions v0 > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > header.ClientInstanceId = > > > > > > > > > UUID-H > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > request.ClientInstanceId > > > > > > > = > > > > > > > > > UUID-R > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> the broker > > > returns > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > response.ClientInstanceId = > > > > > > > > > 0. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> JR21. It > will be > > > > > useful > > > > > > > to > > > > > > > > > document > > > > > > > > > > > > > > what > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > new > > > > > > > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > > > > > > does > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> with > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> returned > > > > > > > > > response.ClientInstanceId. > > > > > > > > > > > > > > Note > > > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > > > > return > > > > > > > > > > > > > > > > > > > > > > > value > > > > > > > > > > > > > > > > > > > > > > > > > may > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> or > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> may not > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> be 0. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> JR22. It's > > > probably > > > > > > > clearer > > > > > > > > > if we > > > > > > > > > > > > could > > > > > > > > > > > > > > > > > > populate the > > > > > > > > > > > > > > > > > > > > > > > table > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> with 4 > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> combinations: > > > old/new > > > > > > > > > clients with > > > > > > > > > > > > > > old/new > > > > > > > > > > > > > > > > > > brokers. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> Jun > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> On Fri, May > 8, > > > 2026 > > > > > at > > > > > > > > > 2:49 AM > > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > Schofield < > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> > > > [email protected]> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> Hi Jun and > > > > > Chia-Ping, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> I've > overhauled > > > > > part of > > > > > > > the > > > > > > > > > KIP > > > > > > > > > > > > to do > > > > > > > > > > > > > > with > > > > > > > > > > > > > > > > > > > > > alignment of > > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> request > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> header > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> client > instance > > > ID, > > > > > > > client > > > > > > > > > > > > telemetry > > > > > > > > > > > > > > > > client > > > > > > > > > > > > > > > > > > > > > instance ID > > > > > > > > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> group > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> protocol > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> member IDs. > The > > > > > > > alignment > > > > > > > > > is by > > > > > > > > > > > > > > > > convention, > > > > > > > > > > > > > > > > > > not > > > > > > > > > > > > > > > > > > > > > mandate > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> (SHOULD > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> not > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> MUST). > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> It would be > > > > > possible to > > > > > > > go > > > > > > > > > around > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > existing RPCs > > > > > > > > > > > > > > > > > > > > > > > such as > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> > > > > > ConsumerGroupHeartbeat > > > > > > > and > > > > > > > > > > > > > > > > > > > > > GetTelemetrySubscriptions, > > > > > > > > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> remove > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> fields > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> containing > the > > > > > existing > > > > > > > > > > > > identifiers > > > > > > > > > > > > > > which > > > > > > > > > > > > > > > > are > > > > > > > > > > > > > > > > > > > > > intended > > > > > > > > > > > > > > > > > > > > > > > to be > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> aligned. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> Doing > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> so would be > a > > > bad > > > > > idea > > > > > > > > > though, > > > > > > > > > > > > > > because we > > > > > > > > > > > > > > > > > > would then > > > > > > > > > > > > > > > > > > > > > > > have > > > > > > > > > > > > > > > > > > > > > > > > > RPC > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> versions > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> which > > > essentially > > > > > depend > > > > > > > > > upon the > > > > > > > > > > > > > > > > presence of > > > > > > > > > > > > > > > > > > a > > > > > > > > > > > > > > > > > > > > > tagged > > > > > > > > > > > > > > > > > > > > > > > field > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> in > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> request > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> header. > This is > > > a > > > > > > > > > > > > > > protocol-compatibility > > > > > > > > > > > > > > > > > > nightmare. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> I have > removed > > > the > > > > > new > > > > > > > > > versions of > > > > > > > > > > > > > > > > > > > > > > > GetTelemetrySubscriptions > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> and > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> > PushTelemetry. I > > > > > have > > > > > > > also > > > > > > > > > > > > explained > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > behavior of > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> > > > > > > > GetTelemetrySubscriptions > > > > > > > > > in the > > > > > > > > > > > > > > presence > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > > > > absence > > > > > > > > > > > > > > > > > > > > > > > of a > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> client > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> instance > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> ID in the > > > request > > > > > > > header. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> Let me know > > > what you > > > > > > > think. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> On > 2026/05/07 > > > > > 15:09:31 > > > > > > > > > Andrew > > > > > > > > > > > > > > Schofield > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>> Hi Jun and > > > > > Chia-Ping, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>> I've been > > > thinking > > > > > and > > > > > > > > > > > > discussing the > > > > > > > > > > > > > > > > > > changes to > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> KIP-714 > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> RPCs. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> There > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> are too many > > > > > > > combinations > > > > > > > > > for my > > > > > > > > > > > > > > liking > > > > > > > > > > > > > > > > at the > > > > > > > > > > > > > > > > > > > > > moment. I > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> want to > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> take > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> another > pass at > > > this > > > > > > > area > > > > > > > > > and will > > > > > > > > > > > > > > make an > > > > > > > > > > > > > > > > > > update > > > > > > > > > > > > > > > > > > > > > in a > > > > > > > > > > > > > > > > > > > > > > > few > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> days. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>> I intend to > > > start > > > > > a new > > > > > > > > > vote > > > > > > > > > > > > once we > > > > > > > > > > > > > > have > > > > > > > > > > > > > > > > > > consensus > > > > > > > > > > > > > > > > > > > > > > > because > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> the spec > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> has > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> changed > somewhat > > > > > since > > > > > > > the > > > > > > > > > > > > earliest > > > > > > > > > > > > > > votes. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>> Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>> Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>> On > 2026/05/06 > > > > > 17:28:27 > > > > > > > > > Chia-Ping > > > > > > > > > > > > Tsai > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>> hi Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>> chia_0: > If the > > > > > > > consensus > > > > > > > > > is to > > > > > > > > > > > > > > remove > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > "duplicate" > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> field > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> from > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> RPC > payloads, > > > the > > > > > tagged > > > > > > > > > field in > > > > > > > > > > > > the > > > > > > > > > > > > > > > > header > > > > > > > > > > > > > > > > > > will > > > > > > > > > > > > > > > > > > > > > > > > > essentially > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> become a > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> required > field. > > > This > > > > > > > means > > > > > > > > > the > > > > > > > > > > > > broker > > > > > > > > > > > > > > > > needs to > > > > > > > > > > > > > > > > > > > > > handle > > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> edge > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> case > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> where > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> both the > header > > > and > > > > > the > > > > > > > > > request > > > > > > > > > > > > body > > > > > > > > > > > > > > have > > > > > > > > > > > > > > > > no > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> ClientInstanceId, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> right? > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> If > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> so, would > you > > > mind > > > > > > > > > clarifying the > > > > > > > > > > > > > > expected > > > > > > > > > > > > > > > > > > broker > > > > > > > > > > > > > > > > > > > > > > > behavior > > > > > > > > > > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> the KIP? > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>> Best, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>> Chia-Ping > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>> On > 2026/04/03 > > > > > 16:17:37 > > > > > > > > > Andrew > > > > > > > > > > > > > > Schofield > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>> Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>> I would > like > > > to > > > > > > > start the > > > > > > > > > > > > > > discussion on > > > > > > > > > > > > > > > > > > KIP-1313. > > > > > > > > > > > > > > > > > > > > > > > This > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> adds a > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> unique > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> client > instance > > > ID > > > > > to > > > > > > > the > > > > > > > > > request > > > > > > > > > > > > > > header > > > > > > > > > > > > > > > > of > > > > > > > > > > > > > > > > > > all > > > > > > > > > > > > > > > > > > > > > Kafka > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> protocol > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> requests to > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> give a > unique > > > > > identifier > > > > > > > > > which > > > > > > > > > > > > can be > > > > > > > > > > > > > > > > used to > > > > > > > > > > > > > > > > > > > > > correlate > > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> requests > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> from > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> each client > for > > > the > > > > > > > > > purposes of > > > > > > > > > > > > > > problem > > > > > > > > > > > > > > > > > > > > > determination. > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/KAFKA/KIP-1313*3A*Client*instance*ID*in*all*request*headers__;JSsrKysrKys!!Ayb5sqE7!uqWf0-b_X82WmpmCYImD2W2rht_s_q5vHcqB9ToMV4IaeQbZF42eMJyS5XC5b5qE_qJJUj3KTCXcqEvYbwYS$ > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>> Thanks, > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>> Andrew > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
