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