Production implementer feedback: relay + provisioning API — and is a draft-englishm-moq-cdn-provisioning refresh planned before it expires Sept 2?

# Production implementer feedback on the relay + provisioning API — and a question about draft-englishm-moq-cdn-provisioning before it expires Sept 2

First: thank you for shipping this. We provisioned a relay through the API in July, and it's been solid — our first live attach connected on the first try, and version negotiation behaved exactly as documented (client offered `[moq-lite-03, moql, moqt-17, moqt-16, moqt-15, moq-00]`, relay selected `moqt-16`). We're integrating MoQ as the media/live-data transport for a Cloudflare-Workers-native real-time platform (E2EE messaging + RTC), with Durable Objects as the per-room coordination layer behind the relay. We also maintain a fork in the `moq-dev/moq` lineage (`moq-lite`, `moq-clock`), which interops cleanly with your relay — happy to be an interop data point.

Because our use case is compliance-sensitive (one vertical is telehealth), we've hit a handful of product-layer gaps worth reporting as implementer feedback. All observed against the live API and the published API reference. (I realize the provisioning API's code likely lives outside this repo — filing here as the closest public MoQ surface; happy to be redirected if there's a better venue.)

## 1. Token revocation does not disconnect established sessions — no eviction path exists

Your own reference is admirably honest about this: `DELETE …/tokens/{jti}` — *"connections already established with the token are not closed."* Combined with tokens that allow expiry up to a year out, this means there is **no mechanism to remove a connected participant** — not revocation, not credential expiry, nothing at the product layer. For clinical and moderation use cases, removing a participant mid-session is a hard requirement.

Notably, the transport itself contemplates the fix: MoQT has expiring auth tokens (`EXPIRED_AUTH_TOKEN`). **Ask:** surface short-TTL auth tokens (or an explicit session-terminate operation) so eviction is achievable at the transport rather than only by application-layer re-key.

## 2. Authorization has no namespace/track dimension

Tokens carry `operations: publish|subscribe` relay-wide — there's no way to authorize a credential to a subset of namespaces or tracks. MoQT's authorization model (§8.4/§8.5 of draft-16) is naturally per-track/per-namespace, and Track Namespace is an ordered tuple that begs for **prefix-scoped authorization** (e.g., authorize `["app","room",""]`). Without it, multi-room applications are pushed toward a scope-per-room workaround, which immediately collides with:

## 3. The 10-token-per-relay cap, and undocumented account ceilings

The token cap is fine for single-scope apps but becomes a hard ceiling under scope-per-room. And we couldn't find documented limits for **relays/scopes per account** — for anyone sizing a multi-tenant or many-room deployment, that number is load-bearing. **Ask:** document the ceilings, and/or make prefix authz (item 2) the path that removes the need to multiply scopes.

## 4. Minor: live vs. documented envelope drift

We've observed small differences between documented response envelopes and live responses in the provisioning API. Happy to file these individually with request/response pairs if useful — flagging here so it's on the radar.

## 5. Roadmap question: draft versions

The relay negotiates `moqt-16`; `draft-ietf-moq-transport` is at **-19** (July 2026). Any guidance on the upgrade cadence you intend would help integrators time their tracking (we currently pin to what the relay selects).

## The main question: `draft-englishm-moq-cdn-provisioning-00` **expires 2026-09-02**

We read the provisioning draft as the most important artifact here — its stated purpose, *common semantics across CDN providers for multi-CDN compatibility*, is exactly why we felt safe building on this API rather than treating it as proprietary surface. And multi-CDN is no longer hypothetical: with moq.pro now commercially live (which, worth noting, ships scoped authorization tokens — the granularity from item 2), there are two hosted MoQ CDNs — and we verified today that the same client stack round-trips through both your relay and cdn.moq.dev. Common provisioning semantics are exactly what's missing to make that portability real at the operations layer. Several of the findings above (eviction semantics, sub-scope authorization, token/scope ceilings) are precisely the kind of implementer input a -01 could absorb.

**Is a refresh planned, and is there interest in pushing it toward WG adoption?** We'd gladly contribute implementation feedback in whatever venue helps — here, the WG list, or against a -01. If it lapses, the semantics default back to proprietary-by-default, which would be a real loss for the multi-CDN story.

Thanks again — the fact that a production MoQ relay is a dashboard button in 2026 is genuinely remarkable. Happy to share more detail about our integration privately if that's useful to the team.

— Norman Todd, infinitum nihil

Start with the published API reference and the live API behavior described in the issue, focusing on token revocation, authorization scope, account ceilings, and response envelopes. Confirm whether these concerns belong in moq-rs or an external provisioning service, then look for an existing roadmap or venue for the draft refresh. Done would require a maintainer decision on scope, ownership, and the proposed API direction.

Written by the indexing model from the issue text.