1432 Resv required to be set before configuring URCB
- Created
- 18 Aug 2015
- Status
- In Force (green)Closed: the solution is part of the standard. No further comments are taken. Show the workflow
- Part
- Part 7-2 (2010; Edition 2)
- Links
- None
- 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 |
|---|---|
|
In Force (green)
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 |
| Ballot Period | 29 Oct 15 |
| Discussion (red) 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 |