jiebi/CodeConvo huggingface dataset:
Code change:
indicated by congestion control and the receiver, this will lead to less bandwidth available for the primary encoding, even when the redundant data is not being used.  This is in contrast to methods <del> like RTX RFC4588 or flexfec I-D.ietf-payload-flexible-fec-scheme retransmissions, which only transmit redundant data when necessary, at the cost of an extra roundtrip. </del> <ins> like RTX RFC4588 or flexfec's retransmission mode ( I-D.ietf-payload- flexible-fec-scheme, Section 1.1.7), which only transmit redundant data when necessary, at the cost of an extra roundtrip. </ins> Given this, WebRTC implementations SHOULD consider using RTX or flexfec retransmissions instead of FEC when RTT is low, and SHOULD

Related discussion:
text: Ah, I see now. I think what would help is "in contrast to methods like RTX or flexfec (when retransmissions are used) [I-D.]"
Code change:
close a connection does not prohibit a session from being resumed. <del> This message notifies the recipient that the sender will not send </del> <ins> This alert notifies the recipient that the sender will not send </ins> any more messages on this connection.  Any data received after a closure MUST be ignored. <del> This message is sent by the client to indicate that all 0-RTT </del> <ins> This alert is sent by the client to indicate that all 0-RTT </ins> application_data messages have been transmitted and that the next message will be handshake message protected with the 1-RTT handshake keys.  This alert MUST be at the warning level.  Servers <del> MUST NOT send this message and clients receiving this message MUST </del> <ins> MUST NOT send this alert and clients receiving this alert MUST </ins> terminate the connection with an "unexpected_message" alert. <del> This message notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a user cancels an operation after the handshake is complete, just </del> <ins> This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a user cancels an operation after the handshake is complete, just </ins> closing the connection by sending a "close_notify" is more appropriate.  This alert SHOULD be followed by a "close_notify". This alert is generally a warning.

Related discussion:
text: NAME did a massive message->alert change a while back and I did yet more when we were rebasing his patch. Looks like there's more up here in Closure Alerts. We're referring to alerts, not the messages that carry them. Switch to "alerts" instead to remain consistent with the rest of the document, notably the following section.
Code change:
4.4. <del> In CoAP over TCP, Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient.  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange. </del> <ins> In CoAP over reliable transports, Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient.  This provides a basic keep-alive function.  In contrast, Ping and Pong messages are a bidirectional exchange. </ins> Upon receipt of a Ping message, a single Pong message is returned with the identical token.  As with all Signaling messages, the

Related discussion:
text: URL CoAP over WebSockets The following now seems unrelated: Another possible configuration is to set up a CoAP forward proxy at the WebSocket endpoint. Depending on what transports are available Figure 12: CoAP Client (UDP client) accesses sleepy CoAP Server (WebSocket client) via a CoAP proxy (UDP server/WebSocket server) s/sleepy// (There is no mention of sleepiness here.) CoAP over WebSockets is intentionally very similar to CoAP over UDP. Therefore, instead of presenting CoAP over WebSockets as a new protocol, this document specifies it as a series of deltas from [RFC7252]. Probably best to delete that paragraph -- it is true not only for WS, but also for TCP. So why only here? 3.1. Opening Handshake Hmm, the title is confusing. WS also uses the same opening handshake as 2.3. The parts that relate to both TCP/TLS and WS/S need to be factored out. 3.2. Message Format The message format shown in Figure 14 is the same as the CoAP over TCP message format (see Section 2.4) with one restriction. The Length (Len) field MUST be set to zero because the WebSockets frame already contains the length. s/restriction/change/. The CoAP over TCP message format eliminates the Version field defined in CoAP over UDP. If CoAP version negotiation is required in the future, CoAP over WebSockets can address the requirement by the definition of a new subprotocol identifier that is negotiated during the opening handshake. This paragraph is a bit weird. Maybe: As with CoAP over TCP, the message format for CoAP over Websockets eliminates the Version field defined in CoAP over UDP. If CoAP Empty messages (Code 0.00) MUST be ignored by the recipient (see also Section 4.4). Why are we saying this here and not in Section 2? Factor out. 3.3. Message Transmission Similar as with CoAP over TCP, Retransmission and deduplication of messages is provided by the WebSocket protocol. CoAP over WebSockets therefore does not make a distinction between Confirmable or Non-Confirmable messages, and does not provide Acknowledgement or Reset messages. 3.4.
Code change:
4.4. <del> In CoAP over TCP, Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient.  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange. </del> <ins> In CoAP over reliable transports, Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient.  This provides a basic keep-alive function.  In contrast, Ping and Pong messages are a bidirectional exchange. </ins> Upon receipt of a Ping message, a single Pong message is returned with the identical token.  As with all Signaling messages, the

Related discussion:
text: Connection Health There is no way to retransmit a request without creating a new one. Re-registering interest in a resource is permitted, but entirely unnecessary. (See the discussion we already had.) [Brian] - The reference is
Closing the Connection Does this mean, only the client must cancel the requests? Or should the server do this also? Then a clarfication may be useful.
The original - URL - was specific to Observe: ~ All updates to Observe are now captured in a single place - Appendix A. This specific case is in URL At this point, I think that Closing the Connection could simply be deleted because there are no specific changes required.
Let's say a client has sent one or more requests to a server but hasn't received any response yet, and/or is observing a resource at a server. If the client or the server closes the connection or if the connection goes down unexpectedly, then the client will never receive the responses or any further notifications. The client has to reconnect and send new requests. Neither the client nor the server needs to send anything to cancel active requests before closing the connection; when a connection closes, all active requests are canceled automatically. The client should signal that to the code waiting for the responses, e.g., by throwing an exception. The server should abort processing the requests or at least discard the responses once the requests have been processed. The server also should remove the client from the lists of observers (at latest when it tries to send the next notification and it notices that the connection is down).
URL General - It's not clear "how" mandatory the use of the CSM is. Clause 2.3 on TCP/TLS indicates that the CSM message must be sent at the start of the connection. Clause 3.1 on Websockets makes no mention of CSM messages. Clause 4.3 indicates that the CSM MUST be sent at the start of the connection also and makes no distinction between TCP/TLS and Websockets. Clause 2.3 also indicates that the connection must be aborted if the CSM is missing or invalid as the first message on the connection. Given the discussion about address changes does more information need to be provided what start of connection means?
In the , the intent of this statement is unclear: There is no way to retransmit a request without creating a new one.
Code change:
4.4. <del> In CoAP over TCP, Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient.  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange. </del> <ins> In CoAP over reliable transports, Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient.  This provides a basic keep-alive function.  In contrast, Ping and Pong messages are a bidirectional exchange. </ins> Upon receipt of a Ping message, a single Pong message is returned with the identical token.  As with all Signaling messages, the

Related discussion:
text: Re-registering interest in a resource is permitted, but entirely unnecessary.
Response from Klaus Hartke: In general, CoAP clients are not allowed to use a token while it is still in use. RFC 7641 defines an exception: a client is allowed to confirm its interest in receiving notifications for a resource by sending a request identical to the original registration request, including the token that is already in use. The above paragraph just says that this is also the case for CoAP over TCP/TLS/WebSockets, but points out that sending a Ping (which checks the health of the connection and hence of all active observations) is better than confirming the interest for all active observations individually. Response from Carsten: Yes, the text is much easier to understand in that context — in the old draft, it was clear that this talks about reregistering interest. So in the new text, we probably need to prefix a sentence like For use with UDP, RFC 7641 discusses ways to re-register interest in a resource to deal with the case that the server providing this resource might have lost the information about this interest. In CoAP over TCP, the framework of the current connection provides fate-sharing between the health of the connection and the health of the expression of interest.
After further review, I think that this note belongs in Appendix A with the other updates/guidance for Observe on reliable transports. Connection Health should limit its discussion to WebSocket specific changes - in this case, the use of the CoAP Ping Signaling message instead of WebSocket Ping/Pong.
Code change:
ADDRESS_REQUEST capsules, endpoints MAY send ADDRESS_ASSIGN capsules unprompted. <del> 4.6.2. </del> <ins> 4.7.2. </ins> The ADDRESS_REQUEST capsule (see iana-types for the value of the capsule type) allows an endpoint to request assignment of IP

Related discussion:
text: I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.
Code change:
7.3.5. The server MAY require a value to be present for the "external- <del> account-binding" field.  This can be used to an ACME account with an existing account in a non-ACME system, such as a CA customer database. </del> <ins> account-binding" field.  This can be used to associate an ACME account with an existing account in a non-ACME system, such as a CA customer database. </ins> To enable ACME account binding, a CA needs to provision the ACME client with a MAC key and a key identifier.  The key identifier MUST

Related discussion:
text: Addresses Martin Stiemerling's TSV-ART review
Merging based on NAME review
On the mailing list, Rifaat Shekh-Yusuf pointed out these issues: Section 7.3.5, first paragraph, second line: A "bind" word is missing between the words "to" and "an" Section 7.4.1, second paragraph, second sentence: "case" should be "cases". When the server builds the authorization object, the document is stating that the response would include "challenges" and "combinations". Remove the "combinations" as it is not being used. Section 7.5.1, the Request URIs in the examples: Should not this be /acme/authz/1234/0?
In "Responding to challenges," we use the term "response fields." These fields are defined by each challenge type, but are not described as "response fields" there. We should add a heading describing them as such in the challenge type definitions.
The other challenges don't expect you to post a payload containing a type field, so it's inconsistent for OOB-01 to do so. It should just take an empty object "{}" as its payload.
This seems fine. It seems to be protected from replay by the and parameters. I think we're OK leaving the challenge name at "oob-01", since this isn't a breaking change.
Code change:
subsequent connection attempt.  The length of the token is explicit in both cases. <del> Retry and Version Negotiation packets are not encrypted or obfuscated in any way.  For other kinds of packets, other information in the packet headers is cryptographically obfuscated: </del> <ins> Retry (Section 17.2.5 of QUIC-TRANSPORT) and Version Negotiation (Section 17.2.1 of QUIC-TRANSPORT) packets are not encrypted or obfuscated in any way.  For other kinds of packets, other information in the packet headers is cryptographically obfuscated: </ins> <del> packet number: Most packets (with the exception of Version Negotiation and Retry packets) have an associated packet number; however, this packet number is encrypted, and therefore not of use to on-path observers.  The offset of the packet number is encoded in the header for packets with long headers, while it is implicit </del> <ins> packet number: All packets except Version Negotiation and Retry packets have an associated packet number; however, this packet number is encrypted, and therefore not of use to on-path observers.  The offset of the packet number is encoded in the header for packets with long headers, while it is implicit </ins> (depending on Destination Connection ID length) in short header packets.  The length of the packet number is cryptographically obfuscated.

Related discussion:
text: (which didn't require any non-editorial changes; the review is done now)
Also call out invariants (esp. in header structure and handshake) explicitly: v2 may/will break functionality outside the invariants.
Document is currently in in with final invariants; do one last pass to make sure everything documented in Section 17 as expose information appears here (which is basically the same check).
Code change:
result is smaller than the min_rtt, the RTT should be used, but the ack delay field should be ignored. <del> A sender calculates both smoothed RTT and RTT variance similar to those specified in RFC6298, see on-ack-received. </del> <ins> A sender calculates both smoothed RTT (SRTT) and RTT variance (RTTVAR) similar to those specified in RFC6298, see on-ack-received. </ins> A sender takes an RTT sample when an ACK frame is received that acknowledges a larger packet number than before (see on-ack-

Related discussion:
text: In the recovery draft, RTT is briefly spelled out in section 5 but is used in several earlier sections. SRTT and PTO are not explained at all, it seems. TLP is spelled out. RTO has a section of its own but it referenced before that. The recovery doc cannot be a tutorial on transmission theory, but it would be helpful to list the key acronyms and possibly reference an RFC with more details. There are already sections summarising key variables in pseudocode. There are references at the end, but the reader would have to go through them all.
Yes, thanks for the note. I'm planning to do a cleanup of that doc soon.
I fixed defined RTT earlier in .
Code change:
candidates, such as STUN and TURN. All of the candidates sent within an ICE session; these are the <del> candidates that are associated with a local/remote ufrag pair (which will change on ICE restart, if any). </del> <ins> candidates that are associated with a specific local/remote ufrag pair (which will change on ICE restart, if any occurs). </ins> Any session-related (as opposed to candidate-related) attributes required to configure an ICE agent.  These include but are not

Related discussion:
text: Changed "media stream" to "media stream and component" in one place, and made some grammatical changes to the definition of an ICE generation.
Code change:
reveal previous message or root keys.  Post-compromise security is provided by Commit operations, in which a new root key is generated from the latest ratcheting tree.  If the adversary cannot derive the <del> updated root key after an Commit operation, it cannot compute any </del> <ins> updated root key after a Commit operation, it cannot compute any </ins> derived secrets. In the case where the client could have been compromised (device

Related discussion:
text: The credentials we have defined at the moment only contain a single public key and no information regarding what signature scheme that keypair works with (even though the Spec actually says it should include the signature scheme as well). It would be nice, however, to support potential CredentialTypes that, similar to KeyPackages, include multiple supported signature schemes, each accompanied by a corresponding public key. The Key that should be used in any given group is then determined by the CipherSuite of the group (which includes a Signature Scheme). When choosing a KeyPackage of a new member, it has to be one that contains a Credential which supports that Signature Scheme. Note, that I'm not suggesting that this be the case in all Credentials, or even that we change the BasicCredential. I understand that it's possible to have multiple credentials per identity, but in some authentication settings it can be beneficial to have a 1-to-1 mapping between Credential and identity.
KeyPackages don't support multiple signature schemes? In what scenario is it beneficial?
Ah, right. I think that was the case in the past, but you're right, they don't. Of course it's always possible to just bundle a bunch of certificates, each supporting a different signature scheme and then treat that as your "Multi-Scheme Credential" in the grand scheme of things. However, if you end up rotating them a lot, where you have to sign them and potentially store the whole chain for a longer period of time, being able to support multiple signature schemes in only one credential means less overhead.
Credentials are stored in each group's ratchet tree though, so you're keeping a bunch of unnecessary key material in the group's tree which everyone has to store
That's fair. And it's not something you have to do if you don't want to. I'm just proposing for MLS to support that type of Credential in general.
To support hybrid PQ/standard schemes at any point in the future, allowing for multiple schemes is reasonable (in addition to the above arguments for it). Most applications probably will not use the feature, especially to start with, but providing support for just the option is not going to cause any of the problems noted.
PQ schemes can be used by switching the entire group to a new ciphersuite using those schemes.
Code change:
reveal previous message or root keys.  Post-compromise security is provided by Commit operations, in which a new root key is generated from the latest ratcheting tree.  If the adversary cannot derive the <del> updated root key after an Commit operation, it cannot compute any </del> <ins> updated root key after a Commit operation, it cannot compute any </ins> derived secrets. In the case where the client could have been compromised (device

Related discussion:
text: Requiring everybody in the group to store a bunch of unused key material isn't reasonable
The statement was not about PQ, but hybrid PQ/standard schemes. Those require use to two signature schemes, for which both types of keying material are used.
Then you need a ciphersuite that specifies a hybrid scheme.
It would be ideal to have a ciphersuite specifying a single hybrid scheme, but even that does not imply use of a single credential, unfortunately. In fact, hybrid schemes may rely on two separate credentials, with the ciphersuite specifying the hybrid algorithm for combining them. Since the "main" method of building a solo hybrid credential is under patent, there is also additional motivation for applications to use two.
I concur with Brendan here. To be consistent with our earlier decisions to (a) keep KeyPackages to one ciphersuite and (b) include the signature algorithm in the ciphersuite, we should keep credentials to one signature algorithm as well. Propose closing this PR without merging.
Discussed at 2020-10-06 interim, TODO: Re-add SignatureScheme enum, re-using the TLS signature schemes Clarify that the main job of a Credential is to provide a public key for verifying messages How it provides the credential might be different per credential type e.g., in BasicCredential, it's provided directly, X509Credential, have to parse the leaf certificate
LGTM with a couple nits.
Code change:
where "[leader]" is the first entry in the task's aggregator endpoints.  The payload is structured as follows: <del> This message is called the Client's report.  It consists of a "header" and the encrypted input share of each of the Aggregators. The header consists of the task ID and report "metadata".  The metadata consists of the following fields: </del> <ins> This message is called the Client's report.  It consists of the report metaata, the "public share" output by the VDAF's input- distribution algorithm, and the encrypted input share of each of the Aggregators.  The header consists of the task ID and report "metadata".  The metadata consists of the following fields: </ins> A timestamp representing the time at which the report was generated.  Specifically, the "time" field is set to the number of

Related discussion:
text: Align with the latest VDAF draft. This requires two minor protocol changes: 02 added a value called the "publicshare" to the VDAF syntax. This is to support Poplar1 (and likely other schemes that need a similar extractability property). To accommodate this, the publicshare field has been added to the Report and ReportShare structures and appended to the AAD for input share encryption. (This may end up being useful for privacy.) 02 added the report count to the aggregate result computation. This is already passed to the Collector in the CollectResp, so we just need to update the aggregate result computation in the draft to match.
Rebased and pushed a minor update: The public share in Report and ReportStore now both have the same length prefix.
Rebased.
This will be VDAF-02 or 03, depending on when we need to cut DAP-02.
VDAF-03 is out, I will send a PR by end of week. URL