TDoc: S4-260189

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