[Technical] The flow makes the UE the primary decision point for split placement (“UE identifies which tasks/AI models to execute locally vs. in network” in steps 10–13), but it does not define how network policy, subscription restrictions, privacy constraints, or charging constraints can override UE choice; this risks contradicting typical IMS/service control principles and needs explicit arbitration rules and rejection/alternative handling.

[Technical] “MF replaces root URL with replacement URL and forwards to DCSF” (step 4) is underspecified and potentially unsafe: there is no normative mechanism described for URL rewriting, origin validation, or integrity protection, and it is unclear how this aligns with TS 23.228 procedures for BDC/DC application routing without creating an open redirect or content substitution risk.

[Technical] The document relies on “HTTP over BDC” for application list and download (steps 3–9) but does not state whether TLS is mandatory, how server authentication is done (MF vs DCSF vs DC AS), and how end-to-end integrity of the application package/task manifest is ensured; without this, the call flow is incomplete for a security-sensitive “download code + model” procedure.

[Technical] The “AI models distributed to both UE and network” (steps 14–16) lacks any versioning, compatibility, or hash/signature binding between (a) the downloaded application, (b) the task manifest, and (c) the model artifacts; this omission can lead to mismatched model/app execution and makes rollback/update behavior undefined.

[Technical] Step 14 (“MF verifies requirements… MF reallocation if requirements not met”) is not consistent with typical IMS functional splits unless the MF has explicit resource management hooks; the contribution should specify what “requirements” are (compute, GPU, latency, locality), how they are signaled, and what the UE sees when reallocation fails (error codes, alternative MF, or fallback to UE-only).

[Technical] The flow introduces “execution endpoints supported by each task/subtask” (step 10) but does not define how endpoint selection maps to actual IMS entities (MF vs DC AS vs other) and how the UE discovers reachable endpoints; this is critical for interoperability and should be tied to explicit identifiers and procedures in the referenced clauses.

[Technical] “Application Data Channel established between UE and DC AS per TS 23.228, clause AC.7.2” (step 12) is inserted after application download via MF, but the call flow does not explain why the UE needs a separate channel to DC AS if MF remains the mediator for model/configuration; the roles of MF vs DC AS vs DCSF in control vs data plane are ambiguous.

[Technical] The SDP re-negotiation step (17) is too vague: it claims to “associate media/data/intermediate data flows … with corresponding tasks” but does not specify the SDP attributes, identifiers, or mapping rules needed to bind a given m-line/data channel to a task/subtask, nor how this interacts with existing IMS media negotiation and BDC/DC constructs.

[Technical] Dynamic task reselection (step 23) “returns to step 12” but ignores the need to re-negotiate media/data flows, update model placement, and potentially revoke/replace already delivered models; without explicit state handling, this can cause inconsistent task-to-flow bindings and resource leaks.

[Technical] The model retrieval alternatives (step 15a via DCAR/DCSF vs 15b via DC AS) are presented without selection criteria, authorization checks, or consistency requirements; the spec text would need to define when each path is allowed and how the UE can trust provenance regardless of source.

[Technical] The contribution assumes “user selects application” and “user selects AI task(s)” (steps 6 and 11), but does not address non-interactive/automated selection, accessibility, or policy-driven selection; for IMS service behavior, the UE behavior should not be purely UI-driven in normative flow.

[Editorial] References to “TS 23.228, clause AC.7.1/AC.7.2/AC.7” and “clause AC.4.3” are not verifiable as written because AC numbering appears to be document-internal; the contribution should cite stable clause numbers/titles or clearly state these are draft annex clauses in the CR baseline.

[Editorial] Terminology is inconsistent/unclear: “MF (Media Function)” is not a standard IMS functional entity name in TS 23.228, and “DC application,” “BDC,” “DCSF,” and “DCAR” are used without definitions in this summary; the call flow text should align naming with the spec’s defined entities and abbreviations.

[Editorial] Several steps mix normative behavior with descriptive language (“may,” “optional,” “identifies,” “presented”) without indicating which parts are mandatory for interoperability; the proposed clause should separate normative requirements (shall) from informative UI/implementation examples.