[Technical] The core premise in §2.2 (downloading a 100 GB model within 500–1000 ms) is not a realistic or relevant requirement for UE-side inferencing; the call flow should instead assume pre-provisioned/on-device models or background download over minutes/hours, otherwise the derived “800 Gbps” conclusion is a strawman that will derail the discussion.

[Technical] §2.1 cites TR 26.927 Table 6.6.2-1 (~40 MB) but then jumps to “public models 100+ GB” without mapping to the IMS/AIML use cases under discussion; the contribution needs to distinguish between (i) UE inference models intended for mobile deployment and (ii) data-center class generative models, otherwise the “required action” to define supported sizes is ungrounded.

[Technical] The text conflates “real-time request-response latency” with “model transfer time” (§2.2); in most architectures the model download is not on the critical path of a single inference transaction, so QoS/latency requirements should be split into (a) inference transaction latency and (b) model acquisition/update latency.

[Technical] Requesting SA2 to “update 5QI specifications” (§2.2) is premature and underspecified: the contribution does not identify whether the model transfer is best treated as GBR/non-GBR, what packet delay budget/jitter/loss are needed, or whether existing 5QIs (e.g., for TCP-based data) are insufficient; without concrete QoS characteristics, SA2 cannot act.

[Technical] §2.4’s protocol critique is internally inconsistent: proposing RTP for “large, quick data downloads” is atypical and ignores reliability, congestion control, and content integrity needs; if the issue is TCP behavior, the more relevant comparison is HTTP/2 vs HTTP/3 (QUIC) and/or segmented download with application-layer pacing rather than RTP.

[Technical] The claim that QUIC “has bindings to 5G XRM framework for improved QoS support” (§2.4) is vague and risks being incorrect/misleading in 3GPP terms; if the intent is to leverage 5G QoS (5QI/ARP/reflective QoS) or ATSSS, the contribution should reference the specific 3GPP mechanisms and how they apply to QUIC flows.

[Technical] §2.3 cites “2–20% compression ratios” from TR 26.927 but does not clarify whether this refers to bitrate reduction, model size reduction, or accuracy trade-offs; without specifying the compression target and acceptable quality loss, the conclusion “still infeasible” is not technically supported.

[Technical] The “No UE capabilities for NN codec support have been defined” point (§2.3) is valid, but the required action is incomplete: it should propose where UE capability signaling would live (e.g., NAS/IMS/UE capability exchange) and what minimum interoperability baseline is assumed if NNC is optional.

[Technical] §2.5 asserts the call flow “indicates model download for every request,” but does not quote the exact steps 12–16 behavior; if the original flow already implies model reuse or versioning, this criticism may be inaccurate—please pinpoint the exact normative/diagram text that mandates per-request download.

[Technical] The proposed “scope limitation” to exclude “complex VLM/LLM” (§3.1) is not actionable without objective criteria (parameter count, model size on disk, compute class, or use-case categories); otherwise it becomes a subjective exclusion that is hard to standardize.

[Technical] The contribution focuses almost entirely on downlink throughput but omits other critical feasibility constraints for UE inferencing (compute, memory footprint, thermal/power, storage, and model integrity/attestation); these are central to whether UE-side inferencing is viable and should be at least acknowledged if the goal is “network, QoS and UE considerations.”

[Editorial] Several “Required Action(s)” are phrased as open-ended requests (“need to be defined”, “clarify correct protocol usage”) without proposing concrete spec text, assumptions, or a target spec/TR clause; as written it reads more like a discussion note than a contribution ready to drive a CR.

[Editorial] Terminology is inconsistent/unclear (e.g., “client/UE side inferencing”, “client-side inferencing”, “UE-based AI inferencing”, “AIML/IMS”) and should be aligned with the agreed WI terminology and the referenced flow (S4aR260004a) to avoid ambiguity about the architecture being critiqued.

[Technical] The contribution still assigns AI/ML inference execution to the MF (“MF manages media flows… executes inference tasks”), but in SA2/TS 23.228 the MF role and its capabilities for AI/ML execution are not clearly standardized; you need to align the execution entity with the agreed IMS DC architecture (e.g., DC AS vs other function) and avoid introducing compute semantics for MF without normative backing.

[Technical] The call flow mixes BbDC to MF and AaDC to DC AS while also stating “Task control messages exchanged over AaDC,” yet UPDATE is sent “over ADC” and may be forwarded by MF; the spec impact is unclear unless you precisely define which DC (BbDC vs AaDC) carries which control messages and whether MF is a DC endpoint or only a relay.

[Technical] “Split inference” is claimed as supported, but no concrete procedure is provided for partitioning, synchronization, or model/component distribution between UE and network (e.g., how intermediate representations are transported, how latency/jitter is handled, and how the split point is negotiated), making the split option currently non-actionable.

[Technical] The UPDATE procedure introduces “start time (when to apply new parameters)” but there is no definition of the time base (RTP timestamp, NTP, IMS time, or relative time), nor how both UE and network ensure consistent switchover, which is critical to avoid media glitches and inconsistent translation states.

[Technical] The task control messages define input/output using SDP mid, but mid identifies an m-line, not a specific direction/source in multi-party or mixer scenarios; for conferencing/add/remove participants you likely need additional identifiers (SSRC, RID, participant identity, or DC application-level stream IDs) and rules for multiple simultaneous inputs/outputs.

[Technical] The document says multiple RTP streams are identified by “comma-separated mid values,” which is not aligned with typical JSON typing and lacks constraints (ordering, uniqueness, mapping to codecs); you should define an array structure and normative mapping to SDP offer/answer and subsequent re-INVITE/UPDATE procedures.

[Technical] The UPDATE use case “new UE added to call” implies new media descriptions and potentially new mid values, but the procedure does not specify the required SIP/SDP signaling (re-INVITE/UPDATE) and how task update sequencing relates to SDP completion (race conditions between task update and new m-line establishment).

[Technical] The contribution states “UE1 registers to IMS with AI/ML capability indication,” but does not specify the mechanism (feature tags, IMS media feature tags, SIP header, or 3GPP-defined capability exchange); without a concrete method it risks conflicting with existing IMS capability negotiation procedures.

[Technical] The response codes are shown as HTTP-like (“200 OK”) inside JSON messages; unless the DC protocol explicitly reuses HTTP semantics, you should define a 3GPP-specific result code space or map to existing DC/IMS error handling to avoid ambiguity and inconsistent implementations.

[Technical] Security and authorization are not addressed for downloading models and updating tasks (e.g., ensuring only authorized UEs can request model delivery, integrity of models, privacy of media sent for inference, and policy controls based on subscription list filtering), which is essential given the introduction of AI model distribution and media offload.

[Technical] Step 23 “Remote UE (UE2) informed when task updates impact it” is underspecified: it does not define whether UE2 is informed via SIP/SDP, DC messaging, or application signaling, nor what UE2 must do (e.g., render changes, accept new media, consent), leaving interoperability gaps.

[Editorial] The document references “TR 26.927 and TS 23.228 Annex AC” but does not provide exact clause numbers for the proposed modifications; for a contribution intended to update specs, you should cite the precise sections/figures being replaced and provide proposed normative text or updated call-flow diagrams.

[Editorial] Terminology is inconsistent: “ADC,” “AaDC,” “Application Data Channel,” and “BbDC” are used interchangeably in places; you should normalize terms and abbreviations and ensure they match the definitions in TS 23.228/related DC specs.

[Editorial] The message format is described as “JSON-like syntax” with URN type values, but no formal schema, field cardinality, optionality, or extensibility rules are given; even at TR level, a consistent pseudo-schema would reduce ambiguity and prevent incompatible interpretations.

[Technical] The CR is largely non-actionable as a normative change: “most technical content is marked with Editor’s Notes” and multiple placeholders (AC.4.2/AC.4.3) mean TS 26.114 would gain an annex that cannot be implemented or verified, which is not appropriate for a Category B CR.

[Technical] The proposed call flow in AC.4.1 relies on entities/procedures (MF, DCSF, DCAR, DC AS, BDC/ADC) “per TS 23.228” without ensuring those entities and interfaces are actually defined for IMS MTSI in the referenced specs; TS 26.114 cannot normatively introduce new core network functions and HTTP-based procedures without tight alignment to SA2/CT.

[Technical] Step 11/13 introduces “ADC: AI Model Selection Request/Response” signaling, but TS 26.114 does not define a new application-layer signaling protocol on ADC; the CR must specify whether this is SIP/SDP, MSRP, HTTP, or a new payload format, and how it is negotiated and secured.

[Technical] The flow mixes “application download” and “model download” via MF as an intermediary (steps 6–9, 12–13) without clarifying whether MF is acting as a proxy/cache, whether this is allowed by IMS architecture, and how content integrity, authorization, and accounting are handled end-to-end.

[Technical] Security and trust are missing: there is no normative requirement for model signing, integrity verification, provenance, or authorization (UE trusting MF/DCSF/DCAR), which is critical when downloading executable models and “AI applications” into the terminal.

[Technical] The CR does not define how AI/ML capabilities are negotiated within MTSI session establishment (e.g., SDP attributes, feature tags, SIP option-tags), yet claims “negotiation and signaling (AC.8)”—without this, interoperability and backward compatibility with non-AI/ML UEs cannot be ensured.

[Technical] The relationship to existing MTSI media processing and data channel usage in TS 26.114 is unclear: the annex appears to introduce new “AI/ML assisted media processing” but does not specify how it interacts with existing codecs, RTP/RTCP, media handling, and data channel procedures already standardized.

[Technical] AC.4.1 is user-driven (“User selects app/tasks”) but TS 26.114 is a stage 3 protocol spec; the CR should define UE behavior and protocol triggers independent of UI assumptions, and specify machine-driven selection/updates for unattended operation.

[Technical] Large model handling is explicitly FFS, yet model size impacts transport choice, fragmentation, resumption, caching, and latency; without at least baseline requirements (chunking, range requests, resume, max sizes), the proposed BDC/ADC transport is incomplete.

[Technical] The CR introduces “AI/ML formats” (AC.6) and “intermediate data” but does not constrain formats (e.g., ONNX/TFLite) or define MIME types, encapsulation, versioning, and compatibility rules; this will lead to non-interoperable implementations.

[Technical] The end-to-end reference architecture (AC.3) is described as “potential updates” and “possible liaison requirements with SA2,” indicating architectural dependencies are unresolved; TS 26.114 should not proceed with normative annex text until SA2 architecture and responsibilities are agreed.

[Editorial] The annex is described as “comprehensive new normative annex,” but the presence of Editor’s Notes, placeholders, and FFS items contradicts “normative”; the CR should clearly separate informative background from normative requirements and remove unfinished notes before approval.

[Editorial] Terminology is inconsistent/undefined in the summary: “AI application,” “task manifest,” “AI feature tags,” “model URNs,” and “intermediate data” need precise definitions in clauses 3.1/3.3 and consistent use throughout AC.4–AC.9.

[Editorial] The step numbering and dual-path descriptions (e.g., 12a/12b, BDC vs ADC in steps 11 and 13) need clearer conditional logic (“shall/should/may” conditions) to avoid ambiguity about which transport and signaling are mandatory vs optional for compliance.

[Technical] The contribution asserts that “request/download of the application list” and “request/download of a selected application” are “already well-defined in TS 23.228”, but TS 23.228 explicitly says the details of providing/using the application list are not defined; you need to distinguish clearly between (a) transport anchoring and URL rewriting behavior vs (b) application-layer semantics (HTTP resources, formats, selection procedure), which are not fully specified.

[Technical] The “root URL replacement” description is oversimplified: TS 26.114 states the application is accessible at HTTP root “/” and that the authority/Host are ignored by the DCMTSI client, but the contribution doesn’t explain how MF should rewrite absolute URLs, relative paths, query strings, fragments, or non-GET methods—without this, “replacement URL” handling is ambiguous and may break real HTTP interactions.

[Technical] The document claims MF replaces the root URL “with the replacement URL received in step 8”, but in the earlier flow you describe DCSF providing it in steps 3–6 and IMS AS forwarding it in Nmf_MRM_Create; the step numbering and ownership of the URL parameter are inconsistent and could mislead normative behavior (which interface carries what, and when).

[Technical] Reuse for AIML_IMS-MED is proposed without checking applicability constraints from TS 26.114 (e.g., bootstrap DC uses HTTP subprotocol, stream ID < 1000, Host header handling); if AIML_IMS-MED needs different subprotocols, larger stream IDs, or non-HTTP payloads, the “reuse as-is” claim is not technically justified.

[Technical] The proposal “capability exchange negotiation between UE and MF should happen after selection and download of a DC application” conflicts with the stated DCSF policy/capability-based provisioning (“based on capabilities and choices”); if capability affects which application list entries are offered, it may need to occur before or during application list retrieval, not strictly after.

[Technical] The contribution treats “application list offered via MDC1 interface” as a single replacement URL per stream, but doesn’t address multi-stream bootstrap cases or multiple application lists (e.g., per service, per media component); the mapping between streamId and replacement URL needs to be explicit to avoid cross-stream confusion.

[Technical] Security and authorization implications of URL rewriting are not discussed: if MF rewrites requests to DCSF endpoints, the contribution should at least acknowledge how TLS/DTLS termination, origin policy, and access control are preserved (otherwise “reuse” may introduce new trust assumptions for AIML content delivery).

[Technical] The statement “Either UE may select applications from local or remote DCSF (subject to DCSF policy)” is presented as part of the “already specified” flow, but no concrete normative reference or condition is given; this is a potentially significant behavioral claim that should be backed by exact clause text or removed.

[Editorial] Several interface names/operations are used without consistent capitalization or exact naming (e.g., Nimsas_SessionEventControl_Notify, Nimsas_MediaControl_MediaInstruction, Nmf_MRM_Create); for a standards contribution, cite the exact service operation names and clause numbers to avoid misquoting.

[Editorial] The contribution mixes “MDC1 media endpoint address”, “DCSF media endpoint”, and “MDC1 interface” loosely; tighten terminology to match TS 23.228/29.176 data types (e.g., remoteMdc1Endpoint, Mdc1Info) so it’s clear whether you mean IP:port, an HTTP URL, or an NF service endpoint.

[Editorial] The “Discussion” section claims “transport mechanism and URL replacement procedures are fully defined” but earlier you quote that details are not defined; rephrase to avoid overclaiming and explicitly scope what is defined (signalling parameters and MF forwarding behavior) vs what remains unspecified (content format, selection logic, HTTP resource structure).

[Editorial] The document reads like a consolidation note but ends with a “Proposal” that would require normative changes for AIML_IMS-MED; it should state explicitly whether you are requesting spec changes, a work item alignment, or merely recording that existing mechanisms could be reused.

[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.

[Technical] The proposal introduces a “partitioning list/submodel partitioning metadata” but does not define how the UE and DCAS ensure cryptographic binding between the selected model version and the partition definition (to prevent mismatched or tampered submodels/partitions), which is essential once execution is split across trust domains.

[Technical] Steps 10–16 add a negotiation/configuration phase but do not specify acceptance/rejection causes or fallback behavior (e.g., if DCAS rejects a partition, whether UE retries with another partition, falls back to device-only, or aborts), leaving the call flow incomplete for interoperable behavior.

[Technical] The flow makes partition selection “user-driven” (Step 13), but split-point selection is typically constrained by latency, uplink bandwidth, privacy policy, and DCAS load; without normative constraints or policy control (operator/AS policy vs. user preference), the procedure risks being non-deployable or inconsistent with operator-controlled IMS service behavior.

[Technical] The “execution endpoints supported by each task and subtask” and “operational characteristics” are introduced without clarifying whether these are static metadata, dynamically updated (e.g., DCAS load), or per-session; if dynamic, the document needs a mechanism for freshness/validity and update triggers.

[Technical] The proposal adds UE capability indication to the MF during BDC application list request, but it is unclear why MF (rather than DCAS or an AIML-specific function) is the correct termination point for split-inference capability negotiation; this risks misplacing AIML-specific logic into a generic media function and creating architectural inconsistency.

[Technical] The FFS “how device capabilities are sent to obtain an accurate list of models” is not a minor detail: capability exchange is foundational to Steps 10–12 (model/partition list derivation) and needs at least a baseline definition (capability categories, granularity, and privacy considerations) to avoid incompatible implementations.

[Technical] The partitioning metadata includes “input/output tensor characteristics,” but the call flow does not address how tensor data is transported over the data channel (format, compression, quantization, framing) nor how interoperability is ensured between UE and DCAS runtimes.

[Technical] Steps 17–18 state “Selected tasks/models and corresponding AI submodels are communicated to DCAS” while also saying UE downloads device-side submodels; it is ambiguous whether DCAS also downloads/hosts its submodels, whether they are pre-provisioned, or whether UE triggers DCAS-side model acquisition—this impacts feasibility and timing.

[Technical] The proposal does not address session continuity and reconfiguration (e.g., UE mobility, radio degradation, battery drop) where the split point may need to change mid-session; without a re-negotiation/update procedure, split inference will be brittle in real networks.

[Technical] No explicit handling is described for privacy/security constraints when tensors or intermediate features are sent to the network (which can leak sensitive information); the partitioning framework should at least indicate how privacy requirements influence allowable partitions.

[Editorial] The contribution summary references “revises previously agreed device inferencing call flow (S4aR260014)” but does not clearly identify the exact spec clause(s), figure numbers, or step numbers being changed, making it hard to review consistency and impacts.

[Editorial] Terminology is inconsistent/undefined (MF, BDC, DC AS/DCAS, “application request message,” “task manifest,” “partitioning list”); the CR should align with existing 3GPP term definitions and use one consistent acronym per entity.

[Editorial] Several steps use non-normative phrasing (“may be based on…”, “potentially expressed as…”) for core interoperability aspects (task manifest, selection criteria), which should be tightened or explicitly scoped as informative to avoid ambiguous requirements.

[Technical] The contribution introduces a “transport-protocol-independent” container while simultaneously mapping each negotiation message to HTTP GET/POST/RESPONSE in Table A4.2-1; the spec needs a clear normative statement on whether HTTP is mandatory, optional, or merely an example, otherwise implementers will diverge.

[Technical] Several metadata fields are not operationally well-defined for interoperability (e.g., minimumTaskInferenceAccuracy, taskAccuracy, outputAccuracy, energyEstimation): there is no mandated metric definition, dataset/benchmark reference, confidence interval, or measurement conditions, so endpoints cannot compare values consistently.

[Technical] The static/dynamic capability split is sensible, but the document does not define update triggers, validity timers, or how dynamic values (e.g., currentComputeLoad, acceleratorAvailability, batteryLevel) are refreshed and correlated to a specific decision point, risking stale negotiation decisions.

[Technical] Units and ranges are inconsistent or missing across key parameters (e.g., flopsProcessingCapabilities, macOpProcessingCapabilities, availableMemorySize, currentComputeLoad); without explicit units (GFLOPS vs FLOPS, bytes vs MB, load as % vs normalized), negotiation logic is ambiguous.

[Technical] The proposal returns “application binary data” and “model binary data” in responses but does not specify integrity/authenticity mechanisms (hash, signature), versioning, or licensing/authorization checks; this is a major gap given executable/model distribution security requirements.

[Technical] URN-based identifiers (applicationIdentifier, modelIdentifier, task identifiers) are introduced without defining the URN namespace, registration/ownership model, and collision handling; interoperability across vendors depends on a normative identifier scheme.

[Technical] The message type list in A.4.4 includes CANDIDATE_MODELS_REQUEST/RESPONSE, while the summary table uses CANDIDATE_MODELS_LIST_REQUEST/RESPONSE; this naming mismatch will cause implementers to treat them as different procedures unless aligned.

[Technical] The call-flow alignment claim (“agreed call flow from S4aR260014”) is not backed by explicit sequencing rules (e.g., whether discovery is mandatory before application request, whether model selection can be repeated, error handling); the procedure needs normative state machine/ordering constraints.

[Technical] sessionId is described as “multimedia session identifier” but the document does not specify which 3GPP identifier it maps to (IMS dialog identifiers, SDP session, MSRP/RTC data channel association, etc.), making correlation across signaling planes unclear.

[Technical] sendingAtTime uses “wall clock timestamp” without defining format (e.g., RFC 3339), time base, and clock synchronization assumptions; if used for ordering/latency, it will be unreliable across endpoints.

[Technical] The endpoint capability fields overlap and may be contradictory (accelerationSupported boolean vs supportedEngines including NPU/GPU, plus acceleratorAvailability dynamic); rules are needed to resolve inconsistencies and define what “acceleration” precisely means.

[Technical] Model I/O descriptors (inputType, inputShape, outputType, outputShape) lack a normative schema (tensor layout, channel order, sample rate for audio, language tags for ASR/TTS/translation), so two endpoints may “match” a model but still be incompatible.

[Editorial] The document mixes “AIML_IMS-MED”, “AI/ML-based media services”, and “local inferencing call flows” terminology without a stable definition section; consistent naming and abbreviations are needed to avoid scope confusion.

[Editorial] Several parameter names are verbose or inconsistent in style (maximumTaskInferenceLatency vs targetInferenceLatency, modelDataType values like Uint8 vs typical uint8), and the JSON examples should be aligned to a single naming convention and enumerated value casing.

[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.

[Technical] The contribution mixes two transport paradigms without a clear normative mapping: messages are described as HTTP GET/POST in Table A4.2-1 while Section A.4.5 defines a generic “AI metadata exchange over data channels”; the spec needs an explicit statement whether these are alternative transports, layered (HTTP payload carried in data channel), or separate procedures, otherwise interoperability will break.

[Technical] Message taxonomy appears internally inconsistent: Table A.4.2 introduces AI_SPLIT_INFERENCE_CONFIGURATION_REQUEST and SPLIT_INFERENCE_CONFIGURATION_AI_RESPONSE, while Section A.4.5 lists SPLIT_INFERENCE_CONFIGURATION_REQUEST (without “AI_”) and no matching ..._AI_RESPONSE; naming and pairing must be aligned and uniquely defined.

[Technical] There is functional overlap/ambiguity between AI_MODEL_SELECTION_REQUEST/RESPONSE and AI_SPLIT_INFERENCE_CONFIGURATION_REQUEST/RESPONSE (both “carry URN(s) of selected models/submodels” and return binaries/metadata); the procedure needs a clear separation of purpose (e.g., selection vs partitioning vs download) and state machine/ordering constraints.

[Technical] The proposal introduces AI_SERVER_CONFIGURATION_REQUEST/RESPONSE in Section A.4.5 but it is not described in the negotiation summary table nor in the earlier metadata sections; either add the missing procedure/metadata or remove it to avoid undefined behavior.

[Technical] The “type” field is defined as a number (message subtype identifier) but no registry/enum values are provided for the listed message types; without normative numeric assignments and extensibility rules, independent implementations cannot interoperate.

[Technical] sessionId is described as “multimedia session identifier” but there is no definition of which IMS identifier is used (SIP Call-ID, dialog identifiers, MSRP session, etc.) and how it binds to the data channel/HTTP exchange; this is critical for correlating negotiation to the correct media session.

[Technical] The endpoint execution location values (UE, SERVER, EDGE, CLOUD, CUSTOM) are not tied to any 3GPP-defined entity (e.g., UE, IMS AS, MEC, DN) and “CUSTOM” is non-interoperable; the spec should either reference 3GPP architecture terms or define discovery/addressing and trust implications.

[Technical] Partitioning metadata is underspecified for correctness: submodelType enumerates HEAD, INTERMEDIATE1, INTERMEDIATE2, TAIL, which hard-limits the number of partitions and cannot represent arbitrary N-way splits; it should be an ordered list with an index/graph structure rather than fixed labels.

[Technical] Tensor metadata is inconsistent: subModelDataType uses Uint8, Float32, Float16 while tensorType is described as integer, float32, float16; the data type vocabulary must be unified and should include signedness/bitwidth and quantization parameters if Uint8 is allowed.

[Technical] outputAccuracy as a single “trained accuracy percentage” is not meaningful across tasks/datasets and is not comparable between partitionings; if kept, it needs a defined metric, evaluation dataset identifier, and conditions, otherwise it risks misleading selection logic.

[Technical] Capability metadata separation into static/dynamic is reasonable, but the proposal lacks update/refresh rules (e.g., when dynamic capabilities are reported, validity timers, thresholds) and lacks units for key fields (compute capacity, memory, load), making negotiation non-deterministic.

[Technical] The messages that “return selected application binary and metadata” / “return selected models/submodels binary and metadata” do not specify integrity/authenticity mechanisms (hash, signature, provenance) or versioning; for executable model binaries this is a security and lifecycle gap.

[Editorial] Several identifiers are inconsistent in casing and spelling (sendingAtTime vs typical sentAtTime; submodelsPartitioningIdentifier vs submodelPartitioningIdentifier; subModelDataType camel-case mismatch), which will cause implementer confusion in JSON schema.

[Editorial] The document references “Table 5” and “Table 6” in Section A.4.5 while earlier it introduces “Table A4.2-1”; table numbering should be consistent with the annex/section numbering conventions of the target specification.

[Editorial] The contribution repeatedly uses “HTTP RESPONSE” as a message name rather than a defined response message type; if the intent is to define application-layer messages, the response should be named consistently (e.g., ..._RESPONSE) and HTTP status/error handling should be specified separately.

[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.

[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.

[Technical] The contribution asserts “split inferencing, approved and mandated in 5G” without citing the specific WI/TS/TR scope and normative home; this is risky because S4 needs a clear mapping to the target spec (e.g., TS 26.xxx vs TR 26.927) and whether the format is normative or informative.

[Technical] The proposal introduces an intermediate-data TLV format but does not define how it is carried over 5GS user plane (PDU session type, RTP/UDP/IP, QUIC, etc.) nor how the receiver identifies framing boundaries; without a transport binding and packetization rules, interoperability is not achievable.

[Technical] The “AIPS lifetime ends when number of tensors or tensor shape changes” conflicts with the earlier claim that tensor characteristics are dynamic and must be conveyed; if shapes can change frequently, the design needs an explicit per-access-unit signaling mechanism (or delta updates) rather than an AIPS that becomes invalid on common runtime events.

[Technical] The document mixes “split_point_id” and “partition_id” and states the partition identifier is “previously split-point identifier” but does not define uniqueness scope, negotiation procedure, or collision handling across sessions/models; this will cause ambiguity when multiple partition configurations exist or when reusing IDs across models.

[Technical] The AIPS field set is incomplete for correct tensor interpretation: it lacks explicit endianness, alignment, tensor layout/order (e.g., NCHW/NHWC), quantization parameters (scale/zero-point), and any indication whether dtype refers to pre- or post-decompression representation.

[Technical] Compression signaling is underspecified: compression_profile_id is referenced but no registry, negotiation, parameter carriage, or error behavior is defined, and it is unclear whether compression applies per tensor, per TLV unit, or per byte range (especially for “multiple tensors encapsulation”).

[Technical] The “tensor length (optional)” is problematic because length is essential for parsing concatenated tensors and for skipping unknown tensors; if omitted, the receiver must derive it from shape×dtype, which fails when compression is used or when padding/strides exist.

[Technical] The TLV Type space (1=AIPS, 2=Intermediate data, 3–255 undefined) lacks versioning and extensibility rules (e.g., how to ignore unknown types, forward compatibility, critical vs non-critical TLVs), which is typically required for long-lived 3GPP formats.

[Technical] The “multiple tensors encapsulation” is not fully specified: it does not define ordering, repetition rules, whether tensor IDs may repeat, and how to associate each tensor payload with its metadata when shapes can change dynamically.

[Technical] The proposal does not address integrity/confidentiality or robustness aspects (e.g., protection against malformed TLVs, maximum sizes, resource exhaustion), which is important given user-plane parsing of potentially large tensors.

[Editorial] Several clause/table references are inconsistent or placeholder-like (e.g., “Clause X.X.24.2”, “Table X.X.13-1”, “Table X.X.24-1”), making it impossible to verify consistency with the rest of the specification or TR 26.927 without a concrete target document structure.

[Editorial] The text alternates between “partitioning”, “partition”, and “split point” and between “AIPS identifier” and ai_parameter_set_id; terminology should be normalized and aligned with existing 3GPP AI/ML vocabulary to avoid interpretive differences.

[Editorial] The contribution claims the format is “derived from Clause 6.8” and adds a field from “Clause 6.6” of TR 26.927, but it does not clearly enumerate deltas versus the TR baseline (field-by-field) nor justify why the TR structure is insufficient, weakening the rationale for standardization.

[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.

[Technical] The claim that “WebAssembly is secure” is not substantiated for the IMS DC threat model: the contribution lists generic browser sandbox properties but does not address concrete risks relevant to codec execution (e.g., side channels, Spectre-class leaks, JIT/Wasm engine vulnerabilities, supply-chain integrity of modules, and DoS via CPU/memory exhaustion), nor does it propose mitigations or normative constraints.

[Technical] The “3GPP-specific considerations” assume trusted sources and authorization by DCSF/DC-AR, but the document does not map these assumptions to any existing SA4/CT/SA security requirements or specify how integrity/authenticity of the Wasm binary and associated model bitstreams are ensured end-to-end (signing, hashing, secure transport, revocation).

[Technical] Performance/latency conclusions are not reproducible: the contribution provides no actual measured numbers (decode time, end-to-end latency, throughput points, thread counts) and no methodology details (number of runs, variance, warm-up, caching disabled, CPU governor), so “substantial latency reductions” cannot be evaluated.

[Technical] The demo uses a single high-end laptop CPU and a Chromium-based browser; without results on representative UE-class hardware (mobile SoCs, thermal throttling, limited cores) the conclusions about practical IMS DC deployment latency are weak.

[Technical] The decoder “does not support tools using temporal prediction,” which may be a significant functional gap versus NNC Edition 2 usage scenarios; the contribution does not clarify whether the tested bitstream avoids those tools by construction, nor whether this limitation affects interoperability expectations in SA4.

[Technical] Parallelizing CABAC “across NNR data units” and scheduling “largest first” may change buffering and memory pressure; the document does not quantify peak memory, queueing behavior, or whether this strategy can starve smaller units and delay first-usable partial model availability (important for progressive use cases).

[Technical] The progressive mode description (“decode fully received NNR data units”) omits dependency handling: it is unclear whether any cross-unit dependencies exist in the bitstream/tools used (e.g., shared contexts, parameter optimization side information), and if so how correctness is preserved when decoding out of original order.

[Technical] The download simulation (“delays availability of each tensor/NNR data unit”) is not equivalent to real network behavior (TCP slow start, jitter, HOL blocking, retransmissions); without modeling these effects, end-to-end latency claims under “realistic download conditions” are overstated.

[Technical] The encoder settings include “QP −27” and specific DeepCABAC options, but the contribution does not state the exact NNC profile/constraints used (and whether they align with TR 26.847 assumptions), making it hard to judge whether the demo reflects typical operating points.

[Technical] The security argument based on “broad industry deployment” is not a security proof and is weak for 3GPP decision-making; the contribution should instead reference concrete security analyses, CVE handling expectations, and required sandboxing policies (e.g., no shared memory, no SIMD, no threads) if those are intended constraints.

[Editorial] The document references “previous telco” concerns and “reported” decoding times/latency but does not cite the specific meeting, contribution numbers, or clauses, making the context and addressed issues hard to trace.

[Editorial] Several statements are absolute or vague (“substantial latency reductions,” “realistic download conditions,” “WebAssembly is secure”) and should be qualified with data, scope, and assumptions to avoid being read as normative conclusions.

[Editorial] The “Precedent” reference to TR 26.858 clauses 5.3.3 and 6 is not summarized; without stating what TR 26.858 actually concluded about Wasm (and under what constraints), the precedent claim is difficult to assess.

[Technical] The contribution does not identify any concrete IMS/3GPP specification touchpoints (e.g., which TS 24.229/24.229 annex, TS 26.114/26.247, MSRP/SIP body usage, or media framework) where NNC would be normatively introduced, so the proposal is not actionable as a 3GPP change.

[Technical] It is unclear whether the AI/ML “model delivery” is intended as IMS media, IMS file transfer, or HTTP-based download outside IMS; without clarifying the transport and session model, requirements like random access, packetization, and error resilience cannot be mapped to IMS procedures.

[Technical] The proposal advocates ISO/IEC 15938-17 “as a representation format” but does not define MIME type(s), SIP/SDP signaling (e.g., m= line vs application/ body), or capability negotiation needed for interoperability in IMS.

[Technical] Claims of “robustness and error resilience through packetization” are not tied to any existing IMS bearer (RTP/RTCP, MSRP, or SIP MESSAGE) and no fragmentation/reassembly rules, loss recovery, or integrity mechanisms are specified for NNR_NDU/NNR_MPS carriage.

[Technical] The stated compression ratios “0.1% to 20% of original size with transparent performance” are presented without defining baselines (FP32? FP16? already-quantized?), model classes, or acceptable accuracy loss criteria, making the performance claim non-verifiable for 3GPP normative adoption.

[Technical] Incremental update signaling (PUT structure, parent hash fields, base_model_id) is described, but there is no end-to-end procedure for versioning, dependency resolution, rollback, or mismatch handling between UE/edge/server—key for “multidirectional co-learning” scenarios.

[Technical] Security and trust are not addressed: model authenticity, integrity, and provenance (especially for “third-party model providers”) are critical in IMS, yet no mapping is given to IMS security (e.g., SIP identity, TLS, object signing) nor guidance on hash usage beyond parent linkage.

[Technical] The “Performance Indicator” feature (accuracy metrics in NNR_MPS/NNR_LPS) raises interoperability and policy concerns (metric definitions, dataset identifiers, comparability, and potential misrepresentation), but the contribution does not define how metrics are standardized or validated in 3GPP context.

[Technical] The document lists “encapsulation flexibility” for ONNX/PyTorch/TensorFlow, but does not specify which topology storage formats are permitted in 3GPP profiles, risking fragmentation where different vendors choose different encapsulated formats and still fail interoperability.

[Technical] WASM/browser-side decoding is not obviously relevant to IMS normative scope and may conflict with UE implementation assumptions; if the intent is WebRTC/IMS interworking, the contribution should explicitly relate this to existing SA4 web real-time communication specifications.

[Technical] Several syntax element names (e.g., topology_storage_format, topology_compression_format, nnr_decompressed_data_format) are presented as if stable normative identifiers, but no profile constraints (allowed values, mandatory/optional tools like PRE, row-skip, DeepCABAC settings) are proposed to ensure decoder interoperability.

[Editorial] The contribution repeatedly cites “validated in SA4 and MPEG evaluations” without referencing specific meeting documents, reports, or objective test conditions; add precise references or remove the implication of SA4 endorsement.

[Editorial] The summary mixes high-level motivation with deep syntax annex material (NNR_NDU fields, CABAC flags) without explaining why these details are needed for the 3GPP decision; it would be clearer to separate “what 3GPP needs to specify” from “how NNC works internally.”

[Editorial] Terminology is inconsistent with 3GPP style: “IMS-based AI/ML services” and “AI/ML data transport in IMS” are vague—define whether this is an IMS multimedia service, an IMS enabler, or an application-layer service using IMS signaling only.

[Technical] Mandating that all DCMTSI clients supporting AI/ML model download “shall support NNC decoding” (ISO/IEC 15938-17) is a major interoperability and implementation-impacting requirement, but the contribution does not justify why decoding is mandatory for all such clients rather than being negotiated/capability-based (e.g., via SDP/IMS signaling) or optional with fallback.

[Technical] The proposal hard-codes specific NNC tool flags/parameters (e.g., compressed_parameter_types = NNR_CPT_LS | NNR_CPT_BN, shift_idx_minus_1_present_flag = 1, row_skip_enabled_flag = 1, etc.) without specifying how these are signaled on the wire and agreed between endpoints; without a negotiation mechanism, “shall support” toolsets can still fail interoperability if the sender chooses different settings.

[Technical] The statement “NNC Edition 2 support is enabled by setting general_profile_idc = 1” is risky as written: it conflates edition selection with profile signaling and does not clarify whether general_profile_idc semantics in ISO/IEC 15938-17 actually map “1” to “Edition 2 baseline” (and whether other constraints/fields must also be set), which could lead to incorrect normative behavior.

[Technical] The “either dq_flag = 1 OR codebook_present_flag = 1” requirement is underspecified: it is unclear whether both may be present, whether one is mandatory, and what the receiver must support if the sender uses the other option—this can create non-interoperable subsets unless the spec defines a single mandatory-to-implement mode or explicit capability exchange.

[Technical] For incremental updates, requiring scan_order > 0 for “parallel decoding support” is not technically grounded in the summary and may be incorrect/overconstraining; scan order values are typically normative enumerations with defined meanings, so “> 0” is not a valid constraint unless the referenced standard defines it that way.

[Technical] The incremental profile enables multiple advanced tools simultaneously (nnr_pre_flag, hist_dep_sig_prob_enabled_flag, temporal_context_modeling_flag), but the contribution does not address decoder complexity, memory, and latency impacts—critical for IMS endpoints—and provides no rationale for making these mandatory rather than optional.

[Technical] The update-tree requirements (mps_parent_signalling_enabled_flag = 1, parent_node_id_present_flag = 1) assume a specific incremental update structure, but the contribution does not define how this maps to AIML_IMS-MED’s model update semantics (e.g., identification of layers/parameters, consistency checks, rollback), risking a mismatch between NNC syntax and the 3GPP application model.

[Technical] The proposal defines two “profiles” but does not specify profile identifiers, compatibility rules, or receiver behavior when encountering unsupported tools; without explicit profile signaling and fallback rules, endpoints cannot reliably interoperate across “baseline” vs “advanced” modes.

[Technical] Adding ISO/IEC 15938-17:2024 Ed.2 as a normative reference may be problematic for 3GPP availability and IPR/patent policy considerations, and the contribution does not discuss whether referencing a 2024 edition is acceptable for the targeted release timeline or whether an earlier stable edition should be referenced.

[Editorial] The contribution reads like a high-level summary but claims “changes to be incorporated into the common base CR” without providing actual CR-style delta text (affected clauses, exact normative wording, and change marks), making it impossible to verify consistency with existing AIML_IMS-MED specification structure.

[Editorial] Several terms are introduced without definition in the AIML_IMS-MED context (e.g., “DCMTSI clients”, “AIML_IMS-MED”, “incremental model download”), and the document does not cite the exact 3GPP spec/section where these entities and procedures are defined.

[Editorial] The parameter names are presented as if they are normative fields (nnr_compressed_data_unit_payload_type, NNC_PT_BLOCK, etc.) but the contribution does not quote the exact ISO/IEC 15938-17 syntax names/casing nor provide a mapping table, increasing the risk of transcription errors and ambiguity in normative text.

[Technical] The contribution proposes adopting ISO/IEC 15938-17 (NNC) “for IMS services” but does not identify any concrete IMS enabler, interface, or 3GPP spec target (e.g., SIP/SDP offer/answer, MSRP, HTTP over Ut, MMTel, RCS, or a new IMS media type), so it is impossible to assess feasibility or normative impact.

[Technical] There is no definition of how NNC payloads would be negotiated (capability exchange, codec parameters, versioning, profiles/levels) in IMS; without SDP attributes or equivalent negotiation rules, interoperability and fallback behavior are undefined.

[Technical] The document mixes “compression and transport” claims, but NNC is a coding format; it does not specify the IMS transport mapping (RTP payload format, MSRP chunking, HTTP object transfer, SIP MESSAGE, etc.), nor packetization/fragmentation rules needed to realize the cited “robustness” and “random access” benefits.

[Technical] Security/privacy implications are not addressed: model updates and co-learning can expose proprietary IP and user data; IMS requires clear handling for integrity, confidentiality, authorization, and potential end-to-end vs hop-by-hop protection, none of which is scoped or mapped to IMS security mechanisms.

[Technical] The “incremental updates” and PUT/MPS/LPS mechanisms are described, but there is no 3GPP-level procedure for synchronization, loss recovery, ordering, or consistency (e.g., what happens if a UE misses an update, how base_model_id is managed across sessions, or how to prevent applying incompatible deltas).

[Technical] The claim of “transparent performance” at 0.1%–20% size is presented without constraints (model types, tasks, quantization settings, acceptable accuracy loss, compute cost), which is too broad for 3GPP requirements and risks overpromising in normative text.

[Technical] UE constraints are discussed (storage/latency), but decoder complexity, memory footprint, and power impact of DeepCABAC/NNC (including random access entry points and dependent quantization state) are not quantified or bounded, which is critical for UE implementability in IMS contexts.

[Technical] The contribution lists encapsulation for PyTorch/ONNX/NNEF/TensorFlow, but does not specify how 3GPP would ensure deterministic execution compatibility (operator sets, versions, endianness, numeric formats), so “interoperability through standardized data formats” is not substantiated at the system level.

[Technical] Error resilience statements (“configurable prioritization/error-protection through packetization; missing update detection”) are not tied to any IMS bearer/QoS mechanism or media transport behavior, so it is unclear how these features would actually be realized over typical IMS paths.

[Technical] No content-type / MIME registration, SIP/SDP media type identification, or IANA/3GPP registry impact is discussed; without a clear identification scheme, IMS entities cannot route, store, or apply policy to NNC objects.

[Editorial] The document reads as a technology overview rather than a 3GPP contribution with actionable change requests: it lacks proposed normative text, spec references, and explicit work item scope (which TS/TR to update and what exact additions are requested).

[Editorial] Several acronyms and structures (e.g., NNR_NDU, NNR_MPS, NNR_LPS, PUT) are introduced without aligning terminology to existing 3GPP AI/ML service discussions in SA4, making it hard to map to current 3GPP architecture and terminology.

[Editorial] The annex-level detail (flags, syntax elements like bit_offset_delta1, dq_state_list, etc.) is overly granular for SA4 decision-making unless accompanied by a clear mapping to 3GPP signaling/transport; it risks distracting from the missing system integration aspects.

[Editorial] The WASM decoder and “multi-fold latency reductions” are mentioned without citing test methodology, baseline, or conditions; as evidence for standardization, the performance claims need references or reproducible parameters.