TDoc: S4-260286

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