Duration maximum diverges between qos-booking, qos-booking-and-assignment, and QoD

[hdamker]

Problem description
Both APIs in this repo define a "requested QoS session duration in seconds" concept with near-identical wording, but with very different upper bounds — added independently during the r4.3-alignment work in this release cycle (neither had a maximum before 0.1.0 / r1.2):

• qos-booking-and-assignment.yaml Duration (code/API_definitions/qos-booking-and-assignment.yaml:1016-1025): maximum: 86400 (24 hours)
• qos-booking.yaml duration property, used in both CreateBooking and BookingInfo (code/API_definitions/qos-booking.yaml:443, :484): maximum: 31622400 (~366 days)

I checked how QualityOnDemand handles the same concept, since both APIs here explicitly say "Value may be explicitly limited for the QoS profile, as specified in the Qos Profile (see qos-profile API)." QoD's duration (quality-on-demand.yaml, SessionInfo and CreateSession) uses maximum: 2147483647 — i.e. no meaningful business limit at the schema level, just the int32 ceiling — and defers the actual bound entirely to the QoS Profile's own Duration object (qos-profiles.yaml, a structured {value, unit} pair via minDuration/maxDuration, not a raw integer-seconds cap).

So neither qos-booking nor qos-booking-and-assignment matches QoD's pattern, and they don't match each other either — three different approaches to a concept all three APIs describe the same way and all defer to the same "QoS Profile" for the real limit.

Expected behavior
Confirm whether the difference between the two QoS Booking APIs is intentional (e.g. qos-booking-and-assignment targets short ad hoc device bookings while qos-booking targets longer-term reservations) and, if so, document the rationale in each API's description. If not intentional, consider aligning with QoD's approach — an effectively unbounded schema maximum (int32 ceiling) with the real limit left to the QoS Profile — for consistency across the CQM-adjacent APIs that share this exact "limited by the QoS profile" language.

Alternative solution
If the two APIs are meant to allow different duration ranges by design, no schema change is needed — just add a short note to each Duration/duration description explaining the bound, so the divergence (from each other and from QoD) reads as deliberate rather than as drift.

[Masa8106]

@hdamker, thank you for raising this issue. Actually I intentionally set maximum: 31622400 in qos-booking.yaml duration property. In my opinion, qos-booking API may be utilised for Live Video(Event) Streaming by broadcasting company. Some of events (e.g. football world cup) may last for more than a month. And then, I believed there was a business need of maximum: 31622400. But I can discuss it openly.

@gmuratk, what do you think on this issue?

[hdamker]

And then, I believed there was a business need of maximum: 31622400. But I can discuss it openly.

The proposal above is to align it with the approach in quality-on-demand: effectively not restricting the duration (using the int32 maximum), and leave the actual limitation to the the value provided by the qosProfile. But sure, one year is also a reasonable upper limit.

L480 of sos-booking is currently saying:

"Requested session duration in seconds. Value may be explicitly limited for the QoS profile, as specified in the Qos Profile (see qos-profile API). Implementations can grant the requested session duration or set a different duration from startTime, based on network policies or conditions."

[Masa8106]

@hdamker, thank you for your reply. I got your point (using the int32 maximum in yaml file, and the actual limitation depends on the value in qosProfile). So I will update the maximum in yaml file from 31622400 to the int32 maximum. Thank you.

@gmuratk, regarding this issue, let me create a PR to update the maximum in qos-booking-and-assignment too. If any, please feel free to modify the PR.