1758   Allow implicit RCB reservation if SCl-configured (revert to pre-Amd1 behaviour)

Created: 24 Feb 2021

Status: Not Applicable

Part: Part 7-2 (2020; Edition 2.1)

Links:

Page: 108

Clause: 17.2.2.17

Paragraph: 3

Issue

Ed2 Clients developed using rules before Amd1 cannot enable reports in Amd1 servers if the SCL file shows a reservation. Prior to Amd1, the server would be "implicitly reserved" for the Client based upon ClientLN element in the SCL file and therefore the client application would NOT write ResvTms before writing the other RCB attributes. In fact, the server was required to actively refuse an attempt for the Client to make the reservation.

Amd1 reverses this and now requires that a Client re-confirm the reservation already in the SCL file by writing ResvTms before writing the other RCB attributes (and requires the server to accept the re-confirmation but NOT to change the value of ResvTms away from -1).

The creates a forward compatibility issue with pre-Amd1 Clients.
Note the same issue exists for both BRCB and URCB.

Proposal

Change "A client TPAA shall reserve “actively” (by using the SetBRCBValues.Request(ReserveTimeSecond > 0)) the BRCB before configuring or enabling it."
to
"If the BRCB is not already reserved, a client TPAA shall reserve “actively” (by using the SetBRCBValues.Request(ReserveTimeSecond > 0)) the BRCB before configuring or enabling it."

The paragraph before this one already states "A value [for ResvTms] of zero (0), shall indicate that the BRCB is not reserved".