TDoc: S4-260198

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