jiebi/CodeConvo huggingface dataset:
Code change:
For TCP connections without TLS, this depends on the host having resolved to the same IP address. <del> For </del> <ins> For " </ins> <del> resources, connection reuse additionally depends on having a </del> <ins> " resources, connection reuse additionally depends on having a </ins> certificate that is valid for the host in the URI.  The certificate presented by the server MUST satisfy any checks that the client would perform when forming a new TLS connection for the host in the URI.  A

Related discussion:
text: Also, use .
and 9.1.1: We quoted "https" where preceded by "resources". Please let us know if this is incorrect. Original: CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with https resources. ... For https resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI. Currently (best viewed in the .html or .pdf output): CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with "https" resources. ... For "https" resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI.
Folded into .
: We made quoting consistent around lowercase instances of "http" and "https" when describing URIs or schemed URIs, per quoted instances in , 3.2, and 10.1. Please let us know any objections. Original: http and https schemed URIs http or https schemed URIs http or https URIs Currently: "http" and "https" schemed URIs "http" or "https" schemed URIs "http" or "https" URIs
Code change:
Specification document(s): accept-ch of this document Related information: for Client Hints <del> 5.2. Header field name: Accept-CH-Lifetime Applicable protocol: HTTP Status: standard Author/Change controller: IETF Specification document(s): accept-ch-lifetime of this document Related information: for Client Hints </del> 6.  References 6.1.  URIs

Related discussion:
text: Based on discussion at IETF 105, removing explicit lifetime in favor of implicit opt-in registration and persistence. NAME can you please take a look? In particular, current language states the preference should be persisted but doesn't explicitly state for what the lifetime is.. Modulo, in privacy section we do talk about MUST criteria for clearing it. Any suggestions or recommendations for how to best approach this?
LGTM
Code change:
The format of "SUBSCRIBE_RST" is as follows: <del> Track Namespace: Identifies the namespace of the track as defined in (track-name). Track Name: Identifies the track name as defined in (track-name). </del> <ins> Subscribe ID: Subscription Identifier as defined in message- subscribe-req. </ins> Error Code: Identifies an integer error code for subscription failure.

Related discussion:
text: This PR is expected to be base PR to support multi-subscribe like flows that will follow up. It adds support for SubscribeID and also renames the trackId to to avoid the confusion and make the scope clear.
NAME NAME NAME wondering if the latest commits address the feedback. thanks
The normative bits look fine. PR needs some cleanup. Recommend splitting ID -> Alias to another PR, so this subscribe ID doesn't get caught up with bikeshedding the field name.LGTM but I would like Subscribe ID to be the first field in every message for consistency.Still looks fine after the split Having reviewed some code that does subscription matching with the current draft, I strongly endorse splitting those.
Code change:
suffix in the "Structured Syntax Suffix" registry IANA.StructuredSuffix in the manner described in [RFC6838], which can be used to indicate that the media type is encoded as an SD-JWT. <del> 14.  References 14.1.  URIs [1] #example-1 </del>

Related discussion:
text: for issue URL
The layout of these section delineations seems off. There's an "Example 1" section header, but no other numbers. Some examples are top-level, some are subordinate. Is this intended?
Kinda. has additional examples with some of those other numbers. ! And a few places refer back to "Example 1" by name. This all could probably be tidied up though.
like it
Code change:
5.2.4. The FIDO Cross-Device Authentication (CDA) flow provides the best <del> protection against attacks on the unauthenticated channel for cross- </del> <ins> protection against attacks on the unauthenticated channel for cross </ins> device flows.  It can be combined with OAuth 2.0 and OpenID Connect <del> protocols for standards -based authorization and authentication flows.  If FIDO2/WebAuthn support is not available, Client Initiated </del> <ins> protocols for standards-based authorization and authentication flows. If FIDO2/WebAuthn support is not available, Client Initiated </ins> Backchannel Authentication (CIBA) provides an alternative, provided that there is a channel through which the authorization server can contact the end user.  Examples of such a channel include device push

Related discussion:
text: Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!
Code change:
The server responds to a client request using the same stream identifier that was used by the request.  An HTTP response begins with a HEADERS frame.  An HTTP response body consists of a series of <del> DATA frames.  The last data frame contains a FINAL flag to indicate the end of the response.  A response that contains no body (such as a 204 or 304 response) consists only of a HEADERS frame that contains the FINAL flag to indicate no further data will be sent on the stream. </del> <ins> DATA frames.  The last data frame contains a END_STREAM flag to indicate the end of the response.  A response that contains no body (such as a 204 or 304 response) consists only of a HEADERS frame that contains the END_STREAM flag to indicate no further data will be sent on the stream. </ins> The response status line is unfolded into name-value pairs like other HTTP header fields and must be present:

Related discussion:
text: This branch also renames the FINAL flag to ENDSTREAM and the CONTINUES flag to ENDHEADERS.
Address
I'll take it, and we can continue to discuss the redundant bit.
Code change:
In the following non-normative example, the HTTP message being signed is the following request: <del> The covered content consists of the "@request-target" specialty content followed by the "Host", "Date", "Cache-Control", "X-Empty- Header", "X-Example" HTTP headers, in order.  The signature creation timestamp is "1618884475" and the key identifier is "test-key-rsa- pss".  The signature input string for this message with these </del> <ins> The covered content consists of the "@method", "@path", and "@authority" specialty content followed by the "Cache-Control", "X- Empty-Header", "X-Example" HTTP headers, in order.  The signature creation timestamp is "1618884475" and the key identifier is "test- key-rsa-pss".  The signature input string for this message with these </ins> parameters is: 3.

Related discussion:
text: This adds several new specialty identifiers for requests and responses to cover the method, authority, scheme, origin, path, query, and status code values of the HTTP message. It also edits the identifier's associated value to remove the verb and the string construction rules and instead align with HTTP Semantics.
NAME I haven't added references in yet but I tried to move the language in the direction you are suggesting. NAME I added the target-uri field we discussed, please review the text.
Responded to comments and updated normalization rules, please re-review.
Folding in this PR to the main document, discussion can continue on specifics of identifiers and their values as needed.
Code change:
only Log using a combination of trusted hardware, replication and consensus protocols, and cryptographic evidence.  A Receipt is an offline, universally-verifiable proof that an entry is recorded in <del> the Append-only Log.  Receipts do not expire, but it is possible to append new entries (more recent Signed Statements) that subsume older entries (less recent Signed Statements). </del> <ins> the Append-only Log.  Receipts do not have an expiration time, but the corresponding key material could.  Requesting a refreshed receipt can result in the same receipt with a different signature or signature with a different signing algorithm. </ins> Anyone with access to the Transparency Service can independently verify its consistency and review the complete list of Transparent

Related discussion:
text: Clarify the terminology around expiry and refreshing receipts. By and large the document is at a point where it can be called on for final reading. There are some nits or issues that we would like to see done to tighten it up. The introduction discusses distributed, but there is no real discussion of how or what that means and it leads readers to set an expectation that is incorrect. This word should be deleted. Removal of the Feeds definition. This was in the original version, and we have bounced all over the place during the last year to formulate a solution to a problem with Federation. We have decided collectively to park that and thus the use of feeds is gone. In a future overarching product or charter it could come back. There is a bit of a misunderstanding generated by stating that receipts don't expire, which later on is a line that requests for a refreshed receipt can be supported. The logical receipt is intended to never expire and based on the protected content in the ledger's log a new receipt can be generated at any time. This gives us an avenue to bridge a world from today to post quantum cryptography based counter signatures that is important. We need to clear up these two points. What goes into the append only log can vary from implementation to implementation. It may be that one implementation records the hash of the signed statement, plus evidence of how we proved that it was valid at the time of acceptance (things like records of OCSP response, or CRL lookups). Another implementation may simply store the signed statement. This from a generic point of view means that given access to the signed statements you can prove that it is on the append only log always. In section 4.1.1.2 it alludes that an auditor can mine the log to authenticate and retrieve the transparent statement. Based on the last statement this has two problems. The first it assumes that the signed statement is kept and that it can generate a new receipt (see 3) and produce a transparent statement. If it could this would be equivalent to the original in intent but not binary equal. The original receipt (or last created receipt from a refresh) is not required (or intended) to be kept in the ledger.
Code change:
only Log using a combination of trusted hardware, replication and consensus protocols, and cryptographic evidence.  A Receipt is an offline, universally-verifiable proof that an entry is recorded in <del> the Append-only Log.  Receipts do not expire, but it is possible to append new entries (more recent Signed Statements) that subsume older entries (less recent Signed Statements). </del> <ins> the Append-only Log.  Receipts do not have an expiration time, but the corresponding key material could.  Requesting a refreshed receipt can result in the same receipt with a different signature or signature with a different signing algorithm. </ins> Anyone with access to the Transparency Service can independently verify its consistency and review the complete list of Transparent

Related discussion:
text: Generically then this is impossible and may be where we would leverage consistency proofs in a later version.By and large the generic aspect of the document is there but we missed one sentence: "Signed Statements and Artifacts associated with a software package." We would suggest removing the "software package".
Code change:
differentiated and used by a single connection at the sender.  A multipath sender can schedule which packets travel on which of its active paths.  This enables a tradeoff in timeliness and reliability. <ins> There are various ways that multipath techniques can be used, </ins> <del> One use is to provide fail-over from one path to another when the original path is no longer viable or to switch the traffic from one path to another when this is expected to improve performance </del> <ins> One example use is to provide fail-over from one path to another when the original path is no longer viable or to switch the traffic from one path to another when this is expected to improve performance </ins> (latency, throughput, reliability, cost).  Designs need to independently track the congestion state of each path, and need to demonstrate independent congestion control for each path being used.

Related discussion:
text: It closes the issue by explicitly stating the I-D describes two use- cases: One we know more about, one much less. There is no intention to add a range of other use-cases in between. I hope this calls out some of the issues and that new proposers could understand where they ought to evaluate.
MP variants of TCP and QUIC, as well as SCTP may see some deployments - should this document mention something aroud coupled congestion control vs. single path congestion control also?
Yes. But we should note that it is still in research.
I have mixed feelings there. If users have payed for a wireless subscription and a land line subscription, why should they not use the full capacity of both paths? I see the "selfish" case for proper scheduling, such as not sending delay sensitive traffic on a lossy path. But I don't see anything with the same moral level as "don't cause congestion" or "don't cause buffer bloat".
Discussed at IETF 117: Christian: Not enough info to make a recommendation Gorry: We should think about it Ian: Inclination is that we don't have enough information to make a recommendation Matt: Impact is no worse than browsers using multiple connections
Gorry will take a look if he has anything constructive to write here; if so, we will run the text by the community. otherwise, close with no action.
See PR for some initial text.
I am really not sure that we should say much about multipath at all, besides the minimum -- making sure that any use of a path is not worse than creating a separate connection on that path. In PR , Gorry is trying to separate "multipath for failover" and "multipath for load balancing". But these are only two points in the spectrum of things that can be done.
Code change:
routers; misbehaving middleboxes; and the potential use of Quick- Start to attack routers or to tie up available Quick-Start bandwidth. <del> 5.4. </del> <ins> 5.5. </ins> When the proposal relies on explicit signals from the path, the effect of traffic passing through the tunnel - where routers may not be aware of the underlying flow - MUST be considered. <del> 5.5. </del> <ins> 5.6. </ins> RFC4653 discusses the effect of extreme packet reordering. <del> 5.6. </del> <ins> 5.7. </ins> The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as

Related discussion:
text: Created a separate issue to discuss ECN.
The guideline section discusses "Investigating a Range of Environments", with a focus especially on "Random Early Detection (RED) ] and Drop-Tail." The IETF and the IRTF have produced several different proposals for Active Queue management, with somewhat different characteristics. Interestingly, there is a tension there between developing Queue Management that "plays well" with existing congestion control algorithms, and developing congestion control algorithms that "take advantage" of AQM. Not sure what to say there, but at a minimum we should develop expectations about "signals" produced by AQM (e.g., the ECN markings of L4S) and reaction by congestion control algorithms. To go further, the could be a discussion of "honest signals", such as delays, that are very hard to "fake" in routing nodes, other signals such as ECN marks that could be produced by the network at very little cost, and packet losses that fall kind of in between. But we are not writing for the IRTF, so this could be kept brief.
On the topic of AQM, IETF published Characterization Guidelines (RFC7928) and Recommendations (RFC7567) that could be exploited for further discussions in this work.
Martin and Gorry: add a reference to 7567 to AQM behavior and evaluation criteria, which is not in scope for this document talk about evaluating CC interaction with AQM
Something like "CCs should be evaluated against AQMs that are prevalent in the internet" -- is there a reference that provides a taxonomy?
Editors: FQ-CoDel, PIE, L4S (RFC9332) have RFCs Are the others that should be evaluated, and do they have available specs?
Discussed at IETF 118: Many operators are not particularly aware of AQM or these concepts in general Include FIFO in the list Also do at least an AQM "you should evaluate the scenario with FIFO queues and should also consider the impact of various common AQMs and run detailed simulations against them", while maybe name-checking a few particularly relevant ones. Yes, should have criteria for this, and also should not ask people to run NxN interop matrix. Out of scope to mandate AQM
I suggest: Probably ought to include a suitably configured RED also.
Code change:
routers; misbehaving middleboxes; and the potential use of Quick- Start to attack routers or to tie up available Quick-Start bandwidth. <del> 5.4. </del> <ins> 5.5. </ins> When the proposal relies on explicit signals from the path, the effect of traffic passing through the tunnel - where routers may not be aware of the underlying flow - MUST be considered. <del> 5.5. </del> <ins> 5.6. </ins> RFC4653 discusses the effect of extreme packet reordering. <del> 5.6. </del> <ins> 5.7. </ins> The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as

Related discussion:
text: ... and not suggest ALL of these need to be checked, more encourage consider AQM and FIFO scenarios.
I fixed a typo, but otherwise this looks good.
Code change:
routers; misbehaving middleboxes; and the potential use of Quick- Start to attack routers or to tie up available Quick-Start bandwidth. <del> 5.4. </del> <ins> 5.5. </ins> When the proposal relies on explicit signals from the path, the effect of traffic passing through the tunnel - where routers may not be aware of the underlying flow - MUST be considered. <del> 5.5. </del> <ins> 5.6. </ins> RFC4653 discusses the effect of extreme packet reordering. <del> 5.6. </del> <ins> 5.7. </ins> The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as

Related discussion:
text: Editors: just focus on what needs to be evaluated (the last sentence) and toss the rest. We are not going to satisfy anyone with a discussion of the bigger picture.
In the Internet, most connections never exit Slow-Start. RFC 5033 kind of explicitly focuses on the long duration connections, because at the time of writing the accepted rule was that the 10% long duration connections were were causing 90% of traffic. I don't know whether that's still true.
With the usage of QUIC, more short-lived connections are aggregated into a long connection.
Looks OKThanks for updating this.
Code change:
routers; misbehaving middleboxes; and the potential use of Quick- Start to attack routers or to tie up available Quick-Start bandwidth. <del> 5.4. </del> <ins> 5.5. </ins> When the proposal relies on explicit signals from the path, the effect of traffic passing through the tunnel - where routers may not be aware of the underlying flow - MUST be considered. <del> 5.5. </del> <ins> 5.6. </ins> RFC4653 discusses the effect of extreme packet reordering. <del> 5.6. </del> <ins> 5.7. </ins> The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as

Related discussion:
text: and .
Also
The text currently reads: "The community should also consider other non-standard congestion controls known to be widely deployed," This is a compromise to land a mostly unrelated PR. NAME doesn't think it's fair to expect participants to test algorithms that aren't fully specified. I would argue that if such specifications exist and the algorithm is systemically important, it absolutely should be modeled. Moreover, if the algorithm is rather loosely described, in many cases there is open source code (often in a Linux fork!) that can be tested on a host, or in simulation frameworks like ns3. If an algorithm is a true black box, with no description besides marketing material, and no open-source code, I agree there is not much to be done. I also believe that while algorithms like this exist, they are not systemically important to the internet.
gorry: ns3 code is not super high fidelity.
Discussed at IETF 118: There's a danger if you see a realtime flow that goes faster than a best effort flow, since realtime is usually constrained by other factors (potentially needing time to move forwards to generate more data) Seems hard to imagine that something not specified is able to place a burden on anybody else. If you want others to do a thing, write it down and document it. Of course, there is no protocol police: we cannot prevent people from deploying whatever they want. Can we provide a carrot for people to play by the rules: Could be a SHOULD consider requirements and how to interact We have: Guidance for people who are writing specs that aren't yet part of the community How do we evaluate those protocols How do we ensure that fairness can exist with these Need to have a commitment from this WG to help and not just throw up new requirements for data and for those bringing new CCs to engage positively. Perhaps spelling this out clearly NAME to file issue to write something encouraging for people early on in the document Christian notes that separate queues between realtime and best effort are not actually a strong requirement To measure capacity you do need some sort of queue, or else you cannot measure
This info RFC has some sensible guidelines on RTP feedback frequency, if we need this: "Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences".
Related to
Condition (1) is concerned with the behavior with respect to Reno and, thanks to our edits, Cubic.
Code change:
routers; misbehaving middleboxes; and the potential use of Quick- Start to attack routers or to tie up available Quick-Start bandwidth. <del> 5.4. </del> <ins> 5.5. </ins> When the proposal relies on explicit signals from the path, the effect of traffic passing through the tunnel - where routers may not be aware of the underlying flow - MUST be considered. <del> 5.5. </del> <ins> 5.6. </ins> RFC4653 discusses the effect of extreme packet reordering. <del> 5.6. </del> <ins> 5.7. </ins> The proposal should consider how the alternate congestion control mechanism would perform in the presence of transient events such as

Related discussion:
text: But there are of course other congestion controls out there, both standard and non-standard, in support of real-time and other non-greedy applications. Should we mention those as a class? Namecheck some examples?
editors meeting 8836 requirements document 8867 and 8868 are test cases, but informational. Reese: standard stuff is not widely deployed, widely deployed stuff is not standardized. But RMCAT is new. Maybe there aren't well-documented protocols to evaluate vs., so it's hard to require anything here. I'll take a look, will probably have to go to the community.
Editors: We need to consider the interaction between real time and not-real time is evaluating real-time in scope? See 8836, 8867, 8868.
Looks good enough.Thanks for the changes.