jiebi/CodeConvo huggingface dataset:
Code change:
PR in response to Al's OPSDIR review -- Reviewer: Al Morton Review result: Has Nits Hi David, this is the OPS-DIR review. I tried to stay in my lane. I found this paragraph confusing (which doesn't mean it is incorrect, just that someone with limited background read the section 2 requirements list, all MUSTs, and then the paragraph below, which seems to have a conflicting MUST with the SHOULD and MAY that follows). Help readers like me understand the options you are allowing here: If the client detects that any of the requirements above are not met by a URI Template, the client MUST reject its configuration and fail the request without sending it to the UDP proxy. While clients SHOULD validate the requirements above, some clients MAY use a general-purpose URI Template implementation that lacks this specific validation. I see that Christer's GEN_ART review picked-up on this too (I looked after I was done...). In Section 5, there seems to be a possible operations issue for proxy operators: Clients MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request. However, implementors should note that such proxied packets may not be processed by the UDP proxy if it responds to the request with a failure, or if the proxied packets are received by the UDP proxy before the request. This seems like a good place to limit the amount of optimistic traffic, given that the request is not yet accepted. (also, would the optimistic traffic use Context ID zero?) In Performance Considerations UDP proxies SHOULD strive to avoid increasing burstiness of UDP traffic: they SHOULD NOT queue packets in order to increase batching. This requirement is written qualitatively, so users might "know a violation if they see it", but not hold the proxy system/operator to any specific performance without providing more details here. Inter-packet delay variation measurements on proxy ingress and egress would characterize increased burstiness well. Another solution is s/SHOULD/should/ (I doubt some increased burstiness will be avoidable, or enforceable.) Thanks in advance for considering these comments, Al

Related discussion:
text: contains the unmodified payload of a UDP packet (referred to as "data octets" in UDP). <del> Clients MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request. However, implementors should note that such proxied packets may not be processed by the UDP proxy if it responds to the request with a failure, or if the proxied packets are received by the UDP proxy before the request. </del> By virtue of the definition of the UDP header UDP, it is not possible to encode UDP payloads longer than 65527 bytes.  Therefore, endpoints MUST NOT send HTTP Datagrams with a Payload field longer than 65527
Code change:
This text was a mistake I made when converting from Datagram-Flow-Id to capsules.
Section 4 states that the proxy responds to a CONNECT-UDP request with 2xx and a corresponding registration capsule to indicate end-to-end support of datagrams. If the client sends a REGISTERDATAGRAMCONTEXT capsule, the corresponding capsule from the proxy will be of the same kind, and it will register a new server-generated context ID. So now we would have two context IDs for the same stream, which seems a bit unnecessary. Could we simply omit the step where the proxy sends a registration capsule and simply state that a 2xx response to the CONNECT-UDP request is sufficient indication of end-to-end datagram support?
My reading of the spec is different, URL says So for example, if the client sends a request on stream 4 and then REGISTERDATAGRAMCONTEXT { Context ID (0)}, the server will respond with REGISTERDATAGRAMCONTEXT { Context ID (0)} to confirm that the context is accepted.
That makes sense, I was assuming that the "used in both directions" referred to datagrams. I think my confusion in part came from the same section that says: But sending a registration capsule with an already registered context ID is not a new registration I suppose. Maybe it's good to clarify this a bit in the datagram spec. I'll open a separate issue there.
I agree the draft is a bit ambiguous here.
Indeed, the spec is unclear here, my apologies. I got this wrong when I rewrote the old Datagram-Flow-Id text. The server doesn't need to echo the registration capsule here since the client's registration is bidirectional. NAME we should add text to HTTP Datagrams to clarify what we want to do about echoing registrations, is it required allowed forbidden I'm leaning towards (3) unless we have a use case for communicating the fact that a context is "accepted" and in which case I'd say (2).
Aha! In that case I apologise too. This seems important for interop! Now I remember, I think some people felt registration ack wasn't needed as long as there was a way to reject. And we have that with CLOSEDATAGRAMCONTEXT. So I think (3), modelled as implicit accept and explicit close, sounds good. That cuts down the chatter (and probably simplifies some code in my implementation).

Related discussion:
text: consider its CONNECT-UDP request as failed. The proxy that is creating the UDP socket to the destination responds <del> to the CONNECT-UDP request with a 2xx (Successful) response, and indicates it supports HTTP Datagrams by sending the corresponding registration capsule. </del> <ins> to the CONNECT-UDP request with a 2xx (Successful) response. </ins> Clients MAY optimistically start sending proxied UDP packets before receiving the response to its CONNECT-UDP request, noting however
Code change:
A proxy can receive a UDP packet from an origin to a client that cannot fit within a DATAGRAM frame, given either the limit set by the maximum datagram frame size, or based on the current path MTU. In this case, one solution is for the proxy to generate ICMP errors back to the sender. If that sender implements PMTU discovery, it should adjust its size.
I think adding advice here is good, though we can't mandate sending ICMP because most OSes don't let user space applications send ICMP.
Yes, we can't mandate it, but we should recommend it I think. For a full-blown production server, it should be possible.
Recommendation seems sensible. Although this does get me thinking about what the expectations of fragmentation are, we can't expect all UDP protocols to set DF.
The DATAGRAM capsule type offers one way to address this. Capsules can be arbitrarily large, because they'll be reassembled by QUIC. If it won't fit in a QUIC DATAGRAM and you don't want to drop it, it goes in a DATAGRAM capsule. Now, that might not always be desirable, because capsules don't have all the behavior that causes you to choose datagrams in the first place; a proxy that behaves that way will mess with PMTUD, and in the degenerate case cause the server to select an MTU back to the client that always gets encoded in capsules. Perhaps the client should be able to inform the server whether it prefers oversize messages to be tunneled or dropped?

Related discussion:
text: 5.1. <ins> When using HTTP/3 with the QUIC Datagram extension DGRAM, UDP payloads are transmitted in QUIC DATAGRAM frames.  Since those cannot be fragmented, they can only carry payloads up to a given length determined by the QUIC connection configuration and the path MTU.  If a proxy is using QUIC DATAGRAM frames and it receives a UDP payload from the target that will not fit inside a QUIC DATAGRAM frame, the proxy SHOULD NOT send the UDP payload in a DATAGRAM capsule, as that defeats the end-to-end unreliability characteristic that methods such as Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) depend on RFC8899.  In this scenario, the proxy SHOULD drop the UDP payload and send an ICMP "Packet Too Big" message to the target RFC4443. 5.2. </ins> UDP proxying does not create an IP-in-IP tunnel, so the guidance in RFC6040 about transferring ECN marks between inner and outer IP headers does not apply.  There is no inner IP header in UDP proxying
Code change:
recovery (e.g., [QUIC]), and the underlying HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery mechanisms. This can reduce performance as both can sometimes independently retransmit the same data. To avoid this, HTTP/3 datagrams SHOULD be used. This text could maybe be clearer. Is it trying to say "You SHOULD use H3 + Datagram" or "You SHOULD use H3 and if you do you should use datagram". I.e., is it possible to use H3 but not datagram?
You're right, this is unclear. That text predates the refactor of HTTP/3 Datagram to HTTP Datagrams, so we should tweak it to say "To avoid this, UDP proxying SHOULD be performed over HTTP/3 to allow leveraging the QUIC DATAGRAM frame."

Related discussion:
text: recovery (e.g., QUIC), and the underlying HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery mechanisms.  This can reduce performance as both can sometimes <del> independently retransmit the same data.  To avoid this, HTTP/3 datagrams SHOULD be used. </del> <ins> independently retransmit the same data.  To avoid this, UDP proxying SHOULD be performed over HTTP/3 to allow leveraging the QUIC DATAGRAM frame. </ins> 6.1.
Code change:
In Section 2 we start with the statement So let's just use that clearer description in the abstract and introduction too,

Related discussion:
text: the security and congestion-control properties of QUIC.  However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC <del> DATAGRAM frames when the application protocol running over QUIC is HTTP/3.  It associates datagrams with client-initiated bidirectional streams.  Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </del> <ins> DATAGRAM frames with HTTP/3 by association with HTTP requests. Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </ins> 1.
Code change:
In Section 2 we start with the statement So let's just use that clearer description in the abstract and introduction too,

Related discussion:
text: leveraging the security and congestion-control properties of QUIC. However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC <del> DATAGRAM frames when the application protocol running over QUIC is HTTP/3 H3.  It associates datagrams with client-initiated bidirectional streams.  Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </del> <ins> DATAGRAM frames with HTTP/3 H3 by association with HTTP requests. Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </ins> This document is structured as follows:
Code change:
As discussed at IETF 110, some MASQUE servers may prefer to avoid sticking out (i.e. they may wish to be indistinguishable from a non-MASQUE-capable HTTP/3 server). The H3_DATAGRAM SETTINGS parameter may stick out. Therefore, we should add a note about this to the Security Considerations section. A simple solution could be to encourage widespread HTTP/3 servers to always send this.

Related discussion:
text: 8. <del> This document does not have additional security considerations beyond those defined in QUIC and DGRAM. </del> <ins> 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 feature SHOULD always send this Settings parameter to avoid leaking the fact that there are applications using HTTP/3 datagrams enabled on this endpoint. </ins> 9.
Code change:
This is based on the post-IETF 107 MOPS meeting where we talked about this. I chased some more references.
We should try to improve this reference - it's a long page, additions are at the top, so we have to either scroll for a long time or search for the date to get the relevant part of the page. Maybe reach out to ATT to get fragment tags that work?

Related discussion:
text: Operational Considerations for Streaming Media <del> draft-ietf-mops-streaming-opcons-00 </del> <ins> draft-ietf-mops-streaming-opcons-01 </ins> Abstract
Code change:
This is based on the post-IETF 107 MOPS meeting where we talked about this. I chased some more references.
We should try to improve this reference - it's a long page, additions are at the top, so we have to either scroll for a long time or search for the date to get the relevant part of the page. Maybe reach out to ATT to get fragment tags that work?

Related discussion:
text: watch for increasing numbers of end users uploading significant amounts of content. <ins> 2.6. The causes of unpredictable usage described in sec-unpredictable were more or less the result of human choices, but we were reminded during a post-IETF 107 meeting that humans are not always in control, and forces of nature can cause enormous fluctuations in traffic patterns. In his talk, Sanjay Mishra Mishra reported that after the CoViD-19 pandemic broke out in early 2020, Comcast's streaming and web video consumption rose by 38%, with their reported peak traffic up 32% overall between March 1 to March 30 Comcast, AT&T reported a 28% jump in core network traffic (single day in April, as compared to pre stay-at-home daily average traffic), with video accounting for nearly half of all mobile network traffic, while social networking and web browsing remained the highest percentage (almost a quarter each) of overall mobility traffic ATT, and Verizon reported similar trends with video traffic up 36% over an average day (pre COVID-19) Verizon. We note that other operators saw similar spikes during this time period.  Craig Labowitz Labovitz reported Weekday peak traffic increases over 45%-50% from pre-lockdown levels, A 30% increase in upstream traffic over their pre-pandemic levels, and A steady increase in the overall volume of DDoS traffic, with amounts exceeding the pre-pandemic levels by 40%. (He attributed this increase to the significant rise in gaming-related DDoS attacks (LabovitzDDoS), as gaming usage also increased.) </ins> 3. 3.1.
Code change:
Ali, this PR looks nice. Two meta-issues (which we can talk about whenever). I changed my references in the draft to a more complete format (using ins: can result in odd formatting in the References section). We don't have to do that for all the references in -04, but that would be a good thing to do in an editorial pass. I see that you're making some terminology changes (from "delivery" to "streaming", stuff like that). I agree with the changes you made in this PR, but we may want to make sure that they are made globally, for consistency.
I was not sure about the reference format, normally I just use the casual format: Authors, "Title," Journal/Conference, Date. I saw the missing author names and realized "ins" would do the trick. By no means, I am tied to that format - don't know even know what "ins" stands for here :)
From URL : "as in the author list, ins is an abbreviation for "initials/surname";" I tend to think an editorial pass on references would be better as a separate commit, where they need cleaning. Anything that somehow made it in and breaks the "make" needs fixing, but others maybe later?
I suggest a definition along these lines: Streaming is transmission of a continuous content from a server to a client and its simultaneous consumption by the client. ("simultaneous" is the key here) This has two implications: 1) Server transmission rate (loosely or tightly) matches to client consumption rate. That is, no buffer overrun or underrun is desirable/acceptable. 2) Client consumption rate is also limited by real-time constraints as opposed to just bandwidth availability. That is, client cannot fetch the content not available yet.
+1, this sgtm. But this probably implies a refactor of the intro section and the abstract, to better focus on the relevant use case.
I can take a crack at this.
Ali has text for this, will create a PR for the issue.

Related discussion:
text: Abstract This document provides an overview of operational networking issues <del> that pertain to quality of experience in delivery of video and other </del> <ins> that pertain to quality of experience in streaming of video and other </ins> high-bitrate media over the internet. 1.
Code change:
Ali, this PR looks nice. Two meta-issues (which we can talk about whenever). I changed my references in the draft to a more complete format (using ins: can result in odd formatting in the References section). We don't have to do that for all the references in -04, but that would be a good thing to do in an editorial pass. I see that you're making some terminology changes (from "delivery" to "streaming", stuff like that). I agree with the changes you made in this PR, but we may want to make sure that they are made globally, for consistency.
I was not sure about the reference format, normally I just use the casual format: Authors, "Title," Journal/Conference, Date. I saw the missing author names and realized "ins" would do the trick. By no means, I am tied to that format - don't know even know what "ins" stands for here :)
From URL : "as in the author list, ins is an abbreviation for "initials/surname";" I tend to think an editorial pass on references would be better as a separate commit, where they need cleaning. Anything that somehow made it in and breaks the "make" needs fixing, but others maybe later?
I suggest a definition along these lines: Streaming is transmission of a continuous content from a server to a client and its simultaneous consumption by the client. ("simultaneous" is the key here) This has two implications: 1) Server transmission rate (loosely or tightly) matches to client consumption rate. That is, no buffer overrun or underrun is desirable/acceptable. 2) Client consumption rate is also limited by real-time constraints as opposed to just bandwidth availability. That is, client cannot fetch the content not available yet.
+1, this sgtm. But this probably implies a refactor of the intro section and the abstract, to better focus on the relevant use case.
I can take a crack at this.
Ali has text for this, will create a PR for the issue.

Related discussion:
text: further.  In this case, the immersive content is typically referred to as volumetric media.  One way to represent the volumetric media is to use point clouds, where streaming a single object may easily <del> require a bitrate of 30 Mbps or higher.  Refer to PCC for more details. </del> <ins> require a bitrate of 30 Mbps or higher.  Refer to MPEGI and PCC for more details. </ins> 2.2.
Code change:
We've been getting help from people, but the ACKs section hasn't changed much since -03 was submitted in November 2020.
I found like two names that we had missed, and added them to the ACKs section. I think we can merge this any time.

Related discussion:
text: 9. <del> Thanks to Mark Nottingham, Glenn Deen, Dave Oran, Aaron Falk, Kyle Rose, Leslie Daigle, Lucas Pardue, Matt Stock, Alexandre Gouaillard, and Mike English for their very helpful reviews and comments. </del> <ins> Thanks to Alexandre Gouaillard, Aaron Falk, Dave Oran, Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Roni Even, and Will Law for very helpful suggestions, reviews and comments. (If we missed your name, please let us know!) </ins> 10.  References
Code change:
Section 3.1 says to include the PPM task ID in a field on the problem details JSON object, but the task ID may be any 32 byte value, and may not be representable as a Unicode string. I propose that we base64-encode the task ID here to resolve this.

Related discussion:
text: errors.  The "instance" value MUST be the endpoint to which the request was targeted.  The problem document MUST also include a "taskid" member which contains the associated PPM task ID, encoded <del> with base64 RFC4648 (this value is always known, see task- configuration). </del> <ins> with base64 using the standard alphabet RFC4648 (this value is always known, see task-configuration). </ins> In the remainder of this document, we use the tokens in the table above to refer to error types, rather than the full URNs.  For
Code change:
Would be helpful to readers if this reference was fixed in the Editor's Copy: [I-D.draft-cfrg-patton-vdaf] " BROKEN REFERENCE ".
Maybe change each reference to ? That way it'll render like in the text, which reads a bit nicer.

Related discussion:
text: This protocol is extensible and allows for the addition of new cryptographic schemes that implement the VDAF interface specified in <del> I-D.draft-cfrg-patton-vdaf.  Candidates include: </del> <ins> VDAF.  Candidates include: </ins> "prio3", which allows for aggregate statistics such as sum, mean, histograms, etc.  This class of VDAFs is based on Prio CGB17 and
Code change:
Would be helpful to readers if this reference was fixed in the Editor's Copy: [I-D.draft-cfrg-patton-vdaf] " BROKEN REFERENCE ".
Maybe change each reference to ? That way it'll render like in the text, which reads a bit nicer.

Related discussion:
text: client ever sees the values for individual clients. In order to address this problem, the aggregators engage in a secure, <del> multi-party computation specified by the chosen VDAF I-D.draft-cfrg- patton-vdaf in order to prepare a report for aggregation.  At the beginning of this computation, each aggregator is in possession of an input share uploaded by the client.  At the end of the computation, each aggregator is in posession of either an "output share" that is ready to be aggregated or an indication that a valid output share could not be computed. </del> <ins> multi-party computation specified by the chosen VDAF VDAF in order to prepare a report for aggregation.  At the beginning of this computation, each aggregator is in possession of an input share uploaded by the client.  At the end of the computation, each aggregator is in posession of either an "output share" that is ready to be aggregated or an indication that a valid output share could not be computed. </ins> To facilitiate this computation, the input shares generated by the client include information used by the aggregators during aggregation
Code change:
Would be helpful to readers if this reference was fixed in the Editor's Copy: [I-D.draft-cfrg-patton-vdaf] " BROKEN REFERENCE ".
Maybe change each reference to ? That way it'll render like in the text, which reads a bit nicer.

Related discussion:
text: "vdaf_verify_param": The aggregator's VDAF verification parameter output by the setup algorithm computed jointly by the aggregators <del> before the start of the PPM protocol I-D.draft-cfrg-patton-vdaf). [OPEN ISSUE: This is yet to be specified.  See issue#161.] </del> <ins> before the start of the PPM protocol VDAF).  [OPEN ISSUE: This is yet to be specified.  See issue#161.] </ins> Finally, the collector is configured with the HPKE secret key corresponding to "collector_hpke_config".
Code change:
The only language I can find in the document that prescribes serialization is in Section 1.2 (please point out if I missed anything): We intend this statement to be prescriptive, i.e., encoding/decoding of messages is as defined in RFC8446. Another valid interpretation might be "we define the fields of each message following the conventions of RFC8446, but leaving encoding/decoding unspecified". I think it would help to refine this statement a bit. WDYTA:
SGTM FWIW (this was our interpretation, and I think it makes sense to clarify)
Yeah, this seems like a fine clarification. I don't think it was under specified before, but more information for those unfamiliar with TLS-style encoding doesn't hurt.

Related discussion:
text: The following terms are used: <del> This document uses the presentation language of RFC8446. </del> <ins> This document uses the presentation language of RFC8446 to define messages in the PPM protocol.  Encoding and decoding of these messages as byte strings also follows RFC8446. </ins> 2.