jiebi/CodeConvo huggingface dataset:
Change:
connections as well as new connections established using one of those fingerprints.  Note that I-D.ietf-rtcweb-jsep, Section 5.2.1 requires that each media section use the same set of fingerprints for every <del> media section. </del> <ins> media section.  If a new identity attribute is received, then the receiver MUST apply that identity to all existing connections. </ins> If the set of fingerprints changes, then the sender MUST either send a new 'identity' attribute or none at all.  Because a change in

Discussion:
What happens if fingerprints don't change but identity does, and there's no new connection, (e.g., a codec change). This text needs to say you propagate that identity to the existing connections.
The webrtc text forbids changing of identity. You might want to note that, even if this new language is correct in a more general sense.
Change:
4.4. In this model, the Origin, Attester, and Issuer are all operated by <del> different entities, as shown in the figure below. </del> <ins> different entities, as shown in the figure below.  As with the joint Origin and Issuer model, the Issuer accepts token requests that come from trusted Attesters, and the details of that trust establishment depend on the issuance protocol. </ins> This is the most general deployment model, and is necessary for some types of issuance protocols where the Attester plays a role in token

Discussion:
cc NAME
[x] 1. The Reference PPEXT is not cited in the document. seems it could be sited in the into PR [x] 2. I think it would be good to explicitly say that the HTTP authentication protocol is targeted at redemption and the issuer protocol is targeted at issuance. PR [ ] 3. Last paragraph in section 3.2.1 mentions Origin Allow Lists. These allow lists are not specifically mentioned earlier in the document. Can you clarify this. [ ] 4. In section 4.3 and 4.4 is the attester involved in the TokeRequest and TokenResponse messages? Is the attester proxying the communication? It would be good to clarify this in the text. [ ] 5. Section 6 has an incomplete reference. [x] 6. It seems that the Reference to RFC 8446 is not needed. PR [ ] 7. The link - URL does not work perhaps this is the updated one? - URL
Change:
In essence, the steps are as follows: <ins> 4.4. Domain owners, intermediaries, and mail receivers can all claim to implement DMARC, but what that means will depend on their role in the transmission of mail.  To remove any ambiguity from the claims, this document specifies the following minimum criteria that must be met for each agent to rightly claim to be "implementing DMARC". Domain Owner: To implement DMARC, a domain owner MUST configure its domain to request that unauthenticated mail be rejected or at least treated with suspicion.  This means that it MUST publish a policy record that: While 'none' is a syntactically valid value for both the p and sp tags, the practical value of either the p tag or sp tag being 'none' means that the domain owner is still gathering information about mail flows for the domain or sub-domains, and is not yet ready to commit to requesting that unauthenticated mail receive different handling than authenticated mail. Intermediary: To implement DMARC, an intermediary MUST do the following before passing the message to the next hop or rejecting it as appropriate: Mail Receiver: To implement DMARC, a mail receiver MUST do the following: </ins> 5. One of the most obvious points of security scrutiny for DMARC is the

Discussion:
How come ARC compliance becomes an integral part of DMARC? They are different protocols.
The work of the design team is to propose text at this stage. Discussion of the proposed text can take place on-list starting after April 23.
Change:
closed (remote) stream state.  This allows WebTransport Streams to participate in header compression and flow control. <del> 3.3. </del> <ins> 3.5. </ins> As described in Section 5.5 of RFC7540, SETTINGS parameters allow endpoints to negotiate use of protocol extensions that would

Discussion:
Landing this now and applying subsequent comments directly to speed things up
Will file issues for the ones indicated, otherwise I made the suggested edits. Thanks for reviewing this, NAME
Change:
QUIC-HTTP at the time of this writing; however, many other applications are currently being defined and deployed over QUIC, so an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3 <del> uses UDP port 443 by default, although URLs referring to resources available over HTTP/3 may specify alternate port numbers.  Simple assumptions about whether a given flow is using QUIC based upon a UDP port number may therefore not hold; see also Section 5 of RFC7605. </del> <ins> uses UDP port 443 by convention but various methods can be used to specify alternate port numbers.  Simple assumptions about whether a given flow is using QUIC based upon a UDP port number may therefore not hold; see also Section 5 of RFC7605. </ins> While the second-most-significant bit (0x40) of the first octet is set to 1 in most QUIC packets of the current version (see public-

Discussion:
No client currently attempts to use UDP port 443 for HTTP/3 without first having been told to do so, most often by AltSvc or HTTPS records. Technically we can also use the URL to decide to use QUIC, but that doesn't currently happen. With HTTPS records, that might never be necessary.
This is not entirely true. As we have HTTPS records and Alternative Services, there is no case where HTTP/3 goes without a means of signaling a port number. So there is no real "default" as far as it goes. It's just that we reserved the number and we tend to use that port number by convention.
For what it's worth, NAME and I were talking about this wrt URL in MOPS, so the timing of this issue in QUIC was very helpful. Thank you for that. I'm using "by convention", at his suggestion.
Change:
control, it may be possible to signal to the congestion control mechanism that there was congestion (loss) even when a packet has been recovered, e.g. using ECN, to reduce the impact on the non-coded <del> flows (see subsec:cc-recov-inter-below). </del> <ins> flows (see subsec:cc-recov-inter-below and TENTET). </ins> 6.3.

Discussion:
There are two possibilities either: "Point-to-point transmetting method based on the use of an erasure coding scheme and TCP/IP protocol", ISAE-SUPAERO (2019) EP 3 432 500 A1, WO 2019015931 (A1). URL "On the joint use of TCP and Network Coding", Emmanuel Lochin, IETF'100 NWCRG session, November 2017. URL
Since this is IPR protected content I gather the IPR declaration is up to date?
Yes Le mer. 28 oct. 2020 à 10:40, patibulon a écrit :
done in PR
Change:
16.2. During each epoch senders MUST NOT encrypt more data than permitted <del> by the security bounds of the AEAD scheme used. </del> <ins> by the security bounds of the AEAD scheme used I-D.irtf-cfrg-aead- limits. </ins> Note that each change to the Group through a Handshake message will also set a new "encryption_secret".  Hence this change MUST be

Discussion:
In the "Restrictions" section, we say "During each epoch senders MUST NOT encrypt more data than permitted by the security bounds of the AEAD scheme used", without specifying the limits. We should cite something here, probably (cc NAME for visibility).
Change:
resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port, and sending an HTTP/3 request message targeting the URI to the server over that <del> secured connection. </del> <ins> secured connection.  Unless some other mechanism is used to select HTTP/3, the token "h3" is used in the Application Layer Protocol Negotiation (ALPN; see RFC7301) extension during the TLS handshake. </ins> Connectivity problems (e.g., blocking UDP) can result in QUIC connection establishment failure; clients SHOULD attempt to use TCP-

Discussion:
Section 3.2: "A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port, and sending an HTTP/3 request message targeting the URI to the server over that secured connection." draft-ietf-quic-tls states in Section 8.1: "Unless another mechanism is used for agreeing on an application protocol, endpoints MUST use ALPN for this purpose." Looking at Section 3.2 with Section 3.1 deleted I think there is an important aspect missing which is expressed in first sentence of Section 3.1: "HTTP/3 uses the token "h3" to identify itself in ALPN and Alt-Svc." In Section 3.3: "QUIC connections are established as described in [QUIC-TRANSPORT]. During connection establishment, HTTP/3 support is indicated by selecting the ALPN token "h3" in the TLS handshake. Support for other application-layer protocols MAY be offered in the same handshake." So what I interpret is that the inclusion of the "h3" ALPN token will be required in the clients messages when establishing an QUIC connection with the intention of communicating using HTTP/3 according to this specification. So I think there are two changes needed here. First that there needs to be a first paragraph in Section 3.2 to state that HTTP/3 uses "h3" as token in ALPN and Alt-Svc as a lead in, secondly that the sentence first referenced above needs to state that ALPN = "h3" will be given in the QUIC-TLS handshake. If I understand this correctly, a QUIC connection that has been established using "h3" ALPN token, i.e. client tells it interested in this application and where the server choice that token in the handshake will be using HTTP/3 according to this specification. It is possible for other ALPN tokens to be application foo using HTTP/3. Finally do I interpret things correctly that "h3" is not strictly required but then both client and server need to know that yes, this connection establishment is for the purpose of HTTP/3?
If some other mechanism is used for agreeing on protocol, ALPN can be omitted, yes. I'm not convinced that the first paragraph of 3.

[2->1] is the appropriate place to put the token statement; the section is about discovering an HTTP/3 endpoint given a URL, and the definition of the ALPN token is incidental there. I've added the token to 3.[2->1] in the paragraph about the connection; see what you think.
I think the proposed text does clarify the issue and makes the default and alternative clear. So this resolves my issue.
Based on , labeling this as "editorial"
Change:
not correspond to a group which was provided in the "key_share" extension in the original ClientHello.  If either of these checks fails, then the client MUST abort the handshake with a fatal <del> "handshake_failure" alert.  Clients SHOULD also abort with "handshake_failure" in response to any second HelloRetryRequest which was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest). </del> <ins> "illegal_parameter" alert.  Clients SHOULD also abort with "unexpected_message" in response to any second HelloRetryRequest which was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest). </ins> Otherwise, the client MUST send a ClientHello with an updated KeyShare extension to the server.  The client MUST append a new

Discussion:
Noticed these while reviewing the negotiation PR: handshakefailure means "the sender was unable to negotiate an acceptable set of security parameters given the options available", but these are all protocol errors that should only occur with a buggy server. Switch them to more appropriate ones: If the HelloRetryRequest makes no sense, it is an illegalparameter. If we get a second HelloRetryRequest, it's an unexpectedmessage (the client is in a state where it expects a ServerHello and will likely just fall through to the generic message-mismatch codepath). If HelloRetryRequest and ServerHello are inconsistent, it is an illegalparameter. If an anonymous server sends a CertificateRequest, it's an unexpected_message (this too will likely use the generic message-mismatch codepath).
Change:
When keys are rotated, there could be a delay in the propagation of that rotation to various components in the AS's ecosystem.  The AS <del> can define its own policy regarding the timeout of the "previous_key", either making it immediately obsolete or allowing for a limited grace period during which both the "previous_key" and the current key can be used for signing requests.  Such a grace period can be useful when there are multiple running copies of the client that are coordinated with each other.  For example, the client </del> <ins> can define its own policy regarding the timeout of the previously- bound key, either making it immediately obsolete or allowing for a limited grace period during which both the previously-bound key and the current key can be used for signing requests.  Such a grace period can be useful when there are multiple running copies of the client that are coordinated with each other.  For example, the client </ins> software could be deployed as a cloud service with multiple orchestrated nodes.  Each of these copies is deployed using the same key and therefore all the nodes represent the same client instance to

Discussion:
To edit notification comments on pull requests, go to your .
The "previous_key" element added in is not necessary in practice because the AS should always be able to look up the current key value based on the access token, and the signature using the previous key proves possession of that key separate from any presentation of the key value or reference.
Makes sense
Change:
a peer to maintain a more accurate round-trip time estimate (see Section 13.2 of QUIC-TRANSPORT). <ins> 3.1.7. QUIC uses a probe timeout (see pto), with a timer based on TCP's RTO computation.  QUIC's PTO includes the peer's maximum expected acknowledgement delay instead of using a fixed minimum timeout.  QUIC does not collapse the congestion window until persistent congestion (persistent-congestion) is declared, unlike TCP, which collapses the congestion window upon expiry of an RTO.  Instead of collapsing the congestion window and declaring everything in-flight lost, QUIC allows probe packets to temporarily exceed the congestion window whenever the timer expires. In doing this, QUIC avoids unnecessary congestion window reductions, obviating the need for correcting mechanisms such as F-RTO RFC5682. Since QUIC does not collapse the congestion window on a PTO expiration, a QUIC sender is not limited from sending more in-flight packets after a PTO expiration if it still has available congestion window.  This occurs when a sender is application-limited and the PTO timer expires.  This is more aggressive than TCP's RTO mechanism when application-limited, but identical when not application-limited. A single packet loss at the tail does not indicate persistent congestion, so QUIC specifies a time-based definition to ensure one or more packets are sent prior to a dramatic decrease in congestion window; see persistent-congestion. </ins> 4. At a high level, an endpoint measures the time from when a packet was

Discussion:
and by documenting the core difference between TCP's RTO and QUIC's PTO.
QUIC: TCP:
Discussed in ZRH. Difference to be explained as an editorial comment.
Specifically, we'll add some text that describes how PTO in QUIC is different than RTO and TLP in TCP.
"When an ACK frame is received that establishes loss of all in-flight packets sent over a long enough period of time, the network is considered to be experiencing persistent congestion." QUIC declares persistent congestion only upon receipt of an ACK for a packet sent after entering loss recovery. This means that the cwnd will remain large and usable even if there is prolonged network silence with packets outstanding. If the state of the transport was application limited, this can cause a large burst on the network. In TCP, an RTO causes immediate drop of the cwnd to min_cwnd. Ideally QUIC should drop the cwnd in the same timescale as TCP would. Typically minrto for the Internet is 200 msec or 300 msec (and larger if the RTT is larger).
I do not want to change the existing algorithm, because the app-limited case is the case when the sender is strictly less aggressive than the congestion controller limits, so I believe it's less likely to cause issues for the network. I can write text pointing out this difference.
Discussed in ZRH. Proposed resolution is to close with no action. Editorial issue to explain the difference to TCP and its safety.
NAME this was in the latest batch of consensus calls, but you didn't mark it has having consensus. Can you review please?
You are correct, I missed this one somehow sorry so moving to has consensus
LGTM
Change:
One way to provision a key is to first generate it external to the device and then copy the key onto the device.  In this case, confidentiality of the generator, as well as the path over which the <del> key is provisioned, is necessary.  This can be achieved in a number of ways. </del> <ins> key is provisioned, is necessary.  The manufacturer needs to take care to protect it with measures consistent with its value.  This can be achieved in a number of ways. </ins> Confidentiality can be achieved entirely with physical provisioning facility security involving no encryption at all.  For low-security

Discussion:
It seems that all that’s relevant to RATS is “if the key is generated externally, the manufacturer needs to take care to protect it with measures consistent with its value” ` This case does seem different – there is simply no known way to extract the key.
I agree with MCR's summary that “if the key is generated externally, the manufacturer needs to take care to protect it with measures consistent with its value”. Can we replace the bulk of section 12.1.2 with this single sentence? The expectation is that private keys can't be extracted (read) once provisioned. That should be a stated security assumption. This section reads like a tutorial or primer. That isn't the goal IMO. Security Considerations should state our our security assumptions.
{not my comment. Guy's. If you like that part, generate a pull request please!}
Change:
An endpoint restarts its idle timer when a packet from its peer is received and processed successfully.  The idle timer is also <del> restarted when sending an ack-eliciting packet (see QUIC-RECOVERY), but only if no other ack-eliciting packets have been sent since last receiving a packet.  Restarting when sending packets ensures that connections do not prematurely time out when initiating new activity. An endpoint might need to send packets to avoid an idle timeout if it is unable to send application data due to being blocked on flow control limits; see flow-control. </del> <ins> restarted when sending the first ack-eliciting packet (see QUIC- RECOVERY) after receiving a packet.  Restarting when sending packets ensures that connections do not prematurely time out when initiating new activity.  Only restarting when sending after receipt of a packet ensures the idle timeout is not excessively lengthened past the time the peer's timeout has expired.  An endpoint might need to send packets to avoid an idle timeout if it is unable to send application data due to being blocked on flow control limits; see flow-control. </ins> An endpoint that sends packets near the end of the idle timeout period risks having those packets discarded if its peer enters the draining state before the packets arrive.  If a peer could time out within a Probe Timeout (PTO; see Section 6.6 of QUIC-RECOVERY), it is <del> advisable to test for liveness before sending any data that cannot be retried safely.  Note that it is likely that only applications or application protocols will know what information can be retried. </del> <ins> advisable to probe the path with an ack-eliciting packet to ensure the connection is still responsive before sending any data that cannot be retried safely.  Note that it is likely that only applications or application protocols will know what information can be retried. </ins> 10.3.

Discussion:
From NAME and NAME comments on
In I received a number of comments on the existing text from NAME and NAME . This is an issue to track improving that text in a separate PR. One suggestion was to introduce an ITO(Idle Timeout) acronym.
NAME thinks cognitive load is increased by ITO and it's not that much shorter, so let's not do that.
Change:
Abstract <del> This document aims to document consensus on the CAPPORT architecture. DHCP or Router Advertisements, an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning Domains (PvDs) is described. </del> <ins> This document describes a CAPPORT architecture.  DHCP or Router Advertisements, an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning Domains (PvDs) is described. </ins> 1.

Discussion:
Happy to elaborate on them if the motivation is not clear from the changes, let me know!
Thanks NAME b1dc7ba4e26ab17ed12d8a5a2408fe8063b1177a accepts the suggestion. 509d855e5ddba7dd1c5db58646c85516d0b40987 corrects the mistake I had made, which your question was about.
Looks great. Thanks for the PR!