TDoc: S4-260169

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