TDoc: S4-260118

[Technical] The CR is largely non-actionable as a normative change: “most technical content is marked with Editor’s Notes” and multiple placeholders (AC.4.2/AC.4.3) mean TS 26.114 would gain an annex that cannot be implemented or verified, which is not appropriate for a Category B CR.

[Technical] The proposed call flow in AC.4.1 relies on entities/procedures (MF, DCSF, DCAR, DC AS, BDC/ADC) “per TS 23.228” without ensuring those entities and interfaces are actually defined for IMS MTSI in the referenced specs; TS 26.114 cannot normatively introduce new core network functions and HTTP-based procedures without tight alignment to SA2/CT.

[Technical] Step 11/13 introduces “ADC: AI Model Selection Request/Response” signaling, but TS 26.114 does not define a new application-layer signaling protocol on ADC; the CR must specify whether this is SIP/SDP, MSRP, HTTP, or a new payload format, and how it is negotiated and secured.

[Technical] The flow mixes “application download” and “model download” via MF as an intermediary (steps 6–9, 12–13) without clarifying whether MF is acting as a proxy/cache, whether this is allowed by IMS architecture, and how content integrity, authorization, and accounting are handled end-to-end.

[Technical] Security and trust are missing: there is no normative requirement for model signing, integrity verification, provenance, or authorization (UE trusting MF/DCSF/DCAR), which is critical when downloading executable models and “AI applications” into the terminal.

[Technical] The CR does not define how AI/ML capabilities are negotiated within MTSI session establishment (e.g., SDP attributes, feature tags, SIP option-tags), yet claims “negotiation and signaling (AC.8)”—without this, interoperability and backward compatibility with non-AI/ML UEs cannot be ensured.

[Technical] The relationship to existing MTSI media processing and data channel usage in TS 26.114 is unclear: the annex appears to introduce new “AI/ML assisted media processing” but does not specify how it interacts with existing codecs, RTP/RTCP, media handling, and data channel procedures already standardized.

[Technical] AC.4.1 is user-driven (“User selects app/tasks”) but TS 26.114 is a stage 3 protocol spec; the CR should define UE behavior and protocol triggers independent of UI assumptions, and specify machine-driven selection/updates for unattended operation.

[Technical] Large model handling is explicitly FFS, yet model size impacts transport choice, fragmentation, resumption, caching, and latency; without at least baseline requirements (chunking, range requests, resume, max sizes), the proposed BDC/ADC transport is incomplete.

[Technical] The CR introduces “AI/ML formats” (AC.6) and “intermediate data” but does not constrain formats (e.g., ONNX/TFLite) or define MIME types, encapsulation, versioning, and compatibility rules; this will lead to non-interoperable implementations.

[Technical] The end-to-end reference architecture (AC.3) is described as “potential updates” and “possible liaison requirements with SA2,” indicating architectural dependencies are unresolved; TS 26.114 should not proceed with normative annex text until SA2 architecture and responsibilities are agreed.

[Editorial] The annex is described as “comprehensive new normative annex,” but the presence of Editor’s Notes, placeholders, and FFS items contradicts “normative”; the CR should clearly separate informative background from normative requirements and remove unfinished notes before approval.

[Editorial] Terminology is inconsistent/undefined in the summary: “AI application,” “task manifest,” “AI feature tags,” “model URNs,” and “intermediate data” need precise definitions in clauses 3.1/3.3 and consistent use throughout AC.4–AC.9.

[Editorial] The step numbering and dual-path descriptions (e.g., 12a/12b, BDC vs ADC in steps 11 and 13) need clearer conditional logic (“shall/should/may” conditions) to avoid ambiguity about which transport and signaling are mandatory vs optional for compliance.