TDoc: S4-260060

[Technical] The proposed “new normative references” include documents that are not stable or may not exist (e.g., TS 22.ABC, TR 23.801-01), which is not acceptable for normative referencing and will block approval unless replaced with valid 3GPP identifiers and correct release/stage.

[Technical] Making TR 22.870 a normative reference in a TR is questionable because TRs typically avoid normative dependencies; if requirements are being derived, TR 22.870 should generally be informative and the text should avoid “shall”-style normative language.

[Technical] Clause 4.2 requirements are largely copied from SA1 “PR” statements (e.g., [PR 5.9.8.2-1], [PR 6.50.6-2]) without translating them into media-system-specific requirements for TR 26.870 (e.g., what 26-series functions, interfaces, or media KPIs are impacted), so the content risks being non-actionable for SA4.

[Technical] The “Non-3GPP access support” text introduces ATSC/DVB as non‑3GPP access for multicast/broadcast, but it does not specify the assumed integration model (trusted/untrusted non‑3GPP access, service layer vs access layer, UE capabilities), nor how this aligns with 3GPP multicast/broadcast enablers—leaving a major architectural ambiguity.

[Technical] Requirement 4 (“UEs determine appropriate access technology when congestion detected, initial access only”) is underspecified and potentially conflicts with 3GPP access selection policy control (ANDSP/URSP/PCF-type mechanisms); it needs clarity on who decides (UE vs network), what inputs are available, and how operator policy is enforced.

[Technical] “Interworking with legacy systems” lists IMS/MMTel, broadcast/multicast, and MPS but does not identify the media continuity requirements (codecs, service layer APIs, QoS/QCI/5QI mapping, session continuity, emergency/priority handling), so it reads as a generic service list rather than SA4 requirements.

[Technical] The “Enhanced Network Service Awareness” requirements propose per-component service characteristics and differentiated charging, but do not define the granularity (flow, sub-flow, media component), identifiers, or mapping to existing 5GMS/RTM mechanisms (e.g., provisioning, metrics reporting, QoS signaling), risking inconsistency with TS 26.501/26.506 concepts.

[Technical] AI-related requirements (e.g., “image to video”, “2D to 3D/avatar”, “text to video”) are framed as network-supported transformations but lack constraints on latency, privacy, content authenticity, and user consent enforcement; without these, the requirements are incomplete and may conflict with regulatory/security expectations.

[Technical] Several AI requirements mix responsibilities across “network”, “application enablement layer”, “Service Hosting Environment”, and “IMS” without defining which 3GPP entity provides the function (e.g., 5GMS AF/MDF, RTM AS, edge hosting), creating scope creep and unclear ownership for SA4.

[Technical] The “video-based AI inference” requirement uses unusual media KPIs (“packet error rate per video frame”) that do not map cleanly to 3GPP QoS models; it should be re-expressed in terms of standardized QoS/QoE metrics (latency, jitter, loss, throughput, reliability) and media-layer metrics where applicable.

[Technical] The “guarantee user experience” requirement for combined AI+communication services is not testable as written; it needs measurable targets (e.g., end-to-end latency bounds, resolution/bitrate targets, inference accuracy reporting intervals) and conditions (mobility, congestion, handover).

[Editorial] The contribution is described as a “pseudo-CR” and includes an editor’s note that content is pending SA1 consolidation; this weakens change control discipline—either provide concrete draft spec text with stable references or keep it as a discussion paper rather than CR-like material.

[Editorial] Terminology is inconsistent and sometimes non-3GPP (e.g., “6G network”, “application enablement layer”, “authorized 3rd party”); the text should align with 3GPP-defined terms and abbreviations and avoid introducing new layers without definition.

[Editorial] The requirements are labeled with SA1-style PR identifiers (e.g., “[PR 6.42.6-1]”) but placed into TR 26.870 Clause 4.2 without a clear numbering/traceability scheme for SA4; add a consistent SA4 requirement ID format and explicit traceability to TR 22.870 clauses.