[Technical] The proposal does not define what constitutes a “dynamic 3DGS sequence” in spec terms (e.g., per-frame independent splat sets vs. temporally predicted updates/deltas), which is essential to avoid ambiguity in TR 26.958 Section 5.4 when later mapping to codec, packaging, and streaming implications.

[Technical] “UE receives successive temporal segments” is underspecified: the contribution should clarify whether segments are CMAF chunks, file segments, or generic time slices, and how segment boundaries relate to random access, buffering, and timeline continuity for dynamic 3DGS.

[Technical] The text implies “spatial structure coherence maintained across frames” but provides no mechanism/assumption (e.g., stable splat IDs, correspondence, motion fields); without this, the example risks implying requirements on representation/decoder behavior that may not be intended in a use-case TR.

[Technical] The “constrained navigation volume derived from original capture setup” needs a concrete definition (e.g., 6DoF bounding volume, camera manifold, near/far limits) and how it is signaled/communicated to the client; otherwise it is not actionable for system design discussions in TR 26.958.

[Technical] The contribution mentions “potential network assistance (partial delivery or network-assisted rendering)” but does not state whether this is in-scope for the example; this can conflict with the stated “real-time rendering on mobile devices” and should be clearly framed as optional/non-normative to avoid scope creep.

[Technical] Alignment to TR 26.928 “Use Case 3: Streaming of Immersive 6DoF (non-live/on-demand variant)” is asserted but not demonstrated; the example should explicitly map the dancer scenario’s navigation, timing, and delivery assumptions to the corresponding TR 26.928 attributes to ensure consistency.

[Technical] The example mixes “on-demand streaming” and “file download” without clarifying whether the same timing/navigation behavior is expected in both modes (e.g., progressive download vs. true streaming), which affects buffering and interactivity assumptions.

[Technical] The statement “visual consistency ensured while avoiding out-of-distribution views” is more of a reconstruction/training limitation than a delivery use-case attribute; it should be reframed to avoid implying normative constraints on user navigation beyond what the system can signal/enforce.

[Technical] The example references “real-time rendering preserving temporal continuity and rhythm” but does not identify the key performance/QoE parameters (target frame rate, motion-to-photon latency tolerance, acceptable stutter) that make the use case meaningful for SA4 evaluation.

[Editorial] The contribution uses “UE” without expansion (Unreal Engine) and introduces it as if it were a normative component; TR text should either generalize to “client renderer” or define UE as an example implementation.

[Editorial] Terminology alternates between “dynamic 3DGS,” “time-varying 3DGS,” and “time-indexed sequence of 3D Gaussian splats” without a consistent term; Section 5.4 should pick one primary term and define it once.

[Editorial] Figure “5.x” is referenced but not anchored to an actual figure number/caption and the surrounding text does not state what the figure concretely illustrates (timeline, navigation volume, segmenting), reducing its value as an illustrative example.

[Editorial] The “In scope / Out of scope” bullets partially repeat general TR boundaries (e.g., “capture processes”) and could be tightened to only what is specific to this dancer example, otherwise it reads like a generic disclaimer rather than a targeted use-case addition.