Heads-up: New qos-booking-and-assignment API overlaps with dedicated-networks scope

[albertoramosmonagas]

Problem description
We would like to inform the Dedicated Networks working group of a potential scope conflict stemming from a newly introduced API under the QoS Booking workstream, led by T-Mobile US.

The new API, named qos-booking-and-assignment.yaml, introduces device-to-slice (or dedicated resource) assignment mechanisms — which are already covered under the scope of the dedicated-networks API, approved and maintained by this group.

This situation creates a risk of functional overlap, and could lead to fragmentation in the CAMARA API landscape if both APIs proceed in parallel with similar purposes.

We believe this group, as owner of the original API and its approved Proposal, should be informed early and may wish to provide input or raise the matter within governance channels if needed.

Expected action

• Review the contents and scope of qos-booking-and-assignment.yaml in relation to the original dedicated-networks API.
• Share your perspective on whether this new API introduces redundancy or overlaps with your current scope.
• If applicable, propose next steps to clarify responsibilities, harmonize the workstreams, or escalate the issue to CAMARA governance for resolution.

Additional context

• The new API was contributed by T-Mobile US within the QoS Booking repo:
  qos-booking-and-assignment.yaml (TMUS)
• It includes a /assignDevices operation that mirrors logic already handled in dedicated-networks.

[tlohmar]

We discussed the suggestion to join the QOD Sub-Project (link) and agreed to it. Aim is to join already for the next QOD community call on 5th of September.

• For the moment, DN group suggested to keep the meeting slot (Mondays, 0800h UTC) until we are confident Dedicated Network related issues have enough time in the QoD WG sessions

@hdamker : Is it ok for the QOD Sub Project to join?