TDoc: S4-260186

[Technical] The proposal to add many normative references to academic papers and commercial products is not appropriate for a TR study item; these should be informative references (and even then, only those actually cited/needed), otherwise the TR becomes dependent on unstable, non-standard, and potentially inaccessible sources.

[Technical] Several listed “2024–2025” references (e.g., VGGT, AnySplat, GS‑LRM, iLRM, MetaSapiens, HTGS, sort-free variants) are not clearly identified with stable bibliographic details (authors/venue/version/URL), making them unsuitable as normative references and hard to verify even as informative references.

[Technical] Adding TR 21.905 as a normative reference is questionable unless the new clause introduces terms that explicitly rely on 21.905 definitions; otherwise it is unnecessary and inconsistent with typical TR referencing practice.

[Technical] The new Clause 11.3 content reads like a market survey of specific vendors (KIRI, Luma, Polycam, etc.) rather than technical study material; 3GPP TRs generally avoid endorsing or cataloging commercial offerings unless there is a clear methodological purpose and neutral selection criteria.

[Technical] Claims about product pipelines and limitations (e.g., “SfM + Gaussian optimization”, “non-deterministic cloud processing”, “no manual SH order adjustment”, “no export capability as of Feb 2026”) are not backed by citations and may quickly become outdated, risking incorrect statements in the TR.

[Technical] The document introduces file formats (.ply, .spz) and parameter concepts (SH order, pruning, “raw Gaussian parameters”) without defining them or linking them to the TR’s terminology/model; this creates ambiguity and weak traceability to the study objectives.

[Technical] The inclusion of SSIM, alpha compositing, and GPU sorting as normative references is not justified by the described Clause 11.3 (which is product overview); if the TR needs these topics, they should appear in technical clauses with clear normative dependency and consistent scope.

[Technical] If the intent is to inform standardization, the clause should extract common functional capabilities and gaps (capture metadata, pose formats, splat parameter sets, compression/streaming needs, rendering profiles) rather than listing per-product features; as written it does not translate into requirements or candidate work items.

[Technical] The “processing location (Cloud/Local)” categorization is oversimplified and may be misleading for hybrid pipelines (on-device pose + cloud optimize, progressive refinement, etc.); the TR should use more precise pipeline stage breakdown if included.

[Editorial] The contribution summary suggests “addition of normative references and a new clause,” but does not indicate exact target TR clause numbers/titles beyond “11.3” nor provide the exact proposed text; reviewers cannot assess consistency with surrounding clauses or numbering.

[Editorial] Product descriptions use inconsistent technical depth and terminology (e.g., “3D Unscented (3DGUT) transform,” “Background Modulation for black segments”) without explanation; this reads like vendor marketing terms and is not aligned with 3GPP neutral style.

[Editorial] The table fields (“export format options”) should be harmonized with defined terms (e.g., “Gaussian splat interchange format”) and should avoid listing proprietary/unclear formats (e.g., .spz) without a reference and short description.

[Editorial] Time-sensitive statements (“as of February 2026”) are inappropriate for a TR unless clearly framed as an observation at the time of study with a citation; otherwise it will age poorly and require frequent maintenance.