[Technical] The conclusion that SA4 studies “support the 20–100 Mbit range” is over-generalized: TR 26.956 Clause 9 results were at 25–30 fps, so using them to justify the same range for 90–120 fps immersive traffic (as RAN1 is modeling) is not technically substantiated without scaling assumptions or additional data.

[Technical] The statement that uplink “expected to require higher bit-rates within the range due to encoder constraints” is internally inconsistent: weaker encoders typically reduce achievable quality at a given bitrate (or require more bitrate for same quality), but uplink is also power/complexity constrained and often uses more aggressive compression—this needs a clearer, evidence-based direction (higher vs lower bitrate) and conditions.

[Technical] The document does not map the cited codec-study “rate points” (20–100 Mbit) to a traffic model definition needed by RAN1 (e.g., average vs peak, packetization, burstiness, frame/GoP structure, latency constraints), so it is not directly actionable for PHY/MAC evaluation.

[Technical] The “no values above 100 Mbit reported” argument from TR 26.955 is not a valid upper bound for future immersive/6G traffic; it reflects tested points and selected sequences, not a limit—this risks incorrectly constraining RAN1 modeling.

[Technical] The GeForce Now “~50 Mbit+” reference is a downlink cloud-gaming service and not representative of immersive uplink capture/telepresence; using it as supporting evidence for uplink or “transparent quality” immersive communications is misleading.

[Technical] The uplink discussion assumes “temporary frame rate drops and/or quality switches” yet still claims “comparable bit-rates”; adaptive drops typically reduce instantaneous/average bitrate—if the intent is that peak bitrate remains high, the text should explicitly distinguish peak vs average and adaptation behavior.

[Technical] The contribution mentions “4K + HDR at 120 fps” but does not specify whether this is mono/stereo, FoV, chroma format, bit depth, or codec configuration; without these, the bitrate numbers are not comparable across studies or usable for a traffic model.

[Technical] The note that Gaussian splat imaging “could result in (much) larger bit-rates” is too vague for RAN1; at minimum it should indicate expected order-of-magnitude ranges, whether uplink/downlink, and whether the traffic is video-like (CBR/VBR) or geometry/texture-stream-like.

[Technical] The document does not clarify whether the 20–100 Mbit range refers to single-stream user traffic or aggregate (e.g., multiple cameras/views/sensors), which is critical for immersive communication where multi-sensor uplink is common.

[Editorial] Several claims cite TR clauses/tables (e.g., “Table 6.6.3.7-1”) without enough context to verify relevance (what codec, what content, what operating points); adding the exact metric (e.g., “target bitrate points for highest quality anchors”) would improve traceability.

[Editorial] Terminology is inconsistent/vague (“transparent quality”, “highest quality sequences”, “higher range of 20–100 Mbit”); these should be aligned to 3GPP wording (e.g., “visually lossless/transparent” with defined test methodology) or clearly qualified as informal.

[Editorial] The document mixes “RAN1” and “RAN WG1” and “SA WG4 to be” in a way that is confusing for an LS; tighten the addressee/source naming and ensure the organizational references match current 3GPP structure for Rel-20 FS_6G_MED.