[Technical] The contribution introduces new entities and flows (DCSF via MF, DCAR, DCMTSI client selecting toolchains) without anchoring them to existing normative architecture and reference points in the target spec; it is unclear which functions are already defined vs newly assumed, risking inconsistency with IMS DC framework definitions.

[Technical] The manifest’s baseUrl URI template (baseurl/$taskId$/$version$/$framework$/$subtask$/$variant$/model.$format$) hard-codes path semantics and variables that are not defined elsewhere (e.g., $framework$, $variant$, $format$) and conflicts with also having per-model url; the spec needs one authoritative download addressing scheme and clear precedence rules.

[Technical] The proposal mixes “task version” and “model version/variant” but does not define compatibility rules (e.g., which model versions satisfy a given task version), nor how the UE/MF selects among multiple models for the same task/subtask.

[Technical] capabilityIndex is used at task, subtask, and model levels but is explicitly FFS; without a defined capability taxonomy, comparison method, and negotiation procedure, the manifest cannot be used interoperably and will lead to vendor-specific interpretation.

[Technical] Execution placement fields are inconsistent and under-specified: task-level executionCandidate (UE or MF) vs subtask-level executionTarget/executionFallback; there is no defined resolution algorithm when task and subtask preferences conflict, nor how split inference is represented end-to-end.

[Technical] The routing model (route-to, from) references IDs across task/subtask scopes (e.g., “subtaskOutputId or taskInputId”) but does not define namespace rules, uniqueness constraints, or validation, making it ambiguous and error-prone for complex graphs.

[Technical] pipe-type semantics (“0=first available, 1=wait for all”) are too simplistic for multi-input synchronization (ordering, buffering, timeouts, partial availability) and lack normative behavior, which is critical for real-time media/DC processing.

[Technical] Latency is specified as “maximum latency requirement (milliseconds)” per model, but there is no definition of what latency measures (inference only vs end-to-end including transport), nor how it is enforced/used in selection across UE vs MF execution.

[Technical] Accuracy is left FFS (“metrics/value/direction”) yet is included as a selection parameter; without a standardized metric definition per task type (e.g., WER, BLEU, MOS proxy), it cannot be compared across models and undermines interoperability.

[Technical] contextSize is described as “typically in tokens,” which is model/framework-specific; the manifest needs explicit units and encoding assumptions (tokens vs bytes vs samples) and how the sender/receiver ensures compliance.

[Technical] Media typing fields (media-type) are introduced for inputs/outputs but there is no linkage to existing 3GPP media type registries/usages (e.g., MIME types, codec parameters, SDP mapping), nor how DC payload formats are negotiated.

[Editorial] Field naming is inconsistent (e.g., media-type vs typical JSON mediaType, route-to vs routeTo, pipe-type), and the document does not state the serialization format (JSON/YAML/XML) or schema conventions, which is necessary for implementable normative text.

[Editorial] Several key terms are introduced without definition or reference (e.g., “AI/ML DC application,” “task,” “subtask,” “toolchains/execution environments”), and the editor’s notes suggest reliance on TS/TR 26.927 but no concrete normative references or alignment text is provided.

[Editorial] The contribution claims it “merges metadata elements” from prior documents, but does not provide a change log, rationale for conflicts resolved, or explicit mapping to the target clause structure (“All New Text” only), making review and integration into the base CR difficult.