jiebi/CodeConvo huggingface dataset:
Change:
parsed as specified in I-D.ietf-ice-trickle, Section 8.2, and its presence or absence flagged and stored. <del> Any "a=fingerprint" lines are parsed as specified in RFC4572, </del> <ins> Any "a=fingerprint" lines are parsed as specified in RFC8122, </ins> Section 5, and the set of fingerprint and algorithm values is stored.

Discussion:
I don't know why build of ghpages is failing travis. It works for me on my machine so going to ignore this for a bit.
Here is the diff of the change.
BLOCKER: The nits tool reports (and a cursory hand check supports this) that six of the references are unused, and RFC4572 has been (recently) obsoleted. The remaining references are largely out of date by many versions, which I believe the current tools will automatically handle if version numbers are simply pulled out of the source. Finally, a large number of the referenced working group documents still use the individual name (e.g., draft-nandakumar-rtcweb-sdp instead of draft-ietf-rtcweb-sdp).
Need to verify section numbers when these refs change, but otherwise seems fine.
LGTMLG, assuming this generates the equivalent text.
Change:
2.1.1. To request a single access token, the client instance sends an <del> "acccess_token" object composed of the following fields. </del> <ins> "access_token" object composed of the following fields. </ins> The values of the "flags" field defined by this specification are as follows:

Discussion:
type, - beit -> be it,
To edit notification comments on pull requests, go to your .
"beit" isn't a word, it should be "be it".
As I was reading through the latest version of the draft, I spotted a typo within section 2.1.1. It should says accesstoken object, not acccess_token object.
Change:
explicit signal of the intended version to the other members of group when they receive the KeyPackage in an Add proposal. <del> The "capabilities" field in the "leaf_node" allows MLS session establishment to be safe from downgrade attacks on the parameters described (as discussed in group-creation), while still only advertising one version / ciphersuite per KeyPackage. </del> <ins> The field "leaf_node.capabilities" indicates what protocol versions, ciphersuites, protocol extensions, and non-default proposal types are supported by the client.  (Proposal types defined in this document are considered "default" and not listed.)  This information allows MLS session establishment to be safe from downgrade attacks on the parameters described (as discussed in group-creation), while still only advertising one version / ciphersuite per KeyPackage. The field "leaf_node.leaf_node_source" of the LeafNode in a KeyPackage MUST be set to "key_package". </ins> <del> The "leaf_node_source" field of the LeafNode in a KeyPackage MUST be set to "key_package". </del> <ins> Extension included in the "extensions" or "leaf_node.extensions" fields MUST be included in the "leaf_node.capabilities" field. </ins> 11.1.

Discussion:
This PR picks up changes from clarifying and cleaning up a few issues around LeafNode.
A big improvement in readability and correctness.
Change:
handshake, the server's transmission of the NewSessionTicket, and KeyUpdate messages.  ACKs SHOULD NOT be sent for other complete flights because they are implicitly acknowledged by the receipt of <del> the next flight, which generally immediately follows the flight. </del> <ins> the next flight, which generally immediately follows the flight, unless generating the responding flight takes significant time.  In this case, implementations MAY send explicit ACKs for the complete received flight even though it will eventually also be implicitly acknowledged through the responding flight.  A notable example for this is the case of post-handshake client authentication in constrained environments, where generating the CertificateVerify message can take considerable time on the client. </ins> Each NewSessionTicket or KeyUpdate is an individual flight; in particular, a KeyUpdate sent in response to a KeyUpdate with update_requested does not implicitly acknowledge that message.

Discussion:
Hanno Becker writes: I have a minor comment on DTLS 1.3 draft 37. On the topic of sending ACKs, the draft recommends: I wonder if the case of post-handshake authentication should be explicitly mentioned as a potential exception to this rule, since the TLS 1.3 RFC explicitly mentions that responses to may be delayed in some contexts: In this case, it would be beneficial to immediately explicitly ACK the message even though it is also implicitly acked through the eventual response via the message.
Change:
Replace the IP address of the ICE host candidate with the name with ".local" appended to it.  Expose the candidate. <ins> This procedure ensures that a mDNS name is used to replace only one IP address.  Specifically an ICE agent using an interface with both IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. </ins> 2.2. For any remote host ICE candidate received by the ICE agent, the

Discussion:
Some additional comments may be needed in the prflx section?
NAME I went ahead and added a commit for my proposed changes. Let me know if the proposed changes are fine with you.
NAME Did you only commit the html changes? Can you include the markdown?
Oh, I probably messed up with the commit. I was expecting to commit only the markdown. I'll fix it.
It is conceivable that a server would implement ICE with mDNS candidates. There should be nothing in the ICE candidate processing that prevents this from working. Therefore we should call out what should happen when an mDNS query returns multiple IP addresses. E.g. use the 'best' on (where IPv6 is better than IPv4)?
This is a complex area. A simpler option could be that we mandate 1:1 for mDNS, and/or pick the first address of the expected type.
Mandating 1:1 for mDNS in the context of WebRTC is probably the straightforward approach. We should probably also define the behavior in the case of multiple responses, picking the first record makes sense to me. This requirement causes a potential issue when using MDNS for non default route though: it creates a fingerprinting vector by counting the number of different MDNS names for a given peer connection. I am not sure what reliable means we have to know the expected type of the address and whether this is a requirement at all. The easy solution would be to include this information in the MDNS name.
Good point about type not being known a priori, and we could put a hint in the name. Another option could be to resolve the name before forming pairs, take the first record found, and then only pair the resolved address with local candidates of the appropriate family.
Fixed by
LGTM with one comment
Change:
3.1. A single consists of a key identifier, a public key, an identifier <del> for the KEM that the public key uses, and a set HPKE symmetric </del> <ins> for the KEM that the public key uses, and a set of HPKE symmetric </ins> algorithms.  Each symmetric algorithm consists of an identifier for a KDF and an identifier for an AEAD.

Discussion:
"and a set HPKE" => "and a set of HPKE"
Thanks for the quick review and approval, NAME I haven't used the GitHub UI for submitting PRs in a long time so please pardon my lack of understanding here but I still don't see a way to merge the PR. Does it also need a review from NAME ?
NAME it doesn't technically need a review from Martin. The pattern we seem to have landed on is that one of us merges once both approve, but this is simple enough that I just merged it now. Thanks for sending the PR!
Change:
an order that results in usable leaf nodes whenever there are multiple branch types that could be used from a single node. <del> The order of operations for branching, where lower numbers are acted upon first, should be: </del> <ins> The order of operations for branching should be: </ins> Alternate Paths

Discussion:
These are mostly wording changes for clarification. Feel free to cherry pick.
Can't find any problems here - this looks good.
This LGTM, many thanks!
Change:
"InitiateWithSend" or "Listen" calls.  At the peer, the event RESET_STREAM-EVENT.SCTP will fire, which the peer must answer by issuing RESET_STREAM.SCTP too.  The resulting local RESET_STREAM- <del> EVENT.SCTP informs the transport system that the stream number can now be re-used by the next "Initiate", "InitiateWithSend" or "Listen" calls, and invokes a "Closed" event towards the application. </del> <ins> EVENT.SCTP informs the Transport Services system that the stream id can now be re-used by the next "Initiate", "InitiateWithSend" or "Listen" calls, and invokes a "Closed" event towards the application. </ins> Abort: If this is the only Connection object that is assigned to the SCTP association, ABORT.SCTP is called.  Else, the Connection object

Discussion:
This is a manual re-application of all the changes to -impl in PR . (Other methods didn't easily work because the master has changed quite a bit during discussion of PR ; at least I found no easy way).
Sec 10.6 of taps-impl is pretty confusing: .. there's yet more. Maybe I should read NEAT-flow-mapping, or remind myself about the details of SCTP, but I think the third sentence (To map Connection Objects...) is not well-constructed. There are three conditions here: both SCTPs must: support 8260,support stream reconfiguration, ANDknow what's going on. But what do these conditions enable? Is it mapping connections to streams at all? Is it mapping them without HOL blocking (i.e., if not met, I still can map but there is HOL blocking)? Something else?
Guilty as charged! I wrote this and I can fix it. Meanwhile, I'll explain: 8260 => to reduce HOL blocking delay. stream reconfiguration => to save memory and be able to re-use stream numbers, and to realize the role of a FIN (stream reset = FIN) know what's going on => yes, but this is an application requirement ... the applications on both sides must be able to handle this. E.g., a server written over a TAPS system could just listen on all protocols, including streams, and get whatever kind of Connection (including, possibly, one that's really only a stream) - and then answer on it (I actually tested exactly this with NEATPy). This server can handle this easily. Another server could be a native TCP server, certainly not expecting SCTP, let alone Connections riding on streams - this server could not handle this. The client application, when connecting, must know what it's doing. I can make a PR to explain these matters in the text.
Change:
selected pairs have been produced for a data stream. It is RECOMMENDED that, when an agent receives an RTP packet with a <del> new source or destination IP address for a particular media data </del> <ins> new source or destination IP address for a particular RTP/RTCP data </ins> stream, that the agent re-adjust its jitter buffers. RFC 3550 RFC3550 describes an algorithm in Section 8.2 for detecting synchronization source (SSRC) collisions and loops.  These algorithms are based, in part, on seeing different source transport addresses with the same SSRC.  However, when ICE is used, such changes will <del> sometimes occur as the media data streams switch between candidates. An agent will be able to determine that a media data stream is from the same peer as a consequence of the STUN exchange that proceeds media data transmission.  Thus, if there is a change in source transport address, but the media data packets come from the same peer agent, this MUST NOT be treated as an SSRC collision. </del> <ins> sometimes occur as the data streams switch between candidates.  An agent will be able to determine that a data stream is from the same peer as a consequence of the STUN exchange that proceeds media data transmission.  Thus, if there is a change in source transport address, but the media data packets come from the same peer agent, this MUST NOT be treated as an SSRC collision. </ins> 14.

Discussion:
Fix spelling: Replace “fulfil” with “fulfill” Fix grammar: “agent sets the state…is set to Completed“ with “agent sets the state…to Completed” Make consistent with recent changes: Replace “candidate is equal to the transport address” with “candidate has the transport address” Replace “multimedia session” with “data session” Replace “media data stream” with “RTP/RTCP data stream” or just “data stream” Replace “media data” with “data”
Change:
1. QUIC QUIC is a new transport protocol providing a number of advanced <del> features.  While initially designed for the HTTP use case, like most transports it is intended for use with a much wider variety of applications.  QUIC is encapsulated in UDP.  The version of QUIC that is currently under development will integrate TLS 1.3 TLS13 to encrypt all payload data and most control information.  HTTP operating over QUIC is known as HTTP/3. </del> <ins> features.  While initially designed for the HTTP use case, it provides capabilities that can be used with a much wider variety of applications.  QUIC is encapsulated in UDP.  QUIC version 1 integrate TLS 1.3 TLS13 to encrypt all payload data and most control information.  HTTP operating over QUIC is known as HTTP/3. </ins> This document provides guidance for application developers that want to use the QUIC protocol without implementing it on their own.  This

Discussion:
These are pretty big. If you would prefer that I create a PR for each individual commit, that can be done. It turns out that there were a lot of things I found needed work. For instance, this completely redoes the 0-RTT advice.
It did kinda snowball, for which I apologize. I was trying to get something under your nose before I got swamped by meetings. I am also on vacation next week. I'm reading through and there is some really good stuff in the doc. I have started to open issues where I don't think the fixes are so simple.
Aside from the keep-alive tweak and the idempotence change, these are all editorial and LGTM, thanks! The keepalive tweak is also good. Having looked at URL, the text here is a good applicability-appropriate view on what's there now. assuming discussion there converges to mostly the same thing, I'd be happy to merge this. (in the future, no need to make tiny PRs, but splitting into "editorial-rollup" and "substantive editorial changes" would be nice to separate discussion, since the former shouldn't need much of it)Changes look all ready good. Thanks! I just have left one minor comment/question to double-check before we merge.
Change:
involved in the group can change from one epoch to the next, and MLS ensures that only the members in the current epoch have access to the epoch secret.  From the epoch secret, members derive further shared <del> secrets for message encryption, group membership authentication, etc. </del> <ins> secrets for message encryption, group membership authentication, and so on. </ins> The creator of an MLS group creates the group's first epoch unilaterally, with no protocol interactions.  Thereafter, the members

Discussion:
Some of these editorial comments I find less clear than the original. The code changes and varint are fine. Could you please split this into two more atomic PRs so we can discuss separately?
Feel free to leave comments on the editorial portion of this PR to keep things moving
Change:
HPACK defines string literals to begin on a byte boundary.  They begin with a single bit flag, denoted as 'H' in this document <del> (indicating whether the string is Huffman-coded), followed by the </del> <ins> (indicating whether the string is Huffman encoded), followed by the </ins> Length encoded as a 7-bit prefix integer, and finally Length bytes of data.  When Huffman encoding is enabled, the Huffman table from Section B of RFC7541 is used without modification and Length

Discussion:
Addresses most of the open RFC Editor questions.
Need to update Buck's contact information to .
Fixed in .
This is a change in the RFC Editor diff that I don't think works; pulling out for separate discussion. Original: Proposed but incorrect: The intended reading is: For... HTTP/3 servers (always, regardless of 0-RTT) and HTTP/3 clients when 0-RTT is not attempted or is rejected URL maximum table capacity is 0.
Fixed in .
Should the following text be formatted using ? See the definition at . Original: Note: Padding schemes only provide limited protection against an attacker with these capabilities, potentially only forcing an increased number of guesses to learn the length associated with a given guess. Padding schemes also work directly against compression by increasing the number of bits that are transmitted. Original: Note: Simply removing entries corresponding to the field from the dynamic table can be ineffectual if the attacker has a reliable way of causing values to be reinstalled. For example, a request to load an image in a web browser typically includes the Cookie header field (a potentially highly valued target for this sort of attack), and websites can easily force an image to be loaded, thereby refreshing the entry in the dynamic table.
Probably yes.
Fixed in .
May we update "Huffman-coded" with "Huffman encoded" in this text to match other uses? Original: They begin with a single bit flag, denoted as 'H' in this document (indicating whether the string is Huffman-coded), followed by the Length encoded as a 7-bit prefix integer, and finally Length bytes of data.
Fixed in .
Change:
interconnected by a TSN sub-network, being the primary focus of this document. <del> DetNet routers ensure that detnet service requirements are met per </del> <ins> DetNet routers ensure that DetNet service requirements are met per </ins> hop by allocating local resources, both receive and transmit, and by mapping the service requirements of each flow to appropriate sub- network mechanisms.  Such mappings are sub-network technology

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
Negotiation (ALPN) RFC7301 to select an application protocol.  Unless another mechanism is used for agreeing on an application protocol, endpoints MUST use ALPN for this purpose.  When using ALPN, endpoints <del> MUST abort a connection if an application protocol is not negotiated. </del> <ins> MUST immediately close a connection (see Section 10.3 in QUIC- TRANSPORT) if an application protocol is not negotiated with a no_application_protocol TLS alert (QUIC error code 0x178, see tls- errors).  While RFC7301 only specifies that servers use this alert, QUIC clients MUST also use it to terminate a connection when ALPN negotiation fails. </ins> An application-layer protocol MAY restrict the QUIC versions that it can operate over.  Servers MUST select an application protocol

Discussion:
Just so you don't have to read the whole RFC7301.
Yeah I was thinking about that. I wonder if it would make sense for the client to simply send PROTOCOL_VIOLATION instead of a TLS alert.
NAME I added a clarification to allow clients to send noapplicationnegotiated as well. Should I send an email to the mailing list for discussion now that the new process is in effect?
Unfortunately yes. This is a design change so it will need an issue as well. I like it and we should do it, but can you add the error code we would use in CONNECTION_CLOSE to the text?
NAME ok, added error code, created issue () and sent email to the list.
NAME thanks, suggestions accepted.
PR added a requirement for end-points to terminate a connection if ALPN negotiation fails, but doesn't specify an error code for this situation. RFC7301 defines the alert that must be used by TLS servers, so QUIC servers should probably use that as well. As for clients, RFC7301 doesn't specify a behaviour, but it also doesn't forbid use of in clients, and it seems better if QUIC clients use the same error code as the servers. Proposed wording change is in .
My :+1: goes to making the change, though I would like to confirm that it wouldn't be illegal for a client to close the connection with error after it sends ClientFinished. I ask this because depending on the design of the TLS stack, the QUIC stack might not be able to see the result of ALPN before the TLS stack generates a ClientFinished (note that EE.ALPN and ServerFinished might arrive in one packet). It's my understanding that the intent of the issue is to not allow the client to send any application data on ALPN failure. Assuming that's true, sending the alert after ClientFinished should be fine.
Yes, I think that would be fine. I don't think that we would be able to guarantee that the alert goes out before sending ClientFinished either. It's certainly possible, but I can see how it might be tricky.
This was fixed with .
a few nits
Change:
round-trip time multiplier, is 9/8.  The RECOMMENDED value of the timer granularity (kGranularity) is 1ms. <ins> TCP's RACK (RACK) specifies a slightly larger threshold, equivalent to 5/4, for a similar purpose.  Experience with QUIC shows that 9/8 works well. </ins> Implementations MAY experiment with absolute thresholds, thresholds from previous connections, adaptive thresholds, or including RTT variation.  Smaller thresholds reduce reordering resilience and

Discussion:
This draft already has an informative reference to RACK, so it seems sensible to note the small difference in time threshold.
Change:
IP address, must be able to make DNS queries, and must be able to send HTTP requests to the cloud registrar.  The pledge operator has already connected the pledge to the network, and the mechanism by <del> which this has happened is out of scope of this document. </del> <ins> which this has happened is out of scope of this document.  Similarly, what address space the IP address belongs to, whether it is an IPv4 or IPv6 address, or if there are firewalls or proxies deployed between the pledge and the cloud registar are all out of scope of this document. </ins> 2.3.

Discussion:
Should specify that you mean "routeable" IP address, I think. (I suppose it could be a ULA in some deployments?)
I'm not sure routeable is correct. I think that many will think it means an address which is world reachable, when any kind of NAT44, SOCKS, or HTTP-PROXY'able address would work. (there are still enterprises that use 10./8 without a default route and socks/http-proxy...)
Change:
on the above-mentioned criteria (in addition to other criteria, such as transport layer endpoint, local configuration and preferences). <del> 4.4.1.2. </del> <ins> 4.4.1.3. </ins> The following rules apply to certificates sent by the client:

Discussion:
This change adds a set of extensions to the Certificate message. This is intended to hold all extension messages that are certificate-specific as opposed to extensions that apply to the entire connection. This change facilitates future extensions to the protocol for post-handshake server authentication and resolves the anomaly of OCSP messages appearing before certificates in the handshake.
Changed SingleCertificate to CertificateEntry
NAME this seems ready to land from my side modulo the rename I propose. Do you have any changes to make?
Change:
RFC4588 MUST be implemented to signal RTX payload type associations. <del> RFC3556 with bandwidth modifiers MAY be supported for specifying RTCP bandwidth as a fraction of the media bandwidth, RTCP fraction allocated to the senders and setting maximum media bit-rate boundaries. </del> <ins> RFC3556 MUST be supported for control of RTCP bandwidth limits. </ins> As required by RFC4566, Section 5.13, JSEP implementations MUST ignore unknown attribute (a=) lines.

Discussion:
I agree that this text is correct. I have no strong opinion on whether we should make the change...
Proposed text:
This seems satisfactory to me. You have my preemptive LGTM