Coming from an author's perspective, I'm happy to remove the extended ACK portion and ship a new draft version before adoption.
I wrote a PR that does that and always includes the timestamp section at the end of ACK frames, for example: https://github.com/wcsmith/draft-quic-receive-ts/pull/8 Thanks, Ian On Tue, Apr 15, 2025 at 5:41 AM Mirja Kuehlewind <mirja.kuehlewind= [email protected]> wrote: > Hi chairs, hi all, > > > > we had some discussion on list and in the meeting suggesting to rather use > a new frame than using an extended ACK. I generally support this work but I > would actually rather want to adopt a document that reflects this change. > Or what’s the plan here? > > > > Mirja > > > > > > > > *From: *Lucas Pardue <[email protected]> > *Date: *Monday, 14. April 2025 at 21:01 > *To: *"[email protected]" <[email protected]> > *Cc: *QUIC WG Chairs <[email protected]> > *Subject: *Re: Adoption call: QUIC Extended Acknowledgement for Reporting > Packet Receive Timestamps > > > > Reminder: the call for adoption closes at the end of this week > > > > On Thu, Apr 3, 2025, at 20:58, Lucas Pardue wrote: > > Hi folks, > > > > At IETF 122 we discussed QUIC Extended Acknowledgement for Reporting > Packet Receive Timestamps [1]. The sense of the room was that there was > support for the QUIC WG adopting work on ACKs with timestamps. > > > > The email launches a formal adoption call > for draft-smith-quic-receive-ts-01 as the basis of this work. The call will > run until end of day 2025-04-18 anywhere on earth [2] > > > > Please post comments in favor or against as replies to this thread. > > > > Cheers > > Lucas & Matt > > QUIC WG Chairs > > > > [1] - https://datatracker.ietf.org/doc/draft-smith-quic-receive-ts/ > > [2] - https://en.wikipedia.org/wiki/Anywhere_on_Earth > > > >
