[Technical] The proposal that SA4 should “define AI formats (tokens, embeddings, latents…)” risks stepping outside SA4’s remit and duplicating/contradicting work in external SDOs (IETF/MPEG) and other 3GPP groups; it should be reframed as characterizing traffic/QoS/QoE requirements and media-relevant payload properties rather than defining formats.

[Technical] “6G Media is 5G Media unless agreed differently” is too strong as a baseline for a feasibility study and may pre-empt legitimate 6G-driven requirements (e.g., compute-in-the-loop, sensing-media fusion, new security/privacy models); it should be qualified to avoid constraining the study outcome before gap analysis.

[Technical] The AI traffic work item lacks clear boundaries vs SA1 (service requirements) and SA2 (architecture), and the document does not specify concrete SA4 deliverables (e.g., traffic models, QoE metrics, codec/transport implications) or interfaces to other WGs, making it hard to avoid overlap and ensure timely, actionable output.

[Technical] The statement that traffic characteristics should be developed “independent of access network” conflicts with the intent to identify “opportunities for future networks,” since key AI-media KPIs (latency/jitter/loss, uplink/downlink asymmetry, edge compute placement) are inherently coupled to access and system architecture; at minimum, the study should define a set of reference network profiles rather than claiming independence.

[Technical] WT#3 monitoring of SA2 “Key Issues #20-#22 in TR 23.801-01” is underspecified: it does not identify what SA4-specific outputs are expected (e.g., media/sensing data models, timing constraints, synchronization, compute offload impacts on media pipelines), so “minimal priority” risks missing early architectural hooks that later become hard to change.

[Technical] WT#4 “Media for ubiquitous access” focuses on data rates/scheduling over NTN but omits core SA4 media aspects that typically dominate feasibility (buffering strategies, playout adaptation, FEC/repair, long RTT impacts on interactive media, multicast/broadcast applicability), so the scope as written is not sufficient for meaningful SA4 conclusions.

[Technical] WT#5 “Trusted and private media communication” is framed as potentially separate but provides no linkage to existing 3GPP security/privacy mechanisms (e.g., identity, key management, E2E media protection, lawful intercept constraints), risking a vague annex with no actionable recommendations.

[Technical] The proposed TR structure (“each work topic may use a dedicated Annex”) combined with “opportunistic” collection risks producing a set of disconnected notes; the TR needs an explicit consolidation mechanism (common terminology, KPI set, cross-topic dependency mapping, and a single recommendations clause with traceability to use cases/requirements).

[Technical] The plan to accept “slide decks and workshop-style contributions” without stating how they will be normalized into TR text (definitions, assumptions, evaluation methodology) risks non-reproducible conclusions, especially for QoE/AI measurements where methodology consistency is critical.

[Technical] The document references reuse of “other 5G media studies” and “FS_AMD_Ph2” but does not identify which outputs are intended to be baselined into TR 26.870 (e.g., specific clauses, findings, KPIs), making it unclear how reuse will be operationalized and avoiding re-litigation.

[Editorial] Several priorities are expressed qualitatively (“low to medium,” “minimal,” “near-separate study”) without criteria or decision gates; for a ways-of-working paper, add explicit triggers (e.g., SA1 requirement availability, SA2 dependency milestones) to justify reprioritization.

[Editorial] The document repeatedly mixes “6G media,” “media delivery architecture,” and “AI traffic” without defining terms or scope boundaries (e.g., what counts as “media” vs generic data/AI payload), which will cause inconsistent interpretation when drafting TR 26.870.

[Editorial] References are informal (e.g., “TR 23.801-01,” “ULBC work”) and should be cited with correct identifiers/titles and versioning expectations to avoid ambiguity when the TR is drafted and maintained over multiple releases.