[Technical] Removing “A data channel SDP media description shall not be placed before the first SDP speech media description.” is likely correct for standalone data channel sessions, but the CR does not cite the exact SA2 normative reference (TS number/clause) that introduces “standalone data channel sessions,” making it hard to verify alignment and scope.

[Technical] The deleted ordering constraint may have been implicitly relied upon to ensure early offer/answer processing assumptions (e.g., MMTel anchoring, feature negotiation expectations, or legacy interop); the CR should confirm there are no remaining dependencies elsewhere in TS 26.114 (or related MTSI clauses) that assume speech m-lines precede data channels.

[Technical] If standalone data channel sessions are allowed, clause 6.2.10.1 should explicitly state that an SDP may contain only data channel m-lines (i.e., no speech/video/text), rather than only implying it via “independently,” to avoid ambiguity for implementers and conformance testing.

[Technical] The CR claims “all other requirements” remain, but does not verify whether media feature tags (+sip.app-subtype, g.3gpp.dc-mux) and bandwidth procedures are still applicable when no MMTel media exists; the spec text should clarify applicability conditions for standalone cases.

[Technical] The updated wording does not address whether any ordering constraints remain for multiple data channel m-lines (e.g., mux/non-mux, multiple SCTP associations), so removing the only explicit ordering rule could leave undefined behavior if other clauses expect a particular structure.

[Editorial] The new sentence “may be added into the SDP independently, or to be added alongside…” is grammatically awkward and redundant; it should be simplified (e.g., “may be included in the SDP either alone or alongside other SDP media descriptions…”).

[Editorial] “such as e.g.” is non-idiomatic and appears in both old and new text; replace with either “e.g.” or “such as” to improve readability and align with 3GPP style.

[Technical] The CR references RFC 8864 for “data channel SDP media descriptions”; it would be safer to confirm that the intended data channel SDP usage is consistent with the WebRTC data channel SDP conventions (including “UDP/DTLS/SCTP” and “webrtc-datachannel”) in the standalone IMS context, since removing ordering may increase exposure to non-WebRTC SDP stacks.

[Editorial] The “Impact” section states “Flexibility in SDP media description ordering,” but the actual change only removes one specific constraint (before first speech m-line); consider tightening the statement to avoid over-claiming broader ordering freedom than actually specified.

[Editorial] The CR summary uses “MMTel media (e.g., audio, video, messaging)” where “messaging” is not an SDP media type in the same sense; consider using “speech/audio, video, and real-time text” (or the exact TS 26.114 terminology) to avoid confusion.