Original text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> [[TODO: Clean up this glossary]] </del> The following terms are used: <del> Aggregation function: The function computed over the users' inputs. Aggregator: An endpoint that runs the input-validation protocol and accumulates input shares. Batch: A set of reports that are aggregated into an output. Batch size: The minimum number of reports in a batch. Batch window: The minimum time difference between the oldest and newest report in a batch (in seconds). Client: The endpoint from which a user sends data to be aggregated, e.g., a web browser. Collector: The endpoint that receives the output of the aggregation function.  It also specifies the parameters of the protocol. False input: An input that is valid, but incorrect.  For example, if the data being gathered is whether or not users have clicked on a particular button, a client could report clicks when none occurred. Input: The measurement (or measurements) emitted by a client, before any encryption or secret sharing scheme is applied. Input share: one of the shares output by feeding an input into a secret sharing scheme.  Each share is to be transmitted to one of the participating aggregators. Input validation protocol: The protocol executed by the client and aggregators in order to validate the client's input without leaking its value to the aggregators. Invalid input: An input for which the input validation protocol fails.  For example, if the input is meant to be a bit vectors, then "[2, 1, 0]" is invalid. Measurement: A single value (e.g., a count) being reported by a client.  Multiple measurements may be grouped into a single protocol input. Leader: A distinguished aggregator that coordinates input validation and data collection. Output: A reduction over the inputs, for instance a statistical aggregation, which is of interest to a collector.  This is the output of the aggregation function. Output share: The share of an output emitted by an aggregator. Output shares can be reassembled by the leader into the final output. Prio v1: Mozilla's Origin Telemetry project [1]. Prio v2: Contact tracing project by Apple, Google, and ISRG. Proof: A value generated by the client and used by the aggregators to verify the client's input. Proof share: A share of a proof, used by an aggregator during the input-validation protocol. Report: Uploaded to the leader from the client.  A report contains the secret-shared and encrypted input and proof. Server: An aggregator or collector. </del> This document uses the protocol definition language of RFC8446. 2. participants know that at least one aggregator is defective, and it may be possible to identify the defector (i.e., if a majority of runs agree, and a single aggregator appears in every run that disagrees). <del> See #22 [2] for discussion. </del>  6.7. 13.1.  URIs <del> [1] https://blog.mozilla.org/security/2019/06/06/next-steps-in- privacy-preserving-telemetry-with-prio/ [2] https://github.com/abetterinternet/prio-documents/issues/22 </del> 

Reviewer comments:
This is just converting to defn. list format. I'm going to submit a separate PR to clean up the contents.

Revised text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  The following terms are used:  This document uses the protocol definition language of RFC8446. 2. participants know that at least one aggregator is defective, and it may be possible to identify the defector (i.e., if a majority of runs agree, and a single aggregator appears in every run that disagrees).  <ins> See #22 [1] for discussion. </ins> 6.7. 13.1.  URIs  <ins> [1] https://github.com/abetterinternet/prio-documents/issues/22 </ins>