jiebi/CodeConvo huggingface dataset:
Change:
At IETF 106, we discussed removing the link relation. This PR does that.
I suppose we should be reading and implementing draft-ietf-git-github-wg-configuration ... As Warren's T-shirt says: "In my defense I was left unsupervised."
100% agreed about the build output...
People who put build output in their repository deserve a special place.

Discussion:
3. <del> Some captive portal network deployments may be unable to change, or unwilling to risk changing, the network infrastructure necessary to use any of the above options.  In such deployments, when clear text HTTP intercept and redirection are used, a Link relation header (RFC8288, Section 3.3) MAY be inserted to convey to a HTTP client (user agent) the associated Captive Portal API URI. HTTP user agents MUST ignore this link relation in any context other than when explicitly probing to detect the presence of a captive portal.  Failure to do so could allow an attacker to inject a Captive Portal API URI other than the correct URI for a given network or for networks where there is no captive portal present at all. 4. </del> A device may learn about Captive Portal API URIs through more than one of (or indeed all of) the above options.  It is a network configuration error if the learned URIs are not all identical.

captive device MUST prioritize URIs learned from network provisioning or configuration mechanisms before all other URIs.  Specifically, URIs learned via any of the options in option should take precedence <del> over any URI learned via a mechanism like the one described in linkrel. </del> <ins> over any URI learned via some other mechanism, such as a redirect. </ins> If the URIs learned via more than one option described in option are not all identical, this condition should be logged for the device owner or administrator.  URI precedence in this situation is not specified by this document. <del> 5. </del> <ins> 4. </ins> This document requests two new IETF URN protocol parameter (RFC3553) entries. Thanks IANA! <del> 5.1. </del> <ins> 4.1. </ins> <del> 5.1.1. </del> <ins> 4.1.1. </ins> Registry name: Captive Portal Unrestricted Identifier

Index value: Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. <del> 5.1.2. Registry name: Captive Portal API Link Relation Type URN: urn:ietf:params:capport-api Specification: RFC TBD (this document) Repository: RFC TBD (this document) Index value: Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. 6. </del> <ins> 5. </ins> <del> An attacker with the ability to inject DHCP messages, RAs, or HTTP headers into cleartext HTTP communications could include an option or link relation from this document and so force users to contact an </del> <ins> An attacker with the ability to inject DHCP messages or RAs could include an option from this document to force users to contact an </ins> address of his choosing.  As an attacker with this capability could simply list himself as the default gateway (and so intercept all the victim's traffic); this does not provide them with significantly more
Change:
Earlier version of this document requested a parameter to be used for Link Relation purposes. This LinkRel use was removed as was the explicit parameter request, but the surround grammar was overlooked. Also: rev draft version to -02 and document month to February in anticipation of post a new version.

Discussion:
Captive-Portal Identification in DHCP / RA <del> draft-ietf-capport-rfc7710bis-01 </del> <ins> draft-ietf-capport-rfc7710bis-02 </ins> Abstract

4. <del> This document requests two new IETF URN protocol parameter (RFC3553) entries.  This document also requests a reallocation of DHCPv4 option </del> <ins> This document requests one new IETF URN protocol parameter (RFC3553) entry.  This document also requests a reallocation of DHCPv4 option </ins> codes (see exp106 for background). Thanks IANA!
Change:
Change last sentence of Introduction from: While other formats could be used as well these are out of scope for this document. to: While other formats could be used as well, those are out of scope for this document.
Good point, thank you!

Discussion:
As recommended in Section 5.8 of I-D.ietf-ace-oauth-authz, this specification uses CBOR web tokens to convey claims within an access token issued by the server.  While other formats could be used as <del> well these are out of scope for this document. </del> <ins> well, those are out of scope for this document. </ins> 1.1.
Change:
It is perhaps a stretch to call the description of using a for DLTS 1.3 as "editorial", but it really is the analogous way to do it, so this seems like just some additional exposition and not new content. I think that it will be okay to just include this in the XML file provided to the RFC Editor when they ask for one after approval.

Discussion:
response for the client.  The access token MUST be bound to the RPK of the client by means of the "cnf" claim. <del> The response MUST contain an "ace_profile" parameter if the"ace_profile" parameter in the request is empty, and MAY contain this parameter otherwise (see Section 5.8.2 of I-D.ietf-ace-oauth- authz).  This parameter is set to "coap_dtls" to indicate that this profile MUST be used for communication between the client and the resource server.  The response also contains an access token with information for the resource server about the client's public key. The authorization server MUST return in its response the parameter </del> <ins> The response MUST contain an "ace_profile" parameter if the "ace_profile" parameter in the request is empty, and MAY contain this parameter otherwise (see Section 5.8.2 of I-D.ietf-ace-oauth-authz). This parameter is set to "coap_dtls" to indicate that this profile MUST be used for communication between the client and the resource server.  The response also contains an access token with information for the resource server about the client's public key.  The authorization server MUST return in its response the parameter </ins> "rs_cnf" unless it is certain that the client already knows the public key of the resource server.  The authorization server MUST ascertain that the RPK specified in "rs_cnf" belongs to the resource

any re-coding.  This allows the resource server to retrieve the shared secret directly from the "cnf" claim of the access token. <ins> DTLS 1.3 does not use the ClientKeyExchange message; for DTLS 1.3, the access token is placed in the "identity" field of a "PskIdentity" within the "PreSharedKeyExtension" of the "ClientHello". </ins> If a resource server receives a ClientKeyExchange message that contains a "psk_identity" with a length greater than zero, it MUST parse the contents of the "psk_identity" field as CBOR data structure

provide similar forward-secrecy properties to using ephemeral Diffie- Hellman (DHE) key exchange mechanisms.  For longer-lived access tokens, DHE cipher suites should be used, i.e., cipher suites of the <del> form TLS_DHE_PSK_*. </del> <ins> form TLS_DHE_PSK_* or TLS_ECDHE_PSK_*. </ins> Constrained devices that use DTLS RFC6347 are inherently vulnerable to Denial of Service (DoS) attacks as the handshake protocol requires
Change:
Feedback from implementers: Section 5.10.1 of the ACE framework uses the term "overwrite" "This specification RECOMMENDS that an RS stores only one token per proof-of-possession key, meaning that an additional token linked to the same key will overwrite any existing token at the RS. The reason is that this greatly simplifies (constrained) implementations, with respect to required storage and resolving a request to the applicable token." and this is mirrored in the OSCORE profile. However, this is not strictly an overwrite of a token because some information in the original token needs to be kept. For example, if the client requests new access rights only using the kid as reference, and the corresponding access token overwrites the original token, then information about the actual key would be lost. Proposed reformulation: "This specification RECOMMENDS that an RS stores only one token per proof-of-possession key. This means that an additional token linked to the same key will supersede any existing token at the RS, by replacing the corresponding authorization information. The reason is that ..."

Discussion:
request, and therefore not stored at the RS. This specification RECOMMENDS that an RS stores only one token per <del> proof-of-possession key, meaning that an additional token linked to the same key will overwrite any existing token at the RS.  The reason is that this greatly simplifies (constrained) implementations, with </del> <ins> proof-of-possession key.  This means that an additional token linked to the same key will supersede any existing token at the RS, by replacing the corresponding authorization information.  The reason is that this greatly simplifies (constrained) implementations, with </ins> respect to required storage and resolving a request to the applicable token.
Change:
This part got reworded a bit in response to IESG comments and this (admittedly unusual) grammatical construction got changed to something that doesn't make sense.
Thanks. "which is considerably more token provisioned" is clearly not right. I think the intent was "tokens provisioned" but "token provisionings" is more accurate. Unless there are any objections I will merge on Monday.

Discussion:
case of re-boots.  This document RECOMMENDS the exchange of 64 bit random nonces.  Considering the birthday paradox, the average collision for each nonce will happen after 2^32 messages, which is <del> considerably more token provisioned than would be expected for </del> <ins> considerably more token provisionings than would be expected for </ins> intended applications.  If applications use something else, such as a counter, they need to guarantee that reboot and loss of state on either node does not provoke reuse.  If that is not guaranteed, nodes
Change:
merging.
Endpoints expect the connection to encounter reordering might want to indicate that the receiver should not send immediate acks on receiving a reordered packet.

Discussion:
Since the last acknowledgement was sent, "max_ack_delay" amount of time has passed. <del> loss and batch section describes exceptions to this strategy. </del> <ins> reordering, congestion, and batch describe exceptions to this strategy. </ins> An endpoint is expected to bundle acknowledgements when possible. Every time an acknowledgement is sent, bundled or otherwise, all

6.1. <del> To expedite loss detection, endpoints SHOULD send an acknowledgement immediately on receiving an ack-eliciting packet that is out of order.  Endpoints MAY continue sending acknowledgements immediately on each subsequently received packet, but they SHOULD return to using delay thresholds as specified above within a period of 1/8 x RTT, unless more ack-eliciting packets are received out of order. </del> <ins> As specified in Section 13.3.1 of QUIC-TRANSPORT, endpoints SHOULD send an acknowledgement immediately on receiving a reordered ack- eliciting packet, unless the peer has sent a "disable_ack_on_reordering" transport parameter, described below: </ins> <del> Similarly, packets marked with the ECN Congestion Experienced (CE) codepoint in the IP header SHOULD be acknowledged immediately, to reduce the peer's response time to congestion events. </del> <ins> This optional transport parameter is sent by an endpoint that is reordering tolerant or expects reordering in the connection.  An endpoint that receives this transport parameter MUST NOT send an immediate acknowledgement when reordering is observed, and MUST continue delaying acknowledgements as per sending.  This parameter is a zero-length value. </ins> 6.2. <ins> As specified in Section 13.3.1 of QUIC-TRANSPORT, an endpoint SHOULD immediately acknowledge packets marked with the ECN Congestion Experienced (CE) codepoint in the IP header.  Doing so reduces the peer's response time to congestion events. 6.3. </ins> For performance reasons, an endpoint can receive incoming packets from the underlying platform in a batch of multiple packets.  This batch can contain enough packets to cause multiple acknowledgements
Change:
Also,
There's nothing odd about an immediate ACK! Perhaps the text should start by saying that the spec allows a receiver to do this anyway? However, the current text doesn't explain why the Immediate ACK might be useful. I could see three places that might benefit from an IMMEDIATE_ACK: Two cases relevant to SCTP [RFC7053] are: When the rate of transmission was very low and packets might be lost and not detected (something not uncommon in some SCTP uses); as an alternative to detect connectivity failure and trigger path failover. I'm not sure how important these specific cases are for QUIC, because the discussion at the time in TSVWG appeared to centre around use for signalling traffic? There could also be real opportunity to use this to get more precise timing/congestion information. A set of per-packet ACKs might be useful while a CC is probing to confirm available capacity, etc. Have I missed a killer application for the method - it would be helpful to me to understand /some example for how the WG think this could be used. (aside: I am actually uncertain whether this would really be a good change to TCP, especially with the heterogeniety of TCP middleboxes and senders,... that's another story, but I'd think it might be nice to not rely on draft-gomez-tcpm-ack-pull as a reference. I could suggest RFC7053, where people might recall there was quite some discussion in TSVWG about whether SCTP would benefit from being able to trigger an immediate response.)
We use an immediate ACK to support CC by delayed ACKs.
URL adds two use cases that uses IMMEDIATE_ACK.
Seems would benefit from a little polish and some improvement in the examples.

Discussion:
6. <del> 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. </del> <ins> A sender can use an ACK_FREQUENCY frame to reduce the number of acknowledgements sent by a receiver, but doing so increases the chances that time-sensitive feedback is delayed as well.  For example, as described in loss, delaying acknowledgements can increase the time it takes for a sender to detect packet loss.  The IMMEDIATE_ACK frame helps mitigate this problem. An IMMEDIATE_ACK frame can be useful in other situations as well. For example, it can be used with a PING frame (Section 19.2 of QUIC- TRANSPORT) if a sender wants an immediate RTT measurement or if a sender wants to establish receiver liveness as quickly as possible. An endpoint SHOULD send a packet containing an ACK frame immediately upon receiving an IMMEDIATE_ACK frame.  An endpoint MAY delay sending an ACK frame despite receiving an IMMEDIATE_ACK frame.  For example, an endpoint might do this if a large number of received packets contain an IMMEDIATE_ACK or if the endpoint is under heavy load. </ins> 7.
Change:
"Generally, when using maxackdelay for PTO computations, endpoints MUST use the maximum of the current value and all those in flight." I think the words generally and MUST do not sit well together, and it would be better to say what is the requirement.

Discussion:
While it is expected that endpoints will have only one ACK_FREQUENCY frame in flight at any given time, this extension does not prohibit <del> having more than one in flight.  Generally, when using "max_ack_delay" for PTO computations, endpoints MUST use the maximum of the current value and all those in flight. </del> <ins> having more than one in flight.  When using "max_ack_delay" for PTO computations, endpoints MUST use the maximum of the current value and all those in flight. </ins> When the number of in-flight ack-eliciting packets is larger than the ACK-Eliciting Threshold, an endpoint can expect that the peer will
Change:
Plus fixing one spot where it said 2^14, but I think it should have been 2^24

Discussion:
at a data receiver.  Experience shows that this cost reduction can be significant for high bandwidth connections. <del> Similarly, receiving UDP packets can also be CPU intensive, and reducing acknowledgement frequency reduces this cost at a data sender. </del> <ins> Similarly, receiving and processing UDP packets can also be CPU intensive, and reducing acknowledgement frequency reduces this cost at a data sender. </ins> Severely asymmetric link technologies, such as DOCSIS, LTE, and satellite links, connection throughput in the data direction

QUIC-TRANSPORT currently specifies a simple delayed acknowledgement mechanism that a receiver can use: send an acknowledgement for every <del> other packet, and for every packet (for a short while) when reordering is observed.  This simple mechanism does not allow a sender to signal its constraints, which in turn limits what a receiver can do to delay acknowledgements and reduce acknowledgement frequency.  This extension provides a mechanism to solve this problem. </del> <ins> other packet, and for every packet when reordering is observed.  This simple mechanism does not allow a sender to signal its constraints, which in turn limits what a receiver can do to delay acknowledgements and reduce acknowledgement frequency.  This extension provides a mechanism to solve this problem. </ins> 3.

A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an <del> acknowledgement.  Values of 0 and 2^14 or greater are invalid, and </del> <ins> acknowledgement.  Values of 0 and 2^24 or greater are invalid, and </ins> receipt of these values MUST be treated as a connection error of type PROTOCOL_VIOLATION.

following fields: A variable-length integer representing the sequence number <del> assigned to the ACK-FREQUENCY frame by the sender, see multiple- frames. </del> <ins> assigned to the ACK-FREQUENCY frame by the sender to allow receivers to ignore obsolete frames, see multiple-frames. </ins> A variable-length integer representing the maximum number of ack- eliciting packets after which the receiver sends an
Change:
With the last draft(-03), there is a change on ACKFREQUENCY frame format (Remove Ignore CE and Reordering Threshold ) may be need change minack_delay value for detect what frame format do you need to use for decode ?
I think we should change the minackdelay Transport Param codepoint, which is currently 0xff03de1a, maybe to 0xff04de1a.
yes, I also thought about this and then forgot to bring it up. Maybe we should even submit a new version with a different number right tomorrow.
Submitting and then revving the version SGTM. I can't see a reason not to bump the codepoint, so please merge my PR if you agree NAME
Following up on discussion in issue and . It is not clear if this signal is needed at all. CE should always be provided as soon as possible. Only follow-up CE in the same RTT might be deployed. However, this seem to be part of the ECN specification (e.g. as discussed for AccECN) and not necessarily in scope for this document, as it is not clear why a sender signal for this is needed.
Thanks for filing this, I'll plan to include this in slides for Philadelphia.
Discussion at IETF 114: Remove Ignore_CE; we can add a transport parameter (possible) if someone really wants this feature.

Discussion:
A 1-bit field representing a boolean truth value.  This field is set to "true" by an endpoint that does not wish to receive an <del> immediate acknowledgement when the peer receives CE-marked packets (out-of-order).  0 represents 'false' and 1 represents 'true'. A 1-bit field representing a boolean truth value.  This field is set to "true" by an endpoint that does not wish to receive an </del> immediate acknowledgement when the peer receives a packet out of order (out-of-order). 0 represents 'false' and 1 represents 'true'.

RFC8257 or other congestion controllers that mark more frequently than classic ECN RFC3168. <del> If the most recent ACK_FREQUENCY frame an endpoint has received from the peer has an "Ignore CE" value of "true" (0x01), receipt of a CE marked packet SHOULD NOT cause an endpoint to send an immediate acknowledgement.  The endpoint still sends an immediate acknowledgement if it would have for a non CE marked packet.  If an immediate acknowledgement is not sent, the CE marks are reported in the next acknowledgement. The Ignore-CE bit SHOULD NOT be set if the sender sets ECT(1) in its outgoing packets, such as with L4S, because it delays the congestion controller's ability to quickly respond to congestion. </del> 7.3. For performance reasons, an endpoint can receive incoming packets
Change:
and provides some further clarification as it was easy to wrongly read to which endpoint the minackdelay applies to. I guess to avoid confusing this could be even called something like capableminack_delay but not sure if that makes a bug difference.
Not remembering it at all would be rather pointless :) I think the authors intended to add, " for use in a subsequent connection."
Yes, this sentence also confused me a lot!
I don't believe the draft says which takes precedence if the Ack-Eliciting Threshold results in the data receiver having to send an ACK sooner than the minackdelay. I believe the draft ought to say that minackdelay takes precedence over Ack-Eliciting Threshold if the two conflict. My reasoning is that a processor needs time before it thinks about a threshold, similar to the reasoning behind §7.3 on Batch Processing of Packets, which says: But I wouldn't fight hard, if someone has better reasoning against this order of precedence.
The minackdelay is an indication from the sender of this information that it practical is not able to send acks faster, e.g. because of the timer granularity. I tried to clarify this in PR NAME does this resolve this issue?
Closing as was merged. Please reopen or open new issue if still not clear!
Looks good, with a few minor textual improvements suggested.

Discussion:
QUIC-TRANSPORT): A variable-length integer representing the minimum amount of time <del> in microseconds by which the endpoint can delay an acknowledgement.  This limit could be based on the receiver's clock or timer granularity. </del> <ins> in microseconds by which the endpoint that is sending this value is able to delay an acknowledgement.  This limit could be based on the receiver's clock or timer granularity. 'min_ack_delay' is used by the peer to avoid requesting too small a value in the Request Max Ack Delay field of the ACK_FREQUENCY frame. </ins> An endpoint's min_ack_delay MUST NOT be greater than its max_ack_delay.  Endpoints that support this extension MUST treat

does not cause the endpoint to change its acknowledgement behavior. Endpoints MUST NOT remember the value of the min_ack_delay transport <del> parameter they received.  Consequently, ACK_FREQUENCY frames cannot be sent in 0-RTT packets, as per Section 7.4.1 of QUIC-TRANSPORT. </del> <ins> parameter they received for use in a subsequent connection. Consequently, ACK_FREQUENCY frames cannot be sent in 0-RTT packets, as per Section 7.4.1 of QUIC-TRANSPORT. </ins> This Transport Parameter is encoded as per Section 18 of QUIC- TRANSPORT.