TDoc: S4-260185

[Technical] The proposal introduces “intermediate data format parameters” (tensor characteristics, compression profile identifiers) but does not define where these are specified (e.g., codec/format registry, SDP attributes, ADC schema) or how interoperability is ensured across vendors; without normative parameter definitions and negotiation rules, the call flow is not implementable.

[Technical] The use of “ADC (Application Data Collection)” for configuring split-inference media/tensor exchange is unclear and likely mis-scoped: ADC is typically about data collection/analytics, not real-time media processing session negotiation; the contribution needs to justify why ADC is the right control plane versus existing IMS/SDP or service-specific signaling.

[Technical] The call flow relies on “MF (Media Function)” as a relay for intermediate tensors and processed media, but does not specify whether MF is in the media path (RTP) or an application proxy, nor how it handles non-media tensor payloads (e.g., RTP payload format, framing, congestion control), creating a major gap for user-plane transport.

[Technical] No session establishment details are provided (e.g., IMS offer/answer, media descriptions, directionality, ports, security), so it is impossible to map the proposed steps onto actual 3GPP procedures; at minimum, the contribution should indicate which existing procedures are reused and what new signaling is required.

[Technical] The proposal assumes a fixed UE→DCAS intermediate data direction and DCAS→UE processed media return, but split inference can be iterative/bi-directional; the “split inferencing loop” term implies multiple exchanges, yet only a single pass is described, risking mismatch with the intended feature.

[Technical] Latency, jitter, and synchronization requirements are not addressed (e.g., timestamping of intermediate tensors relative to captured media, buffering, reordering), which is critical for real-time media processing and for any MF-mediated transport.

[Technical] There is no error handling or fallback behavior (e.g., DCAS unreachable, intermediate data decode failure, compression profile mismatch, packet loss), which is essential for a normative call flow and impacts service continuity.

[Technical] Security and privacy aspects are missing: intermediate tensors may leak sensitive content; the contribution should specify protection (e.g., SRTP/DTLS, keying, authorization of DCAS, integrity) and whether MF can access plaintext or must be end-to-end protected.

[Technical] The selection of “UE submodel” and “Remote submodel” is mentioned but not defined (who selects, based on what capabilities/conditions, how model identifiers/versions are negotiated, and how consistency is ensured), which is a core part of split inference interoperability.

[Technical] The role and definition of DCAS in the IMS-MED context is not clarified (is it an AF, an application server, a media resource function, or an external analytics server), leading to architectural ambiguity and potential inconsistency with existing SA4 functional entities.

[Editorial] The contribution references TR 26.927 but does not cite specific clauses or align terminology; terms like “processed media data,” “intermediate data,” and “tensor characteristics” should be harmonized with existing definitions to avoid introducing parallel vocabularies.

[Editorial] The text reads as a high-level narrative rather than a CR-ready specification change: it lacks explicit target spec/clause numbers, exact proposed text, and clear indication of additions/deletions, making it difficult for SA4 to assess normative impact.

[Editorial] “Configuration Phase … over ADC” and “via MF” are repeated without clarifying interfaces (reference points) and message names; the call flow would benefit from a diagram or step numbering tied to concrete protocol exchanges rather than abstract actions.