TDoc: S4-260247

[Technical] The proposed “Client-Server configuration” is underspecified as a workflow because it does not define any normative interfaces or information exchange (e.g., pose/viewport signaling, tile/LOD request/response, timing model), so it is unclear how interoperability would be achieved beyond a conceptual split.

[Technical] “Packaging and Distribution … via MMS, OTT messaging, Download services” is not technically credible for interactive navigation and on-demand tile/LOD delivery due to latency, payload size, and session control constraints; the clause should either constrain these to non-interactive/offline use or align with appropriate 3GPP delivery frameworks (e.g., DASH/CMAF, 5GMS, MBS) already used for streaming.

[Technical] The text mixes responsibilities inconsistently: server “Adaptive Selection” chooses tiles/LODs based on “UE device capabilities,” while the client also “select[s] Gaussians based on LODs”; the split of decision-making (server vs client) and the resulting data sent (selected tiles vs multi-LOD representations) needs to be made consistent.

[Technical] “Optional partial or full rendering support” implies server-side rendering, but no rendering output format, transport, latency budget, or synchronization with local rendering is described; without defining whether this is video streaming, point/gaussian streaming, or hybrid composition, the workflow is incomplete.

[Technical] “Dynamic Content Generation … region-based parts … for adaptive delivery” introduces new concepts (dynamic 3DGS, region-based parts) without defining how regions/tiles are partitioned, addressed, versioned, or updated over time, which is essential for any client-server adaptive scheme.

[Technical] The clause claims “Enhanced scalability … leverages theoretically infinite network resources,” which is misleading and ignores bottlenecks (uplink pose signaling, per-user state, edge compute limits); scalability should be qualified with realistic assumptions and constraints.

[Technical] “Network Usage: Content generation, Rendering (full or partial), Distribution” is too broad and conflates offline authoring with real-time session operations; the workflow should separate pre-processing (content generation) from runtime adaptation/streaming to avoid architectural ambiguity.

[Technical] The client “Storage … in local memory or GPU memory” is implementation-specific and not appropriate even for a TR workflow description unless tied to a requirement/assumption (e.g., caching model, persistence, eviction), otherwise it adds noise without technical value.

[Technical] Referencing “UE device capabilities and characteristics (camera pose, display resolution, etc.)” conflates static capabilities with dynamic state; if pose is used for adaptation, the clause should explicitly define update rate, coordinate system, and privacy/security considerations for transmitting pose to the network.

[Technical] The workflow lists “3D Avatars using time-aligned animation streams (clause 5.5)” but does not explain how avatar streams synchronize with 3DGS scene updates/tiles (timestamps, clock model, buffering), risking inconsistency with any existing timing assumptions in clause 5.

[Editorial] The CR summary repeatedly cites “clause 5.2/5.3/5.4/5.5” but does not indicate whether those clauses already define the needed primitives for client-server operation; add explicit cross-references to the exact subclauses and confirm no contradictions with clause 9.1 terminology.

[Editorial] Terminology is inconsistent and sometimes vague (“network server,” “server (network),” “OTT messaging,” “download services,” “partial-delivery”); the clause should align with 3GPP-defined terms (e.g., AF/AS, 5GMS Application Server, file delivery over HTTP) and define any new terms.

[Editorial] The “Characteristics” section reads like marketing statements rather than a technical study outcome; it should be rewritten to state measurable factors (latency contributors, bandwidth drivers, compute split options) and remove unsubstantiated claims.