jiebi/CodeConvo huggingface dataset:
Code change:
The entries in iana-setting-table are registered by this document. <del> Additionally, each code of the format "0x1f * N + 0x21" for integer values of N (that is, "0x21", "0x40", ..., through </del> <ins> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, "0x21", "0x40", ..., through </ins> "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. 11.2.3.

Related discussion:
text: Clarify reserved values for stream types, settings identifiers, frame types, and error codes. 0x1f N + 0x21 for the value of N = -1 is 0x02. Literal interpretation of the current text includes this as a reserved value. The parenthetical examples given in Section 11.2 make it clear that this was not the intention, rendering this PR editorial. The main motivation of this PR is not that the current text is inconsistent, but that parenthetical examples from 11.2 are necessary to correctly interpret the definitions in sections 6.2.3, 7.2.4.1, 7.2.8, and 8.1. Alternative wordings could be: "0x1f N + 0x21 for N = 0, 1, 2, ..." "0x1f N + 0x02 for positive integer values of N" "0x1f N + 0x02 for N = 1, 2, 3, ..." "0x21, 0x21 + 0x1f, 0x21 + 2 * 0x1f, ..." "a value of at least 0x21 with a remainder of 0x02 modulo 0x1f" "a value of at least 0x21 that is congruent to 0x21 modulo 0x1f" none of which is better than what this PR proposes.
Code change:
Every time an acknowledgement is sent, bundled or otherwise, all counters and timers related to delaying of acknowledgments are reset. <ins> The receiver of an ACK_FREQUENCY frame can continue to process multiple available packets before determining whether to send an ACK frame in response, as stated in Section 13.2.2 of QUIC-TRANSPORT. </ins> 6.1. As specified in Section 13.2.1 of QUIC-TRANSPORT, endpoints are

Related discussion:
text: Also updates the transport parameter codepoint to 0xff03de1a from 0xff02de1a.
While reading the latest ack-frequency draft, I am confused with the wording that was added in URL If I have ack-eliciting threshold = 1, to me it means that I can receive 1 ack-eliciting packet before sending an ACK, i.e. I have to send ACK after receiving 1 packet. But looking at the example of 0, this interpretation looks wrong. NAME suggested, maybe the "before" needs to be "without" and an additional sentence added: "An immediate acknowledgement is sent when more than this number of packets have been received." I agree with his suggestion.
Thanks for the issues, this is a bit unclear. PTAL at
The definition that I use internally is "the number of packets you can receive without sending an immediate acknowledgment". This is different than saying "please acknowledge every N packets". The main benefit of this definition is that there are no invalid values for the number. I recommend making this adjustment in the frame definition: it will be more efficient (by a tiny amount), but it also removes the need to validate the value.
This seems like a good change, it's just a matter of writing the text.
Code change:
away. When mDNS fails, ICE will attempt to fall back to either NAT hairpin, <del> if supported, or TURN relay, if not.  As noted in IPHandling, this may result in increased media latency and reduced connectivity/ increased cost (depending on whether the application chooses to use TURN). </del> <ins> if supported, or TURN relay if not.  This may result in reduced connectivity, reduced throughput and increased latency, as well as increased cost in case of TURN relay. </ins> One potential mitigation, as discussed in {#privacy}, is to not conceal candidates created from RFC4941 IPv6 addresses.  This permits

Related discussion:
text: Let's also consider data use cases here: Fallback to TURN has a severe effect on throughput in many cases.
Sure, could add a brief note on this.
The text here isn't normative, so I don't think we need to have a lengthy discussion of this - a few words should suffice.
Fixed by
LGTM
Code change:
idle timeout".  When only one path is available, servers MUST follow the specifications in QUIC-TRANSPORT. <del> When more than one path is available, servers shall monitor the arrival of non-probing packets on the available paths.  Servers SHOULD stop sending traffic on paths through where no non-probing packet was received in the last 3 path RTTs, but MAY ignore that rule if it would disqualify all available paths.  To avoid idle timeout of a path, endpoints can send ack-eliciting packets such as packets containing PING frames Section 19.2 of QUIC-TRANSPORT on that path to keep it alive.  Sending periodic PING frames also helps prevent middlebox timeout, as discussed in Section 10.1.2 of QUIC-TRANSPORT. </del> <ins> When more than one path is available, hosts shall monitor the arrival of non-probing packets and the acknowledgements for the packets sent over each path.  Hosts SHOULD stop sending traffic on a path if for at least max_idle_timeout milliseconds (a) no non-probing packet was received or (b) no non-probing packet sent over this path was acknowledged, but MAY ignore that rule if it would disqualify all available paths.  To avoid idle timeout of a path, endpoints can send ack-eliciting packets such as packets containing PING frames (Section 19.2 of QUIC-TRANSPORT) on that path to keep it alive. Sending periodic PING frames also helps prevent middlebox timeout, as discussed in Section 10.1.2 of QUIC-TRANSPORT. </ins> Server MAY release the resource associated with paths for which no non-probing packet was received for a sufficiently long path-idle

Related discussion:
text: So if you decide to always only send ack on one path and all payload data flows into one direction only over multiple paths, the current text would require you to send potentially unnecessary ping packets over each non-ack'ing paths or you would end up closing those paths which also is wrong as everything seems to work fine. So the question is really is, do we want to require pings in this scenario (payload traffic over multiple paths but acks only on one path) in order to ensure that all paths are usable bidirectionally? I think that's unnecessary overhead and believe Olivier's proposed addition is the correct thing to do.
I can look at what I implemented in picoquic: If there is no traffic in either direction for the idle period, the path is automatically abandoned. If traffic is sent and acked, or traffic is received, the path is not considered idle. This is pretty much what Olivier proposed. If there is a "timer loss", and if there is an alternate, the path is put in a low priority list. The node will send ping and try get an ack. If no ack is received after N trials, the path is abandoned. If "abandon path" frame is received, the path is abandoned.
I marked this issue as editorial as we have an editorial PR for it. However, I open a new issue for the per path idle timeout discussion (). Do we need another issue to clarify path closure or sending of keep-alive traffic? However this might be covered in other parts of the draft already...?
The modified text looks good.Looks good to meThe text looks good to me.
Code change:
DNS API clients using the DNS wire format MAY have one or more EDNS options RFC6891 in the request. <del> The media type is "message/dns". </del> <ins> The media type is "application/dns-message". </ins> 7.

Related discussion:
text: Fixes issue
The message/ tree requires that the sub-types contain other MIME messages, which DOH does not. Maybe use application/dns-message instead.
Code change:
3.2. <ins> This section outlines how received ICE candidates with mDNS names are processed by ICE agents, and is relevant to all endpoints. </ins> For any remote ICE candidate received by the ICE agent, the following procedure is used:

Related discussion:
text: Also wrap long lines for #processing section.
Comments addressed, PTAL.
Will wait for NAME approval before merging.
LGTM, updated PR for line wrapping.
The changes to ICE candidate gathering are targeted to web browsers; the changes to ICE candidate processing affect all WebRTC endpoints.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private? If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
LGTM
Code change:
4- The multiplexed server establishes the connection to the protected service, thus revealing the identity of the service. <ins> One of the goals of SNI encryption is to prevent adversaries from knowing which Hidden Service the client is using.  Successful replay attacks breaks that goal by allowing adversaries to discover that service. </ins> SNI encryption designs MUST mitigate this attack. 2.2.

Related discussion:
text: …fix the various typos flagged by DKG, submit as WG draft.
Code change:
Retransmission and deduplication of messages is provided by the TCP/ TLS protocol. <ins> 2.4. Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient.  This provides a basic keep-alive function that can refresh NAT bindings. If a client does not receive any response for some time after sending a CoAP request (or, similarly, when a client observes a resource and it does not receive any notification for some time), it can send a CoAP Ping Signaling message (sec-ping) to test the connection and verify that the server is responsive. </ins> 3. <ins> CoAP over WebSockets is intentionally similar to CoAP over TCP; therefore, this section only specifies the differences between the transports. </ins> CoAP over WebSockets can be used in a number of configurations.  The most basic configuration is a CoAP client retrieving or updating a <del> CoAP resource located at a CoAP server that exposes a WebSocket </del> <ins> CoAP resource located on a CoAP server that exposes a WebSocket </ins> endpoint (arch-1).  The CoAP client acts as the WebSocket client, establishes a WebSocket connection, and sends a CoAP request, to which the CoAP server returns a CoAP response.  The WebSocket

Related discussion:
text: Re-registering interest in a resource is permitted, but entirely unnecessary.
Response from Klaus Hartke: In general, CoAP clients are not allowed to use a token while it is still in use. RFC 7641 defines an exception: a client is allowed to confirm its interest in receiving notifications for a resource by sending a request identical to the original registration request, including the token that is already in use. The above paragraph just says that this is also the case for CoAP over TCP/TLS/WebSockets, but points out that sending a Ping (which checks the health of the connection and hence of all active observations) is better than confirming the interest for all active observations individually. Response from Carsten: Yes, the text is much easier to understand in that context — in the old draft, it was clear that this talks about reregistering interest. So in the new text, we probably need to prefix a sentence like For use with UDP, RFC 7641 discusses ways to re-register interest in a resource to deal with the case that the server providing this resource might have lost the information about this interest. In CoAP over TCP, the framework of the current connection provides fate-sharing between the health of the connection and the health of the expression of interest.
After further review, I think that this note belongs in Appendix A with the other updates/guidance for Observe on reliable transports. Connection Health should limit its discussion to WebSocket specific changes - in this case, the use of the CoAP Ping Signaling message instead of WebSocket Ping/Pong.
Code change:
At the time this is published, the response types are works in progress.  The only response type defined in this document is <del> "message/dns", but it is possible that other response formats will be defined in the future. </del> <ins> "application/dns-message", but it is possible that other response formats will be defined in the future. </ins> <del> The DNS response for "message/dns" in dnswire MAY have one or more EDNS options, depending on the extension definition of the extensions given in the DNS request. </del> <ins> The DNS response for "application/dns-message" in dnswire MAY have one or more EDNS options, depending on the extension definition of the extensions given in the DNS request. </ins> Each DNS request-response pair is matched to one HTTP exchange.  The responses may be processed and transported in any order using HTTP's

Related discussion:
text: Fixes issue
The message/ tree requires that the sub-types contain other MIME messages, which DOH does not. Maybe use application/dns-message instead.
Code change:
7. <del> Two examples are shown below.  The first example showing an company with an internal-only DNS server resolving the entire zone for that company (e.g., *.example.com) the second example resolving only a subdomain of the company's zone (e.g., *.internal.example.com). </del> <ins> Two examples are shown below.  The first example shows a company with an internal-only DNS server that claims the entire zone for that company (e.g., ).  In the second example, the internal servers resolves only a subdomain of the company's zone (e.g., ). </ins> 7.1.

Related discussion:
text: Includes: Text adjustments for grammar and clarity Replacing "public" resolver with "external" Changes to references and blockquotes Made diagrams narrower
NAME NAME Please review
Changes look good to me.
Code change:
comandeered those user agents to send DDoS traffic to various sites Marczak-2015. <del> 4.5. </del> <ins> 4.6. </ins> While it is perhaps the crudest of all censorship techniques, there is no more effective way of making sure undesirable information isn't

Related discussion:
text: s/prevention/interference/ ... Censors can degrade performance to a particular site, or for a particular service, effectively making performance so bad for a site that users opt to use a different site or service. China is known to do this. Censors can try to have content removed via takedown requests, under the guise of laws that forbid certain content (e.g., hate speech or whatnot). The ANC is .za has been accused of using the laws in this fashion.
Will Scott also noted in feedback to me that throttling should get more of a call out than it currently does:
Code change:
Properties when sending.) Abort: The action the application takes on a Connection to <del> indicate a Close and also indicate that the Transport System SHOULD NOT attempt to deliver any outstanding data.  This is intended for immediate termination of a connection, without </del> <ins> indicate a Close and also indicate that the Transport Services system SHOULD NOT attempt to deliver any outstanding data.  This is intended for immediate termination of a connection, without </ins> cleaning up state. 4.2.

Related discussion:
text: Addresses
In the architecture document, I noticed that we sometimes say "Transport Services system" and sometimes "Transport System". Are these the same? Are "Transport Services implementation" and "Transport System implementation" the same, too?
I prefer "Transport Services system" and "Transport Services implementation"
I find it long and clumsy :( Side note: we'll have to rename it everywhere in the API draft too if we go with this.
was this fixed by ?
Yes it was. We already used Transport Services most places so it's not all that different.
Looks good, thanks!
Code change:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-04 ECIES is now renamed in favor of HPKE (*) </ins> draft-03 Added ciphersuites and signature schemes (*)

Related discussion:
text: This does not handle the removal of DH uses instead of KEM which will be done as part of Issue / PR ...
I would be happier if this PR were moving the draft to use draft-barnes-cfrg-hpke, which is one of the changes I had in mind for -04. Do you think that's premature?
This text is wrong:
This could also be addressed by using draft-barnes-cfrg-hpke.
This has been fixed by
Enable, e.g., P-256 with both AES-GCM and ChaChaPoly Re-use code points from TLS
We should discuss that today
Code change:
When there is no user consent, the following filtering should be done to prevent private IP address leakage: <del> host ICE candidates with an IP address are not exposed as ICE candidate events. </del> <ins> ICE candidates with an IP address are not exposed as ICE candidate events. </ins> Server reflexive ICE candidate raddr field is set to 0.0.0.0 and rport to 0. <del> SDP does not expose any a=candidate line corresponding to a host ICE candidate which contains an IP address. </del> <ins> SDP does not expose any a=candidate line corresponding to an ICE candidate which contains an IP address. </ins> Statistics related to ICE candidates MUST NOT contain the resolved IP address of a remote mDNS candidate or the IP address of a peer-

Related discussion:
text: PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?
Code change:
direct path of the new node Set the leaf node in the tree at position "index" to a new node <del> containing the public key from the UserInitKey in the Add </del> <ins> containing the public key from the ClientInitKey in the Add </ins> corresponding to the ciphersuite in use, as well as the credential <del> under which the UserInitKey was signed </del> <ins> under which the ClientInitKey was signed </ins> The "update_secret" resulting from this change is an all-zero octet string of length Hash.length.

Related discussion:
text: Overall, this seems OK. Just using "InitKey" would be clear and less wordy.
I tried this and that led people to confuse and
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
These keys are Client one-time use keys, so "UserInitKey" seems like a strange name.
I'm fine with ClientInitKey, as long as a client is not only a physical endpoint. Changes in the architecture doc should make this clear soon.
Code change:
IP packet forwarding, or a specific proxied flow; see scope. An IP proxying request that does not conform to these restrictions is <del> malformed (see H2 and H3). </del> <ins> malformed; see H2 and H3. </ins> For example, if the client is configured with URI Template "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" and wishes to open an IP forwarding tunnel with no target or protocol limitations, it could send the following request: <del> 4.4. </del> <ins> 4.5. </ins> The IP proxy indicates a successful response by replying with the following requirements:

Related discussion:
text: I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.
Code change:
it can request-interact-usercode. The AS determines that interaction is needed and response with a <del> response-interact-usercode.  This could optionally include a URI to direct the user to, but this URI should be static and so could be configured in the client instance's documentation.  The AS also includes information the client instance will need to response- continue in (8) and (10).  The AS associates this continuation information with an ongoing request that will be referenced in (4), (6), (8), and (10). </del> <ins> response-interact-usercode.  The AS also includes information the client instance will need to response-continue in (8) and (10). The AS associates this continuation information with an ongoing request that will be referenced in (4), (6), (8), and (10). </ins> The client instance stores the continuation information from (2) for use in (8) and (10).  The client instance then interaction-

Related discussion:
text: Update all diagrams to use AASVG for rendering in HTML.
To edit notification comments on pull requests, go to your ._
Code change:
section 5.1.1, the candidate is processed as follows: Check whether the ICE agent has a usable registered mDNS hostname <del> resolving to the ICE host candidate's IP address.  If one exists, skip ahead to Step 6. </del> <ins> resolving to the ICE candidate's IP address.  If one exists, skip ahead to Step 6. </ins> Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local".

Related discussion:
text: PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?