[Technical] The proposal targets TR 26.813 clause 8.3.3.x, but the described procedures are for BAR APIs “integrated into TS 26.264 Annex B”; it is unclear why normative-looking API procedures are being added to a TR rather than aligned with (or referenced from) TS 26.264, risking duplication and inconsistency across specs.

[Technical] Several API names are inconsistent across the document (e.g., Mbar_Management_BaseAvatarModels_GetBaseAvatarModel vs Mbar_Management_Avatars_CreateBaseAvatarModel), suggesting mismatches with the actual OpenAPI operationIds in TS 26.264 Annex B and making the procedures potentially non-actionable/incorrect.

[Technical] The “Update Base Avatar Model” PATCH mechanism (“multipart/mixed … asset identifiers list and binary assets”) is underspecified: no definition of the patch semantics, part naming, content-types, ordering, or how assetIds map to parts, and no reference to a standard patch format (e.g., JSON Patch / Merge Patch), which will lead to non-interoperable implementations.

[Technical] The “Update Asset” PATCH description (“multipart/mixed message with LoDs/components to replace”) introduces new concepts (LoDs/components) without defining them in BAR/ARF context or referencing ARF container structure, so the server-side update behavior cannot be consistently implemented.

[Technical] Response payloads are inconsistent: “Create Asset” says response is “201 Created with assetId” but later “Response Information Elements” says “Avatar resource entity (M)”; similarly “Create Base Avatar Model” returns “Avatar resource entity” but “Get Base Avatar Model” returns both “Avatar resource entity and binary ARF container”—the resource model vs binary container handling needs a consistent pattern.

[Technical] Error handling is entirely missing (401/403/404/409/413/415/422 etc.); given authorization checks, missing avatarId/assetId, and container validation, the procedures should at least identify key failure cases and expected HTTP status codes to avoid divergent behavior.

[Technical] The document repeatedly states “globally unique identifier” creation for avatar and representation IDs but does not specify scope/format (UUID/URI), nor how it relates to the resource path variables {avatarId}, {assetId}, {avatarRepresentationId}—this is critical for API interoperability.

[Technical] Authorization/ownership rules are inconsistent and incomplete: only Avatar Representation update notes “only owner allowed,” while create/update/delete of avatars/assets also imply restrictions; the contribution should define a coherent authorization model (who may create assets under an avatar, who may delete, delegation to MF/DC AS, etc.).

[Technical] The “Get Avatar Representation” procedure says {avatarId} is replaced in the resource path, but retrieval should typically be keyed by {avatarRepresentationId} (and possibly {avatarId}); as written it is ambiguous which representation is retrieved when multiple representations exist for one avatar.

[Technical] “Destroy Avatar Representation” allows “204 No Content (or 200 OK if response body needed)”; this optionality without specifying when/what body is returned undermines interoperability and should be fixed to a single behavior aligned with TS 26.264.

[Technical] The procedures mention “BAR stores ARF container locally” and “may repackage container” but do not address versioning/ETags/If-Match concurrency control; without this, simultaneous updates (especially PATCH) can corrupt container state.

[Editorial] There are multiple typos in operation names and paths that would be problematic if copied into a spec: Mbar_Managment_Avatars_DeleteBaseAvatarModel (Management misspelled), GetAssoicatedInformation (Associated misspelled), and inconsistent underscores in Mbar_Management_Avatar_Representations_UpdateAvatarRepresentation.

[Editorial] The “Request Information Elements” tables mix “Security credentials (M)” with “Requestor identifier (M)” only for Update Asset; terminology and presence conditions (M/CM) are not defined in this contribution, and “CM” is used without explanation (conditional mandatory on what condition).

[Editorial] The “Note: DC AS or BAR apply restrictions…” is vague and not written in 3GPP normative style (no “shall/should/may” with clear conditions), and it’s unclear whether it is informative guidance or intended normative behavior.

[Editorial] The proposal text (“Document section 2 contents as new clause 8.3.3.4… Add editor’s note…”) does not include the actual CR-style change text, clause numbering context, or exact insertion points, making it hard for SA4 to assess impact and consistency with existing TR 26.813 structure.