TDoc: S4-260200

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