[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.

[Technical] The contribution provides no visibility of the actual tracked changes/CR text (attachment not included), so SA4 cannot verify the claim that the changes are “purely editorial” or ensure no normative/technical meaning is altered in TR 26.958 v0.1.1.

[Technical] Because the specific edits are missing, it is impossible to assess whether any terminology changes (e.g., “shall/should/may”, “encoder/decoder”, “bitstream/syntax”) inadvertently change requirements or assumptions in the 3DGS study conclusions.

[Technical] The pCR does not identify the impacted clauses/subclauses, figures, or tables in TR 26.958, preventing consistency checks (e.g., definitions vs. usage, abbreviations, and cross-references) across the document.

[Technical] No change log or summary of edit categories is provided (e.g., reference updates, figure renumbering, equation fixes), which makes it hard to detect high-risk “editorial” edits such as corrected formulas, parameter names, or units that can materially affect interpretation.

[Technical] The contribution does not state whether any references (external specs, codecs, file formats, rendering pipelines) are updated; reference changes can have technical impact if versions, titles, or scopes shift.

[Editorial] The “Purpose: Agreement” is not supported by a concrete list of proposed corrections; for an agreement request, the document should at least enumerate the main edits or provide a diff excerpt in the main body.

[Editorial] The document labels itself “editorial” but does not include the standard CR-style fields that help review (affected version, affected clauses, detailed change description), reducing reviewability even for purely editorial maintenance.

[Editorial] The summary is generic (“clean-up modifications to improve clarity and consistency”) and does not justify urgency or priority; a brief rationale tied to specific recurring issues (typos, inconsistent naming, broken cross-references) would be expected.

[Editorial] The contribution should explicitly confirm that no figures/tables are added/removed and no numbering changes affect cross-references; renumbering is a common source of residual inconsistencies if not carefully managed.

[Editorial] As a pCR against TR 26.958 v0.1.1, it should clarify whether the edits are intended for the next draft (v0.1.2) and whether they align with SA4 drafting rules (e.g., consistent capitalization of defined terms, abbreviation introduction on first use).

[Technical] The contribution treats MPEG_gaussian_splatting_transport as a “nested extension inside KHR_gaussian_splatting.extensions”, but glTF extension governance/namespacing and validation rules typically require explicit registration and clear JSON schema; without normative references to the actual MPEG/Khronos drafts and their JSON structures, the proposed two-layer nesting risks being non-interoperable or even invalid in strict glTF validators.

[Technical] The stated graceful degradation (“render as standard point cloud using POSITION and COLOR_0”) is overstated: if splats rely on OPACITY/scale/rotation/SH for appearance, a POINTS fallback will not approximate splat rendering and may be misleading; TR text should qualify this as a debug/preview fallback and specify minimum attributes for meaningful fallback.

[Technical] The attribute list claims SCALE is in log-space and ROTATION is required, but no rationale or interoperability impact is discussed (e.g., quantization, decoding, coordinate conventions, handedness); TR 26.958 would need to capture these conventions precisely or risk implementers producing incompatible decoders.

[Technical] The SH signaling is described as SH_DEGREE_l_COEF_n with degree 0–3, but the mapping to actual coefficient counts, ordering, and whether coefficients are RGB triplets vs scalar per channel is unclear; the proposed “alternative layouts” (mpegProgressive/mpegPerChannel) need an unambiguous normative definition of coefficient indexing and reconstruction to avoid mismatched lighting.

[Technical] The proposal says DC term reconstructed from COLOR_0.rgb or carried via KHR SH_DEGREE_0_COEF_0, which creates two possible sources of truth; this needs a strict precedence rule and constraints (e.g., must match within tolerance) or decoders will diverge.

[Technical] “Progressive download” via progressive.stages listing accessor indices is underspecified: it doesn’t define whether stages are additive vs replacement, how partial accessors are fetched (byte ranges? separate buffers?), and how this maps to 5GMS segmenting; without a concrete packaging model, this is not actionable for 3GPP.

[Technical] The “timed delivery for 4D splats” relies on MPEG_accessor_timed and “circular buffers as defined by MPEG-I Scene Description,” but no details are provided on timestamping, random access, buffering constraints, or synchronization with audio/video; TR 26.958 would need at least a clear reference model for timing and synchronization to be useful.

[Technical] The document implies glTF is already “adopted” by TS 26.118/26.119, but does not specify which profiles/constraints (e.g., glTF 2.0 core vs specific extensions, binary GLB usage, buffer constraints); the integration argument is weak without aligning the proposed extensions to those existing 3GPP profiles.

[Technical] The comparison against PLY focuses on file size and missing features, but omits that PLY is often used with external metadata and that many pipelines use custom binary formats; the TR should avoid implying PLY is inherently non-extensible without clarifying it’s a container lacking standardized extension mechanisms.

[Technical] The contribution references SPZ and “Qualcomm’s L-GSC” as “being considered,” but does not clarify whether these are compatible with the proposed KHR/MPEG layering (e.g., as buffer compression extensions) or require different semantics; this weakens the recommendation of a single “primary format path.”

[Editorial] The document cites a “review draft published August 2025” for KHR_gaussian_splatting, which is future-dated relative to typical 3GPP timelines and raises credibility/versioning issues; the TR proposal should reference stable, publicly accessible draft identifiers/URLs and revision dates.

[Editorial] Proposed TR changes are described only at a high level (“include in Section 4 and new subsection under Section 11”) without concrete text, clause numbers, or proposed wording; for a 3GPP contribution, this makes it hard to assess exact impact and consistency with TR 26.958 structure and terminology.

[Editorial] Several terms are used without definition in 3GPP context (e.g., “canonical splat semantics,” “nested extensions mechanism,” “circular buffers”), and the contribution mixes Khronos/MPEG terminology with 3GPP service language; the TR additions should introduce a short glossary or align terms to existing TR 26.958 definitions.

[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.

[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.

[Technical] The proposal introduces a “static 3DGS representation” that “follows mesh deformation” at the receiver, but it does not specify a deformation model for Gaussians (e.g., per-Gaussian skinning weights, attachment to mesh surface, or a learned deformation field), making interoperability and feasibility unclear.

[Technical] “Spatial alignment” between the deformable mesh and 3DGS is asserted without defining the coordinate frames, calibration requirements, and how alignment is maintained under pose/expression changes; this is a core missing element for a normative scenario description.

[Technical] The transmission strategy lacks a concrete definition of what constitutes the “base avatar” payload versus “animation parameters” (parameter sets, units, ranges, timing model), so the claimed bandwidth/latency benefits cannot be evaluated or compared to other TR 26.958 scenarios.

[Technical] The document assumes SMPL‑X/FLAME parameter extraction in real time but does not address model licensing/IP, standardization suitability, or whether the scenario is intended to be model-agnostic; referencing specific proprietary/de facto models may conflict with 3GPP’s technology-neutral TR positioning.

[Technical] “3DGS updated at lower frequency than animation parameters” is underspecified: no triggers (appearance change, lighting change, topology change), update granularity (full set vs patches), or drift/consistency handling are described, which is critical for interactive bidirectional use.

[Technical] The receiver rendering is described as “composite” (mesh shading + 3DGS appearance) but no compositing rules are given (occlusion, depth ordering, alpha blending, shadowing), risking ambiguous visual results and undermining the scenario’s reproducibility.

[Technical] “Viewpoint adaptation supported within application-defined constraints” is too vague for a TR scenario; it should at least state whether free-viewpoint is expected, what baseline view range is assumed, and how artifacts are handled when extrapolating beyond capture coverage.

[Technical] The capture assumptions (“one or more cameras”) omit key constraints that drive feasibility (mono vs multi-view, depth availability, required resolution/frame rate, lighting), which are necessary to justify real-time parameter extraction and 3DGS generation.

[Technical] The proposal does not discuss error resilience and synchronization between the low-latency animation stream and the lower-rate 3DGS updates (e.g., timestamping, buffering, late/early update handling), which is essential for interactive communication scenarios.

[Technical] There is no discussion of how identity personalization is handled (e.g., per-user mesh/3DGS creation, enrollment time, update cadence), yet “base avatar transmitted once” implies a prior creation pipeline that should be captured in the scenario.

[Editorial] As a “Pseudo-CR,” the contribution summary does not indicate the exact TR 26.958 clause(s) to be updated, nor does it provide proposed text; without clause-level changes, SA4 cannot efficiently assess consistency with existing scenarios and terminology.

[Editorial] Several terms are introduced without definition or alignment to TR terminology (e.g., “deformation propagation,” “appearance contributions,” “application-defined constraints”), which should be tightened to avoid multiple interpretations across implementers.

[Editorial] The summary claims “efficient bandwidth utilization” but provides no qualitative comparison point (e.g., versus full 3DGS streaming or mesh+texture video), making the motivation read as aspirational rather than supported by scenario requirements.

[Technical] TR 26.958 is a Study Item TR; introducing “recommended for normative results” and “bit-exact rendering” language (CPU rasterizer) risks implying normative conformance where none exists—wording should be strictly informative and aligned with TR scope.

[Technical] The proposal relies on a fork of MPEG’s mpeg-gsc-metrics but provides no evidence of licensing/IPR compatibility, long-term maintenance plan, or reproducibility guarantees within 3GPP Git (e.g., pinned commit, dependency versions), which is critical if it becomes the de facto reference.

[Technical] “Bit-exact rendering regardless of hardware/OS” for a CPU rasterizer is a strong claim that is typically false without strict control of floating-point behavior, compiler flags, SIMD paths, and math libraries; the CR should specify determinism constraints and validation methodology.

[Technical] The metric definitions are underspecified: PSNR/MSE “in RGB and YUV with weighted averages” needs explicit color conversion (matrix, range, primaries, transfer), bit depth, rounding, and weighting (e.g., 4:2:0 vs 4:4:4, luma/chroma weights) to ensure cross-implementation comparability.

[Technical] “Object Masked (OM) metrics” based on “union of object masks” is ambiguous (union of source+decoded masks vs per-view mask generation); this choice materially affects scores and should be precisely defined, including how masks are generated from splats and how occlusions/background are handled.

[Technical] Viewpoint generation “from original PLY or explicit definition” is not sufficiently constrained; without a standardized view sampling strategy (count, distribution, near/far planes, FOV, resolution), results across companies will remain non-comparable despite a common tool.

[Technical] The --useCameraPosition approach depends on non-standard PLY header comments “typically inserted by tools”; without a defined schema/grammar and required fields (intrinsics/extrinsics conventions, coordinate system, units), interoperability will be poor and results non-repeatable.

[Technical] The CR mixes evaluation of “source vs decoded PLY” but does not clarify whether “source” is the original capture point cloud, the encoder input 3DGS, or a rendered reference; for codec evaluation, the reference should be the encoder input representation, not necessarily the original reconstruction.

[Technical] GPU rasterizer based on OpenGL is inherently non-deterministic across drivers and platforms; the CR should clearly restrict GPU mode to non-comparative visualization only and prevent accidental use in reported results (e.g., tool default, output labeling).

[Technical] Inclusion of IVSSIM is mentioned but not defined (version, parameters, viewing conditions); perceptual metrics often have multiple variants—without parameter locking, reported numbers will not be comparable.

[Technical] “Occupancy rate = valid pixel coverage percentage” needs a precise definition of “valid pixel” (alpha threshold? depth test? mask generation?) and whether it is computed on source, decoded, or combined; otherwise it can be gamed and misinterpreted.

[Editorial] Section numbering (new 6.4.1 and 12.4) may conflict with existing TR 26.958 structure; the CR should show exact insertion points and ensure consistent cross-references, rather than describing “new sections” abstractly.

[Editorial] The contribution reads like a “pseudo-CR” and tool user guide; it should clearly separate (a) metric definitions, (b) reference implementation description, and (c) example commands/outputs, and avoid promotional phrasing (“comprehensive”, “ensures exact”) unless substantiated.

[Editorial] Example results (Bartender, 1920×1080, PSNR/SSIM, 100% occupancy) are not traceable without specifying dataset version, rendering settings, and tool version/commit; examples should be labeled as illustrative and reproducible inputs should be referenced.

[Technical] The proposal mandates/assumes per-frame full back-to-front sorting “for proper alpha blending” without discussing established alternatives (e.g., approximate OIT, depth peeling limits, per-tile sorting, or k-buffer) or the correctness impact; TR text should not imply a single required method if multiple are viable for 3DGS.

[Technical] Claiming “CPU-based Radix Sort preferred over GPU Compute Shaders on mobile for thermal balance and driver compatibility” is not substantiated with comparative data or conditions (SoC/GPU family, driver versions, dataset sizes), and risks being misleading guidance in a TR.

[Technical] The renderer description mixes “tile-based rasterizer inspired by original 3DGS” with OpenGL ES vertex/fragment pipeline but does not specify where tile binning occurs (CPU vs GPU), how tiles map to screen space, or how overdraw/blending is handled; as written it is incomplete and hard to reproduce.

[Technical] Stating “Gaussian attributes loaded into VRAM at startup” and “only sorted indices transferred CPU→GPU per frame” omits the memory footprint and bandwidth feasibility on mobile (e.g., FP32 covariance/color/SH for 485k points), and does not address what happens under memory pressure or when models exceed GPU memory.

[Technical] Use of “FP32 textures/buffers for precision” is presented as a design choice but the TR should discuss precision/performance trade-offs (FP16/packed formats/quantization) since FP32 is often a major bottleneck on mobile and may contradict the study’s “mobile feasibility” narrative.

[Technical] Benchmark methodology is under-specified: resolution, FOV, render target format, MSAA, vsync, fixed camera path, and whether AR pose updates are disabled are not clearly defined, making the FPS/power numbers non-comparable across implementations.

[Technical] “Thermal management API usage for consistent clock speeds” is vague and potentially incorrect for Android devices (many controls are advisory and OEM-specific); the TR should specify exact APIs, permissions, and how effectiveness was verified, otherwise results may not be reproducible.

[Technical] Power measurement via “Android Battery Manager API” is not sufficiently accurate/consistent across devices and often reports averaged or estimated values; the TR should either qualify the limitations strongly or recommend external power measurement for normative comparisons.

[Technical] The conclusion “GPU saturation occurs at ~150k points (87% load)” relies on “GPU %” metrics that are not defined (source tool, sampling interval, what 100% means); without a standardized measurement method, the saturation point is not defensible.

[Technical] The reported behavior “Beyond saturation, frame rate decreases linearly with point count” is an overreach given only a few data points and no confidence intervals; the TR should present it as an observed trend for this setup, not a general property.

[Technical] SH degree impact results show lower power at higher SH degree (e.g., 1.45W at degree 0 vs 0.99W at degree 3) while GPU remains “100%”; this is internally inconsistent and suggests measurement artifacts or uncontrolled variables that must be explained before drawing conclusions.

[Technical] Disabling “AR runtime” for benchmarking may invalidate the stated mobile player architecture use case (AR camera tracking + rendering); the TR should either benchmark both modes or clearly separate “renderer-only” performance from “end-to-end AR” performance.

[Editorial] The contribution is described as a “Pseudo-CR” against TR 26.958 v0.1.1 but does not provide actual CR-style change markup, exact clause text, or proposed insertions/deletions; reviewers cannot verify consistency with existing Section 12.4.x wording.

[Editorial] Several statements read like requirements (“critical,” “preferred,” “recommended <200k visible points”) but TRs should keep such guidance clearly non-normative and scoped (device class, resolution, quality targets), otherwise it may be misinterpreted as specification direction.

[Technical] The proposal introduces “capability reporting” and “negotiation modes” in TR 26.958 Clause 9.2 but does not define where this negotiation occurs (e.g., 5GMS AF/AS, application layer, DASH/HTTP, MIV/scene protocol), nor the message/parameter set, so the workflow is not implementable or assessable for interoperability.

[Technical] Several reported metrics are not well-defined or measurable in a consistent way across UEs (e.g., “maximum visible Gaussians at 30 fps”, “available GPU/CPU compute headroom”, “memory bandwidth”, “GPU rendering capacity”), risking non-comparable capability reports and unstable adaptation decisions.

[Technical] The “dynamic state” items (thermal status, battery level, throttling level) raise privacy/policy and platform-access issues; the text should clarify optionality, granularity, and whether these are exposed via standardized APIs, otherwise the workflow assumes capabilities many OSes do not reliably provide.

[Technical] The “rendering budget” concept is introduced but not normatively bounded (units, parameters, mapping to point budget/SH degree/LOD/bitrate), and it is unclear how it relates to existing 3GPP media adaptation constructs (e.g., representation selection, bitrate ladders), creating ambiguity and potential duplication.

[Technical] Server-centric mode claims the server can map “raw metrics to rendering budget” via lookup tables, but no guidance is provided on required inputs/outputs or stability (hysteresis, oscillation control), which is critical when dynamic metrics fluctuate (thermal/battery) and could cause rapid quality switching.

[Technical] Client-centric mode allows the UE to request “quantization levels, SH orders, point budget” but does not specify constraints/validation (e.g., server limits, content availability, security against abusive requests), nor how the server signals supported operating points back to the UE.

[Technical] The adaptation operations listed (pruning, LOD selection, SH degree reduction, “Direct Color components”) can change visual appearance and potentially break authoring intent; the text should address objective quality targets/metrics and whether these transformations are reversible or require precomputed assets.

[Technical] For dynamic 3DGS content (claimed alignment with Clause 5.4), the workflow omits latency and update-frequency considerations (e.g., incremental updates, delta coding, synchronization with pose/time), which are typically the dominant constraints for “dynamic” scenes.

[Technical] The proposal mentions “supported quantization/compression formats” but does not align them with any referenced 3GPP/ISO codec or payload format for 3DGS; without identifying candidate formats and signaling, the negotiation cannot be tied to actual delivery mechanisms.

[Technical] The UE “local adaptation” step (further pruning/merging) is underspecified and may invalidate server-side assumptions (e.g., bounding volumes, LOD selection, rate control), so the workflow should clarify whether UE-side changes are purely rendering-time culling or alter the delivered asset.

[Editorial] References to “TR 26.928 principles” are vague; the contribution should cite the exact clauses/principles being reused and ensure terminology matches (e.g., “capability exchange”, “adaptation”, “representation”) to avoid inconsistent wording across TRs.

[Editorial] The proposed new subclause structure (9.2.1/9.2.2/9.2.2.x) is described, but the summary does not indicate how it integrates with existing Clause 9.2 text (what is replaced vs. appended), risking duplication or contradictions with current workflows already in TR 26.958.

[Editorial] Example values like “SH degree (0–3)” and “30 fps” are presented without stating whether they are informative examples or requirements; the text should clearly mark them as non-normative to avoid accidental specification of fixed operating points.

[Editorial] Figures 2 and 3 are referenced but not described in enough detail to verify consistency (entities, interfaces, message directions); the contribution should ensure the figures use consistent naming with TR 26.958 architecture terms and clearly show negotiation signaling paths.

[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.

[Technical] The mapping assumes raw captured images/video are sent over MSE-4 / IMS DC data channels for SfM and training, but it does not address feasibility (uplink bitrate, latency tolerance, session duration) nor identify any 3GPP mechanisms for large-volume bulk upload vs conversational transport.

[Technical] The proposal treats “SfM and 3DGS training in MSE AS / DC-AS” as straightforward, but it does not specify where compute is anchored (edge vs central), how UE selects/steers to the compute instance, or how continuity is handled if the UE moves—key for Objective 3 (edge/cloud operations).

[Technical] For IMS DC, the contribution relies on DC-AS “not 3GPP-specified” while also placing core 3DGS processing there; this weakens the mapping because no normative service capabilities, QoS, security, or interop behavior can be referenced for the essential function.

[Technical] The IMS DC description mixes roles: MF is said to support rendering (per S4-251420) and also “handles transcoding,” but it is unclear how 3DGS-specific rendering (view synthesis) maps onto MF capabilities without defining media formats, processing primitives, or whether rendering is in MF vs DC-AS.

[Technical] The MSE mapping uses MSE-7 for camera access, but it does not clarify whether MSE-7 is intended to expose such device sensor/camera control for high-rate capture workflows, nor how capture synchronization/metadata (intrinsics/extrinsics, timestamps) needed for SfM is conveyed.

[Technical] Neither mapping identifies the 3DGS representation formats and transport encapsulation (e.g., how a trained 3DGS model or progressive updates are packaged, versioned, and delivered), making it hard to assess consistency with TS 26.501/26.510 media delivery assumptions.

[Technical] Security/privacy aspects are missing despite uploading potentially sensitive raw imagery to network compute; the contribution does not map authentication/authorization, consent, data retention, or encryption to MSE/IMS DC procedures and interfaces.

[Technical] The workflows omit any control-plane procedures for job orchestration (start/stop, progress, retries, partial results, failure handling) and do not state whether these are carried on MSE-5 / IMS DC application channel, which is essential for long-running training tasks.

[Technical] The IMS DC provisioning text (“Provisions and configures resources via NEF and DC4”) is unclear/possibly incorrect: NEF exposure is typically for northbound API exposure, but the specific API set and how it relates to DC4/DCSF control is not described, risking architectural inconsistency.

[Editorial] Several interface names appear with typos or inconsistent terminology (e.g., “ingest/egest” likely “ingest/egress”), which reduces clarity when referencing TR 26.857 interface definitions.

[Editorial] The contribution cites “draft TR 26.958v0.1.0” and multiple S4 references, but it does not pinpoint the exact clauses being mapped; adding clause-level references would make the mapping verifiable and align with study objective tracking.

[Editorial] The conclusion proposes to “develop mappings” but does not provide concrete proposed TR text, work item impact, or specific deliverable updates (e.g., which sections of TR 26.958/26.857/IMS DC annexes would be amended), limiting usefulness as a contribution beyond high-level discussion.

[Technical] The proposed Clause 6.3 text is largely qualitative and does not resolve the editor’s note intent (“scene complexity impacts on feasibility”) because it provides no measurable complexity metrics (e.g., Gaussian count ranges, per-Gaussian attribute sizes, update rates, target FPS/resolution) or any method to map “complexity drivers” to UE capability classes.

[Technical] “Number of Gaussians” is cited as a primary driver, but the contribution does not distinguish between active/visible Gaussians per frame vs total stored Gaussians, nor does it account for view-dependent culling/LOD—key to actual mobile rendering and decoding complexity.

[Technical] The “tracked / partially tracked / untracked” categorization is underspecified and risks being non-actionable: it does not define what constitutes an association (ID persistence? correspondence confidence? motion model?) or how partial tracking is signaled/quantified, making it hard to use consistently elsewhere in TR 26.958.

[Technical] Compression statements (e.g., “requires more frequent keyframes”, “reduces benefits of temporal prediction”) are plausible but incomplete without identifying which coding tools/architectures are assumed (e.g., inter-frame prediction of attributes, topology delta coding, entropy coding), so the conclusions may not generalize across candidate dynamic 3DGS codecs.

[Technical] The text implies decoding complexity scales with “intrinsic complexity and temporal variability” but does not separate encoder-side complexity (tracking, correspondence, optimization) from decoder-side complexity (parsing, reconstruction, rendering), which is critical for UE feasibility discussions in S4.

[Technical] “Magnitude of motion” and “topology changes” are listed as drivers, but there is no proposal for how to measure them (e.g., per-Gaussian displacement statistics, birth/death rates, attribute change rates), leaving the clause unable to support later normative requirements or comparative evaluations.

[Technical] The contribution discusses “session duration” constraints without clarifying whether this is due to thermal throttling, battery drain, memory pressure, or network bitrate; without tying to specific resource models, the statement is too vague to guide TR conclusions.

[Technical] The claim that original INRIA 3DGS has “frame-independent Gaussian attributes” and “static topology assumption” is not carefully framed for dynamic extensions—readers may interpret it as a spec limitation rather than a property of a particular academic method; this needs clearer scoping to avoid misleading conclusions about what 3GPP could standardize.

[Technical] The proposal introduces multiple FFS items (max scene complexity per UE category; comparison of tracked formats; coexistence of formats) but does not propose any evaluation plan, test conditions, or reporting parameters, which weakens its usefulness as TR text intended to close an editor’s note.

[Editorial] The contribution references “Clause 6.3 (Complexity) currently empty” but does not provide the exact draft text with placement, numbering (e.g., 6.3.1/6.3.X), or integration points with existing clauses/terminology in TR 26.958, increasing editor burden and risk of inconsistency.

[Editorial] Several terms are introduced without alignment to 3GPP style/definitions (e.g., “topology changes” for Gaussian sets, “temporal association”, “intrinsic complexity”), and should either be defined in a definitions clause or rephrased to match existing TR vocabulary.

[Editorial] The summary cites references [1]-[4] but does not indicate how they map to the proposed categories or complexity claims; the clause should explicitly tie each key assertion to a reference or mark it as an observation to avoid appearing unsubstantiated.

[Technical] The proposed clause 9.2.3 introduces continuous UE pose/FoV reporting but does not specify the transport/protocol binding (e.g., which 3GPP interface, message type, timing model), making the workflow non-actionable and potentially inconsistent with TR 26.958’s assumed delivery architecture.

[Technical] Referencing “metadata format adheres to TR 26.928” is too vague: TR 26.928 contains multiple XR metadata constructs, and the contribution does not identify the exact fields (pose, projection, frustum, timestamps) nor how they map to 3DGS delivery, risking incompatible implementations.

[Technical] The server-centric workflow claims the server “maintains control over rendering budget throughout session,” but it doesn’t define how budget enforcement is verified/updated when UE conditions change (thermal throttling, background load, network degradation), which is critical for mobile feasibility.

[Technical] Both workflows omit latency/jitter handling for 6DoF feedback (prediction, time synchronization, stale pose handling); without this, viewport-adaptive selection can cause visible popping and incorrect tile selection, especially over cellular RTT.

[Technical] The “tiled environments with LOD” approach does not define tile addressing, coordinate reference system, tile boundary handling, or LOD switching rules (hysteresis), which are necessary to avoid oscillation and seams when the user moves/rotates.

[Technical] The “unstructured scenes” approach lists pruning/merging but does not define objective metrics (error bounds, screen-space density targets) or constraints to preserve visual fidelity; this reads as an algorithm sketch rather than spec-quality workflow guidance.

[Technical] The contribution introduces parameters like “max point count” and “SH degree” but does not align them with any existing 3DGS representation constraints in TR 26.958 clause 5.4/9.2.2 (e.g., whether SH degree is mandatory/optional, per-point vs per-tile), risking internal inconsistency.

[Technical] The client-centric workflow lets the UE request “quantization” and other format parameters, but there is no negotiation/error handling if the server cannot satisfy the request (fallback modes, rejection, partial compliance), which is essential for interoperability.

[Technical] Step 8 “Local Adaptation” is underspecified and potentially contradicts the earlier “budget control” premise: if UE can further adapt, the spec should clarify what is allowed (dropping points, reducing SH) and how that interacts with negotiated constraints.

[Technical] The workflows do not address caching/prefetching strategies (e.g., near-future tiles along motion vector) or continuity requirements; for large-scale scenes, purely reactive frustum streaming will likely fail bandwidth/latency targets.

[Technical] Security/privacy implications of continuous pose streaming (user location/behavior leakage) are not mentioned; at minimum, the clause should note privacy considerations or reference relevant 3GPP security guidance.

[Editorial] The document is described as a “pseudo-CR” but the proposed changes are not presented with explicit CR-style change markup, making it hard to review exact normative text deltas and to ensure clause numbering (9.2.3.1–9.2.3.4, Figures 4–6) is consistent with the current TR 26.958 v0.1.1 structure.

[Editorial] Terminology is inconsistent: “UE,” “client,” and “mobile device” are used interchangeably, and “server” is not clearly distinguished from “application server/content server,” which can confuse the architecture assumed in clause 9.2.x.

[Editorial] Several claims are absolute without qualification (e.g., “simple capability negotiation alone is insufficient”); the text should either provide supporting rationale/conditions (e.g., scene scale thresholds) or soften to “may be insufficient” to match TR study-item style.

[Technical] The proposed “All-in-client” definition (“functionality primarily runs on the UE”) is too vague to be normative within a TR clause; it should explicitly scope which functions are assumed local (capture, 3DGS training/reconstruction, packaging, rendering) and which are out of scope (e.g., any server-side optimization, CDN delivery), otherwise it overlaps ambiguously with other configurations likely covered elsewhere in the report.

[Technical] “3DGS Model Generation on UE” is asserted without stating feasibility constraints or alternatives (e.g., on-device incremental training vs. conversion from prebuilt assets); given 3DGS training is compute/memory intensive, the workflow should at least acknowledge optionality, minimum capability assumptions, or fallback paths to avoid an unrealistic baseline.

[Technical] The “Packaging and Distribution” step introduces MMS as a distribution channel, which is atypical for large 3D assets and not aligned with 3GPP media delivery assumptions; if kept, it needs constraints (asset size limits, fragmentation, reliability) or should be generalized to “messaging/file transfer” without naming MMS.

[Technical] The workflow omits any explicit handling of codec/format signaling and compatibility (e.g., how a UE knows the 3DGS asset format/version, animation stream format, and required rendering features), which is critical for interoperability even in a study report.

[Technical] “Asset Reception and Storage” mentions “storage in GPU memory” as if it were persistent storage; GPU memory is transient and device/OS-managed, so the workflow should distinguish persistent storage vs. runtime upload/caching to GPU.

[Technical] The “Network only used for distribution/asset transfer” and “No network interaction during playback” statements are too absolute and conflict with common needs like progressive download, adaptive LOD streaming, updates, rights/license checks, or telemetry; this should be phrased as a typical/optional characteristic rather than a defining property.

[Technical] Rendering step lists LOD selection inputs (preferences, capabilities, pose, resolution) but does not mention performance targets (frame rate, thermal constraints) or how LOD relates to 3DGS-specific parameters (e.g., Gaussian count, SH degree, splat size), making the workflow incomplete for 3DGS-specific study value.

[Technical] The “Animation Stream Generation” and “time-aligned animation streams” are referenced, but the workflow does not define the synchronization mechanism (timestamps, clock source, alignment to render frames) or whether animation is applied to Gaussians, camera, or avatar rig—key to understanding feasibility.

[Technical] The contribution references clause 5.4 for “dynamic 3DGS scene content via file delivery,” but does not clarify whether dynamic sequences are precomputed 3DGS frames, parameter deltas, or hybrid representations; without this, “dynamic” is underspecified and may contradict other parts of the TR.

[Editorial] Clause numbering “New Clause 9.1” is presented without confirming existing Clause 9 structure in TR 26.958 v0.1.1; the CR should ensure numbering, titles, and cross-references are consistent with the current document skeleton.

[Editorial] Multiple bullets say “Referenced to clause 5.2/5.5” but do not specify which subclauses or exact concepts are being reused; tighter references (e.g., 5.2.x) would improve traceability and reduce ambiguity.

[Editorial] The “Configuration Characteristics” section reads like conclusions rather than a workflow description and repeats “dependent on UE capabilities” without adding measurable or comparative insight; it would be stronger to relate characteristics to the steps (capture/training/rendering) and to other configurations in the TR.

[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.

[Technical] The statement in NOTE 1 that “5G latency or jitter requirements do not apply” is too absolute; even file-based delivery can have user-experience constraints (e.g., time-to-first-render, progressive download), so the CR should qualify the conditions (offline vs interactive) and avoid implying no QoS considerations at all.

[Technical] Claiming “Standard 5G bearers specified in TS 23.501 are adequate” is underspecified and potentially misleading because TS 23.501 defines QoS framework and 5QI characteristics; the CR should indicate which QoS treatment is assumed (e.g., default/non-GBR, TCP-based delivery) or explicitly state that no specific 5QI is mandated.

[Technical] Mapping “3DGS File Delivery” to MMS (TS 26.140/26.143) and RCS messaging is questionable for typical 3DGS asset sizes; MMS/RCS have practical payload limits and store-and-forward behaviors that may not support large 3DGS datasets, so the CR should either constrain the use case (small assets/thumbnails) or prioritize HTTP-based delivery.

[Technical] The CR asserts a “file-based delivery model rather than streaming,” but 3DGS can be delivered progressively or as time-aligned animation streams (as mentioned under content generation); the mapping should address whether timed delivery uses DASH/MPEG-based streaming, MBS, or other 3GPP media streaming services rather than only “download/message-based assets.”

[Technical] The “time-aligned animation stream generation” function is mapped only to an on-UE application, but the CR does not explain how timing, synchronization, and clock/reference (e.g., with audio/video or pose streams) are handled within the 3GPP media framework; this is a gap if the clause is meant to be a workflow mapping.

[Technical] The mapping to “Media Access Function of Media Delivery architecture (TS 26.501)” for MMS/RCS/HTTP is not clearly justified; TS 26.501’s Media Delivery architecture typically assumes HTTP-based media access, and messaging services are not obviously “Media Access Function” instances—this needs architectural consistency or a rationale.

[Technical] “Low Packet Error Rate and reliable delivery required” is vague and somewhat contradictory with the earlier dismissal of QoS; if reliability is a requirement, the CR should clarify whether it relies on transport-layer reliability (TCP/QUIC) versus radio-layer QoS, and what failure/retry behavior is expected.

[Technical] Storage is mapped to “UE local storage (no 3GPP-specific mapping),” but the clause should at least mention whether any 3GPP enablers are relevant for content management (e.g., caching, content hosting, or application-layer DRM/security) if the intent is a comprehensive mapping.

[Editorial] The contribution references “3GPP TR 26.501” and “TS 26.501” interchangeably; TS 26.501 is a Technical Specification, so the document should use consistent and correct document type references.

[Editorial] The CR summary says it introduces “a new clause (Clause 10)” but does not show the actual inserted text, table structure, or exact normative wording; for a CR review, the proposed clause text and precise edits are necessary to assess completeness and consistency.

[Editorial] The term “All in UE configuration” is used without a clear definition or cross-reference to earlier clauses in TR 26.958; the clause should explicitly define the configuration assumptions (where capture, encoding, delivery, rendering occur) to avoid ambiguity.

[Editorial] The mapping table items mix functions (“scene capture”) with deployment statements (“3DGS/XR Application on the UE”) and with 3GPP service names; the table would be clearer if it separated functional blocks, 3GPP enablers, and interfaces, and used consistent terminology aligned with TS 26.501 entities.

[Technical] The CR is internally inconsistent on the target spec: it is titled “TR 26.501 Change Request Summary” but states “Pseudo CR for TR 26.958 v0.1.1”; the exact target document, version, and clause numbering (e.g., “Clause 10.2”) must be aligned or the change cannot be applied.

[Technical] The mapping heavily relies on TS 26.565 “Split Rendering Client/Server” without justifying applicability to 3DGS streaming/generation; split rendering is defined for specific XR rendering splits, so the CR should state which split(s) are assumed and what interfaces carry 3DGS-specific data.

[Technical] “Network-side 3DGS generation from 2D capture” is mapped to “(Edge) Media AS” in TS 26.501, but TS 26.501 Media AS is primarily for media processing/delivery functions; the CR should clarify whether 3DGS reconstruction is in scope for Media AS or requires an application server outside the media architecture.

[Technical] The delivery section lists “DASH, HLS, RTP, QUIC” as protocols, but TS 26.501/26.501-based architectures typically reference specific 3GPP media profiles (e.g., DASH in TS 26.247/26.244, RTP/RTCP in TS 26.114/26.237); “HLS” and generic “QUIC” are not clearly anchored to 3GPP normative specs here.

[Technical] “Tiled LOD streaming” and “region-based parts of 3DGS scenes” are introduced without mapping to an existing 3GPP tiling/ROI mechanism (e.g., MCTS/viewport-dependent streaming concepts); the CR should specify how tiles/LOD are addressed, signaled, and synchronized with pose.

[Technical] Pose/LOD reporting is mapped to “real-time/conversational service interfaces (TS 26.506)”, but TS 26.506 is not the typical anchor for XR pose transport; the CR needs to identify the exact service/API (and directionality, timing constraints) and how it interworks with media delivery (e.g., RTP header extensions, SEI, timed metadata).

[Technical] QoS claims are problematic: “utilizing 5G URLLC” for 3DGS delivery is likely unrealistic for high-throughput media and conflicts with typical XR QoS handling (e.g., XR 5QI work); the CR should avoid implying URLLC unless it specifies which flows (pose vs media) and how they map to standardized QoS flows.

[Technical] “New 5QI for XR services” and “PDU Set based QoS” are presented as if available, but in a TR mapping clause they should be referenced to the exact 3GPP stage-2/stage-3 specs and current Rel-20 status; otherwise this reads as speculative and may contradict agreed QoS frameworks.

[Technical] “3DGS Model and Tile Caching: Utilizes 5G Edge CDN infrastructure” is vague and not mapped to a 3GPP-defined function (e.g., M4E/Edge enablers, 5GMS AF/AS roles); the CR should state whether caching is in 5GMSd, 5GMSu, or generic edge CDN outside 3GPP scope.

[Technical] The CR mixes “interactive XR service” and “6DoF media streaming” but does not state which 3GPP service category (e.g., 5GMS, MTSI, XR conversational) is assumed per workflow; this ambiguity undermines the mapping table’s usefulness and may lead to contradictory function assignments.

[Technical] Multicast/broadcast mapping to TS 26.502 is questionable: TS 26.502 is 5GMS architecture, but multicast/broadcast for media is typically tied to 5MBS/MBMS-related specs; the CR should reference the correct multicast/broadcast specifications and indicate whether 5GMS supports the intended distribution mode.

[Editorial] The contribution claims to “introduce a comprehensive mapping table” in Clause 10.2, but no actual table content (rows/columns, exact mappings) is included in the CR summary; reviewers cannot verify completeness, consistency, or whether mappings duplicate/contradict existing clauses.

[Editorial] Several references are imprecise or potentially wrong (e.g., “TS 26.501 Media-Aware Application” vs the actual 5GMS entities, “Edge Media AS” terminology); the CR should use exact entity names as defined in the target TR/TS to avoid misinterpretation.

[Editorial] “NOTE 1/NOTE 2” content is largely FFS and reads like requirements rather than mapping; if kept, it should be clearly scoped as informative text and separated from normative mapping statements to avoid overstating conclusions in a TR.

[Technical] The CR proposes mapping “3DGS services” to pre-defined 5QIs but does not define concrete QoS requirements (PDB, PER, priority level, packet size/rate assumptions) per identified 3DGS flow in clause 6.X.2, so the mapping in clause 6.X.3 is not actionable or verifiable.

[Technical] Several cited 5QI examples appear incorrect or misleading versus TS 23.501 tables: e.g., “5QI 1-4 … buffered streaming” is not aligned with typical standardized service examples (buffered streaming is commonly associated with non-GBR 5QI 6/8/9), risking wrong conclusions for 3DGS traffic treatment.

[Technical] The CR mixes GBR, delay-critical GBR, and non-GBR 5QIs without stating which 3DGS flows are expected to require guaranteed bit rate versus non-GBR (e.g., static scene download vs pose/gaze uplink), which is fundamental to QoS Flow selection and admission control behavior.

[Technical] The identified flows in clause 6.X.2 overlap and are not mutually exclusive (e.g., “delivery of 3DGS media content” vs “dynamic or view-based 3DGS content”), making it unclear what traffic classification rules the UE/AF/SMF would apply.

[Technical] The CR does not address that 5QI selection in 5GS is typically driven by AF/PCF policy (TS 23.503) and QoS profiles, not by application-layer “recommendations” alone; the proposal should clarify whether it targets AF signaling (e.g., via NEF) or is purely informative.

[Technical] The recommendation “use existing 5QI values … as reference for determining appropriate 5QI values and QoS characteristics limits” is problematic because pre-defined 5QIs already have fixed standardized characteristics; if different limits are needed, the correct mechanism is a standardized new 5QI or a non-standardized QoS profile, which should be explicitly discussed.

[Technical] The CR suggests liaison “likely SA2” to define new 5QIs, but 5QI standardization and QoS characteristics are specified in SA2 (TS 23.501) with strong SA5/CT involvement for management/signaling impacts; the liaison scope and target groups are underspecified.

[Technical] No consideration is given to uplink pose/gaze/LOD traffic being small-packet, high-rate, jitter-sensitive control traffic; mapping it to generic “motion tracking” 5QI 88 without discussing jitter, periodicity, and reliability trade-offs may be technically unsound.

[Technical] The CR does not discuss whether 3DGS delivery is downlink-heavy eMBB-like (throughput-driven) versus interactive XR-like (latency/jitter-driven), yet it cites 5QI 80/89/90; without a traffic model, selecting among these is speculative.

[Editorial] The contribution claims a “comprehensive table” of relevant 5QIs but only lists selected ranges and examples; if clause 6.X.1 is intended to be normative study text, it should either reproduce the exact TS 23.501 entries with correct service examples or clearly state it is a non-exhaustive subset.

[Editorial] The document references “TS 23.501 clause 6.X.1” style content but does not provide exact TS 23.501 table numbers/versions; precise references are needed to avoid mismatches across releases and revisions.

[Editorial] Terminology is inconsistent: “3DGS services,” “3DGS media content,” “scene content,” and “view-based content” are used without definitions; TR 26.958 should define these terms or reference a definitions clause to prevent ambiguous interpretation.

[Editorial] The proposed clause numbering “6.X” is placeholder-like; for a CR it should include final clause numbers and indicate insertion points relative to existing TR 26.958 structure to ensure consistency with the document’s table of contents and cross-references.