[Technical] The described “via DC AS” mechanism relies on TS 23.228 allowing an IMS AS to change the endpoint type from P2P to P2A, but the contribution does not specify which SDP attribute/parameter carries this endpoint type (e.g., within a=3gpp-req-app) nor how the UE is expected to interpret it, leaving the interworking behavior under-defined.

[Technical] The claimed misalignment with TS 26.114 6.2.10.3 is plausible, but the contribution stops at identifying the conflict and does not propose concrete normative resolution (e.g., an explicit exception allowing modification of adc-stream-id-endpoint in interworking cases, or an alternate signaling indicator), so it cannot be implemented consistently.

[Technical] The statement that the terminating UE “returns bootstrap DC negotiation result with port number zero” when it doesn’t support IMS DC needs validation against the exact AC.7.9 procedure; if this is only one rejection method (vs. omitting m-line, setting port 0, or rejecting attribute), the text risks being incorrect or incomplete for real SDP negotiation behavior.

[Technical] The “DCSF recognizes rejection and establishes bootstrap data channels only between originating UE and MF” is architecturally unclear: if the terminating UE does not support IMS DC, it is not obvious why a bootstrap data channel to MF is still required/usable, and what application-level function it serves without a peer DC endpoint.

[Technical] The “via MF” interworking description says MF performs transcoding “upon DCSF instructions,” but does not specify what is transcoded (data channel content vs. associated RTP media) and how that maps to MTSI/MMTEL media; as written it conflates data channel interworking with media transcoding.

[Technical] The contribution introduces “data channel associated media” and “non-data channel associated media” flows, but does not define the association mechanism (SDP grouping, mid, bundle, or 3GPP-specific linkage), which is essential for interworking and for the UE to bind DC and RTP streams correctly.

[Technical] The “via DC AS: Not specified (e.g., SMS)” path is too hand-wavy for a key issue text: SMS is not an IMS Data Channel media interworking method in TS 26.114 context, and suggesting it without constraints risks misleading conclusions in TR 26.814.

[Technical] The text says DCSF determines interworking “based on session event notification from IMS AS,” but does not identify the relevant interface/procedure (e.g., ISC event package, SIP dialog event, or proprietary notification), making the trigger for switching P2P→P2A non-verifiable.

[Technical] The identified UE need—“capability to identify when interworking mode is enabled”—is correct, but the contribution does not propose where this indication should appear (SDP attribute, SIP header, or application-layer signaling), nor how it interacts with TS 26.114’s constraint on mirroring a=3gpp-req-app.

[Editorial] The document mixes entities and terminology (MF, DC AS, “IMS Data Channel functional entities,” DCSF) without a consistent definition set or reference to the exact TS 23.228 functional model, making it hard to map the described flows to standardized nodes.

[Editorial] Several claims are attributed to TS 23.228 clause “AC.7.9” without quoting the exact step/behavior; for a gap analysis, the contribution should cite the precise subclause text and the exact SDP/attribute behavior to avoid misinterpretation.

[Editorial] The section titles imply TR 26.814 text (“X.2.1”, “X.2.2”), but the contribution summary does not provide the actual proposed wording, so reviewers cannot assess whether the inserted TR text is scoped appropriately and aligned with existing TR structure and terminology.

[Technical] The contribution asserts a “key gap” in TS 26.114 clause 6.2.10.1 for BDC re-establishment after DTLS/SCTP restart, but it does not quote the exact normative text nor demonstrate that the existing “initial entry point at HTTP root (‘/’)” requirement does not already apply on every (re)establishment; without pinpointing the ambiguity, the problem statement is not technically substantiated.

[Technical] Option 1 (“use ‘/’ again”) is presented as having “no identified downsides,” but it ignores the practical dependency on the network-side URL rewriting described via TS 29.176; if the MF previously provided a subscriber-specific entry point that is not ‘/’, forcing the UE to always start at ‘/’ after restart may break service unless the network guarantees that ‘/’ is always a valid bootstrap entry for that subscriber on every re-established BDC.

[Technical] The document conflates “transport restart” (DTLS/SCTP restart) with “BDC reestablishment” without clarifying whether the HTTP application context (e.g., cookies, authorization state, resource identifiers) is expected to survive; the correct behavior depends on whether the restart is treated as a new HTTP origin/session, which is not analyzed.

[Technical] The restart triggers listed (call forwarding, forking/early media, access IP/port change) are plausible, but the contribution does not map each trigger to the specific IMS DC procedures and roles (UE/MF/DCSF) in TS 26.114/23.228/26.264/26.567, so it’s unclear which entity is expected to detect restart and how the UE learns it must “bootstrap” again.

[Technical] The claim that Option 2 (“use last URL”) would “likely fail” in forking/forwarding is not rigorously argued: it depends on whether the post-restart DC is anchored to the same HTTP origin/authority and whether the URL is absolute vs relative; the contribution should distinguish origin changes (scheme/host/port) from path changes and explain which are expected in IMS DC.

[Technical] The contribution references RFC 8864 and RFC 8841 as covering DTLS/SCTP restart, but does not verify alignment with how TS 26.114 profiles those RFCs (e.g., whether ICE restarts, DTLS role changes, or SCTP association resets are permitted) and how those events translate into HTTP-level bootstrap behavior.

[Technical] If the MF “modifies” the root URL per TS 29.176 before passing to DCSF, the contribution should consider whether the UE ever receives an explicit initial URL via signaling (e.g., in SDP/HTTP config) rather than assuming it is always implicit ‘/’; otherwise the proposed “ambiguity” may be an artifact of an incomplete signaling description.

[Technical] The proposal to add this as a “key issue” in TR 26.823 is reasonable, but the contribution does not propose concrete normative outcomes (e.g., a TS 26.114 change) or acceptance criteria (interoperability expectations), which limits its usefulness for the study item beyond problem awareness.

[Editorial] The document repeatedly uses “IMS DC transport restart,” “BDC reestablished,” and “restart point” without defining these terms or distinguishing between (a) rekey/rehandshake on the same 5-tuple and (b) full re-establishment with new ICE candidates/IP/ports; this imprecision makes the ambiguity harder to assess.

[Editorial] The statement “Possible interpretation of existing text” (Option 1) is too vague for a standards contribution; it should cite the exact clause(s) and explain the competing interpretations that lead to interoperability risk.

[Editorial] The summary references “HTTP protocol usage on DC” and “inconsistencies between TS 23.228, TS 26.114, TS 26.264, TS 26.567,” but the contribution does not identify any specific inconsistency or clause-level conflict, so the scope appears broader than the actual content (which is narrowly about initial URL after restart).

[Technical] The contribution stays at a high-level “feasibility analysis” and does not propose any normative requirements, procedures, or impacted spec text, so it is not actionable for FS_DCE_MED Key Issue #4 closure or for aligning with GSMA NG.129 requirements.

[Technical] The “persistent identifier” concept is underspecified: there is no definition of identifier format, uniqueness scope (per UE, per application, per session, per peer-pair), collision handling, or binding to an application/context, which makes interoperability and security analysis impossible.

[Technical] The document does not state where/how the identifier is carried (SIP header, SDP attribute, MSRP/HTTP payload, data channel protocol, etc.) nor how it is negotiated, updated, or confirmed, leaving a major gap versus “exchanged between peers” requirement.

[Technical] Lifetime management is mentioned but not defined: no rules for creation, refresh, expiry, revocation, or behavior on expiry, and no mapping to existing IMS/3GPP timers or registration/session lifetimes.

[Technical] No security/privacy assessment is provided for a cross-session persistent identifier (tracking risk, correlation across calls, replay/impersonation, leakage to intermediaries), nor any mitigation (confidentiality, integrity, authentication, consent).

[Technical] The proposal does not clarify whether state is stored locally, in the network, or in an application server, and how the identifier maps to that storage; without an architecture choice, feasibility and responsibilities (UE vs network vs AS) cannot be evaluated.

[Technical] “Session termination scenarios” include user-initiated termination; the contribution does not address whether resumption is allowed/expected after explicit user hang-up, and how this aligns with user intent and service policy.

[Technical] The “system notification” use case sounds like temporary suspension rather than session termination; the document does not distinguish between in-session pause/hold vs cross-session resumption, which may require different mechanisms.

[Technical] Call transfer support is asserted but not analyzed: transferring from UE#2 to UE#3 changes the peer and potentially trust domain, yet there is no procedure for identifier handover, authorization, or preventing unintended state disclosure to UE#3.

[Technical] There is no discussion of interaction with existing IMS mechanisms (dialog identifiers, GRUU, Replaces/Refer, session refresh, registration, service continuity), risking duplication or conflict with established identifiers and procedures.

[Technical] The contribution does not specify failure handling (identifier missing/mismatch, stale state, partial state restore, multi-device scenarios), which are essential for a robust “automatic resumption” feature.

[Editorial] The document reads as a narrative summary rather than a 3GPP contribution with clear conclusions, proposed work items, or specific questions to the group; it should explicitly state what decision or agreement is being sought in S4.

[Editorial] References are incomplete: it cites GSMA PRD NG.129 and LS S4-250755 but does not quote the exact requirement text/IDs being addressed, making it hard to verify coverage and traceability.

[Technical] The recommended “UE fetches external resources directly over HTTPS” conflicts with the IMS Data Channel concept if the UE is expected to be confined to the DC media plane; the contribution does not state whether such external HTTPS uses the normal IP bearer outside IMS, nor how this aligns with any assumed operator policy that DC apps’ traffic stays within the IMS/DC path.

[Technical] The proposal assumes the DC AS can reliably enforce security by sending CSP, but it does not address the trust model for the DC AS itself (authentication of the DC AS origin, integrity of delivered headers/content, and binding of the web origin to the DC AS) which is essential before CSP can be meaningful in a 3GPP-delivered web app context.

[Technical] “Fully compatible with all web browsers” is overstated: CSP enforcement and especially nonce/strict-dynamic behavior varies across engines and embedded WebViews, and the document does not discuss minimum browser requirements or fallback behavior for UEs that do not support the needed CSP directives.

[Technical] The document treats CORS as a straightforward opt-in by the external origin, but OAuth flows often involve redirects, iframes/popups, and third-party cookies; the contribution does not analyze modern browser privacy restrictions (e.g., third‑party cookie blocking, Storage Access API) that can break the proposed “frame-src/form-action to auth domain” patterns.

[Technical] The proxy-tunnel critique assumes “one external destination maps to one application data channel” and requires SDP renegotiation per destination; this is not justified against TS 26.114/SDP usage (e.g., multiplexing multiple HTTP/TLS connections over a single SCTP stream or multiple streams under one negotiated data channel), so the scaling argument may be partially based on an unnecessarily constrained design.

[Technical] The MF egress-IP attribution issues (rate limiting, geolocation, abuse) are valid for a centralized proxy, but the document does not consider mitigations that could preserve per-user attribution without TLS termination (e.g., CONNECT-style tunneling with per-UE source identity signaling, or IPv6 prefix delegation/unique egress per UE), weakening the “rejected approach” conclusion.

[Technical] The CSP examples omit directives relevant to the stated use cases: WebSockets/SSE/HTTP streaming are covered by connect-src, but if the app loads external scripts/fonts/images as claimed, the example policies still default most resource classes to 'self' and do not show the necessary script-src/img-src/font-src allowances for third-party subresources.

[Technical] The contribution proposes TR 26.814 clarifications but does not identify exact clauses to change nor normative impact; without pinpointing where TR text currently constrains external fetching, it’s unclear whether this is a genuine spec gap or simply an implementation guidance note.

[Technical] The “application origin = DC AS” statement needs precision: web origin is scheme+host+port, but DC delivery over IMS DC is not inherently an HTTPS origin; the document does not specify how the browser maps DC-delivered content to an origin (e.g., https://dcas.example), which is critical for same-origin, CSP, and CORS to function.

[Technical] The LI discussion is hand-wavy and potentially contradictory: recommending end-to-end TLS to external origins while also suggesting SA4 document “decrypted content at network element” cases needs clearer separation of scenarios (DC media vs external HTTPS) and explicit statement of what 3GPP can/cannot require for LI in each.

[Editorial] Several claims are absolute without qualification (e.g., “extreme security risks,” “fully compatible with all web browsers,” “keeps OAuth flows predictable”); these should be softened or backed by concrete references to web standards and known browser behaviors.

[Editorial] References are incomplete/inconsistent: the text cites TS 26.114 and TS 24.229 for SDP and SIP procedures but does not cite the specific clauses, nor does it reference the relevant W3C specs for CSP/CORS/OAuth redirect handling, making it hard to validate the proposed “standard web security model” alignment.