jiebi/CodeConvo huggingface dataset:
Code change:
applies) "NodesType". If it occurs directly as a "comparable" in a comparison, the <del> function is declared to have a result type of "ValueType", or (conversion applies) "NodesType". </del> <ins> function is declared to have a result type of "ValueType". </ins> Otherwise, it occurs as an argument in another function expression, and the following rules for function arguments apply

Related discussion:
text: Thanks to NAME for spotting this.
NAME I presume you are ok with this change, so I'm going to merge it. Any concern, let me know and we can adjust the result.
Yes. Just didn't have chance to check this in context, but if I remember this properly, this change is good (and necessary).
Code change:
transport parameter; see termination.  However, state in middleboxes might time out earlier than that.  Though REQ-5 in RFC4787 recommends a 2 minute timeout interval, experience shows that sending packets <del> every 15 to 30 seconds is necessary to prevent the majority of middleboxes from losing state for UDP flows. </del> <ins> every 30 seconds is necessary to prevent the majority of middleboxes from losing state for UDP flows GATEWAY. </ins> 10.3.

Related discussion:
text: Thanks to Lucas for finding the study. Note that I found at least one middlebox with a default timeout of 30s; that was not a home gateway included in this study.
says that "experience shows" you should send packets every 15-30 seconds, RFC4787 notwithstanding. Ideally, we would have a source that we could reference for this "experience."
Maybe see URL
I'm going to say that while the 15s floor is a good requirement, I don't want to cite RFC 8085 for this gem, which I think is straight-up misinformation: "NATs require a state timeout of 2 minutes or longer [RFC4787]." We do cite RFC 8085 elsewhere and that's fine, but the fact here is that the IETF has requested that NATs provide a state timeout of 2 minutes. That does not mean that they do.
I have seen anecdata as well that showing 30 seconds is an important threshold. I think the ref we now have is good.
Code change:
6. <ins> The IMMEDIATE_ACK Frame is a frame which causes the peer to send a packet containing an ACK frame immediately, similar to the receipt of Initial and Handshake packets during the QUIC handshake. Receivers of the IMMEDIATE_ACK frame MAY choose to delay sending the ACK if the vast majority of received packets contain an IMMEDIATE_ACK or the receiver is under heavy load.  Senders MAY include multiple IMMEDIATE_ACK frames in a single QUIC packet, but the behavior is identical to a single IMMEDIATE_ACK frame. 7. </ins> Prior to receiving an ACK_FREQUENCY frame, endpoints send acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT.

Related discussion:
text: by adding a one byte IMMEDIATE_ACK frame.
editorial nit: my preference would be for frame diagrams to use the notation in QUIC transport. I see that ACK_FREQUENCY is defined using ASCII art, so perhaps you want to consider a separate follow up PR to switch styles after this lands.
Thanks Lucas, I filed to update them.
They currently use ascii art. Will write this up once is merged.
sgtm, thanks!
When sending a PTO packet, a sender wants to induce an immediate ACK. The only trick I know to induce such an ACK is intentionally skip the packet number. However, the problem of that approach is that it relies on the receiver not ignoring reorders. When an ACKFREQUENCY frame previously sent had set the bit, then it become impossible for a sender to induce an immediate ACK when sending a PTO packet. At the moment, the only solution is to bundle an ACK_FREQUENCY packet in each PTO packet, but that seems like a bit of unnecessary overhead to me. Should we have a dedicated frame for inducing immediate ACKs instead?
That's an option. Another option is to revisit the max_reordering idea discussed in . If the max reordering was 5, then you could skip 5 PNs. I do feel like it'd be nice to allow specifying an int for max reordering, since that matches up with adaptive packet threshold loss detection, but as I expressed in , I think getting the details right are deceptively difficult, so I'm torn.
This does seem like a real problem. I like the idea of a single "ELICIT_ACK" type frame. With one byte a sender could effectively mark its PTOs ensuring they get an ACK without relying on the trick. An explicit frame is also easier to implement for the sender than the packet number skipping.
There's quite a bit of discussion on this on the tcpm mailing list at the moment, ie: URL I'm increasingly thinking it's worth using an unused protected bit in the header for this. It'd end up competing with the 2-bit packet loss measurements, but given those are experimental and may never be widely deployed, I think it might be worth it. For example, I believe this could allow an implementation to not include maxackdelay in PTO if it set the "ACK-pull"(or whatever it's called) bit on the final packet.
Code change:
6. <ins> The IMMEDIATE_ACK Frame is a frame which causes the peer to send a packet containing an ACK frame immediately, similar to the receipt of Initial and Handshake packets during the QUIC handshake. Receivers of the IMMEDIATE_ACK frame MAY choose to delay sending the ACK if the vast majority of received packets contain an IMMEDIATE_ACK or the receiver is under heavy load.  Senders MAY include multiple IMMEDIATE_ACK frames in a single QUIC packet, but the behavior is identical to a single IMMEDIATE_ACK frame. 7. </ins> Prior to receiving an ACK_FREQUENCY frame, endpoints send acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT.

Related discussion:
text: That already seems possible if more than the threshold number of ack-eliciting packets are outstanding.
I've thought more about this, and I think most of the time a 1-byte frame would be acceptable, but it definitely adds some implementation complexity, so I'd be curious which design others prefer? If we can decide, then I'll be happy to write a PR(or NAME can). Besides PTO, a use case would be making the last packet before becoming app-limited elicit an immediate ACK. This could allow skipping maxackdelay for all PTOs(see ), though always doing it could be a bit much in some cases. For example, browsers commonly send a series of requests, but to the transport it seems app-limited between them, because it doesn't know the browser has another request to send. It might be useful for 'chirping' as well, but I've never tried that, so it's mostly speculation.
We don't currently have any intention of deploying them either, and I think that's unlikely to change. I haven't seen a lot of good evidence that they are terribly helpful, and content providers don't seem to have a good incentive for implementing it. For us at least, the difference in complexity for a frame versus a bit in the header is negligible. A frame is actually be slightly easier to implement and losing a byte here and there isn't so bad.
I strongly prefer using the header bit. Although it will be a bit more work to implement, the fact that I won't end up with a 1-byte STREAM frame that I have to split off at the end of the packet will be worth the effort.
Is testimony of network operators not taken as evidence? I remember a line of people, from different companies -- BT, ATT, and so on, at IETF 101 practically begging for some information in QUIC packets to be exposed for monitoring and troubleshooting.
I do not see anyone propose a 1-byte STREAM frame. I believe what is meant is a new frame type. If anything, using a new frame type to elicit an ACK is easier than using a header bit, as it involves fewer parts of the code to change.
Nobody is proposing a 1-byte STREAM frame (you can't just make up stream data anyway). The problem is that a new frame would consume bytes (or probably one byte) in the packet payload.
Code change:
6. <ins> The IMMEDIATE_ACK Frame is a frame which causes the peer to send a packet containing an ACK frame immediately, similar to the receipt of Initial and Handshake packets during the QUIC handshake. Receivers of the IMMEDIATE_ACK frame MAY choose to delay sending the ACK if the vast majority of received packets contain an IMMEDIATE_ACK or the receiver is under heavy load.  Senders MAY include multiple IMMEDIATE_ACK frames in a single QUIC packet, but the behavior is identical to a single IMMEDIATE_ACK frame. 7. </ins> Prior to receiving an ACK_FREQUENCY frame, endpoints send acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT.

Related discussion:
text: Given that you set this signal on a PTO, and PTOs are often retransmissions of packets, this would require you to repackage (and, most likely, cut off a single byte from a STREAM frame). Using a header bit would solve that problem.
NAME and I discussed this and there are number of ways to fix this, but given this issue of not being able to elicit an immediate ACK by skipping packet numbers is introduced by the draft, we feel it's important it be fixed in some way. One more option is new STREAM frame codepoints that elicit an immediate ACK.
I'm ready to write a PR, but I'd appreciate thoughts on whether the existing PING frame should be repurposed or we should add a new frame(ACK, PONG, etc). I lean towards a new frame, since there are enough code-points and I believe there are use cases for the existing PING frame that does not elicit an immediate ACK.
+1. While I would not be opposed to repurposing the existing PING frame, I do not see the necessity of doing that. Let's simply consume one code point of the remaining 33.
Thanks, now for bikeshedding time. Some possible names: ACKME ACKPULL (from TCP) FAST_ACK PONG
Putting on my bikeshedding hat: I don't think we should prefix the frame name with ACK since that almost makes it looks like yet another variant of the ACK frame. The "pull" TCP terminology is fine (e.g. PULLACK) but we could also be more explicit with something like SOLICIT_ACK.
SCTP has something similar and calls it SACK-IMMEDIATELY (RFC 7053).
Thanks, I'd be happy with ACKIMMEDIATELY or IMMEDIATEACK
For those two options I'd prefer IMMEDIATE_ACK for the same reasoning as above -- so it appears less like an ACK variant.
IMMEDIATEACK sounds good to me. Alternatively, I'd be also fine with something like ACKNOW.
IMMEDIATE_ACK it is, PR coming.
Code change:
The bandwidth is per L2VPN service. <del> 'svc-inbound-bandwidth' indicates the inbound bandwidth of the </del> <ins> 'svc-pe-to-ce-bandwidth' indicates the inbound bandwidth of the </ins> connection (i.e., download bandwidth from the service provider to the site). <del> 'svc-outbound-bandwidth' indicates the outbound bandwidth of the </del> <ins> 'svc-ce-to-pe-bandwidth' indicates the outbound bandwidth of the </ins> connection (i.e., upload bandwidth from the site to the service provider).

Related discussion:
text: RFC8299 and RFC8466 use "inbound-bandwidth" and "outbound-bandwidth" from the point of view of the customer site. L3NM also uses this terminology from the point of view of the customer's site. L2NM flips the terminology, for example "inbound" is from PE's perspective. To avoid confusion, it would better in both L3NM and L2NM to use explicit terminology so that the direction is obvious, e.g. "PE-to-CE-bandwidth" "CE-to-PE-bandwidth" In the description field, it would be good to say which field in RFC8299/RFC8466 this corresponds to.
practically it is ingress-Policer and egress-Shaper, because the BW is controlled only from the PE side. in addition there is policer and shaper per CoS/Queue which should be addressed.
I guess you meant "input-bandwidth" and "output-bandwidth". We do have the following for the L3NM: 'inbound-bandwidth': Indicates, in bits per second (bps), the inbound bandwidth of the connection (i.e., download bandwidth from the service provider to the site). 'outbound-bandwidth': Indicates, in bps, the outbound bandwidth of the connection (i.e., upload bandwidth from the site to the service provider). >L2NM flips the terminology, for example "inbound" is from PE's perspective. 'svc-inbound-bandwidth' indicates the inbound bandwidth of the connection (i.e., download bandwidth from the service provider to the site). 'svc-outbound-bandwidth' indicates the outbound bandwidth of the connection (i.e., upload bandwidth from the site to the service provider). Please note that we do already have the following in the common I-D: "Indicates support for the inbound bandwidth in a VPN. That is, support for specifying the download bandwidth from the service provider network to the VPN site. Note that the L3SM uses 'input' to identify the same feature. That terminology should be deprecated in favor of the one defined in this module."; Which was echoed in the L3NM, e.g., "Note that the L3SM uses 'input- -bandwidth' to refer to the same concept.";
Hi Med In URL it says as follows, maybe it is a typo?
Code change:
The bandwidth is per L2VPN service. <del> 'svc-inbound-bandwidth' indicates the inbound bandwidth of the </del> <ins> 'svc-pe-to-ce-bandwidth' indicates the inbound bandwidth of the </ins> connection (i.e., download bandwidth from the service provider to the site). <del> 'svc-outbound-bandwidth' indicates the outbound bandwidth of the </del> <ins> 'svc-ce-to-pe-bandwidth' indicates the outbound bandwidth of the </ins> connection (i.e., upload bandwidth from the site to the service provider).

Related discussion:
text: container svc-outbound-bandwidth { if-feature "vpn-common:outbound-bw"; description "From the PE perspective, the service outbound bandwidth of the connection."; But I would urge you to change the terminology to "PE-to-CE-bandwidth" /"CE-to-PE-bandwidth" to make it super-explicit, the current terminology has been causing endless confusion to implementers (I realise it's inherited from the service models, but changing the terminology in LXNM would cure the problem well)
This is a typo. It needs to be fixed. Will move this one to the list.
Julian, please check the PR at 7e5286a
Med, this is great, thanks! Can it be changed similarly in L3NM as well? Julian
Code change:
its prior membership with a PSK. There are a few practical challenges to this approach.  For example, <del> the application will need to ensure that the new members have the </del> <ins> the application will need to ensure that all members have the </ins> required PSK, including any new members that have joined the group since the epoch in which the PSK was issued.

Related discussion:
text: Thanks both, I'll have a look today.
Looks good ! Thanks Richard!
The architecture document mentions PSKs in several places, but does not discuss the security of them. Nor does it discuss the security of External Proposals and External Commits. Notably, the third paragraph of 5.1 Membership Changes says "…the set of devices controlled by the user can only be altered by an authorized member of the group." The set of devices could be altered via an External Commit by a non-member. At the end of 5.2 Parallel Groups there is a vague mention of "using the PSK mechanism to link healing properties among parallel groups.", but no discussion of the security. Likewise Section 5.5 Recovery After State Loss talks about PSKs as the solution to a problem but the risks are not discussed. External Proposals and External Commits should be discussed in section 5.4 Access Control.
NAME I fixed the specific problems you note in
Code change:
nonce re-use since the client's ESNI key share, and thus the value of Zx, does not change across ClientHello retries.) <ins> Note that ESNIContents will not be directly transmitted to the server in the ClientHello.  The server will instead reconstruct the same object by obtaining its values from ClientEncryptedSNI and ClientHello. </ins> [[TODO: label swapping fixes a bug in the spec, though this may not be the best way to deal with HRR.  See https://github.com/tlswg/ draft-ietf-tls-esni/issues/121 and https://github.com/tlswg/draft- ietf-tls-esni/pull/170 for more details.]] <ins> Same value as ClientEncryptedSNI.record_digest. Same value as ClientEncryptedSNI.key_share. Same nonce as ClientHello.random. </ins> The client then creates a ClientESNIInner structure: A random 16-octet value to be echoed by the server in the

Related discussion:
text: I got a little tripped up on this point! Maybe you have a better way to explain it.
Thanks, NAME
Code change:
The next bit (0x40) of byte 0 is set to 1.  Packets containing a zero value for this bit are not valid packets in this version and <del> MUST be discarded. </del> <ins> MUST be discarded.  A value of 1 for this bit allows QUIC to coexist with other protocols; see RFC7983. </ins> The third most significant bit (0x20) of byte 0 is the latency spin bit, set as described in spin-bit.

Related discussion:
text: NAME said:
This particular choice has not a lot to do with QUIC and would therefore bring in a lot of non-sequitur references, but a single sentence won't hurt. It has to be repeated, which is gross, but I can live with that.
Code change:
5.2. The following MAC algorithm applies to block ciphers that use the <del> with Encrypt-then-MAC processing described in RFC7366. </del> <ins> Encrypt-then-MAC processing described in RFC7366. </ins> 5.3.

Related discussion:
text: URL Francesca Palombini has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Thank you for the work on this document. I only have minor comments and nits below. Francesca sending messages to the client. A zero-length CID value indicates that the client is prepared to send with a CID but does not wish the server to use one when sending. ... to use when sending messages towards it. A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID. FP: clarification question: I am not sure the following formulation is very clear to me: "to send with a(/the client's) CID". Could "send with" be rephrased to clarify? The previous paragraph uses "using a CID value", that would be better IMO. the record format defined in {{dtls-ciphertext} with the new MAC FP: nit - missing "}" in markdown. The following MAC algorithm applies to block ciphers that use the with Encrypt-then-MAC processing described in [RFC7366]. FP: remove "with" Section 10.1 FP: I believe you should specify 1. what allowed values are for this column (i.e. Y or N, and what they mean) and 2. what happens to the existing entries - namely that they all get "N" value. Section 10.2 FP: Just checking - why is 53 "incompatible with this document"? Value Extension Name TLS 1.3 DTLS Only Recommended Reference FP: nit- s/DTLS Only/DTLS-Only to be consistent with 10.1
Code change:
7. Security considerations for DetNet are described in detail in I- <del> D.ietf-detnet-security.  This section considers exclusively security considerations which are specific to the DetNet data plane. </del> <ins> D.ietf-detnet-security.  General security considerations are described in I-D.ietf-detnet-architecture.  This section considers exclusively security considerations which are specific to the DetNet IP data plane. </ins> Security aspects which are unique to DetNet are those whose aim is to provide the specific quality of service aspects of DetNet, which are

Related discussion:
text: Sorry, now it is uploaded to the right folder. Simple accept pull request. Thx Bala'zs
Code change:
DTLS RFC6347 or DTLS-SRTP RFC5763, MUST be used, as appropriate for the media type, as specified in <del> 5.1.3. </del> <ins> The SDES SRTP keying mechanism from RFC4568 MUST NOT be used, as discussed in I-D.ietf-rtcweb-security-arch. 5.1.2. </ins> <del> For media m= sections, JSEP implementations MUST support both the "UDP/TLS/ RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of these two profiles for each media m= line they produce in an offer.  For data m= sections, implementations MUST support both the "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" profiles and MUST indicate one of these two profiles for each data m= line they </del> <ins> For media m= sections, JSEP implementations MUST support the "UDP/TLS/RTP/SAVPF" profile specified in RFC7850, and MUST indicate this profile for each media m= line they produce in an offer.  For data m= sections, implementations MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this profile for each data m= line they </ins> produce in an offer.  Because ICE can select either TCP or UDP <del> transport depending on network conditions, both advertisements are </del> <ins> transport depending on network conditions, this advertisement is </ins> consistent with ICE eventually selecting either either UDP or TCP. Unfortunately, in an attempt at compatibility, some endpoints

Related discussion:
text: All the xref I removed are used elsewhere in spec other than the one which I added to where it is used.
Fixed as Justin suggested and ready for re review
NAME - have a look - I think I got all the changes
I tweaked the discussion of unknown a=; now LGTM
Code change:
In addition, the client MAY advise the server at which IP the challenge is provisioned: <del> An IPv4 or IPv6 address which, if given, MUST be included in the set of IP addresses to which the domain name resolves.  If given, the server will connect to that specific IP address instead of arbitrarily choosing an IP from the set of A and AAAA records to which the domain name resolves.  If the field is given but equal to ""peer"", the server MUST treat the field as if it contained the IP address from which the response was received. </del> <ins> An IPv4 or IPv6 address which, in dotted decimal form or RFC4291 form, respectively.  If given, this address MUST be included in the set of IP addresses to which the domain name resolves.  If given, the server SHOULD connect to that specific IP address instead of arbitrarily choosing an IP from the set of A and AAAA records to which the domain name resolves. </ins> On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the

Related discussion:
text: The format should be specified more clearly, by reference to a couple of RFCs The "peer" provision seems kind of awkward. For server implementations where the validation is done by a separate entity than the ACME interactions (like ), this means that the challenge no longer has all the information that the validation agent needs to do the validation. I'm inclined to drop it and put the burden on the client.