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