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