TDoc: S4-260195

[Technical] The CR introduces extensive new normative behavior (task manifests, model cards, “3gpp-ai” subprotocol, time binding) but does not identify exact TS 26.114 clause numbers to be changed nor provide normative text deltas, making it impossible to verify consistency with existing DCMTSI procedures and requirements in clauses 6.2.10/6.2.13.

[Technical] The call flow AD.4.1 is internally inconsistent (it claims a “14-step procedure” but lists 15 steps) and mixes BDC/ADC roles in a way that conflicts with the stated architecture (e.g., step 11 “BDC: HTTP GET with task/model URLs” implies UE informs MF via GET, which is semantically wrong for selection signaling).

[Technical] The proposal assumes MF can fetch and relay large AI model artifacts (steps 12–13) while also stating “IMS Media Function does not perform inference or process RTP media”; it still requires MF to understand application/model selection and act as a distribution proxy, but no impact analysis is provided for MF behavior, caching, authorization, charging, or load.

[Technical] Introducing a new ADC subprotocol “3gpp-ai” and JSON message types without defining a stable, interoperable schema (it says “detailed schema specified by AI/ML application”) undermines cross-vendor interoperability and contradicts the claim of “normative procedures, formats, and signaling.”

[Technical] The time-binding mechanism in AD.8.2 is underspecified/incorrect for synchronization: “NTP-based timestamp associated with RTP stream” is not defined (RTP itself doesn’t carry NTP unless using RTCP SR mapping), and allowing either RTP timestamp or “NTP + durSamples” without a mandated mapping to RTP clock rate/RTCP SR risks ambiguous alignment at the receiver.

[Technical] The use of SDP “mid” alone for binding is insufficient in multi-SSRC, simulcast, or stream-restart scenarios; the CR should specify whether SSRC, RID, or other identifiers are needed to uniquely bind metadata to a specific RTP source/encoding within a given mid.

[Technical] The CR mandates ONNX 1.16.0 and opset ≥18 as “Mandatory Model Format” without justification or fallback; this is likely unrealistic for UE implementations and conflicts with the stated “WebNN-aligned runtime” (WebNN support is not equivalent to ONNX opset support), risking non-deployable requirements.

[Technical] Security/integrity is incomplete: SHA-256 verification is mentioned, signatures are “optional,” but there is no trust model (certificate chain, key provisioning, revocation), no binding between model card and artifact, and no protection against downgrade/mix-and-match attacks across model_id/model_version_id/artifact variants.

[Technical] The CR introduces “capability discovery” and “resource limits” exchange but does not define privacy constraints, user consent, or minimization; exposing detailed device accelerator/operator support to a DC AS can materially increase fingerprinting risk and may conflict with 3GPP privacy expectations.

[Technical] The “split inference” concept is described but not normatively constrained: it is unclear how tasks are partitioned, how intermediate representations are transported (if any), and how this interacts with the statement “RTP media unchanged,” especially for tasks like noise suppression that typically require modifying the media stream.

[Technical] The CR claims “DCMTSI client shall not transmit user media over BDC,” but then allows ADC metadata delivery without defining whether metadata may contain user content (e.g., STT text is user content); policy and confidentiality requirements (encryption end-to-end vs hop-by-hop) are not addressed.

[Editorial] Several references appear incorrect or non-actionable: “TS 23.228, clause AC.7.1” and new clauses “AD.1…AD.9” are not existing TS 26.114 clause identifiers, so the contribution cannot be reviewed against the actual spec structure.

[Editorial] Terminology is inconsistent and sometimes non-3GPP: “DCMTSI clients must support … web runtime,” “WebNN-aligned runtime,” “model card,” and “task manifest” are introduced as if standardized, but no alignment to existing 3GPP definitions or external normative references (W3C WebNN, ONNX spec) is provided.

[Editorial] The example metadata uses fields like "ntpTs": 381245120 without defining epoch, units, wraparound, or relation to RTP/RTCP, and uses "mid": "audio" even though mid values are tokens negotiated in SDP (not semantic labels), which may mislead implementers.