TDoc: S4-260125

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