jiebi/TextFlow huggingface dataset:
Original text:
of contexts, and they MAY do so in a way which is opaque to intermediaries. <del> 4.3. </del>  The CLOSE_DATAGRAM_CONTEXT capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer that it will

Reviewer comments:
Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.

Revised text:
of contexts, and they MAY do so in a way which is opaque to intermediaries.  <ins> 4.4.3. </ins> The CLOSE_DATAGRAM_CONTEXT capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer that it will
Original text:
extension, the endpoint MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. <del> 4.4. </del>  The DATAGRAM capsule (see iana-types for the value of the capsule type) allows an endpoint to send a datagram frame over an HTTP

Reviewer comments:
Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.

Revised text:
extension, the endpoint MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR.  <ins> 4.4.4. </ins> The DATAGRAM capsule (see iana-types for the value of the capsule type) allows an endpoint to send a datagram frame over an HTTP
Original text:
8. <del> We can provide DATAGRAM support in HTTP/2 by defining the CAPSULE frame in HTTP/2. We can provide DATAGRAM support in HTTP/1.x by defining its data stream format to a sequence of length-value capsules. TODO: Refactor this document and add definitions for HTTP/1.x and HTTP/2. 9. </del> Since this feature requires sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a server supports this feature.  Implementations that support this

Reviewer comments:
Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.

Revised text:
8.  Since this feature requires sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a server supports this feature.  Implementations that support this
Original text:
the fact that there are applications using HTTP/3 datagrams enabled on this endpoint. <del> 10. 10.1. This document will request IANA to register the following entry in the "HTTP/3 Frames" registry: </del>  <del> 10.2. </del>  This document will request IANA to register the following entry in the "HTTP/3 Settings" registry: <del> 10.3. </del>  This document establishes a registry for HTTP capsule type codes. The "HTTP Capsule Types" registry governs a 62-bit space.

Reviewer comments:
Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.

Revised text:
the fact that there are applications using HTTP/3 datagrams enabled on this endpoint.  <ins> 9. </ins>  <ins> 9.1. </ins> This document will request IANA to register the following entry in the "HTTP/3 Settings" registry:  <ins> 9.2. </ins> This document establishes a registry for HTTP capsule type codes. The "HTTP Capsule Types" registry governs a 62-bit space.
Original text:
A name or label for the capsule type. <del> The value of the Capsule Type field (see capsule-frame) is a 62bit integer. </del>  An optional reference to a specification for the type.  This field MAY be empty.

Reviewer comments:
Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.

Revised text:
A name or label for the capsule type.  <ins> The value of the Capsule Type field (see capsule-protocol) is a 62bit integer. </ins> An optional reference to a specification for the type.  This field MAY be empty.
Original text:
arbitrary values.  These values MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. <del> 10.4. </del>  This document establishes a registry for HTTP datagram context extension type codes.  The "HTTP Context Extension Types" registry

Reviewer comments:
Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.

Revised text:
arbitrary values.  These values MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values.  <ins> 9.3. </ins> This document establishes a registry for HTTP datagram context extension type codes.  The "HTTP Context Extension Types" registry
Original text:
assigned by IANA and MUST NOT appear in the listing of assigned values. <del> 10.5. </del>  This document establishes a registry for HTTP context extension type codes.  The "HTTP Context Close Codes" registry governs a 62-bit

Reviewer comments:
Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.

Revised text:
assigned by IANA and MUST NOT appear in the listing of assigned values.  <ins> 9.4. </ins> This document establishes a registry for HTTP context extension type codes.  The "HTTP Context Close Codes" registry governs a 62-bit
Original text:
5.6. <del> In addition to measurements media players use to guide their segment- by-segment adaptive streaming requests, streaming media providers may also rely on measurements collected from media players to provide analytics that can be used for decisions such as whether the adaptive encoding bitrates in use are the best ones to provide to media players, or whether current media content caching is providing the best experience for viewers.  To that effect, the Consumer Technology Association (CTA) who owns the Web Application Video Ecosystem (WAVE) project has published two important specifications. 5.6.1. </del>  CTA-2066 specifies a set of media player events, properties, quality of experience (QoE) metrics and associated terminology for

Reviewer comments:
LGTM
From NAME The very first sentence is mostly unparseable due to its length (7 lines). Please consider splitting it.
I added this, from NAME review: This section and the next one should be a list with 2 bullets rather than 2 sections to make the text more readable.

Revised text:
5.6.  <ins> Media players use measurements to guide their segment-by-segment adaptive streaming requests, but may also provide measurements to streaming media providers. In turn, providers may base analytics on these measurements, to guide decisions such as whether adaptive encoding bitrates in use are the best ones to provide to media players, or whether current media content caching is providing the best experience for viewers. To that effect, the Consumer Technology Association (CTA) who owns the Web Application Video Ecosystem (WAVE) project has published two important specifications. CTA-2066: Streaming Quality of Experience Events, Properties and Metrics </ins> CTA-2066 specifies a set of media player events, properties, quality of experience (QoE) metrics and associated terminology for
Original text:
defining a common terminology as well as how each metric should be computed for consistent reporting. <del> 5.6.2. </del>  Many assume that the CDNs have a holistic view into the health and performance of the streaming clients.  However, this is not the case.

Reviewer comments:
LGTM
From NAME The very first sentence is mostly unparseable due to its length (7 lines). Please consider splitting it.
I added this, from NAME review: This section and the next one should be a list with 2 bullets rather than 2 sections to make the text more readable.

Revised text:
defining a common terminology as well as how each metric should be computed for consistent reporting.  <ins> CTA-5004: Common Media Client Data (CMCD) </ins> Many assume that the CDNs have a holistic view into the health and performance of the streaming clients.  However, this is not the case.
Original text:
4.1. <del> (To the editor: check this repository URL after the draft is adopted. The working group may create its own repository) </del>  <del> This document is in the Github repository at https://github.com/GrumpyOldTroll/ietf-mops-drafts.  Readers are welcome to open issues and send pull requests for this document. </del>  Substantial discussion of this document should take place on the MOPS working group mailing list (mops@ietf.org).  4.2. Presentations: IETF 105 BOF: https://www.youtube.com/watch?v=4G3YBVmn9Eo&t=47m21s <del> IETF 106 Mops meeting: https://www.youtube.com/ </del>  watch?v=4_k340xT2jM&t=7m23s <del> List archive search for doc mentions: https://mailarchive.ietf.org/arch/browse/mops/?q=draft-ietf-mops- streaming-opcons </del> 5. This document requires no actions from IANA.

Reviewer comments:
I actually used the URL in the draft to clone a copy, so I think this is good to go.

Revised text:
4.1.  <ins> This document is in the Github repository at: </ins>  <ins> https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons Readers are welcome to open issues and send pull requests for this document. </ins> Substantial discussion of this document should take place on the MOPS working group mailing list (mops@ietf.org). <ins> Join: https://www.ietf.org/mailman/listinfo/mops Search: https://mailarchive.ietf.org/arch/browse/mops/ </ins> 4.2. Presentations: IETF 105 BOF: https://www.youtube.com/watch?v=4G3YBVmn9Eo&t=47m21s  <ins> IETF 106 meeting: https://www.youtube.com/ </ins> watch?v=4_k340xT2jM&t=7m23s  5. This document requires no actions from IANA.
Original text:
Media servers can provide media streams at various bitrates because the media has been encoded at various bitrates.  This is a so-called "ladder" of bitrates that can be offered to media players as part of <del> the manifest that describes the media being requested by the media player, so that the media player can select among the available </del>  bitrate choices. The media server may also choose to alter which bitrates are made

Reviewer comments:
looks good.
From NAME
NAME and NAME - I'm not sure who wrote this text, except I don't think it was me. >And as with other parts of the ecosystem, new technology brings new challenges. For example, with the emergence of ultra-low-latency streaming, responses have to start streaming to the end user while still being transmitted to the cache, and while the cache does not yet know the size of the object. Some of the popular caching systems were designed around cache footprint and had deeply ingrained assumptions about knowing the size of objects that are being stored, so the change in design requirements in long-established systems caused some errors in production. Incidents occurred where a transmission error in the connection from the upstream source to the cache could result in the cache holding a truncated segment and transmitting it to the end user's device. In this case, players rendering the stream often had the video freeze until the player was reset. In some cases the truncated object was even cached that way and served later to other players as well, causing continued stalls at the same spot in the video for all players playing the segment delivered from that cache node. NAME was curious if there's a reasonable reference that we could provide for this.
Yeah, that was me. There was not a public reference for this, alas, just a word of mouth anecdote.
NAME - I agree with you about your comment on Section 3.6. It happens that I got comments that Section 3.6 and 3.7 didn't need to be nearly as detailed as they were, so they were heavily rewritten. The text where "throttled" was used is now in Section 3.6.1, and the emphasis is now on the cause of unexpected traffic profile changes, rather than the ISP response to the unexpected traffic profile changes in this specific incident, so the text that included "throttled" has been removed.
NAME - I agree with your comment on Section 4.4, that some description or reference should be provided for the word "manifest". The next occurrence of "manifest" is in Section 5.2, which does provide a description. I don't think that's quite right - I'd say So I'm changing this definition, and moving it to the first occurrence of "manifest" in Section 4.4. Thanks for helping us fix problems you didn't even tell us about. :upsidedownface:
lgtm

Revised text:
Media servers can provide media streams at various bitrates because the media has been encoded at various bitrates.  This is a so-called "ladder" of bitrates that can be offered to media players as part of  <ins> the manifest, so that the media player can select among the available </ins> bitrate choices. The media server may also choose to alter which bitrates are made
Original text:
MUST be in the same order.  The leader's endpoint MUST be the first in the list.  The order of the "encrypted_input_shares" in a "Report" (see uploading-reports) MUST be the same as the order in <del> which aggregators appear in this list. </del>  "max_batch_lifetime": The maximum number of times a batch of reports may be used in collect requests.

Reviewer comments:
All protocol request messages contain a field, which allows aggregators to service multiple tasks from a single set of endpoints. The exception is : since it is an HTTP GET request, there is no body, and thus no place for the client to indicate the desired to the aggregator. We don't want to introduce a request body to , because then it would have to be a POST instead of a GET, and that would make it harder for implementations to cache HPKE config values. So instead we have clients encode the task ID in RFC 4648 Base16 (a.k.a. hexadecimal) and provide it as a query parameter. See issue
My goal here is to enable our aggregator implementations in the interop target to use one HPKE config per task. The alternative to this would be for us to use aggregator endpoints that somehow incorporate the task ID, as I described , which is already permitted by the spec as written.
The Base64 alphabet includes , and , which means you have to URL encode (a.k.a. percent encode) Base64 strings before you can use them in a URL, which is a chore and yields less readable URLs (not that 64 character hex strings is especially user-friendly). An alternative would be to use RFC 4648's , omitting the padding characters as suggested in since task IDs are of a known length.
Gotcha. I think the main thing is to be consistent. I would either: Change this PR to use base64url; or Tack on a commit that makes all encodings of the taskID (except those that appear in the body, of course) the same (i.e., hexadecimal). I think (2.) would be my preference.
I agree with the consistency argument. I'm leaning towards using everywhere because it's more compact than Base16/hex, and also I think implementations are less likely to be surprised by case requirements in base64url (i.e., it's obvious that base64 is case sensitive, but you have to read RFC 4648 attentively to notice that it mandates uppercase hex strings).
Base64Url sounds good to me. I took a quick look and it appears that most standard base64 libraries also support the URL encoding.
I will clean this up and merge it once I have implemented it in Janus and convinced myself it's sound.
SGTM, but why not base64 encode the taskID for consistency with URL

Revised text:
MUST be in the same order.  The leader's endpoint MUST be the first in the list.  The order of the "encrypted_input_shares" in a "Report" (see uploading-reports) MUST be the same as the order in  <ins> which aggregators appear in this list.  Aggregators MAY use the same endpoint for multiple tasks. </ins> "max_batch_lifetime": The maximum number of times a batch of reports may be used in collect requests.
Original text:
Initialize VDAF preparation and initial outputs as described in input-share-prep. <del> [[OPEN ISSUE: consider moving the helper nonce check into #early- </del>  input-share-validation]] Once the helper has processed each valid report share in

Reviewer comments:
Justify text after bullets consistenly Make sure all lines break at 80 characters
LGTM, modulo conflicts. It'd be nice if we had a linter that blocked PRs until their formatting was right, since changes like this taint git history.

Revised text:
Initialize VDAF preparation and initial outputs as described in input-share-prep.  <ins> [[OPEN ISSUE: consider moving the helper nonce check into early- </ins> input-share-validation]] Once the helper has processed each valid report share in
Original text:
The last input comprises the randomness consumed by the sharding algorithm.  The sharding randomness is a random byte string of length specified by the VDAF.  The Client MUST generate this using a <del> cryptographicallly secure random number generator. </del>  The Client then wraps each input share in the following structure:

Reviewer comments:
As of draft-irtf-cfrg-vdaf-05 (not yet published), the random coins used for sharding are an explicit parameter of . Add this parameter and explasin how it is generated.
NAME I believe this is the only API change we need to account for, correct?

Revised text:
The last input comprises the randomness consumed by the sharding algorithm.  The sharding randomness is a random byte string of length specified by the VDAF.  The Client MUST generate this using a  <ins> cryptographically secure random number generator. </ins> The Client then wraps each input share in the following structure:
Original text:
Each report share has a corresponding task ID, report metadata (report ID and, timestamp), the public share sent to each Aggregator, and the recipient's encrypted input share.  Let "task_id", <del> "metadata", "public_share", and "encrypted_input_share" denote these values, respectively.  Given these values, an aggregator decrypts the input share as follows.  First, it constructs an "InputShareAad" message from "task_id", "metadata", and "public_share".  Let this be denoted by "input_share_aad".  Then, the aggregator looks up the HPKE config and corresponding secret key indicated by "encrypted_input_share.config_id" and attempts decryption of the payload with the following procedure: </del>  where "sk" is the HPKE secret key, and "server_role" is the role of the aggregator ("0x02" for the leader and "0x03" for the helper).

Reviewer comments:
All references to "metadata" are now to "report_metadata". References to "CollectReq" are now "CollectionReq". References to "CollectResp" are now "Collection".
The current version of the draft renames field "metadata" to "report_metadata" in the Report structure, but does not do the same renaming in the ReportShare and InputShareAad structures. I think this naming should be consistent, though I don't have a preference between the alternatives.
Thanks for pointing this out! Can you send prepare a PR?
Fixed in
Thanks a bunch NAME

Revised text:
Each report share has a corresponding task ID, report metadata (report ID and, timestamp), the public share sent to each Aggregator, and the recipient's encrypted input share.  Let "task_id",  <ins> "report_metadata", "public_share", and "encrypted_input_share" denote these values, respectively.  Given these values, an aggregator decrypts the input share as follows.  First, it constructs an "InputShareAad" message from "task_id", "report_metadata", and "public_share".  Let this be denoted by "input_share_aad".  Then, the aggregator looks up the HPKE config and corresponding secret key indicated by "encrypted_input_share.config_id" and attempts decryption of the payload with the following procedure: </ins> where "sk" is the HPKE secret key, and "server_role" is the role of the aggregator ("0x02" for the leader and "0x03" for the helper).
Original text:
Implementation note: The Leader considers a batch to be collected once it has completed a collection job for a <del> CollectReq message from the Collector; the Helper considers a batch to be collected once it has responded to an </del>  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.

Reviewer comments:
All references to "metadata" are now to "report_metadata". References to "CollectReq" are now "CollectionReq". References to "CollectResp" are now "Collection".
The current version of the draft renames field "metadata" to "report_metadata" in the Report structure, but does not do the same renaming in the ReportShare and InputShareAad structures. I think this naming should be consistent, though I don't have a preference between the alternatives.
Thanks for pointing this out! Can you send prepare a PR?
Fixed in
Thanks a bunch NAME

Revised text:
Implementation note: The Leader considers a batch to be collected once it has completed a collection job for a  <ins> CollectionReq message from the Collector; the Helper considers a batch to be collected once it has responded to an </ins> 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.
Original text:
the hash values with a bitwise-XOR operation. Then, for each Aggregator endpoint "{aggregator}" in the parameters <del> associated with "CollectReq.task_id" (see collect-flow) except its </del>  own, the Leader sends a POST request to "{aggregator}/tasks/{task- id}/aggregate_shares" with the following message:

Reviewer comments:
All references to "metadata" are now to "report_metadata". References to "CollectReq" are now "CollectionReq". References to "CollectResp" are now "Collection".
The current version of the draft renames field "metadata" to "report_metadata" in the Report structure, but does not do the same renaming in the ReportShare and InputShareAad structures. I think this naming should be consistent, though I don't have a preference between the alternatives.
Thanks for pointing this out! Can you send prepare a PR?
Fixed in
Thanks a bunch NAME

Revised text:
the hash values with a bitwise-XOR operation. Then, for each Aggregator endpoint "{aggregator}" in the parameters  <ins> associated with "CollectionReq.task_id" (see collect-flow) except its </ins> own, the Leader sends a POST request to "{aggregator}/tasks/{task- id}/aggregate_shares" with the following message:
Original text:
4.5.6. <del> Before an Aggregator responds to a CollectReq or AggregateShareReq, it must first check that the request does not violate the parameters associated with the DAP task.  It does so as described here. </del>  First the Aggregator checks that the batch respects any "boundaries" determined by the query type.  These are described in the subsections

Reviewer comments:
All references to "metadata" are now to "report_metadata". References to "CollectReq" are now "CollectionReq". References to "CollectResp" are now "Collection".
The current version of the draft renames field "metadata" to "report_metadata" in the Report structure, but does not do the same renaming in the ReportShare and InputShareAad structures. I think this naming should be consistent, though I don't have a preference between the alternatives.
Thanks for pointing this out! Can you send prepare a PR?
Fixed in
Thanks a bunch NAME

Revised text:
4.5.6.  <ins> Before an Aggregator responds to a CollectionReq or AggregateShareReq, it must first check that the request does not violate the parameters associated with the DAP task.  It does so as described here. </ins> First the Aggregator checks that the batch respects any "boundaries" determined by the query type.  These are described in the subsections