TDoc: S4-260182

[Technical] The adaptive procedure introduces “request for updatable model via MF” (step 11) and “UE requests model update via MF” (step 15) but does not define any new IMS DC/MF protocol messages, parameters, or mapping to existing procedures, so the flow is not implementable or verifiable against TS 26.114/26.927-derived mechanisms.

[Technical] The contribution is inconsistent on the transport for model delivery/updates: basic flow says delivery via BDC or ADC (and “from DC AS or DCAR via DCSF”), while adaptive steps 12/17 say “download via MF”; it must be clarified whether MF is in the media path, control-only, or simply an endpoint label, otherwise it conflicts with the IMS DC architecture where bDC/ADC are the defined data channels.

[Technical] “Lower precision model” and “bit-incremental model update” are referenced, but no normative constraints are given on model compatibility (e.g., base model ID, update applicability, versioning, delta format, rollback), risking interoperability failures when applying updates (step 18).

[Technical] The proposal claims “inference can continue while model updates are applied,” but does not specify atomicity/synchronization requirements (e.g., when the new model becomes active, how to avoid mixed-parameter inference, buffering, or dual-model execution), which is critical for real-time IMS sessions.

[Technical] “Selection can be performed by UE, MF, or DC AS” is too open-ended without a defined decision procedure and signaling of the selected variant; this creates ambiguous authority and potential mismatch between what is requested, delivered, and executed (especially with two sources: DCAR vs DC-AS).

[Technical] Dual-source delivery (DCAR via DCSF vs DC-AS) lacks rules for precedence, consistency, and trust (e.g., how UE validates that an update from DCAR matches the base model from DC-AS), which is essential for security and correctness.

[Technical] The flow mixes UE1/UE2 roles but does not clearly state which UE performs inference and which endpoints receive model delivery; step 8 (“UE2 side DC procedures”) is particularly unclear and could contradict the stated “UE-centric inference” objective.

[Technical] The initial steps mention “UE1 registers to IMS with AI/ML capability indication” but no capability container, registration mechanism, or reference to an existing IMS/SDP/DC capability exchange is provided; without this, DCSF filtering and app list creation (step 5/6) is underspecified.

[Technical] The proposal does not address session continuity and reselection interactions already mentioned from S4aR260014 (task reselection during session) with adaptive updates—e.g., what happens to pending updates when task/model changes mid-session.

[Technical] Large model handling is explicitly FFS in the referenced editor’s note, yet adaptive delivery is motivated by startup latency; without at least a baseline for chunking/resume, partial delivery, or caching, the proposed procedure does not resolve the core latency problem in realistic model sizes.

[Editorial] The contribution uses inconsistent terminology and acronyms (MF, DC-AS, DC AS, DCAR, DCSF, bDC/BDC, ADC, DCMTSI client) without a definitions section or consistent casing, making it hard to align with existing spec terms.

[Editorial] Step numbering is inconsistent (basic flow includes step “0” and adaptive has “12a/12b, 16a/16b”), and references to “Figure X.X-1 / X.Y-2” are placeholders; for a spec contribution/CR, the exact clause/figure numbers and stable step numbering are needed.

[Editorial] The document cites TR 26.927 and TR 26.847 for concepts but does not identify the target normative specification and exact clauses to be added/modified (e.g., TS 26.114), which is necessary to assess consistency and avoid duplicating or contradicting existing normative text.