Draft: draft-ietf-ppm-dap

Commentary: Continue editorial pass up to the collection flow . Along , clarify an ambiguity in the mapping of VDAF preparation to DAP aggregation initialization / continuation . In particular , is meant to take in the " preperation message " from the previous round and output either ( 1 ) the Aggregator 's output share or ( 2 ) the Aggregator 's next preparation sate and next " preparation message - share " . We are currently using the term " inbound message " for the former and " outbound message " for the latter . This seems to be causing us to conflate " preparation message " with " preparation message - share " , which may result in misunderstanding the protocol flow . 
 Reviewer note : This change is meant to be strictly editorial , so I 'm hoping it 'll be straightforward to review . That said , it 's quite big , so I 'd be happy to split it up if desired .
Paragraph (version A):
Once a set of clients have uploaded their reports to the leader, the
leader can send them to the helpers to be verified and aggregated.
In order to enable the system to handle very large batches of
reports, this process can be performed incrementally.  Verification
of a set of reports is referred to as an aggregation job.  Each
aggregation job is associated with exactly one DAP task, and a DAP
task can have many aggregation jobs.  Each job is associated with an
ID that is unique within the context of a DAP task in order to
distinguish different jobs from one another.  Each aggregator uses
this ID as an index into per-job storage, e.g., to keep track of
report shares that belong to a given aggregation job.
Paragraph (version A):
To run an aggregation job, the leader sends a message to each helper
containing the report shares in the job.  The helper then processes
them (verifying the proofs and incorporating their values into the
ongoing aggregate) and replies to the leader.
Paragraph (version B):
Once a set of Clients have uploaded their reports to the Leader, the
Leader can begin the process of verifying and aggregating them with
the Helpers.  To enable the system to handle very large batches of
reports, this process can be parallelized across smaller sets of
reports.  Verification of a set of reports is referred to as an
"aggregation job".  Each aggregation job is associated with exactly
one DAP task, and a DAP task can have many aggregation jobs.  Each
job is associated with an ID that is unique within the context of a
DAP task in order to distinguish different jobs from one another.
Each aggregator uses this ID as an index into per-job storage, e.g.,
to keep track of report shares that belong to a given aggregation
job.
Paragraph (version B):
To run an aggregation job, the Leader sends a request to each Helper
containing the report shares in the job.  Each Helper then processes
them (verifying the proofs and incorporating their values into the
ongoing aggregate) and responds to the Leader.
Paragraph (version A):
For each valid report share, initialize the VDAF preparation
process.
Paragraph (version B):
For each valid report share, initialize the VDAF preparation
process (see VDAF).
Paragraph (version A):
The opaque, VDAF-specific aggregation parameter provided during
the collection flow ("agg_param"),
Paragraph (version B):
"agg_param": The opaque, VDAF-specific aggregation parameter
provided during the collection flow (collect-flow),
Paragraph (version A):
The sequence of report shares to aggregate.  The
"encrypted_input_share" field of the report share is the
"HpkeCiphertext" whose index in "Report.encrypted_input_shares" is
equal to the index of the aggregator in the task's
"aggregator_endpoints" to which the "AggregationJobInitReq" is
being sent.
Paragraph (version B):
This field is called the "partial" batch selector because,
depending on the query type, it may not determine a batch.  In
particular, if the query type is "time_interval", the batch is not
determined until the Collector's query is issued (see query).
Paragraph (version B):
"report_shares": The sequence of report shares to aggregate.  The
"encrypted_input_share" field of the report share is the
"HpkeCiphertext" whose index in "Report.encrypted_input_shares" is
equal to the index of the aggregator in the task's
"aggregator_endpoints" to which the "AggregationJobInitReq" is
being sent.
Paragraph (version A):
Each helper begins their portion of the aggregate initialization
phase with the set of candidate report shares obtained in an
"AggregationJobInitReq" message from the leader.  It attempts to
recover and validate the corresponding input shares similar to the
leader, and eventually returns a response to the leader carrying a
VDAF-specific message for each report share.
Paragraph (version B):
Each Helper begins their portion of the aggregate initialization when
they receive an AggregationJobInitReq message from the Leader.  For
each ReportShare conveyed by this message, the Helper attempts to
initialize VDAF preparation (see VDAF) just as the Leader does.  If
successful, it includes its prepare message in its response that the
Leader will use to continue the process.
Paragraph (version A):
Check that the decrypted input share can be decoded.  If not, the
input share MUST be marked as invalid with the error
"unrecognized_message".
Paragraph (version B):
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 "unrecognized_message".
Paragraph (version A):
Check if the report's timestamp has passed its task's
"task_expiration" time, if so the Aggregator MAY mark the input
share as invalid with the error "task_expired".
Paragraph (version A):
Check if the PlaintextInputShare contains unrecognized extensions.
If so, then the Aggregator MUST mark the input share as invalid
with error "unrecognized_message".
Paragraph (version A):
Check if the ExtensionType of any two extensions in
PlaintextInputShare is the same.  If so, then the Aggregator MUST
mark the input share as invalid with error "unrecognized_message".
Paragraph (version B):
Check if the report's timestamp has passed the task's
"task_expiration" time.  If so, the Aggregator MAY mark the input
share as invalid with the error "task_expired".
Paragraph (version B):
Check if the PlaintextInputShare contains unrecognized extensions.
If so, the Aggregator MUST mark the input share as invalid with
error "unrecognized_message".
Paragraph (version B):
Check if the ExtensionType of any two extensions in
PlaintextInputShare are the same.  If so, the Aggregator MUST mark
the input share as invalid with error "unrecognized_message".
Paragraph (version B):
If the report pertains to a batch that was previously collected,
then make sure the report was already included in all previous
collections for the batch.  If not, the input share MUST be marked
as invalid with error "batch_collected".  This prevents Collectors
from learning anything about small numbers of reports that are
uploaded between two collections of a batch.
Paragraph (version B):
Implementation note: The Leader considers a batch to be
collected once it has completed a collection job for a
CollectReq message from the Collector; the Helper considers a
batch to be collected once it has responded to an
AggregateShareReq message from the Leader.  A batches is
determined by query (query) conveyed in these messages.
Queries must satisfy the criteria covered in batch-validation.
These criteria are meant to restrict queries in a way make it
easy to determine wither a report pertains to a batch that was
collected.
Paragraph (version A):
An initial VDAF state and preparation message, denoted
"(prep_state, prep_msg)".
Paragraph (version A):
If either step fails, the aggregator marks the report as invalid with
error "vdaf_prep_error".  Otherwise, the value "out" is interpreted
as follows.  If this is the last round of the VDAF, then "out" is the
aggregator's output share.  Otherwise, "out" is the pair
"(prep_state, prep_msg)".
Paragraph (version A):
During the aggregation job initialization (leader-init) or
continuation (agg-continue-flow) phases, the Leader will receive an
"AggregationJobResp" message from the Helper, which should be
validated before the Leader can move to the next phase of the
aggregation protocol.
Paragraph (version B):
An initial VDAF state and preparation message-share, denoted
"(prep_state, prep_share)".
Paragraph (version B):
If either step fails, the Aggregator marks the report as invalid with
error "vdaf_prep_error".  Otherwise, the value "out" is interpreted
as follows.  If this is the last round of the VDAF, then "out" is the
aggregator's output share.  Otherwise, "out" is the pair
"(prep_state, prep_share)".
Paragraph (version B):
During the aggregation job initialization (leader-init) or
continuation (agg-continue-flow) phases, the Leader will receive an
"AggregationJobResp" message from the Helper, which needs to be
validated before the Leader can move to the next phase of the
aggregation protocol.
Paragraph (version A):
where "[leader_outbound, helper_outbound]" is a vector of two
elements.  If either of these operations fails, then the leader marks
the report as invalid.  Otherwise it interprets "out" as follows: If
this is the last round of the VDAF, then "out" is the aggregator's
output share, in which case the aggregator finishes and stores its
output share for further processing as described in collect-flow.
Otherwise, "out" is the pair "(new_state, prep_msg)", where
"new_state" is its updated state and "prep_msg" is its next VDAF
message (which will be "leader_outbound" in the next round of
continuation).  For the latter case, the helper sets "prep_state" to
"new_state".
Paragraph (version B):
where "[leader_prep_share, helper_prep_share]" is a vector of two
elements.  If either of these operations fails, then the leader marks
the report as invalid with error "prep_share_failed".  Otherwise it
interprets "out" as follows: If this is the last round of the VDAF,
then "out" is the Leader's output share, in which case it stores the
output share for further processing as described in collect-flow.
Otherwise, "out" is the pair "(next_prep_state, next_prep_share)",
where "next_prep_state" is its updated state and "next_prep_share" is
its next preparation message-share (which will be "leader_prep_share"
in the next round of continuation).  For the latter case, the helper
sets "prep_state" to "next_prep_state".
Paragraph (version A):
An error, in which case the input report share is marked as
invalid.
Paragraph (version A):
An updated VDAF state and preparation message, denoted
"(prep_state, prep_msg)".
Paragraph (version A):
If failed, then mark the report as failed and reply with a failed
PrepareStep to the leader.
Paragraph (version A):
If finished, then mark the report as finished and reply with a
finished PrepareStep to the leader.  The helper then stores the
output share and awaits for collection; see collect-flow.
Paragraph (version B):
An error, in which case the report share is marked as invalid.
Paragraph (version B):
Its next VDAF preparation state and message-share, denoted
"(next_prep_state, next_prep_share)".
Paragraph (version B):
If the status is "failed", then mark the report as failed and
reply with a failed PrepareStep to the Leader.
Paragraph (version B):
If the status is "finished", then mark the report as finished and
reply with a finished PrepareStep to the leader.  The Helper then
stores the output share and awaits collection; see collect-flow.
Paragraph (version A):
An updated VDAF state and preparation message, denoted
"(prep_state, prep_msg)", in which case the Helper replies to the
Leader with a "PrepareStep" in the "continued" state containing
"prep_msg".
Paragraph (version B):
An updated VDAF state and preparation message-share, denoted
"(next_prep_state, next_prep_msg)", in which case the Helper
replies to the Leader with a "PrepareStep" in the "continued"
state containing "prep_share".
Paragraph (version A):
If the "round" in the Leader's request is equal to the Helper's
current round (i.e., this is not the first time the Leader has sent
this request), then the Helper responds with the current round's
prepare messages.  The Helper SHOULD verify that the contents of the
"AggregationJobContinueReq" are identical to the previous message
(see aggregation-round-skew-recovery).
Paragraph (version B):
If the "round" in the Leader's request is equal to the Helper's
current round (i.e., this is not the first time the Leader has sent
this request), then the Helper responds with the current round's
prepare message-shares.  The Helper SHOULD verify that the contents
of the "AggregationJobContinueReq" are identical to the previous
message (see aggregation-round-skew-recovery).