1441 Optonal fields in buffered reports
- Created
- 24 Sep 2015
- Status
- In Force (green)Closed: the solution is part of the standard. No further comments are taken. Show the workflow
- Part
- Part 8-1 (2011; Edition 2)
- Links
- None
- Page
- Clause
- 17.2.2
- Paragraph
- 17.2.3.2.2.3
- Category
- Issue may impact interoperability of implementations of Edition 2
Issue
This chapter specifies that changing optional fields does not purge the reports stored already in the buffer. The clause is not clear if the reports/events already stored in the buffer before the optional field change may/should/shall be transmitted on the Ethernet with the original optional fields or with the new optional fields.
Proposal
Considering this is a very rare case in operational substations we propose to make this a "local issue". The old reports may be transmitted with the original optional fields at the creation time or the new optional fields at the time of transmitting over the Ethernet
| Discussion | Created |
|---|---|
| In Force (green) | 16 Dec 15 |
|
Ballot Period
Loss of data should be avoided if possible, especially in a BRCB. Based upon the proposal in Tissue 1453, a write of the same OptFld value will not cause a purgeBuf. I agree with Thierry that a change of the OptFld value shall not cause a purgeBuf.
The proposal is the following: A V-Put of OptFld shall not cause a purgeBuf. |
16 Oct 15 |
|
Discussion (red)
Agree, it is a 7-2 issue. However, 7-2 does not say that a change of the option fields does not purge the buffer; it just does not make this purge mandatory, leaving the option for both: reformatting or purging. From actual use cases it does not make sense for a client to change the option fields somewhere in between a reporting process. This is only done if a new client connects - and this is mostly not interested in 'old' buffer contents.
|
24 Sep 15 |
|
Discussion (red)
1) this is not an 8-1 issue, if at all, a 7-2 issue.
2) this is a responsability of the implementation to take care of what to store in its internal buffer so that it can any time send the entries using the option field that are required at the time of the tranmission and not the one that were selected at the time of the storage. The not purge is on purpose as changing the optional field only change the meta data and not the way the entries are stored. I propose to turn the issue to blue |
24 Sep 15 |