jiebi/CodeConvo huggingface dataset:
Change:
The record protection functions translate a TLSPlaintext structure into a TLSCiphertext.  The deprotection functions reverse the process.  In TLS 1.3 as opposed to previous versions of TLS, all <del> ciphers are modelled as "Authenticated Encryption with Additional </del> <ins> ciphers are modeled as "Authenticated Encryption with Additional </ins> Data" (AEAD) RFC5116.  AEAD functions provide a unified encryption and authentication operation which turns plaintext into authenticated ciphertext and back again.

Discussion:
(includes )
I'll let native speakers fix the typos next time xD
Your intuition on how to treat that last one was not wrong, but you need to know the specifics of the terminology to handle it properly. If that weren't a specific term, you'd have been correct, though usage of the word "compatible" there would've been strange. As to hyphenation, tech terminology turns hyphenated words into compound words way faster than natural language evolution. In other words, we tend to make up new words frequently and write them shorter each time. ;)
In my experience, native speakers are usually far from the best :)
Native speakers can muddle through free-form usage easily, so they don't notice how bad things might be to others. Non-native speakers can't intuitively piece together words as easily, and thus follow the rules more, which can be problematic because no verbal language actually follows its own rules fully, especially ones with lots of borrowed words. We all screw up language in different and interesting ways. :p I think a rebase is needed, as the whitespace changes were merged via your other PR. A squash of these commits into one to drop the reverted bits is probably a good idea, while you're at it.
Done, ready for merge... =)
Change:
Composition of names -- A name in the global DNS has one or more labels.  The length of each label is between 0 and 63 octets <del> inclusive.  In a fully-qualified domain name, the first label (logically speaking) is 0 octets long; it is the only label whose </del> <ins> inclusive.  In a fully-qualified domain name, the first label in the ordered list is 0 octets long; it is the only label whose </ins> length may be 0 octets, and it is called the "root" or "root label".  A domain name in the global DNS has a maximum total length of 255 octets in the wire format; the root represents one

Discussion:
Split into two pairs of commits (each first changing content and then line lengths) for easy partial acceptance, should that be desired: Improve grammar and diction Be consistent about ordering domain name labels from the root The second pair attempts to provide a consistent treatment of "domain name" as an abstract sequence of labels in directed graph order starting at the root, while maintaining clarity about wire, presentation, and common display formats rendering domain names in reverse.
Change:
proxy. The lifetime of the socket is tied to the request stream.  The proxy <del> MUST keep the socket open while the request stream is open.  Proxies MAY choose to close sockets due to a period of inactivity, but they MUST close the request stream before closing the socket.  If a proxy is notified by its operating system that its socket is no longer usable, it MUST close the request stream. </del> <ins> MUST keep the socket open while the request stream is open.  If a proxy is notified by its operating system that its socket is no longer usable, it MUST close the request stream.  Proxies MAY choose to close sockets due to a period of inactivity, but they MUST close the request stream before closing the socket.  Proxies that close sockets after a period of inactivity SHOULD NOT use a period lower than two minutes, see Section 4.3 of BEHAVE. </ins> A successful response (as defined in resp1 and resp23) indicates that the proxy has opened a socket to the requested target and is willing

Discussion:
RFC 4787 (URL) does define some default timeouts for NAT bindings for UDP. Over general Internet I would not expect that UDP flow state is mainstained longer than these default values. Thus, I think it makes sense to indicate that if the MASQUE server is recovering state for inactive UDP flows, it SHOULD NOT recover them faster than the timeout recommendation in the behave UDP RFC.
That makes sense to me, can you send a PR? Otherwise I'll add it in the next batch.
Change:
connection with error PROTOCOL_VIOLATION.  Endpoints that wish to use DATAGRAM frames need to ensure they send a max_datagram_frame_size value sufficient to allow their peer to use them.  It is RECOMMENDED <del> to send the value 65536 in the max_datagram_frame_size transport </del> <ins> to send the value 65535 in the max_datagram_frame_size transport </ins> parameter as that indicates to the peer that this endpoint will accept any DATAGRAM frame that fits inside a QUIC packet.

Discussion:
Current text says: This is nice, but I'm wondering if it should be 65535. The max UDP payload for a QUIC packet is 65527, which is lower than both. It's nice for an implementation to only need to store 16-bit integers for max datagram size to avoid excess memory, and it's of course easy to round down from 65536 to 65535, but it just seems arbitrary to have it be 1 more than the max value for a 16-bit integer...
NAME thoughts?
That sounds reasonable, 65535 is fine by me. (as long as the 1s don't take longer to travel than the 0s )
Change:
of the flag-type features that use this extension and that were declared by the ClientHello extension SHALL send this extension with the intersection of the flags it supports with the flags declared by <del> the client.  The intersection operation MAY be implemented as a bitwise AND.  The server may need to send two tls_flags extensions, one in the ServerHello and the other in the EncryptedExtensions message.  It is up to the document for the specific feature to determine whether support should be acknowledged in the ServerHello or the EncryptedExtensions message. </del> <ins> the client.  The intersection operation may be implemented as a bitwise AND.  The server may need to send multiple tls_flags extensions, up to one in each of the four response messages that may carry extensions: ServerHello (SH), EncryptedExtensions (EE), Certificate (CT), and HelloRetryRequest (HRR).  It is up to the document for the specific feature to determine which of these should be used to acknowledge support. </ins> A server MUST NOT indicate support for any flag-type feature not <del> previously indicated by the client.  It MUST NOT include this extension in either message (ServerHello or EncryptedExtensions) if it has no appropriate flag-type to indicate.  This extension MUST NOT be included empty. </del> <ins> previously indicated by the client in the ClientHello in any response message.  It MUST NOT include this extension in any of the four messages if it has no appropriate flag-type to indicate.  This extension MUST NOT be included empty. A server MAY indicate support for flag-type features in a flags extension of CertificateRequest (CR).  Flag-type extensions that have been indicated in CR (and only such extensions) MAY be also be present in a flags extension of the Certificate (CT) message sent by the client.  However, a client MUST NOT indicate support for any flag-type feature in a Certificate message that was not previously indicated by the server in its CertificateRequest message. A server MAY indicate support for flag-type features in a flags extension of NewSessionTicket (NST).  This message has no client-side response. In summary, unsolicited flags may appear only in ClientHello, CertificateRequest, and NewSessionTicket. </ins> 4.

Discussion:
All messages that carry extensions can have a tls_flags extension: CH, SH, EE, Cert, NST
NAME can you please respond to the comments above?
Ping NAME :-)
Done.
I might have framed this slightly differently, but this accurately captures the outcome of the discussion. Thanks for doing this.
Change:
2.4. <del> There are certain operations that an application MUST be able to perform when interacting with QUIC streams.  This document does not specify an API, but any implementation of this version of QUIC MUST expose the ability to perform the operations described in this section on a QUIC stream. </del> <ins> This document does not define an API for QUIC, but instead defines a set of functions on streams that application protocols can rely upon. An application protocol can assume that an implementation of QUIC provides an interface that includes the operations described in this section.  An implementation designed for use with a specific application protocol might provide only those operations that are used by that protocol. </ins> <del> On the sending part of a stream, application protocols need to be able to: </del> <ins> On the sending part of a stream, an application protocol can: </ins> write data, understanding when stream flow control credit (data- flow-control) has successfully been reserved to send the written

Discussion:
The strong requirements here were wrong. What is necessary from these sections is defining operations in QUIC that application protocols can depend on being present. Levying the requirement on implementations was incorrect. As some application protocols don't use certain QUIC features, it is not necessary to require implementations to support features if they are not general purpose. This rephrases these requirements without normative language, instead concentrating on what services the application protocol can depend on. This translates into requirements on implementations, but only via the application protocols they intend to support.
S 5.4 requires that the application be able to control resource allocation of various types, including flow control and the number of permitted streams of each type; This seems like a good idea, but it seems like one could have a reasonable QUIC stack that did not do this.
I would prefer to leave this. Noting that the level of control is not specified. This also suggests that the stack provide a keep-alive control, but there are likely cases (I'm thinking here of DNS over QUIC) where that is unlikely to be a useful feature. The goal is to list things that the specification believes a generic stack will provide. Maybe we could avoid the implication that such an implementation is incomplete by saying that specialized implementations might provide less than a complete API.
NAME willing to fight for this one?
After discussing with editors, we think that it would be better to remove the MUST in this section and say something like: "A general purpose QUIC implementation provides the following functions:" and add "A specialized implementation might provide a subset of these." The same applies to the stream operations.
I think that is a positive change. Borderline design issue by the sound of it. It would be good to see the PR once its available.
Change:
9.3. <del> QUIC, TLS, and HTTP/2 all contain messages that have legitimate uses in some contexts, but that can be abused to cause a peer to expend processing resources without having any observable impact on the state of the connection.  If processing is disproportionately large in comparison to the observable effects on bandwidth or state, then this could allow a malicious peer to exhaust processing capacity without consequence. While there are legitimate uses for some redundant packets, implementations SHOULD track redundant packets and treat excessive volumes of any non-productive packets as indicative of an attack. 9.4. </del> Header protection relies on the packet protection AEAD being a pseudorandom function (PRF), which is not a property that AEAD algorithms guarantee.  Therefore, no strong assurances about the

Discussion:
Issue observes that this text mentions HTTP/2, which isn't necessary. In reviewing it, I noticed that this talks about messages that do nothing, but not really about messages that do little (or that can be reversed to have net zero effect). So I expanded the text a little.
Thanks for improving the section's clarity. As a follow up question, when implementations decide that excessive packets is an attack, is there a recommended actionable (eg. sending reset, dropping the connection, do nothing) or would that be up for implementer's discretion?
Maybe this needs to be stated explicitly, but there is no point in continuing discussion with an attacker. So while it might be considered polite to send a connection error, it is also acceptable to just drop any further incoming packets. I'll add that here.
Under the section Peer Denial of Service of TLS draft, a referenced was made to HTTP/2. URL I was wonder if this is in fact referring to HTTP/3 or HTTP/2. Also curious why the section is labelled
That mention of h2 was a mistake. I've made a few changes after reviewing this. (The thing is a joke.)
Change:
Each encryption level is associated with a different sequence of bytes, which is reliably transmitted to the peer in CRYPTO frames. When TLS provides handshake bytes to be sent, they are appended to <del> the current flow.  Any packet that includes the CRYPTO frame is protected using keys from the corresponding encryption level.  Four encryption levels are used, producing keys for Initial, 0-RTT, </del> <ins> the handshake bytes for the current encryption level.  Any packet that includes the CRYPTO frame is protected using keys from the corresponding encryption level. Four encryption levels are used, producing keys for Initial, 0-RTT, </ins> Handshake, and 1-RTT packets.  CRYPTO frames are carried in just three of these levels, omitting the 0-RTT level.  These four levels correspond to three packet number spaces: Initial and Handshake

Discussion:
This also adds a paragraph about buffering of CRYPTO frames that references the buffering text in the transport doc. Closes no issue, but there have been complaints.
Change:
could send more data to an unwilling target than a CONNECT proxy. However, in practice denial of service attacks target open TCP ports so the TCP SYN-ACK does not offer much protection in real scenarios. <del> Proxies MUST NOT introspect the contents of UDP payloads as that would lead to ossification of UDP-based protocols by proxies. </del> 8.

Discussion:
the target has to indicate its willingness to accept TCP connections by responding with a TCP SYN-ACK before the proxy can send it application data. UDP doesn't have this property, so a UDP proxy could send more data to an unwilling target than a CONNECT proxy. However, in practice denial of service attacks target open TCP ports so the TCP SYN-ACK does not offer much protection in real scenarios. Proxies MUST NOT introspect the contents of UDP payloads as that would lead to ossification of UDP-based protocols by proxies. This seems like an RFC 6919 "MUST (but we know you won't)"
Agreed. Are you proposing a change to the draft?
Yes. I would remove the last sentence. OTOH, given that the status of proxies is still under discussion maybe we just wait on this one.
Change:
In the specific case of ingest into a platform, some assumption can be made about the server-side which simplifies the webrtc compliance <del> burden, as detailled in webrtc-gateway document. </del> <ins> burden, as detailed in webrtc-gateway document. </ins> https://tools.ietf.org/html/draft-ietf-rtcweb-gateways-02 <del> This document proposse a simple protocol for supporting WebRTC as </del> <ins> This document proposes a simple protocol for supporting WebRTC as </ins> ingest method which is: - Easy to implement, - As easy to use as current RTMP URI.  - Fully compliant with Webrtc and RTCWEB specs.  - <del> Allow for both ingest in traditionnal media platforms for extention </del> <ins> Allow for both ingest in traditional media platforms for extention </ins> and ingest in webrtc end-to-end platform for lowest possible latency. - Lowers the requirements on both hardware encoders and broadcasting services to support webrtc.  - Usable both in web browsers and in

Discussion:
Authtentication, bearear, proposse, detailled, endpoings, adption, traditionnal.
Thank you very much!
Change:
If a DNS API server responds to a DNS API client with a DNS message that has the TC (truncation) bit set in the header, that indicates that the DNS API server was not able to retrieve a full answer for <del> the query over TCP and is providing the best answer it could get. This protocol does not require that a DNS API server that cannot get an untruncated answer send back such an answer; it can instead send back an HTTP error to indicate that it cannot give a useful answer. </del> <ins> the query and is providing the best answer it could get.  This protocol does not require that a DNS API server that cannot get an untruncated answer send back such an answer; it can instead send back an HTTP error to indicate that it cannot give a useful answer. </ins> 10.

Discussion:
Fixes to PR
It doesn't feel to me like "beyond what is already in {{RFC1035}}" really clarifies anything, and might just cause additional confusion, as it makes me as a reader wonder, "oh well what's in 1035? Guess I have to go searching..."
If you want to put the specific limit from RFC 1035 in, that's fine.
Well no, because I don't think there should be a limit. While DNS messages implicitly have a maximum size of 64k in DNS, there's no reason dns-udpwireformat in HTTPS can't surpass that.
NAME It would be an interoperability problem if a DNS API server handed a DNS API client a message that it could not handle. It is reasonable to assume that DNS API clients expect to parse messages as if they were DNS messages.
NAME This was sloppy on my part: I meant the addition to point to RFC 6891; now changed.
Right NAME but my point is that something like multiple AXFR messages re-assembled into one unit is still a DNS message even if it exceeds 64k. From a wire-format point of view, it parses exactly the same way.
NAME Really? Ugh. Gotta love this protocol. So, you would prefer that the text says "URL this protocol allows DNS-on-the-wire format payloads of any size"?
Yes, I would. Realistically almost everything is still going to be sub-10k, but I don't see an intrinsic need to limit it, especially with https channels routinely handling far larger responses.
I think David and I are now in agreement; NAME should consider accepting.
Change:
For AMR/AMR-WB, packets can contain copies or lower-quality encodings of multiple prior audio frames.  This mechanism is similar to the <del> RFC2198 mechanism described above, but as it adds no additional framing, it can be slightly more efficient.  See RFC4867, </del> <ins> redundant encoding mechanism described above, but as it adds no additional framing, it can be slightly more efficient.  See RFC4867, </ins> Section 3.7.1 for details on this mechanism. In-band FEC mechanisms cannot recover any of the RTP header.

Discussion:
While reading the document, I wrote down the following notes that the editor may take into account when revising the document: in 3.1, expland SSRC on first usage and say that this is about sending streams over RTP somewhere early on (I assume this is implied by using the term WebRTC but for outsiders like me it may help to be more specific). Acknowledged. stylistic: I am not a big fan of using citations like '[RFC2198]' as ordinary words or nouns, it makes text difficult to follow unless you know the RFC numbers by heart and your brain translates them back to something meaningful on the fly. This makes texts more difficult to read for outsiders. Example: This mechanism is similar to the [RFC2198] mechanism described above. I prefer this: This mechanism is similar to the redundant encoding mechanism described above. There are couple of such usages of [RFCXXXX] in the document OK. add reference for PCMU OK. Reminder to self, RFC 5391.
Change:
An entity (typically a manufacturer) whose Endorsements help Verifiers appraise the authenticity of Evidence <del> A set of information about an Attester that is to be appraised by a Verifier.  Evidence may include configuration data, measurements, telemetry, or inferences. </del> <ins> A set of Claims generated by an Attester to be appraised by a Verifier.  Evidence may include configuration data, measurements, telemetry, or inferences. </ins> An entity (typically a manufacturer) whose Reference Values help Verifiers appraise Evidence to determine if acceptable known

Discussion:
Signed-off-by: Dave Thaler
` What’s the difference between claim and evidence? Maybe you start with a Claim, then sign it and that makes it into Evidence? Is Evidence a ‘set of claims’? [and what’s the difference between a ‘set of information’ and ‘information’?]
Maybe "A signed set of Claims about an Attester..."? (Want to make sure it's not "just" a set of claims, since the signing is important too.)
Change:
In this example, the simplest possible handshake is completed.  The server is authenticated, but the client remains anonymous.  After connecting, a few application data octets are exchanged.  The server <del> sends a session ticket that permits the use of 0-RTT in any resumed session. </del> <ins> sends a session ticket that permits the use of 0-RTT data in any resumed session. </ins>

Discussion:
"IV" is usually capitalized, and a couple of grammar nits. I couldn't figure out what "PRK" meant in the (generated) output; should that be expanded?
I think Sean had tried to clue me in a while ago, but I only just now realized, that it would be nice if this one could be in the same cluster as the core spec, but doing that (basically) requires going through IETF LC/etc. while the test vectors are still for a draft version. So I'd like to kick things off soon and we can see how long it takes. Please do drop a new rev, though; no need to have genart pester us again.
Change:
If the multipath option is enabled with a value of 2, each path has its own packet number space for transmitting 1-RTT packets and a new <del> ACK frame format is used as specified in mp-ack-frame.  Compared to the QUIC v1 ACK frame, the MP_ACK frames additionally contains a </del> <ins> ACK frame format is used as specified in ack-mp-frame.  Compared to the QUIC v1 ACK frame, the ACK_MP frames additionally contains a </ins> Packet Number Space Identifier (PN Space ID).  The PN Space ID used to distinguish packet number spaces for different paths and is simply derived from the sequence number of Destination Connection ID.

Discussion:
This should be a simple fix. There was only one place where MP_ACK appeared.
In the current draft, we are having two names of multi-path ACK. I think we should stick to just one.
I have a slight preference for ACKMP, on the model of ACKECN.
I submitted PR to fix this.
I would be consistent in how the I-D identifies MP additions vs. RFC9000. Given that the document uses MPCONNECTIONERROR and MPPROTOCOLVIOLATION, I have a preference for MP_ACK.
I added changes of the tag "mp-ack-frame" to "ack-mp-frame" for consistency...
Change:
IETF 108 meeting: https://www.youtube.com/watch?v=ZaRsk0y3O9k&t=2m48s <ins> MOPS 2020-10-30 Interim meeting: https://www.youtube.com/watch?v=vDZKspv4LXw&t=17m15s </ins> 2. 2.1.

Discussion:
…nd update public discussion venues
I left the previous description of Sanjay Mishra's presentation, but removed the sub-references in that description (which included the problematic ATT reference).
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?
Change:
also support the imposition and disposition of the required DetNet encapsulation.  These are functionally similar to pseudowire (PW) Terminating Provider Edge (T-PE) nodes which use MPLS-TE LSPs.  In <del> this example TSN Streams are simple applicaions over DetNet flows. </del> <ins> this example TSN Streams are simple applications over DetNet flows. </ins> The specific of this operation are discussed later in this document. In this example, edge nodes provide a service proxy function that

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)