IETF MOQ WG: MoQT relay diagnostics follow-up from IETF 126 / issue #1692

Message Snapshot

• List: moq@ietf.org
• Thread subject: MoQT relay diagnostics follow-up from IETF 126 / issue #1692
• Message subject: [Moq] MoQT relay diagnostics follow-up from IETF 126 / issue #1692
• Author: Altanai B
• Published: 2026-07-23T13:03:58.000Z
• Source tag: ietf-mailing-list
• Message URL: Open in IETF Mail Archive

Summary

Altanai B posted to the MOQ working group mailing list on July 23, 2026. Hi Ian and Cullen, Following up on the IETF 126 discussion around MoQT issue #1692, �Way for client to get diagnostic data from relay�: I voluntee…

Why It Matters

This message came from the public MOQ working group archive and captures active discussion, meeting coordination, or implementation feedback around Media over QUIC.

Message Excerpt

Hi Ian and Cullen, Following up on the IETF 126 discussion around MoQT issue #1692, �Way for client to get diagnostic data from relay�: I volunteered to help co-author a draft that could capture the problem statement and propose a few starting-point designs for client-visible relay diagnostics in MoQT.

Plain-Text Body

Hi Ian and Cullen, Following up on the IETF 126 discussion around MoQT issue #1692, �Way for client to get diagnostic data from relay�: https://github.com/moq-wg/moq-transport/issues/1692

I volunteered to help co-author a draft that could capture the problem statement and propose a few starting-point designs for client-visible relay diagnostics in MoQT. My initial thought is to frame the draft around a small set of use cases first, then compare design options such as:

an explicit diagnostic request/response mechanism on the control path * diagnostic information carried in existing responses or errors where appropriate * relay capability advertisement during setup

I would need a coauthor to help giude with

privacy, authorization and avoiding leakage of operational topology * alignment with qlog/metrics work where the diagnostic data is better treated as logging or telemetry rather than protocol state

Could you let me know what you think the right next step is? For example, start with an individual draft, a short design sketch on the GitHub issue, or a PR against the transport draft if the scope is narrow enough? I�m happy to take a first pass at an outline and circulate it for review.

Cordially , Altanai Bhttps://www.linkedin.com/in/altanai/