Thank you both for the clarification
Respectfully,
* Edward R. Aylward II *702.533.9112
On Sat, Jul 12, 2025 at 7:19 PM Lucas Pardue <lu...@lucaspardue.com> wrote:
> Hi Edward
>
> On Sat, Jul 12, 2025, at 16:48, Marten Seemann wrote:
>
> 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.
>
> +1 Marten's points
>
> Generally, embedding non-transport capabilities into the transport layer
> is an anti-pattern. Furthermore, there is no common QUIC API, which makes
> exposing transport features that applications rely on a difficult task.
>
> I'd first encourage you to explore some options for running your protocol
> over HTTP/3 or WebTransport. Both of which run over QUIC and provide clear
> explanations of how QUIC streams or datagrams can be used to exchange
> application protocol data. Then you might get a clearer idea what, if any,
> inefficiences you see.
>
> Cheers
> Lucas
>
>
> 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
>
>
>
