It’s difficult to provide meaningful feedback without access to the draft itself, but my initial question would be: what’s the justification for defining new QUIC frame types? In general, QUIC frames, aside from STREAM and DATAGRAM, are intended to modify transport-layer behavior. Based on the description, DAAP appears to be an application-layer protocol, and it seems more appropriate for it to be layered on top of QUIC rather than extending the transport itself.
On Fri, 11 Jul 2025 at 16:44, Edward Aylward <aylward.edw...@gmail.com> wrote: > *Subject:* Proposal: Integrating DAAP Functionality into QUIC > > *To:* quic-cha...@ietf.org > *Cc:* quic@ietf.org > *From:* Ed Aylward aylward.edw...@gmail.com > *Date:* July 11, 2025 > ------------------------------ > > Dear Lucas and Matt, > > I hope you’re both doing well. > > My name is Ed Aylward, and I’m the author of *draft-aylward-daap-v2*, > which outlines the Distributed AI Accountability Protocol (DAAP). It’s a > framework designed to help maintain human oversight over autonomous AI systems > by requiring regular, verifiable communication with a designated authority. > > I’m reaching out to propose a new QUIC extension that would allow DAAP to > run natively over QUIC. The goal is to move beyond HTTP-over-TCP, embedding > DAAP’s core functions directly into the transport layer by defining: > > - > > New QUIC frame types for behavioral check-ins, policy updates, and > emergency signaling > - > > A TLS extension (daap_identity) to establish agent identity at the > start of the QUIC handshake > - > > Multiplexed streams to handle real-time control, telemetry, and > enforcement in parallel > > This integration would provide tighter security guarantees, better > performance, and more responsive control, especially valuable for > environments where speed, reliability, and accountability are critical. > > If the working group is open to reviewing this idea, either as a > contribution to QUIC or as an individual draft submission, I’d be happy > to share: > > - > > A working draft in the IETF format > - > > Notes on how the implementation maps to current QUIC capabilities > - > > Example use cases in sectors like robotics, edge AI, and smart > infrastructure > > Thanks for considering this. I appreciate your time and would welcome any > suggestions or guidance on next steps. > > Best regards, > *Edward Richard Aylward, Jr.* > Email: aylward.edw...@gmail.com > DAAP GitHub: https://github.com/ELF-GUARD/DAAP/ > ORCID: 0000-0003-0313-6993 >
