While implementing https://www.w3.org/TR/compute-pressure/#data-delivery, step 6.2.1 and 6.2.2, I noticed a missing element in the specs.

Case 1:
During observationWindowTime, no source is going over the states changeCountThreshold.
The ObservationWindow is then reset. This is ok.

Case 2:
During observationWindowTime, one source is going over the states changeCountThreshold.
The PenaltyTimer is started.
any new record change during penalty is saved into AfterPenaltyRecordMap.
When PenaltyTimer is over, AfterPenaltyRecordMap(source) record is queued for reporting.

The main issue in Case2, is what to do after Case 2 with the ObservationWindow?
solutionA) Resetting the window, will then hide other "issues" with other sources. For example what if an attackers keeps on attacking source1 (Strong frequency attack) and source2 (softer frequency attack). Source1 will always take the penalty, but source2 never, because source1 will always reset the window before penalty is triggered on source2. So this doesn't sound like an option.

solutionB) Resetting the ChangeCount[source] after penalty and letting the ObservationWindow finishing its time, is maybe a better solution but it still involves some problems which are not defined in the specs.

What if the penalty is triggered close to the end of the ObservationWindow lifetime and the penalty is longer than the time left in the ObservationWindow.
While taking the penalty, the ObservationWindow will be reset, and if we choose solution B), we will be reseting the countChange of the next ObservationWindow.

I believe Case 2, should be define better in the specs, on what to do with the window and its members in case of penalty.