TDoc: S4-260088

[Technical] Replacing the generic “3D tile” definition with “3DGS tile” risks breaking consistency with existing 3GPP usage (and external ecosystems like 3D Tiles) and may remove a useful generic concept; the CR should either retain “3D tile” as a generic term and add “3DGS tile” as a specialization, or clearly scope the term change to TR 26.958 only and update all dependent text accordingly.

[Technical] The new “3DGS tile” definition (“spatial volume…containing a set of 3D Gaussians for a given LOD”) implicitly makes LOD part of the tile identity, but later requirements talk about associating “different LODs with spatial volumes”; this is internally inconsistent unless the spec defines whether a tile is (volume, LOD) or volume-only with multiple LOD representations.

[Technical] Clause X.2 requirements are too high-level to be actionable (“method to identify…”, “method to identify and access…”) and do not translate into measurable encapsulation/delivery format requirements (e.g., required metadata fields, indexing granularity, dependency signaling, random access points, or constraints on bounding volumes).

[Technical] The “frustum-based access” requirement introduces frustum parameters (FoV, viewing distance) but does not define how these map to requested spatial volumes/LOD selection (server-driven vs client-driven, deterministic mapping, hysteresis), risking non-interoperable implementations.

[Technical] The use case claim that the selection process “maintains constant number of displayed splats for quality consistency” is not generally valid across devices and scenes and reads like a specific renderer policy; it should be framed as an example strategy or removed from normative-style assumptions.

[Technical] The proposal mentions “signaling for spatial and LOD indices and dependencies” but does not specify what dependencies mean for 3DGS (e.g., inter-LOD prediction, progressive refinement, shared codebooks) and therefore cannot guide encapsulation design or compression choices.

[Technical] Clause X.4 “LOD and partial delivery support…without compression optimization dependency” is unclear and potentially contradictory: if compression is not designed for partial delivery, random access may be infeasible; the CR should clarify whether this is a requirement on the delivery format (independent access units) versus on the compression tool.

[Technical] The CR introduces “bounding volume” but does not constrain its type (AABB/OBB/sphere), coordinate system, or precision, which are essential for interoperable spatial indexing and frustum intersection across UE/server.

[Technical] The navigation constraints discussion (“allowed navigation volume”, collision detection) is introduced but not tied to any encapsulation/delivery requirement; if it impacts delivery (e.g., prefetch region, validity of tiles), it needs explicit linkage or should remain purely informative.

[Editorial] The change description says “replaces generic ‘3D tiles’ references with ‘3D Gaussians’” in Clause 5.3, but “tiles” and “gaussians” are not interchangeable concepts; the edits should consistently distinguish between the primitive (Gaussian) and the packaging/indexing unit (tile/set).

[Editorial] The new clause numbering (“Clause X”) and subclauses (X.1–X.4) need proper integration into TR 26.958 structure (actual clause number, references from Clause 5.3 working assumptions), otherwise the document becomes hard to navigate and cross-reference.

[Editorial] Multiple editor’s notes (“need for additional technical details”, workflow documentation, parameter characterization) indicate the text is not yet stable; the CR should either add the missing minimum content or clearly mark these as future work items in a dedicated “open issues” section rather than inline notes.