[Technical] The document repeatedly assumes “token” semantics (importance, dependency, token-to-PDU mapping, visibility to RAN) are relevant to RAN handling, but it does not justify how tokens would be observable given end-to-end encryption and application-layer framing; without a concrete exposure mechanism (e.g., explicit QoS marking/metadata), most token-level proposals are not actionable in 3GPP RAN.

[Technical] Several items imply new RAN behavior based on “importance differentiation” and “error-tolerant token transmission,” but there is no linkage to existing 5QI/QFI/QoS Flow constructs or a proposal for how importance maps to standardized QoS parameters (PDB, PER, priority level, MDBV, etc.), risking duplication or conflict with the 5GS QoS model.

[Technical] The recommendation to reuse XR “PDU Set” mechanisms for AI traffic is underspecified: it does not state which layer/function (PDCP/RLC/MAC) would bind/annotate sets, nor how this interacts with segmentation/retransmissions, making the feasibility of “PDU Set binding/annotation for AI traffic” unclear.

[Technical] The Rel-20 vs 6G split is asserted (“Rel-20 uplink/non-real-time; 6G real-time bidirectional”) without evidence from the summarized inputs that downlink real-time AI is out of Rel-20 scope; this may prematurely constrain RAN2 study/work item scope and misalign with SA4/SA1 service requirements.

[Technical] “Small packet sizes” and “uplink-heavy” are presented as near-universal characteristics, but the document also includes training/federated learning “bulk, synchronized uploads” and split inference intermediate data, which can be large and periodic; the summary should explicitly separate these regimes to avoid misleading one-size-fits-all conclusions.

[Technical] The text suggests “small packet transmission in RRC inactive” as an uplink enhancement, but does not reference existing mechanisms (e.g., RRC Inactive data transmission solutions) or identify what gap remains for AI traffic, making it hard to assess whether new work is needed.

[Technical] “Multi-modal synchronization beyond MMSID for QoS control” is mentioned, but MMSID is not defined in this document and the required synchronization primitive (timestamping, cross-flow dependency signaling, common deadline) is not articulated; this risks creating vague requirements that SA4 cannot answer.

[Technical] The dependency list asks SA4 for “packet delay budget, PER tolerance, packet importance variability,” but SA4 typically specifies codecs/formats and RTP/transport behavior rather than 5GS QoS targets; the document should clarify which items are expected from SA4 vs SA1/SA2 (service requirements/QoS) vs RAN2 (radio handling).

[Technical] The “AI codec vs non-AI codec” categorization (Type 1/2/3) is introduced without defining what constitutes an “AI codec” in 3GPP terms or how it maps to TR 26.847/26.927 scope; this ambiguity undermines the proposed coordination and could lead to inconsistent terminology across groups.

[Technical] “Error tolerance determination” contains conflicting directions (SA4 to define vs RAN2 to proactively determine based on task/source data), but the document does not propose a resolution path (e.g., normative parameters, profiles, or measurement methodology), leaving a key design input unresolved.

[Editorial] The document reads as a narrative summary but lacks traceability: many “strong consensus/nearly universal” statements are not backed by explicit references to which contributions support them, making it difficult for reviewers to validate the characterization.

[Editorial] Several terms are used inconsistently or without definition (e.g., “token-based communication,” “AI-native communication,” “service awareness at L2,” “context-aware traffic flow”), and the document would benefit from a short terminology section to prevent misinterpretation across RAN2/SA4.

[Editorial] The “Specific Questions to SA4” list is long and partially overlapping; consolidating into a smaller set of well-scoped questions (with clear expected output: definition, traffic model, or timeline) would improve the likelihood of actionable SA4 feedback.

[Editorial] The section “Divergent Views and Open Issues” mentions scope items like “suggests RAN1 scope” and “include RedCap,” but does not state the implication for RAN2 next steps (e.g., whether to forward to RAN1/SA1 or exclude), leaving the reader without a clear decision-oriented outcome.