TDoc: S4-260245

[Technical] The proposed “All-in-client” definition (“functionality primarily runs on the UE”) is too vague to be normative within a TR clause; it should explicitly scope which functions are assumed local (capture, 3DGS training/reconstruction, packaging, rendering) and which are out of scope (e.g., any server-side optimization, CDN delivery), otherwise it overlaps ambiguously with other configurations likely covered elsewhere in the report.

[Technical] “3DGS Model Generation on UE” is asserted without stating feasibility constraints or alternatives (e.g., on-device incremental training vs. conversion from prebuilt assets); given 3DGS training is compute/memory intensive, the workflow should at least acknowledge optionality, minimum capability assumptions, or fallback paths to avoid an unrealistic baseline.

[Technical] The “Packaging and Distribution” step introduces MMS as a distribution channel, which is atypical for large 3D assets and not aligned with 3GPP media delivery assumptions; if kept, it needs constraints (asset size limits, fragmentation, reliability) or should be generalized to “messaging/file transfer” without naming MMS.

[Technical] The workflow omits any explicit handling of codec/format signaling and compatibility (e.g., how a UE knows the 3DGS asset format/version, animation stream format, and required rendering features), which is critical for interoperability even in a study report.

[Technical] “Asset Reception and Storage” mentions “storage in GPU memory” as if it were persistent storage; GPU memory is transient and device/OS-managed, so the workflow should distinguish persistent storage vs. runtime upload/caching to GPU.

[Technical] The “Network only used for distribution/asset transfer” and “No network interaction during playback” statements are too absolute and conflict with common needs like progressive download, adaptive LOD streaming, updates, rights/license checks, or telemetry; this should be phrased as a typical/optional characteristic rather than a defining property.

[Technical] Rendering step lists LOD selection inputs (preferences, capabilities, pose, resolution) but does not mention performance targets (frame rate, thermal constraints) or how LOD relates to 3DGS-specific parameters (e.g., Gaussian count, SH degree, splat size), making the workflow incomplete for 3DGS-specific study value.

[Technical] The “Animation Stream Generation” and “time-aligned animation streams” are referenced, but the workflow does not define the synchronization mechanism (timestamps, clock source, alignment to render frames) or whether animation is applied to Gaussians, camera, or avatar rig—key to understanding feasibility.

[Technical] The contribution references clause 5.4 for “dynamic 3DGS scene content via file delivery,” but does not clarify whether dynamic sequences are precomputed 3DGS frames, parameter deltas, or hybrid representations; without this, “dynamic” is underspecified and may contradict other parts of the TR.

[Editorial] Clause numbering “New Clause 9.1” is presented without confirming existing Clause 9 structure in TR 26.958 v0.1.1; the CR should ensure numbering, titles, and cross-references are consistent with the current document skeleton.

[Editorial] Multiple bullets say “Referenced to clause 5.2/5.5” but do not specify which subclauses or exact concepts are being reused; tighter references (e.g., 5.2.x) would improve traceability and reduce ambiguity.

[Editorial] The “Configuration Characteristics” section reads like conclusions rather than a workflow description and repeats “dependent on UE capabilities” without adding measurable or comparative insight; it would be stronger to relate characteristics to the steps (capture/training/rendering) and to other configurations in the TR.