jiebi/CodeConvo huggingface dataset:
Code change:
uses the ::boilerplate macro of URL
I'm not sure what I'm doing wrong but when I try this I get an error: I'm using kramdown-rfc2629 version 1.4.3
fixed in URL NAME
Friendly reminder ;)
PTAL

Related discussion:
text: underlying credentials ensures their confidentiality. When client authentication is not possible, the authorization server <del> SHOULD employ other means to validate the client's identity -- for </del> <ins> SHOULD employ other means to validate the client's identity - for </ins> example, by requiring the registration of the client redirect URI or enlisting the resource owner to confirm identity.  A valid redirect URI is not sufficient to verify the client's identity when asking for
Code change:
uses the ::boilerplate macro of URL
I'm not sure what I'm doing wrong but when I try this I get an error: I'm using kramdown-rfc2629 version 1.4.3
fixed in URL NAME
Friendly reminder ;)
PTAL

Related discussion:
text: authorization requests automatically without user consent or interaction, except when the identity of the client can be assured. This includes the case where the user has previously approved an <del> authorization request for a given client ID -- unless the identity of </del> <ins> authorization request for a given client ID - unless the identity of </ins> the client can be proven, the request SHOULD be processed as if no previous request had been approved.
Code change:
uses the ::boilerplate macro of URL
I'm not sure what I'm doing wrong but when I try this I get an error: I'm using kramdown-rfc2629 version 1.4.3
fixed in URL NAME
Friendly reminder ;)
PTAL

Related discussion:
text: service, or introduce a wide range of malicious side-effects. The authorization server and client MUST sanitize (and validate when <del> possible) any value received -- in particular, the value of the </del> <ins> possible) any value received - in particular, the value of the </ins> "state" and "redirect_uri" parameters. 7.18.
Code change:
rewords a circular definition in §2.3
Some editorial improvements [x] definition of user agent ( is an abnf syntax)

Related discussion:
text: 2.4. <del> Confidential and credentialed clients establish a client authentication method with the authorization server suitable for the security requirements of the authorization server.  The authorization </del> <ins> If the client is confidential or credentialed, the authorization </ins> server MAY accept any form of client authentication meeting its <del> security requirements. Confidential and credentialed clients are typically issued (or establish) a set of client credentials used for authenticating with the authorization server (e.g., password, public/private key pair). </del> <ins> security requirements (e.g., password, public/private key pair). </ins> The authorization server MUST authenticate the client whenever possible.  If the authorization server cannot authenticate the client
Code change:
consistently use "confidential or credentialed"
Some editorial improvements [x] definition of user agent ( is an abnf syntax)

Related discussion:
text: 3.2.1. <del> Confidential clients or other clients issued client credentials MUST authenticate with the authorization server as described in client- authentication when making requests to the token endpoint.  Client authentication is used for: </del> <ins> Confidential or credentialed clients MUST authenticate with the authorization server as described in client-authentication when making requests to the token endpoint.  Client authentication is used for: </ins> Enforcing the binding of refresh tokens and authorization codes to the client they were issued to.  Client authentication is critical
Code change:
From Vittorio: The “insufficientscope” description here is problematic. The privileges the AT carries/points to are not necessarily (or exclusively) represented by the included scopes (eg the RO might have granted document:read to the client, but RO might have no privileges for the particular document being requested in this particular call). It might be useful to specify that “invalidscope” should be used for authorization errors that can be actually expressed in terms of delegated authorization, leaving to RS implementers the freedom to handle other authorization issues (eg user privileges, RBAC, etc) with a different error code. Or at least, we should be clear that authorization logic not expressed via scopes is out of scope (pun not intended) for this specification. Note, this isn’t an abstract problem: there are SDKs out there that use “invalid_scope” for every permission issues. Very confusing.
to me, insufficientscope => the client does not have scope required for the request invalidscope => when I see invalid_scope, I think that the RS does not understand what scope the client has
I'll get clarity for what Vittorio is asking for.
Here is my restatement from thread with Vittorio: "insufficientscopes" - is the correct error to return if the application has not been granted the scopes required for the request Vittorio: "to me the highest order but is ensuring that the reader doesn’t abuse insufficientscopes and realizes other error codes are possible." I've submitted a pull request with suggested language changes

Related discussion:
text: HTTP 401 (Unauthorized) status code.  The client MAY request a new access token and retry the protected resource request. <del> The request requires higher privileges than provided by the access token.  The resource server SHOULD respond with the HTTP 403 (Forbidden) status code and MAY include the "scope" attribute with the scope necessary to access the protected resource. </del> <ins> The request requires higher privileges (scopes) than provided by the scopes granted to the client and represented by the access token. The resource server SHOULD respond with the HTTP 403 (Forbidden) status code and MAY include the "scope" attribute with the scope necessary to access the protected resource. </ins> If the request lacks any authentication information (e.g., the client was unaware that authentication is necessary or attempted using an
Code change:
Thanks as lot Vittorio! You gave us a lot of homework but I think the draft will be improved a lot based on it. Re OIDC implicit: I‘m reluctant to explicitly endorse use of OIDC implicit (response type „idtoken“ or „code idtoken“) as there are examples in the wild where the idtoken is used as access token. Moreover, I‘m not aware of any systematic security threat analysis of those flows. I‘m fine with pointing out to readers that omission of response type „token“ does not deprecate other extension response types. WDYT? Thank you, I am so glad you think so! I hear you on the idtoken abuse. That would be easily solved by appending a “provided that the resulting idtoken is not abused by using it as access token”, in fact that would explicitly address one of the most common abuses we witness in this space by finally providing explicit language on the matter. I had frequent clashes with the Kubernetes crowd about it, and they required nuanced arguments, making them grok the concept of audience etc etc- all stuff that could have been avoided by having straightforward language along the lines of the above. We could argue whether that language belongs to the OIDC spec more than the OAuth2.1: my position is that we should take this opportunity to bring extra clarity, nothing prevents repeating that if the OIDC people will do their own updates in the future. I also hear you on the open endorsement, however I suspect that just saying what you suggest without mentioning OIDC at all will not solve the problem of people thinking this deprecates those OIDC flows, too. Perhaps a compromise would make it explicit that the security considerations that led to the omission of implicit for the token response type in oauth2.1 do not apply to those flows in OIDC, provided that the idtoken is not used as access token. So non an endorsement, but an explicit scoping statement would that sound more balanced?
Best place to add this is probably URL
We got consensus in the interim meeting to add the proposed text.

Related discussion:
text: Refresh tokens should either be sender-constrained or one-time use as per Section 4.12.2 of <ins> 10.1. The OAuth 2.0 Implicit grant is omitted from OAuth 2.1 as it was deprecated in I-D.ietf-oauth-security-topics. The intent of removing the Implicit grant is to no longer issue access tokens in the authorization response, as such tokens are vulnerable to leakage and injection, and are unable to be sender- constrained to a client.  This behavior was indicated by clients using the "response_type=token" parameter.  This value for the "response_type" parameter is no longer defined in OAuth 2.1. Removal of "response_type=token" does not have an effect on other extension response types returning other artifacts from the authorization endpoint, for example, "response_type=id_token" defined by OpenID. </ins> 11. This document does not require any IANA actions.
Code change:
The second paragraph of 5 reads: I probably agree that some of the scenarios are statistically small, and may remain that way in the future, but others aren't all that statistically small even today and/or could become less small in the foreseeable future. AQM is now reasonably widely deployed, anyone with Starlink internet sees varying delay, most Wi-Fi links exhibit periodic transient link disconnections during channel scanning, etc. I'd suggest something like: The first paragraph of 5.7 Transient Events reads: The [Tools] link takes one to URL, where Section 17 provides us with: Was this intended to be a joke? .... Actually, I think you meant Section 16.
This is indeed long-since expired: title: Tools for the Evaluation of Simulation and Testbed Scenarios target: "URL" seriesinfo: Work in Progress date: 2007-7 author: - ins: S. Floyd - ins: E. Kohler.
WFM

Related discussion:
text: even if the criteria indicate an unsatisfactory result for these scenarios. <del> In general, measurements from Internet-scale deployments will not expose the properties of operation in these scenarios, as they are statistically small. </del> <ins> In general, measurements from Internet-scale deployments might not expose the properties of operation in each of these scenarios, because they are not as ubiquitous as the General Use scenarios. </ins> 5.1.
Code change:
The second paragraph of 5 reads: I probably agree that some of the scenarios are statistically small, and may remain that way in the future, but others aren't all that statistically small even today and/or could become less small in the foreseeable future. AQM is now reasonably widely deployed, anyone with Starlink internet sees varying delay, most Wi-Fi links exhibit periodic transient link disconnections during channel scanning, etc. I'd suggest something like: The first paragraph of 5.7 Transient Events reads: The [Tools] link takes one to URL, where Section 17 provides us with: Was this intended to be a joke? .... Actually, I think you meant Section 16.
This is indeed long-since expired: title: Tools for the Evaluation of Simulation and Testbed Scenarios target: "URL" seriesinfo: Work in Progress date: 2007-7 author: - ins: S. Floyd - ins: E. Kohler.
WFM

Related discussion:
text: algorithm would perform in the presence of transient events such as sudden onset of congestion, a routing change, or a mobility event. Routing changes, link disconnections, intermittent link connectivity, <del> and mobility are discussed in more detail in Section 17 of Tools. </del> <ins> and mobility are discussed in more detail in Section 16 of Tools. </ins> As an example from an Experimental RFC, response to transient events is discussed in Section 9.2 of RFC4782 (Quick-Start).
Code change:
This is an attempt to address issue
Current version looks good to me as well, FWIW.
Thanks! Looks good to me, FWIW. :-)
I'm satisfied but won't merge until Gorry is satisfied too.This seems fine.

Related discussion:
text: 3.1.3. <ins> A congestion control algorithm should try to avoid causing excessively high rates of packet loss.  To accomplish this, it should avoid excessive increases in sending rate, and reduce its sending rate if experiencing high packet loss. The first version of the BBR algorithm BBRv1-draft failed this requirement.  Experimental evaluation BBRv1-Evaluation showed that it caused a sustained rate of packet loss when multiple BBRv1 flows shared a bottleneck and the buffer size was less than roughly one and a half BDP.  This kind of behavior needed to be fixed, and indeed further versions of BBR BBR-draft fixed this issue. This requirement does not imply that the algorithm should react to packet losses in exactly the same way as current standards-track congestion control algorithms (e.g., RFC5681). 3.1.4. </ins> When multiple competing flows all use the same proposed congestion control algorithm, the proposal should explore how the capacity is shared among the competing flows.  Capacity fairness can be important
Code change:
This is an attempt to address issue
Current version looks good to me as well, FWIW.
Thanks! Looks good to me, FWIW. :-)
I'm satisfied but won't merge until Gorry is satisfied too.This seems fine.

Related discussion:
text: that seek to send at different rates or when some of the flows do not last sufficiently long to approach asymptotic behavior. <del> 3.1.4. </del> <ins> 3.1.5. </ins> A great deal of congestion control analysis concerns the steady-state behavior of long flows.  However, many Internet flows are relatively
Code change:
…ms..." AFAICT the goal is to consider harm induced relative to the harm induced by Reno/CUBIC. There may be other experimental algorithms that become "defined", which are not intended as a yardstick by which to measure harm.
cc: NAME NAME NAME NAME

Related discussion:
text: In contexts where differing congestion control algorithms are used, it is important to understand whether the proposed congestion control <del> algorithm could result in more harm than previously defined algorithms to flows sharing a common bottleneck.  The measure of harm is not restricted to the equality of capacity, but ought also to consider metrics such as the introduced latency, or an increase in packet loss.  An evaluation must assess the potential to cause starvation, including assurance that a loss of all feedback (e.g., detected by expiry of a retransmission time out) results in backoff. </del> <ins> algorithm could result in more harm than previous standards-track algorithms (e.g.  RFC5681, RFC9002, RFC9438) to flows sharing a common bottleneck.  The measure of harm is not restricted to the equality of capacity, but ought also to consider metrics such as the introduced latency, or an increase in packet loss.  An evaluation must assess the potential to cause starvation, including assurance that a loss of all feedback (e.g., detected by expiry of a retransmission time out) results in backoff. </ins> 4.2.1.
Code change:
Fixed an editorial problem resulting in removing the end of the sentence, which went on to say that you can't assume DSCP, etc. Also changed /many deployments/ to simply say this happens without saying it is often.
From NAME review: Section 3.2.2: Although there are clearly a number of network especially access networks that do deploy and use DSCP classes for its real-time media traffic I think this sentence is misleading. I would think that the majority of the WebRTC traffic carrying audio and video will in fact not be marked or have DSCP markings that survive into the general Internet. I would at least suggest to rewrite the above first sentence to indicate that although this may occur, the CC algorithm under consideration will have to deal with this type of traffic.

Related discussion:
text: simulate their interaction with those algorithms.  To the extent they are not, experiments can be conducted where possible. <del> Note that in many deployments, real-time flows are directed into distinct queues via Differentiated Services Code Points (DSCP) or other mechanisms, which substantially reduces the interplay with other traffic.  However, a proposal targeting general Internet use </del> <ins> Real-time flows can be directed into distinct queues via Differentiated Services Code Points (DSCP) or other mechanisms, which can substantially reduce the interplay with other traffic.  However, a proposal targeting general Internet use can not assume this is always the case. </ins> 4.2.3.
Code change:
To address review comments and closing Issue
From NAME review: I reacted to the use of “forbidden” in this sentence. Would not “not intended at all for use in the Internet” be a better formulation? Because forbidden want me to invoke the Protocol Police if someone ever attempted to use it.
For me, this was meant to be stronger than "not intended", more like "confined to a limited to a controlled environment". RFC 8799 describes some of these cases, and could be a useful reference?
So I think a stronger wording is fine. But, an alternative formulation would be good that doesn't imply that you might get the protocol police after you.

Related discussion:
text: introduce bursty traffic where many nodes complete a task at the same time). <del> In evaluating a new proposal for use in a controlled environment, the IETF needs to understand the usage, e.g., how the usage is scoped to the controlled environment, whether the algorithm will share resources with Internet traffic and consider what could happen if used in a protocol that is bridged across an Internet path. Algorithms that are designed for special environments and are forbidden from use in the general Internet, might instead seek real- world data for those environments.  In such cases, the evaluation criteria in the remainder of this document might not apply. </del> <ins> In evaluating a new proposal for use in a controlled environment RFC8799, the IETF needs to understand the usage, e.g., how the usage is scoped to the controlled environment, whether the algorithm will share resources with Internet traffic and consider what could happen if used in a protocol that is bridged across an Internet path. Algorithms that are designed to be confined to a controlled environment and are not intended for use in the general Internet, might instead seek real-world data for those environments.  In such cases, the evaluation criteria in the remainder of this document might not apply. </ins> 4.
Code change:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Related discussion:
text: Informational RFC in 2017 RFC8312 and then as a Proposed Standard in 2023 RFC9438. <del> BBR is developed as an internal research project by Google, with the first implementation contributed to Linux kernel 4.19 in 2016.  It was described in an IRTF draft in 2018, and that draft is regularly updated to document the evolving versions of the algorithm BBR-draft. BBR is widely used for Google services using either TCP or QUIC, and is also widely deployed outside of Google. </del> <ins> At the time of writing, BBR is being developed as an internal research project by Google, with the first implementation contributed to Linux kernel 4.19 in 2016.  It was described in an IRTF draft in 2018, and that draft has been regularly updated to document the evolving versions of the algorithm BBR-draft.  BBR is currently widely used for Google services using either TCP or QUIC, and is also widely deployed outside of Google. </ins> We cannot say now whether the original authors of RFC5033 expected that developers would be somehow waiting for IETF review before widely deploying a new congestion control algorithm over the Internet, but the examples of Cubic and BBR teach us that deployment <del> of new algorithms is not in fact gated by publication of the </del> <ins> of new algorithms is not in fact gated by the publication of the </ins> algorithm as an RFC. Nevertheless, specifying congestion control algorithms has a number
Code change:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Related discussion:
text: specification can help multiple contributors align on a consensus change to the algorithm. <del> A specification that is accessible to anyone circumvents the issue that some implementors may be unable to read open source reference implementations due to the constraints of some open source licenses. </del> <ins> A specification that is accessible to anyone can circumvent the issue that some implementors may be unable to read open source reference implementations due to the constraints of some open source licenses. </ins> Beyond helping develop specific algorithm proposals, guidelines can also serve as a reminder to potential inventors and developers of the
Code change:
Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"

Related discussion:
text: proposals in this space. This document is meant to reduce the barriers to entry for new <del> congestion control work to the IETF.  As such, proponents ought not to interpret these criteria as a checklist of requirements before approaching the IETF.  Instead, proponents are encouraged to think about these issues beforehand, and have the willingness to do the work implied by the remainder of this document. </del> <ins> congestion control work to the IETF.  As such, proponents of new congestion control algorithms ought not to interpret these criteria as a checklist of requirements before approaching the IETF.  Instead, proponents are encouraged to think about these issues beforehand, and have the willingness to do the work implied by the remainder of this document. </ins> 2.