Pass of abstract, intro, and references

Make the terminology in the intro more consistent with the rest of the
document, e.g., say "measurement" instead of "input".

For the references (cf.
cfrg/draft-irtf-cfrg-vdaf#508):

* Use "refcontent" instead of "seriesinfo" for conferences
* Use "name" instead of "ins" with the authors' full names as they
  appear in the references
* Harmonize ordering and date format

Tidy up the presentation language section:

* We want to say "encoding and encoding of messages as bytes strings are
  as in RFC8446", but for some reason we say this into the second to
  last paragraph, between two exceptions to RFC8446 we want to document.
  Move this language up to the first paragraph.

Co-authored-by: Brandon Pitman <[email protected]>

draft-ietf-ppm-dap.md

@@ -110,17 +110,18 @@ informative:
 
   Dou02:
     title: "The Sybil Attack"
-    date: 2022-10-10
-    target: "https://link.springer.com/chapter/10.1007/3-540-45748-8_24"
     author:
-      - ins: J. Douceur
+      - name: John R. Douceur
+    refcontent: "International Workshop on Peer-to-Peer Systems (IPTPS)"
+    date: 2002
+    target: https://doi.org/10.1007/3-540-45748-8_24
 
   Vad16:
     title: "The Complexity of Differential Privacy"
-    date: 2016-08-09
-    target: "https://privacytools.seas.harvard.edu/files/privacytools/files/complexityprivacy_1.pdf"
     author:
-      - ins: S. Vadhan
+      - name: Salil Vadhan
+    date: 2016
+    target: "https://privacytools.seas.harvard.edu/files/privacytools/files/complexityprivacy_1.pdf"
 
 --- abstract
 
@@ -139,15 +140,18 @@ revealing any individual user's data.
 # Introduction
 
 This document describes the Distributed Aggregation Protocol (DAP) for privacy
-preserving measurement. The protocol is executed by a large set of clients and
-two aggregator servers. The aggregators' goal is to compute some aggregate
-statistic over the clients' inputs without learning the inputs themselves. This
-is made possible by distributing the computation among the aggregators in such a
-way that, as long as at least one of them executes the protocol honestly, no
-input is ever seen in the clear by any aggregator.
+preserving measurement. The protocol is executed by a large set of clients and two
+aggregation servers. The aggregators' goal is to compute some aggregate
+statistic over measurements generated by clients without learning the
+measurements themselves. This is made possible by distributing the computation
+among the aggregators in such a way that, as long as at least one of them
+executes the protocol honestly, no measurement is ever seen in the clear by any
+aggregator.
 
 ## Change Log
 
+(RFC EDITOR: Remove this section.)
+
 (\*) Indicates a change that breaks wire compatibility with the previous draft.
 
 12:
@@ -387,28 +391,27 @@ input is ever seen in the clear by any aggregator.
 ### Glossary of Terms
 
 Aggregate result:
-: The output of the aggregation function computed over a batch of measurements
-  and an aggregation parameter. As defined in {{!VDAF}}.
+: The output of the aggregation function. As defined in {{!VDAF}}.
 
 Aggregate share:
-: A share of the aggregate result emitted by an Aggregator. Aggregate shares are
-  reassembled by the Collector into the aggregate result, which is the final
-  output of the aggregation function. As defined in {{!VDAF}}.
+: A secret share of the aggregate result computed by each Aggregator and
+  transmitted to the Collector. As defined in {{!VDAF}}.
 
 Aggregation function:
-: The function computed over the Clients' measurements. As defined in {{!VDAF}}.
+: The function computed over the measurements generated by the Clients and the
+  aggregation parameter selected by the Collector. As defined in {{!VDAF}}.
 
 Aggregation parameter:
-: Parameter used to prepare a set of measurements for aggregation. As defined in
-  {{!VDAF}}.
+: Parameter selected by the Collector used to prepare a batch of measurements
+  for aggregation. As defined in {{!VDAF}}.
 
 Aggregator:
-: A server that receives input shares from Clients and validates and aggregates
-  them with the help of the other Aggregators.
+: A server that receives report shares from Clients and validates and aggregates
+  them with the help of the other Aggregator. As defined in {{!VDAF}}.
 
 Batch:
 : A set of reports (i.e., measurements) that are aggregated into an aggregate
-  result.
+  result. As defined in {{!VDAF}}.
 
 Batch duration:
 : The time difference between the oldest and newest report in a batch.
@@ -418,28 +421,28 @@ Batch interval:
   of the reports in the batch.
 
 Client:
-: The DAP protocol role identifying a party that uploads a report. Note the
-  distinction between a DAP Client (distinguished in this document by the
-  capital "C") and an HTTP client (distinguished in this document by the phrase
-  HTTP client), as the DAP Client is not the only role that sometimes acts as an
-  HTTP client.
+: The DAP protocol role identifying a party that generates a measurement and
+  uploads a report. Note the distinction between a DAP Client (distinguished in
+  this document by the capital "C") and an HTTP client (distinguished in this
+  document by the phrase "HTTP client"), as the DAP Client is not the only role
+  that sometimes acts as an HTTP client.
 
 Collector:
-: The party that selects the aggregation parameter and receives the aggregate
+: The party that selects the aggregation parameter and computes the aggregate
   result.
 
 Helper:
-: The Aggregator that executes the aggregation and collection interactions as
-  instructed by the Leader.
+: The Aggregator that executes the aggregation and collection interactions
+  initiated by the Leader.
 
 Input share:
 : An Aggregator's share of a measurement. The input shares are output by the
   VDAF sharding algorithm. As defined in {{!VDAF}}.
 
 Output share:
 : An Aggregator's share of the refined measurement resulting from successful
-  execution of the VDAF preparation phase. Many output shares are combined into
-  an aggregate share during the VDAF aggregation phase. As defined in {{!VDAF}}.
+  execution of VDAF preparation. Many output shares are combined into an
+  aggregate share during VDAF aggregation. As defined in {{!VDAF}}.
 
 Leader:
 : The Aggregator that coordinates aggregation and collection with the Helper.
@@ -451,25 +454,29 @@ Measurement:
   {{!VDAF}}.
 
 Minimum batch size:
-: The minimum number of reports in a batch.
+: The minimum number of reports that must be aggregated before a batch can be
+  collected.
 
 Public share:
-: The output of the VDAF sharding algorithm broadcast to each of the
+: The output of the VDAF sharding algorithm transmitted to each of the
   Aggregators. As defined in {{!VDAF}}.
 
 Report:
 : A cryptographically protected measurement uploaded to the Leader by a Client.
-  Comprised of a set of report shares.
+  Includes a pair of report shares, one for each Aggregator.
 
-Report Share:
-: An encrypted input share comprising a piece of a report.
+Report share:
+: An input share encrypted under the HPKE public key of an Aggregator. The
+  report share also includes some associated data used for processing the report.
 
 {:br}
 
 ## Representation Language
 
-We use the presentation language defined in {{!RFC8446, Section 3}} to define
-messages in the DAP protocol, with the following deviations.
+With some exceptions, we use the presentation language defined in {{!RFC8446,
+Section 3}} to define messages in the DAP protocol. Encoding and decoding of
+these messages as byte strings also follows {{RFC8446}}. We enumerate the
+exceptions below.
 
 {{Section 3.7 of !RFC8446}} defines a syntax for structure fields whose values
 are constants. In this document, we do not use that notation, but use something
@@ -496,22 +503,23 @@ struct {
 ~~~
 
 Then we describe the specific variant of `ExampleStruct` where `type == number`
-with a `variant` block like so:
+with a `variant` block as follows:
 
 ~~~ tls-presentation
 variant {
   /* Field exists regardless of variant */
   uint32 always_present;
   ExampleEnum type = number;
   /* Only fields included in the `type == number`
-    variant is described */
+     variant is described */
   uint32 a_number;
 } ExampleStruct;
 ~~~
 
 The protocol text accompanying this would explain how implementations should
-handle the `always_present` and `a_number` fields but not `type`. This does not
-mean that the `type` field of `ExampleStruct` can only ever have value `number`.
+handle the `always_present` and `a_number` fields, but not the `type` field.
+This does not mean that the `type` field of `ExampleStruct` can only ever have
+value `number`; it means only that it has this type in this instance.
 
 This notation can also be used in structures where the enum field does not
 affect what fields are or are not present in the structure. For example:
@@ -538,11 +546,8 @@ variant {
 } FailedOperation;
 ~~~
 
-Encoding and decoding of these messages as byte strings also follows
-{{RFC8446}}.
-
-Finally, for variable-length vectors, the lower length limit is `0` rather than
-the length of the smallest vector.
+Finally, by convention we do not specify the lower length limit of
+variable-length vectors. Rather, the lower limit is always set to `0`.
 
 # Overview {#overview}