jiebi/CodeConvo huggingface dataset:
Change:
the validation is still in progress, the server MUST return a 202 (Accepted) response with a Retry-After header field. <del> 6.7. </del> <ins> 6.4.2. If a client wishes to relinquish its authorization to issue certificates for an identifier, then it may request that the server delete the authorization.  The client makes this request by sending a POST request to the authorization URI containing a payload in the same format as in deleting-an-account.  The only difference is that the value of the "resource" field is "authz". The server MUST perform the same validity checks as in deleting-an- account and reject the request if they fail.  If the server deletes the account then it MUST send a response with a 200 (OK) status code and an empty body. 6.5. </ins> The holder of an authorized key pair for an identifier may use ACME to request that a certificate be issued for that identifier.  The

Discussion:
Adds a little more granularity to section headings.
It should be possible for a client to delete his account / registration, and to renounce authorization for a domain. The right way to do this is probably to define a "delete" object that can be POSTed to the reg/account URI, rather than having a separate endpoint (as for certificate revocation).
Change:
established with 0-RTT MUST be idempotent (as specified in section 2.1 in QUIC-TLS).  Applications MUST be designed, and their data MUST be framed, such that multiple reception of idempotent data is <del> recognized as such by the receiverApplications that cannot treat data that may appear in a 0-RTT connection establishment as idempotent MUST NOT use 0-RTT establishment.  For this reason the QUIC transport SHOULD provide an interface for the application to indicate if 0-RTT support is in general desired or a way to indicate whether data is idempotent, whether PFS is a hard requirement for the application, and/or whether rejected 0-RTT dgitata should be retransmitted or withdrawn. </del> <ins> recognized as such by the receiver.  Applications that cannot treat data that may appear in a 0-RTT connection establishment as idempotent MUST NOT use 0-RTT establishment.  For these reason the QUIC transport SHOULD provide some or all of the following interfaces to applications: indicate if 0-RTT support is in general desired, which implies that lack of PFS is acceptable for some data; an indication when 0RTT data for both egress and ingress, so that both sender and receiver understand the properties of the communication channel when the data is sent; and/or whether rejected 0-RTT data should be retransmitted or withdrawn. Some TLS implementations may offer replay protection, which may mitigate some of these issues. </ins> 3.3.

Discussion:
Intended to , ,
The draft says section 8 of quic-transport; it's section 13.
It is odd that this section doesn't mention QUIC's robustness to NAT rebinding at all. While this won't work behind 4-tuple load balancers, middlebox timers may be irrelevant depending on the conesequences of the timeout.
While TFO has some 0RTT-like properties, it does not fully replace it, not only because the SYN or option gets scrubbed, but also because you're limited to one packet payload. Also, this ought to mention TLS stacks that offer replay protection. I would think a modern QUIC interface would offer a signal to separate 0RTT from 1RTT data, so that both senders and receivers can manage their application data appropriately.
will be
This is editorial, but the whole introduction is written as if the quic drafts are some early concept kicking around in the working group. This will not age well, and the intro should be worded as if it were already a published RFC. The intro still talks about "HTTP/2 over QUIC" when it's now HTTP/3.
Change:
A peer-reflexive remote candidate could be learned and constructed from the source transport address of the STUN Binding request as an ICE connectivity check.  The peer-reflexive candidate could share the <del> same address as a remote mDNS ICE candidate whose name is in the process of being resolved.  In addition to the elimination procedure of redundant candidates defined in Section 5.1.3 of RFC8445, which could remove constructed peer-reflexive remote candidates, the address of any existing peer-reflexive remote candidate should not be exposed to Web applications by ICE agents that implement this proposal, as detailed in Section #guidelines. </del> <ins> same address as a remote mDNS candidate that is in the process of being signaled or name resolution. In addition to the elimination procedure of redundant candidates defined in Section 5.1.3 of RFC8445, which could remove constructed peer-reflexive remote candidates, the address of any existing peer- reflexive remote candidate should not be exposed to Web applications by ICE agents that implement this proposal, as detailed in Section #guidelines. </ins> 3. <del> 3.1. </del> <ins> In this example, mDNS candidates are exchanged between peers and resolved to obtain the corresponding IP addresses. The following two examples indicate how peer-reflexive candidates for host IP addresses can be created due to timing differences. In this example, a peer-reflexive candidate is generated because the mDNS candidate is signaled after the STUN checks begin. In this example, a peer-reflexive candidate is generated because the mDNS resolution for name N2 does not complete until after the STUN checks are received. 4. 4.1. </ins> When there is no user consent, the following filtering should be done to prevent private IP address leakage:

Discussion:
PR of
Added a 'good' example as well, and put them all in an examples section. PTAL.
Will merge once I get a second approval.
Some of this stuff is complicated, example diagrams can help.
Great to have examples. Regenerating the html, the examples do not show up in full on the html version, probably not a big deal, the txt version is fine.
LGTM
Change:
7.6. <del> When a sender establishes loss of all ack-eliciting packets sent over a long enough duration, the network is considered to be experiencing persistent congestion. </del> <ins> When a sender establishes loss of all packets sent over a long enough duration, the network is considered to be experiencing persistent congestion. </ins> 7.6.1.

Discussion:
Removes the word ack-eliciting in the descriptive text to persistent congestion. It also contains minor text changes in the following of that section.
I'm taking the suggested changes and this PR. Thanks, NAME !
On the mailing list Timo Völker asked some questions about persistent congestion and why it was only applicable to in-flight packets. During the explanation, I realized that it should probably be ack-eliciting packets, not in-flight. UPDATE: It already is ack-eliciting in all but one spot. I wrote PR to fix that one spot.
To have the context, I quote your explanation. I think ack-eliciting makes more sense here than in-flight. At least, I understand that for the persistent congestion detection the first and the last packet need to be ack-eliciting. But why does this have to be true for packets sent between these two ack-eliciting packets? Here is an example for the edge case. The loss of three out of 50 packets let the sender consider this a persistent congestion. In general, I don't see a real issue here. But, I would like to understand why it is helpful to ignore the fact that non-ack-eliciting packets, sent between two lost ack-eliciting packets, have been acknowledged.
This absolutely should not be in flight packets. This may not cause a major issue as it stands but it is not technically correct.
The text is largely correct(ack-eliciting, not in-flight) already, based on my reading. Unfortunately, the very first description is incorrect, which is potentially confusing, so see
Looking good, one further suggestion.
Change:
A protocol version and ciphersuite that the client supports, a public key that others can use to encrypt a Welcome message to <del> this client, and </del> <ins> this client, (an "init key") and </ins> the content of the leaf node that should be added to the tree to represent this client.

Discussion:
This PR picks up changes from clarifying and cleaning up a few issues around LeafNode.
A big improvement in readability and correctness.
Change:
Other attacks can target the behavior of underlying technologies such as UTF-8 (see RFC3629) and the Unicode character set. <del> Editorial Comments [dedup] Well, that can be discussed. </del>

Discussion:
Delete the editor's note as »Note that there is no deduplication of the nodelist.« is now the agreed behavior.
As currently specified, there is no deduplication of nodes input to the count() function extension. But the spec contains a placeholder suggesting discussion of deduplication. This issue is for that discussion. This issue is related to URL because if function extensions do not have access to node location, then it would not be possible to deduplicate on node identity, only potentially on value.
2023-01-10 Interim: Remove the editor's note now.
Change:
or <del> of their element or member values then.  Applied to other value types, it will select nothing. </del> <ins> of their array elements or member values, respectively.  Applied to other value types, it will select nothing. A relative path, beginning with "@", refers to the current array element or member value as the filter selector iterates over the array or object. Comparisons using one of the operators "<", "<=", ">", and ">=" are between numeric values only.  Using these operators to compare other types of values produces a "false" comparison result. The semantics of regular expressions are as defined in I-D.draft- bormann-jsonpath-iregexp. </ins> 3.5.8.3.

Discussion:
Fixes URL
The notes need separating out into paragraphs. The semantics section needs to be expanded.
Change:
14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> 4. [Author's note: review required on his part.] </del> <ins> 3. </ins> fig_tsn_mpls_detnet shows IEEE 802.1 TSN end stations operating over a TSN aware DetNet service running over an MPLS network.  DetNet Edge

Discussion:
Major clean up and simplification as data plane drafts can be referred for MPLS related details. TSN over DetNet MPLS follows the concept of RFC3985. Description focus on Edge Nodes procedures and functions. Text covers the Edge Nodes components: (1) TSN functions (in NSP block); (2) DetNet Service Proxy; and (3) DetNet sub-layers.
Approving from teelcon review
Change:
3.3. <del> A Transport Services implementation can select Protocol Stacks based on the Selection and Connection Properties communicated by the application, along with any security parameters.  If two different Protocol Stacks can be safely swapped, or raced in parallel (see racing), then they are considered to be "equivalent".  Equivalent Protocol Stacks are defined as stacks that can provide the same Transport Properties and interface expectations as requested by the application. </del> <ins> A Transport Services implementation can attempt and select between multiple Protocol Stacks based on the Selection and Connection Properties communicated by the application, along with any security parameters.  The implementation can only attempt to use multiple Protocol Stacks when they are "equivalent", which means that the stacks can provide the same Transport Properties and interface expectations as requested by the application.  Equivalent Protocol Stacks can be safely swapped or raced in parallel (see racing) during connection establishment. </ins> The following two examples show non-equivalent Protocol Stacks:

Discussion:
URL Here it seems we are defining "equivalent" twice. I would rather write - >Equivalent Protocol Stacks are defined as stacks that can provide the same Transport Properties and interface expectations as requested by the application. and the equivalent stacks can be swapped or raced. Also in the example - it is not clear that swapping and racing in important, however, application provided properties are. Apart from this I also think the title and content is mismatching. I found the last paragraph talking about swapping and racing focusing on security. Here we are imposing requirements on swapping and racing. These are very important for the security consideration and to me should get its own title and section separated from selection of equivalence.
LGTM!Looks good
Change:
values between 0x0400 and 0xefff; and Private Use for values between 0xf000 and 0xffff. <del> 9.  References </del> <ins> 9.3. </ins> <del> 9.1.  URIs </del> <ins> This document contains the request for the registration of the URI scheme "quic-transport".  The registration request is in accordance with RFC7595. quic-transport Permanent QuicTransport IETF Chair chair@ietf.org [2] IESG iesg@ietf.org [3] uri of this document. 10.  References 10.1.  URIs </ins> [1] https://fetch.spec.whatwg.org/#serializing-a-request-origin <ins> [2] mailto:chair@ietf.org [3] mailto:iesg@ietf.org </ins>

Discussion:
This defines a new URL scheme for QuicTransport, and clarifies the use of "https" for Http3Transport.
Change:
Instead of saying that, for JSON-encoding purposes, the module name for the "notification" element is "ietf-restconf, the module <del> name will instead by "ietf-https-notif". </del> <ins> name will instead be "ietf-https-notif". </ins> 4.2.

Discussion:
Getting the draft ready for publication. Did file a bug with libyang folks and even though it was an operator error on my part, the default in yanglint now is to enable all features when none are mentioned. The examples now validate correctly.
Change:
value in a "return_routability_check" message of type "path_response". <del> When the initiator receives and verifies the "return_routability_check" message contains the sent cookie, it updates the peer address binding. If T expires, or the address confirmation fails, the peer address binding is not updated. </del> <ins> When the initiator receives the "return_routability_check" message and verifies that it contains the sent cookie, it updates the peer address binding. </ins> <del> After this point, any pending send operation is resumed to the bound peer address. path-challenge-reqs and path-response-reqs list the requirements for the initiator and responder roles, broken down per protocol phase. </del> <ins> If T expires the peer address binding is not updated. </ins> 7.2. <del> Note: This algorithm also takes the off-path scenario into account. The receiver that observes the peer's address or port update MUST stop sending any buffered application data (or limit the data sent to the unvalidated address to the anti-amplification limit) and initiate the return routability check that proceeds as follows: </del> The receiver creates a "return_routability_check" message of type "path_challenge" and places the unpredictable cookie into the message.

Discussion:
factor out common text remove the spurious "address confirmation failure": path validation only fails on timeout provide further rationale for choosing between basic and enhanced
We probably need to tell implementers why/when they should choose the basic algorithm vs the enhanced. For example, avoid enhanced if: you need to minimise implementation complexity you have privacy concerns -- i.e., to avoid providing a clear correlation signal off-path attackers are not in your threat model and/or you want to reduce the time it takes to switch path
In the path validation algorithm (both base and enhanced) we say "[...] or the address confirmation fails [...]", but we don't say precisely what we mean by that. If it refers to failure in validating the received Cookie value, than there's a potential out-of-sync with the requirement: "[...] the initiator MUST silently discard any invalid path_response it receives." If not, we should say what we mean by "address confirmation failure."
Change:
"a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. <del> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC8122, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature. </del> <ins> For each desired digest algorithm, one or more "a=fingerprint" lines for each of the endpoint's certificates, as specified in RFC8122, Section 5. </ins> An "a=setup" line, as specified in RFC4145, Section 4, and clarified for use in DTLS-SRTP scenarios in RFC5763, Section 5.

Discussion:
certificate. This was updated in RFC 8122.
NAME PTAL
NAME PTAL
Section 5.2.1 (creating an offer) still has this paragraph: In RFC4572-update, this requirement doesn't exist. So should this be changed to reference RFC4572-update, removing the second half of this paragraph?
Related webrtc-pc issue: URL
Change:
application wishes to avoid losing state that has been associated with an open connection, but does not expect to exchange application data for some time.  With this option, an endpoint could send a PING <del> frame periodically to defer an idle timeout; see frame-ping. </del> <ins> frame (frame-ping) periodically, which will cause the peer to restart its idle timeout period.  Sending a packet containing a PING frame restarts the idle timeout for this endpoint also if this is the first ack-eliciting packet sent since receiving a packet.  Sending a PING frame causes the peer to respond with an acknowledgment, which also restarts the idle timeout for the endpoint. </ins> Application protocols that use QUIC SHOULD provide guidance on when deferring an idle timeout is appropriate.  Unnecessary sending of

Discussion:
Idle timeout doesn't enter the draining period. Sending PING will reset both idle timeouts for both endpoints.
if it is expecting response data, but does not have or is unable to send application data. However, you can't necessarily reset your own idle_timeout that way because it only is reset when you haven't already sent an ack-eliciting packet after the last received packet. If this is about resetting the peer, then maybe editorial. If it is about resetting yourself, then this may be design.
This is both idle timeouts. The idea behind the rules regarding the local reset of the idle timer is that if you send an ack-eliciting packet, you will get an acknowledgment. You are required to send probes until you do. So you only reset the timeout on the first.
says that after the idle timeout expires, "the connection is silently closed and its state is discarded." However, 10.2.1 says that the peer "might enter its draining state." Based on 10.2, I would not expect there to be a draining state; the connection is simply gone, and you would get a stateless reset. Is the draining state used after the endpoints time out, or not?
I need to find the issue, but we explicitly decided to not drain after idle timeout.
resolved this.
Couple of nits, but LGTM.
Change:
The first step in generating an initial answer is to generate session-level attributes.  The process here is identical to that <del> indicated in the Initial Offers section above. </del> <ins> indicated in the Initial Offers section above, except that the "a=ice-options" line, with the "trickle" option, as specified in I- D.ietf-mmusic-trickle-ice, Section 4 is only included if such an option was present in the offer. </ins> The next step is to generate lip sync groups as defined in RFC5888, Section 7.  For each MediaStream with more than one MediaStreamTrack,

Discussion:
This contains the ice-options changes as well - will take another look once that PR is merged.
looks like a straightforward change - lgtm
LGTM
JSEP defines this attribute on media level, while 5245 says it is a session level attribute. I understand that there is development ongoing here (e.g. 5245bis), but given that canTrickleIceCandidates is an API on the PeerConnection it makes more sense IMO to have ice-options:trickle on the session level than media line level. If we want this on media line line level, canTrickleIceCandidates should be a (readonly) Transceiver attribute. To that seems messy though, what would happen if Bundle is negotiated but one media line can do trickle but the other not? While the relation between the application of an Answer and canTrickleIceCandidates is spelled out, the same thing should be done for application of an Offer.
Decision on 1): simplest thing here is to move ice-options to session level, right after "An "a=msid-semantic:WMS" line MUST be added..." 2) yes, this should be put into handling a remote description, not handling an answer.
I can take this.
JSEP requires sending q=msid-semantics:WMS: If I read URL correctly, that is no longer defined, so that requirement should probably go. I'm happy to provide a PR that removes the requirement, the example usage and updates the reference, but I assume that updating the reference involves more work than just this, so I'll refrain from doing so unless I hear it would still be useful.
I think we can just remove this line, and scrub it from the examples. More work is probably needed to fix up the refs regarding a=msid, but I think this part should be easy to handle.
Change:
within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams. <del> 9. </del> <ins> 10. </ins> <del> 9.1. </del> <ins> 10.1. </ins> The following entry is added to the "HTTP/2 Settings" registry established by RFC7540:

Discussion:
There is not "right" place to put these, but as they are fairly large (and not that useful, frankly), I am going to suggest that they go after the frame definitions.
Yeah, these used to describe how you'd handle a bunch of new concepts, this is now pretty basic and not particularly enlightening. Mayyyybe useful for the establishment, if you've never seen Extended CONNECT, but... yeah. Seems good to move around now and we can cut it later if we don't end up adding anything useful to them. (I also updated with the section reference change from the other PRs to fix up conflicts, since this moved one of those)
I think these have evolved through various versions of the drafts. When the original draft was presented, things like a "CONNECT stream" and how other streams relate to it were not common knowledge, so the examples were maybe more useful. If everyone has got the idea, we can drop it.
Change:
"token_type" is a 2-octet integer, which matches the type in the challenge. <del> "token_key_id" is the least significant byte of the "key_id". </del> <ins> "token_key_id" is the least significant byte of the "key_id" in network byte order (in other words, the last 8 bits of "key_id"). </ins> "blinded_msg" is the Ne-octet blinded message defined above, computed as "SerializeElement(blinded_element)".  Ne is as defined

Discussion:
Is this the most exact way to put this? For byte arrays like a hash, I generally don't think of it as being network- or host- byte order. Do we have other docs that refer to stuff like this that we can crib from?
Nothing comes to mind right now, but I'm happy to look at alternatives.
Works for me =)
We should be explicit about what this means: This means that the byte is the last/rightmost byte of the hash, in order. Misinterpretation of this caused some confusion in interop.
Here's an attempt at saying this in other words to be extra clear?