TDoc: S4-260112

[Technical] The contribution still assigns AI/ML inference execution to the MF (“MF manages media flows… executes inference tasks”), but in SA2/TS 23.228 the MF role and its capabilities for AI/ML execution are not clearly standardized; you need to align the execution entity with the agreed IMS DC architecture (e.g., DC AS vs other function) and avoid introducing compute semantics for MF without normative backing.

[Technical] The call flow mixes BbDC to MF and AaDC to DC AS while also stating “Task control messages exchanged over AaDC,” yet UPDATE is sent “over ADC” and may be forwarded by MF; the spec impact is unclear unless you precisely define which DC (BbDC vs AaDC) carries which control messages and whether MF is a DC endpoint or only a relay.

[Technical] “Split inference” is claimed as supported, but no concrete procedure is provided for partitioning, synchronization, or model/component distribution between UE and network (e.g., how intermediate representations are transported, how latency/jitter is handled, and how the split point is negotiated), making the split option currently non-actionable.

[Technical] The UPDATE procedure introduces “start time (when to apply new parameters)” but there is no definition of the time base (RTP timestamp, NTP, IMS time, or relative time), nor how both UE and network ensure consistent switchover, which is critical to avoid media glitches and inconsistent translation states.

[Technical] The task control messages define input/output using SDP mid, but mid identifies an m-line, not a specific direction/source in multi-party or mixer scenarios; for conferencing/add/remove participants you likely need additional identifiers (SSRC, RID, participant identity, or DC application-level stream IDs) and rules for multiple simultaneous inputs/outputs.

[Technical] The document says multiple RTP streams are identified by “comma-separated mid values,” which is not aligned with typical JSON typing and lacks constraints (ordering, uniqueness, mapping to codecs); you should define an array structure and normative mapping to SDP offer/answer and subsequent re-INVITE/UPDATE procedures.

[Technical] The UPDATE use case “new UE added to call” implies new media descriptions and potentially new mid values, but the procedure does not specify the required SIP/SDP signaling (re-INVITE/UPDATE) and how task update sequencing relates to SDP completion (race conditions between task update and new m-line establishment).

[Technical] The contribution states “UE1 registers to IMS with AI/ML capability indication,” but does not specify the mechanism (feature tags, IMS media feature tags, SIP header, or 3GPP-defined capability exchange); without a concrete method it risks conflicting with existing IMS capability negotiation procedures.

[Technical] The response codes are shown as HTTP-like (“200 OK”) inside JSON messages; unless the DC protocol explicitly reuses HTTP semantics, you should define a 3GPP-specific result code space or map to existing DC/IMS error handling to avoid ambiguity and inconsistent implementations.

[Technical] Security and authorization are not addressed for downloading models and updating tasks (e.g., ensuring only authorized UEs can request model delivery, integrity of models, privacy of media sent for inference, and policy controls based on subscription list filtering), which is essential given the introduction of AI model distribution and media offload.

[Technical] Step 23 “Remote UE (UE2) informed when task updates impact it” is underspecified: it does not define whether UE2 is informed via SIP/SDP, DC messaging, or application signaling, nor what UE2 must do (e.g., render changes, accept new media, consent), leaving interoperability gaps.

[Editorial] The document references “TR 26.927 and TS 23.228 Annex AC” but does not provide exact clause numbers for the proposed modifications; for a contribution intended to update specs, you should cite the precise sections/figures being replaced and provide proposed normative text or updated call-flow diagrams.

[Editorial] Terminology is inconsistent: “ADC,” “AaDC,” “Application Data Channel,” and “BbDC” are used interchangeably in places; you should normalize terms and abbreviations and ensure they match the definitions in TS 23.228/related DC specs.

[Editorial] The message format is described as “JSON-like syntax” with URN type values, but no formal schema, field cardinality, optionality, or extensibility rules are given; even at TR level, a consistent pseudo-schema would reduce ambiguity and prevent incompatible interpretations.