1038   Loss of Info Detection After Resynch

Created: 11 Mar 2013

Status: In Force (green)

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

Links:

Page: 106

Clause: 17.2.3.2.2.8

Paragraph:

Category: Issue for edition 2 of this part

Issue

Clause 17.2.3.2.2.8 says that: "The detection of possible loss of information occurs when a client requests a resynchronization to a non-existent entry...". On the other hand, clause 17.2.2.1 (when explaining BRCB state machine, resync state) says: "If the value of the set EntryID does not exist within the queue of entries, a ServiceError of parameter-value-inappropriate shall be returned and the BRCB state shall transition to disabled". According to the last statement there is no way that we can differentiate between wrong EntryID input and possible loss of information from client's point of view. More than that, having addressed to the wrong EntryID, we get no reports at all (no BufOvfl value indicated).

Proposal

The detection of possible loss of information occurs when a client requests a resynchronization to the first entry in the queue.

Discussion Created Status
24 May 13 In Force (green)
12 Apr 13 Ballot Period
I would say that to 17.2.3.2.2.8
The parameter BufOvfl shall indicate to the client that entries within the buffer may have been lost. The detection of possible loss of information occurs when a client requests a resynchronization to a non-existent entry or to the first entry in the queue.

correspond to "the note should be added clearly stating the consequences of setting an invalid EntryID (which is logically equal to setting EntryID to zero)."

No change required. 		20 Mar 13 Discussion (red)
Thierry, having checked UCA procedures I do see that one has to verify that after setting an invalid or non-existing EntryID the DUT sends all reports in the buffer. But there is no clear indication about this in the standard (part 7-2) (although there is a note about setting EntryID to zero, clause 17.2.2.15). I guess that the proposal is not to be accepted but that the note should be added clearly stating the consequences of setting an invalid EntryID (which is logically equal to setting EntryID to zero). 13 Mar 13 Discussion (red)
The standard says: as soon as the requested EntryID in the SetBRCBValues has not been found in the list, the BRCB goes to the state disabled.
1) The Report Handler shall set BufOvfl= TRUE in the first report that is sent after the transition from disabled to enabled.
[17.2.3.2.2.8]

2) A transition from disabled to enabled shall start reporting with the first available entry (i.e. oldest) in the queue of entries. Reporting of the next sequential entries shall occur.
[17.2.2.15]

This is however correct that a server does not have to keep a list of all EntryID that did once exists. So the server does not know if the request EntryID ever existed or not. Therefore, it uses the BufOvfl to reinforce that a possible lost of information may have occured.

As for the statement: we do not get reports at all (no BufOvfl value indicated) show an unproper implementation of the BRCB. The UCA testing procedure have a test case to certify proper implementation in sBr20, sBr21, sBr22.
Note that the behavior has been fixed in Edition1 also with means of TISSUE 453.

In case the client DOES not request a resynchronization to at all, before enabling the report, will also lead to a transition from disabled to enabled, i.e. equivalent to a resynchronization to the first entry in the queue.

I would not accept the proposal. 		13 Mar 13 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1