[Technical] The CR appears to add a “basketball game segment” example but does not state what new requirements/implications this example drives for Dynamic 3DGS (e.g., bitrate/latency bounds, segment duration, viewport-dependent delivery), so it risks being non-actionable narrative rather than a use-case clarification in TR 26.958 §5.4.

[Technical] The text mixes “real-time rendering on the UE” with “network-assisted rendering” and “partial delivery mechanisms” without clarifying the assumed functional split (decode vs render vs compose) and whether the example targets client-side rendering, edge rendering, or hybrid—this can conflict with the intended scope of §5.4.1 if not explicitly bounded.

[Technical] “Time-indexed sequence of 3D Gaussian splats” is underspecified: it is unclear whether this implies per-frame independent 3DGS, inter-frame prediction, or parameter updates/deltas; without that, the example cannot meaningfully inform delivery/decoding aspects that §5.4 is supposed to cover.

[Technical] The “allowed-view volume derived from original capture configuration” introduces a key constraint but does not define how it is represented/signalled to the UE (metadata? scene description? per-segment constraints), which is essential if the example is meant to support requirement derivation.

[Technical] The example claims “wide-area environments with complex background dynamics” and “fast-moving subjects” but does not discuss occlusions, motion blur, or temporal consistency artifacts specific to 3DGS; these are central technical challenges for dynamic sports scenes and should be acknowledged if the example is to be credible.

[Technical] The contribution states alignment with TR 26.928 “Use Case 3: Streaming of Immersive 6DoF (non-live/on-demand variant)” but does not explain the mapping (e.g., 6DoF navigation limits, viewport-adaptive streaming, segmenting model), risking inconsistency with the referenced use case framing.

[Technical] “UE receives successive temporal segments” is vague: it should clarify whether segments are GOP-like timed chunks, tiles/partitions, or layered representations, and whether “partial delivery” is temporal-only, spatial-only, or both.

[Technical] The scope says “pre-recorded dynamic 3DGS sequences” yet the sports example implies potentially long-form content; without stating assumptions on duration, storage, and buffering, it’s hard to reconcile with “real-time rendering” and any implied latency constraints.

[Technical] If the example is intended to support “traffic analysis requirements,” it should specify what traffic characteristics are being highlighted (e.g., peak vs average bitrate, burstiness due to viewpoint changes, uplink feedback frequency), otherwise the claim is unsubstantiated.

[Editorial] The CR references “Figure 5.1” but the summary does not indicate whether the figure is newly added/updated and properly captioned/numbered consistent with TR 26.958; figure insertion often breaks numbering and cross-references if not carefully integrated.

[Editorial] Terminology is inconsistent/ambiguous: “Dynamic 3DGS content,” “3DGS content sequences,” and “time-indexed sequence of 3D Gaussian splats” should be harmonized with existing definitions in TR 26.958 to avoid introducing parallel phrasing for the same concept.

[Editorial] The list of dynamic subjects in §5.4.1 (“performers… exhibitions… sport actions”) mixes nouns and activities; consider normalizing wording (e.g., “sports events” rather than “sport actions”) to match TR style and improve clarity.