[Technical] The “Single Core Network / standalone architecture” assumption (Clause 4.1, item 2) is too strong and risks contradicting ongoing 6G architecture exploration (e.g., interworking/multi-core evolution paths); it should be framed as a working assumption with explicit scope/limitations or aligned verbatim to TR 23.801-01 wording.

[Technical] The “No duplication between 6G RAN and 6G CN” assumption (Clause 4.1, item 4) is not generally valid for media delivery, where edge/RAN functions (e.g., caching, adaptation, compute offload) may intentionally duplicate or complement CN functions; the text should clarify what “duplication” means and whether it excludes edge media functions.

[Technical] “IMS for real-time services / MMTel voice/video services provided by IMS” (Clause 4.1, item 5) is overly prescriptive for a 6G media delivery study and conflicts with the later emphasis on “Real-time Communication beyond IMS”; it should be rephrased to avoid constraining non-IMS RTC service models.

[Technical] The mapping “TS 26.114 as baseline for Voice Services” (Clause 4.1, item 11) is conceptually off: TS 26.114 specifies media handling for IMS conversational services, not “voice services” in general; if the intent is conversational media, say “IMS conversational services,” and separately address non-IMS RTC media.

[Technical] The “Native TN/NTN support” assumption (Clause 4.1, item 6) is not actionable for SA4 without identifying media-specific NTN implications (latency/jitter, forward error correction, buffering, bitrate adaptation, multicast/broadcast, QoE); the contribution should at least list the media delivery impacts that motivate the assumption.

[Technical] The “Key Issues baseline” list (Clause 4.1) appears selectively copied and may be incomplete/misaligned (e.g., missing security/privacy, energy efficiency, mobility continuity, multicast/broadcast evolution) for media delivery; the document should justify why these specific SA2 key issues are the baseline for FS_6G_MED.

[Technical] Clause 4.2 “Requirements” is a placeholder with no normative structure (e.g., requirement identifiers, categories, traceability to SA1 use cases); for a study TR, at least a requirements framework and initial high-level requirements should be included or the clause deferred until inputs exist.

[Technical] The “Existing Media Services” classification into “full media services” vs “media service enablers” is useful but currently ambiguous: several items (e.g., 5GMS, 5G RTC) can be seen as both service and enabler depending on deployment; the text should define criteria (e.g., Stage-1/2/3 completeness, interoperability scope) to avoid inconsistent categorization.

[Technical] The XR section (Clause 4.3.2) is described at a very high level and misses key SA4-relevant baselines (e.g., which XR specs/TS/TR are the starting point, what traffic models/codecs/formats are assumed); without concrete references, it is hard to use as a baseline for 6G media work.

[Technical] The list of “5G media specifications as starting points” (Clause 4.1, items 8–12) omits important adjacent baselines for media delivery (e.g., QoE/QoS measurement/reporting, media synchronization, accessibility, security/DRM considerations where applicable); the baseline set should be checked for completeness relative to the intended 6G media scope.

[Editorial] Several references look non-existent or placeholder (e.g., “TS 22.ABC”, “TR 23.801-01” naming) and should be validated against official 3GPP document identifiers; incorrect references will block approval.

[Editorial] The contribution contains many editor’s notes and “to be added” statements (Clauses 4.1–4.3), which weakens it as a CR; either convert to a discussion paper or provide concrete text with clear scope and remove open-ended notes.

[Editorial] Terminology is inconsistent (“6G CN”, “single 6G CN type”, “5GC SBA as starting point”, “6G RAN connects to single core”) and may confuse readers; align terms with SA2 conventions and define abbreviations (TN/NTN, RTC, MSE, MBS, XR) at first use.

[Editorial] The “References section adds comprehensive normative and informative references” claim is not substantiated by the summary and mixes normative/informative without rationale; the CR should clearly separate normative vs informative references and justify why each is needed for TR 26.870.