1432   Resv required to be set before configuring URCB

This tissue has following status: green

Created: 18 Aug 2015


Page: 117



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
Ballot until Editor
04 Nov 15 green
29 Oct 15 final proposal 2015 - Nov, 28
Agreed. 29 Oct 15 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 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 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 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 red


Privacy | Contact | Disclaimer