[Technical] The paper asserts a “critical gap” that TS 26.264 lacks media configuration details for an AR‑MTSI client in an avatar call, but it does not pinpoint which procedures are missing (e.g., SDP offer/answer attributes, codec/format negotiation, RTP payloads, B2BUA/MF insertion rules), making the gap statement too vague to justify an SA2 liaison.

[Technical] The claimed issue that “IMS network element behavior is unspecified” when receiving +sip.3gpp-ar-support / +sip.3gpp-avatar-support in REGISTER is not substantiated by citing the relevant IMS specs (e.g., TS 24.229 handling of unknown Contact header parameters, registration storage, and feature tag processing), so it’s unclear whether this is truly an architectural gap or already covered by generic SIP/IMS behavior.

[Technical] The document treats +sip.3gpp-*-support as “parameters in SIP REGISTER Contact header,” but does not clarify whether these are intended as SIP feature tags (RFC 3840/3841) and how they are used for routing/matching (e.g., in INVITE Accept-Contact/Reject-Contact), which is central to whether IMS needs new behavior at all.

[Technical] The “network-assisted avatar rendering” description (AR AS allocates MF, modifies SDP, inserts MF in media path) implies B2BUA/SDP mangling behavior, but the paper does not identify which network function is authorized to do this in IMS (P-CSCF/S-CSCF/AS/MRF/MF) nor the normative call flows, so SA2 cannot act on a concrete requirement.

[Technical] The proposal conflates two separate topics—registration-time capability indication and session-time media configuration/MF selection—without stating the decision logic (e.g., when to select MF based on avatar-assisted vs remote capabilities), risking an LS that is too broad and non-actionable.

[Technical] The definitions of “ar-assisted” and “avatar-assisted” (“requires network rendering/animation support”) omit how the UE signals request vs capability (i.e., whether “assisted” is a preference, a hard requirement, or simply a limitation), which affects IMS behavior and service continuity.

[Technical] The paper does not address interworking/roaming implications: if visited/home IMS elements ignore these tags, what is the expected fallback behavior and does the service still work (e.g., direct UE rendering, downgrade to video), which is important before requesting architectural changes.

[Technical] No security/privacy considerations are raised for exposing avatar/AR capabilities in REGISTER (e.g., profiling, feature disclosure), which may be a concern for SA2/SA3 and should be at least acknowledged in the LS request.

[Editorial] References are imprecise: “TS 26.264 Clause 7” and “Clause 7.3.1/7.3.2” are cited, but the paper does not quote the exact normative text being interpreted, making it hard to verify whether the described behavior is accurate or already specified.

[Editorial] The document states “media configuration requirements” but provides no concrete media configuration elements (SDP attributes, payload formats, bitrate/resolution constraints, RTP/RTCP usage), so the title and scope read mismatched to the actual content (which is primarily about IMS behavior and liaisoning).

[Editorial] The narrative references S4-251845 and “feedback indicated…” but does not summarize the specific objections or decisions from SA4-134, weakening traceability and making it difficult to judge whether an LS is the right next step.