1432   Resv required to be set before configuring URCB

Created: 18 Aug 2015

Status: In Force (green)

Part: Part 7-2 (2010; Edition 2)

Links:

Page: 117

Clause: 17.2.4.5

Paragraph:

Category: Issue for edition 2 of this part

Issue

As indicated in the note, Resv is intended to be a semaphore.

It is apparently not clear enough to all that this means the client is required to set Resv before attempting configuration of the URCB.

Proposal

Note: Client shall set successfully set Resv to true before attempting to configure the URCB.

Discussion Created Status
7-2 Editors conclusion applicable with Ed2.1. The FDIS implements the following.

Clause 17.2.4.5 Resv
The attribute Resv indicates that the URCB is reserved for a particular client TPAA. While a URCB is reserved no other client TPAA shall write to that URCB.
A client TPAA shall reserve “actively” (by setting the attribute Resv to TRUE) the URCB before configuring or enabling it. Based on authentication mechanism / exclusivity considerations, the reservation may fail.

The URCB resource remains reserved for that client TPAA :
- until the client TPAA is lost or,
- until the client TPAA "actively" ureserves the resource (writing the Resv attribute of the URCB to FALSE).

A SCL preconfigured URCB for a set of specific clients based upon configuration displays an attribute Resv with a value set to TRUE. In that case:
- setting the value of Resv to FALSE by the client TPAA owner unreserves the URCB from the TPAA (postive response) or,
- a loss of the client TPAA owner unreserves the URCB,
but the Resv attribute will continue to reflect the SCL reservation value TRUE.
See E.3 for further clarifications.



28 Jun 19 In Force (green)
04 Nov 15 In Force (green)
29 Oct 15 Ballot Period
Agreed. 29 Oct 15 Discussion (red)
7-2 Editors conclusion applicable with Ed2.1:

1) An Ed2.1 Client shall reserve “actively” (by setting the attribute resv to true) the URCB before working with it (working= configuring or enabling).

2) A SCL preconfigured URCB displays an attribute resv with a value set to true. It might be preconfigured for a client LN. However, the Ed2.1 client shall actively set the attribute resv to true indicating herewith the exclusive reservation of the URCB. Based on authentication mechanism / exclusivity considerations, the reservation may fail.

3) For backward compatibility reasons, an Ed2.1 server shall auto-reserve a URCB that was not reserved so far when a client configures or enables the URCB before "actively" reserving it (by setting resv to true). The auto-reservation by the server sets the resv to true and the URCB is herewith exclusively reserved for that client.

The URCB resource remains reserved for that client until
1) the association to the client is lost (release or abort)
2) the client "actively" un-reserves the resource (writing the resv attribute of the URCB to false).

If a URCB has been preconfigured with ClientLN(s) in SCL:
- setting the value of resv to false by the owner association unreserves the URCB from the current association,
- losing the owner association un-reserves the URCB from the current association
- reading the URCB resv attribute returns the value true even if the URCB is not "actively" reserved.
28 Oct 15 Discussion (red)
If SOME Servers set Resv=TRUE automatically when a Client writes any URCB attribute, I think this could be confusing to Clients. A Client wouldn't know if it automatically reserved the URCB or if another Client reserved the URCB a second later. The Client wouldn't know if it needed to set Resv=FALSE later.

If Clients can deal with this confusion, OK, but I think it is clearer if ALL Servers automatically reserve the URCB ONLY when a Client writes RptEna=TRUE.

I don't think 7-2 ever stated or implied that the Server should automatically reserve the URCB when a Client writes ANY attribute. 		25 Aug 15 Discussion (red)
agree with the proposal.
If the client does not set the Resv before configuring the URCB, this is a server implementation issue to set the Resv automatically or not.

If the server set the reservation automatically, then the reservation is active and not other client is allowed to change the configuration as long as the reservation is active.
If the server does not set the reservation automatically, then the reservation is not active, and any other clent is allowed to change the configuration as long as the reservation is not active.
Note: a successfull set of RptEna lead to an automatic reservation of the URCB by the client; i.e. if the client enables the URCB without having enabled it, then the server autmatically set the Resv attribute.
19 Aug 15 Discussion (red)
In part 8-1, clause 17.1.3 there is the week point: "If a V-PUT occurs while Resv=FALSE, the value returned in the V-GET is a local issue." That means a server can refuse a SetURCBValues Service if Resv=FALSE. So this can lead into problems also in a single client setup.

I strongly recommend to exchange the wording in 7-2 that "A Client shall set Resv=TRUE before any configuration." instead of the "semaphore" Note. 		18 Aug 15 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1