[Technical] The contribution argues SA4 should avoid “normative work on AI formats,” but it does not clearly distinguish between (a) normative specification of application payload schemas (likely out of scope) and (b) normative traffic descriptors/traffic models needed by RAN2/SA2; this risks leaving RAN2/SA2 without actionable, comparable parameters.

[Technical] The paper claims “no clear interoperability requirement exists today,” yet AI services already rely on interoperable transport/application behaviors (e.g., HTTP/2/3, TLS, streaming responses); the contribution should clarify what “interoperability” means in 3GPP terms and why that precludes any normative assumptions for modeling.

[Technical] The proposed “focus on traffic characteristics” is not operationalized: no concrete set of traffic model parameters (e.g., request size distributions, token/segment inter-arrival, response truncation, concurrency, session duration) is provided, so SA4 cannot translate the guidance into a usable model.

[Technical] The characterization “bursty and unpredictable” / “event-driven rather than steady-state streaming” is too generic and potentially misleading given common AI response streaming (server-sent events / chunked transfer / WebSocket-like patterns) that can resemble quasi-streaming; the document should explicitly cover both non-streaming and streaming inference modes.

[Technical] The “Text-to-Text small prompt, token-based responses” framing omits key drivers of traffic: context window growth, retrieval-augmented generation (RAG) document fetches, tool-calling/agent loops, and multi-turn conversation history, all of which can dominate uplink/downlink volumes and burst patterns.

[Technical] Multimodal is reduced to “photo uploads,” but emerging patterns include continuous audio (speech) and video understanding with sustained uplink plus low-latency downlink; excluding these biases any future traffic model toward sporadic UL bursts only.

[Technical] The document references REST/JSON examples (OpenAI/Claude/Gemini) but does not address that payload encoding (JSON vs protobuf), compression, and HTTP streaming materially affect packetization and burstiness; if SA4 avoids format standardization, it should still bound these factors for modeling.

[Technical] The “5+ years in the future / 6G deployment” argument is not aligned with SA4’s immediate remit to support Rel-19/Rel-20 studies; the contribution should reconcile near-term modeling needs with long-term uncertainty rather than using long-term uncertainty to defer specifics.

[Technical] “Continuous review” is proposed without a mechanism (trigger conditions, cadence, ownership, or liaison process with RAN2/SA2), making it unlikely to be actionable within 3GPP work planning.

[Technical] The paper does not map its recommendations to existing 3GPP traffic model frameworks (e.g., TS 26.234/26.247 style service requirements, TR-based traffic models, or SA2 service exposure assumptions), risking inconsistency with established methodology.

[Editorial] The contribution reads as a positioning note but lacks explicit asks to SA4 (e.g., “agree to treat AI payload formats as non-normative in TR X,” “provide parameter set Y to RAN2 by date Z”), which makes it hard to conclude or capture in meeting notes.

[Editorial] Terms like “AI formats,” “data packet structure,” “model formats,” and “traffic patterns” are used interchangeably; tighter terminology (application payload schema vs transport protocol vs traffic model parameters) is needed to avoid misinterpretation.

[Editorial] The summary cites external proprietary API references as evidence of variability, but does not provide stable citations or extract the relevant commonalities/differences; for a 3GPP contribution, the argument should be supported by a more systematic comparison or at least a table of observed behaviors.