From 049847553abb51d915877ecbc9061af045f558ee Mon Sep 17 00:00:00 2001 From: Christopher Patton Date: Tue, 14 Jan 2025 09:27:21 -0800 Subject: [PATCH] Clarify rejection criterion for future reports The spec encourages rejection of reports with timestamps too far in the future. The Aggregator's action in this case is unspecified. It says if a report is rejected because it's too searly, then the Aggregator "SHOULD mark an input share rejected with error `report_too_early`". This allows for the possibility of a different error. Co-authored-by: Brandon Pitman --- draft-ietf-ppm-dap.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-ppm-dap.md b/draft-ietf-ppm-dap.md index 9781474b..468b9142 100644 --- a/draft-ietf-ppm-dap.md +++ b/draft-ietf-ppm-dap.md @@ -1876,10 +1876,10 @@ following checks: 1. Check that the input share can be decoded as specified by the VDAF. If not, the input share MUST be marked as invalid with the error `invalid_message`. -1. Check if the report is too far into the future. Implementors can provide for - some small leeway, usually no more than a few minutes, to account for clock - skew. If a report is rejected for this reason, the Aggregator SHOULD mark the - input share as invalid with the error `report_too_early`. +1. Check if the report's timestamp is too far in the future. If the report's + timestamp is more than a few minutes ahead of the current time, then the + Aggregator SHOULD mark the input share as invalid with error + `report_too_early`. 1. Check if the report's timestamp is before the task's `task_start` time. If so, the Aggregator MUST mark the input share as invalid with the error