jiebi/CodeConvo huggingface dataset:
Change:
nonce is in this set, it either ignores it or aborts the upload sub- protocol as described in upload-flow.  A Helper who receives an encrypted input share whose nonce is in this set rejects the report <del> as described in input-share-batch-validation. </del> <ins> as described in early-input-share-validation. </ins> [OPEN ISSUE: This has the potential to require aggreagtors to store nonce sests indefinitely.  See issue#180.]

Discussion:
Clarify that is used when it's impossible to determine if an input share is valid. One situation we need this for is when an Aggregator drops some anti-replay state in order to reduce storage costs. This should result in data loss in the worst case, not a loss of privacy.
Since , aggregators are required to store report nonces for batch intervals that have not yet been collected. This is necessary in order to prevent replay attacks. The problem is that nothing guarantees that a batch interval will be collected in a timely manner: In theory, it's possible that aggregators will have to store nonce sets indefinitely. To prevent this, there needs to be a way for the aggregators to agree on when to stop accepting reports for a given batch interval. The strawman solution is to allow each aggregator to, at its own discretion, ignore a report if it can't confirm if the report was replayed or not. The problem is that this potentially leads to unnecessary data loss.
I propose resolving this with .
Change:
Examples of use of the EDHOC-Exporter are given in transfer. <del> 4.2.2. To provide forward secrecy in an even more efficient way than re- running EDHOC, EDHOC provides the optional function EDHOC-KeyUpdate. When EDHOC-KeyUpdate is called, a new PRK_out is calculated as a "hash" of the old PRK_out using the Expand function as illustrated by the following pseudocode.  The change of PRK_out causes a change to PRK_exporter and derived keys using EDHOC-Exporter. where hash_length denotes the output size in bytes of the EDHOC hash algorithm of the selected cipher suite. The EDHOC-KeyUpdate takes a context as input to enable binding of the updated PRK_out to some event that triggered the keyUpdate.  The Initiator and the Responder need to agree on the context, which can, e.g., be a counter or a pseudorandom number such as a hash.  To provide forward secrecy the old PRK_out and derived keys must be deleted as soon as they are not needed.  When to delete the old keys and how to verify that they are not needed is up to the application. I-D.ietf-core-oscore-key-update describes key update for OSCORE using EDHOC-KeyUpdate. While this key update method provides forward secrecy it does not give as strong security properties as re-running EDHOC, see security. </del> 5. This section specifies formatting of the messages and processing

Discussion:
Replacing a session key with its hash for forward secrecy as specified with EDHOC-KeyUpdate, can alternatively be defined by the application as is done in KUDOS (draft-core-oscore-key-update). For this reason there is no need to recommend EDHOC-KeyUpdate as is done in Section 7. "Implementations SHOULD support EDHOC-KeyUpdate." EDHOC-KeyUpdate can useful in other applications but the description should be moved out of the body in the interest of focusing on the core functionality of EDHOC.
Discussed in the interim and PR merged.
Change:
(ESP).  Each protocol can be used independently, but this document considers them together, since that is the most common pattern. <del> 3.8.1. </del> <ins> 3.4.1. </ins> <del> 3.8.1.1. </del> <ins> 3.4.1.1. </ins> IKEv2 is a control protocol that runs on UDP port 500.  Its primary goal is to generate keys for Security Associations (SAs).  It first

Discussion:
Sort the protocols we describe based on perceived importance, popularity, etc. Basically, put non-standard ones at the end, and all else towards the front.
Correct!
I'm assuming the content itself hasn't changed, just moved around? It's not obvious from the diff, so LMK if not and I'll un-approve.
Change:
The encoding of the Length field is modeled after the Option Length field of the CoAP Options (see Section 3.1 of RFC7252). <del> The following figures show the message format for the 0-bit, 16-bit, and the 32-bit variable length cases. </del> <ins> For simplicity, a Payload Marker (0xFF) is shown in fig-frame; the Payload Marker indicates the start of the optional payload and is absent for zero-length payloads (see Section 3 of RFC7252).  (If present, the Payload Marker is included in the message length, which counts from the start of the Options field to the end of the Payload field.) </ins> For example: A CoAP message just containing a 2.03 code with the <del> token 7f and no options or payload would be encoded as shown in fig- frame2. </del> <ins> token 7f and no options or payload is encoded as shown in fig-frame2. </ins> The semantics of the other CoAP header fields are left unchanged.

Discussion:
Changes since -09 (Brian's earlier ones included): URL
Yes, that happens to me as well. Keeps you awake :-) We have 14 more issues to go before a full reread is indicated...
The box notation in Figures 4, 5, 7, 8 does not make very transparent that this is all the same format. Maybe we can cut this down to a single figure of the form: This would also allow to pull down the remark at the end of section 2 to that single figure.
CoAP (RFC 7252) / This Document is too wide when indented as much as it is.
I propose that the speculation about what we'll do when we need something the reasons for which we don't even know yet can be removed.
»Messages may be in flight when the sender decides to send a Release message. The general expectation is that these will still be processed.« EKR notes that this is not clearly describing this case: The intention is that a Release actually does allow the other side to process outstanding requests, so in the above example the server would actually send “Response A” before closing.
+1 for consolidating the message format figures. One small, long-standing usability nit: Whenever I want to look at the message format, I scroll through the document until I see the first figure with a message format. Every time it takes me a few seconds to realize that this figure shows the existing RFC 7252 format, not the new message format that I'm looking for. Otherwise, this looks good to me. (I only read the diff. Let me know when I should read the whole document.)
Change:
"CoAP client" and "CoAP server", respectively, as defined in RFC7252. The terms "payload" and "body" of a message are used as in RFC7959. <del> The complete interchange of a request and a response body is called a </del> <ins> The complete interchange of a request and a response is called a </ins> (REST) "operation".  An operation fragmented using RFC7959 is called <del> a "blockwise operation".  A blockwise operation which is fragmenting the request body is called a "blockwise request operation".  A blockwise operation which is fragmenting the response body is called a "blockwise response operation". </del> <ins> a "blockwise operation". </ins> Two blockwise operations between the same endpoint pair on the same resource are said to be "concurrent" if a block of the second request

Discussion:
I did quite a lot of changes to the Echo parts as discussed earlier. The Echo parts are now clearer updated in requirements and general processing, and example implementations for Token Option Values. I wrote a reasonably long security consideration chapter and added the missing IANA section. I added updated Token handling which requires some changes to abstract and introduction. Removed some definitions that were not used. I have not touched the Request-Tag parts except for maybe some editorials.
I think you should already have write access to the repository; if you can't just push your changes, I'm afraid you'll have to ask Carsten to add you to the team at URL I'm merging this now to get things on, and am trying to add some fixes today still to upload this evening's state before the cut-off. A suggestion w/rt the pull request branches: could you just add commits rather than appending them (unless you're changing around in the same place)? That'd make it much easier to update one's mental model of the document.
The terms "blockwise request operation" and "blockwise response operation" are used (the former frequently, the latter only once), so I've reverted the line that drops them to their previous state in 382c308f3.
Change:
(client-facing) SNI.  If present, clients SHOULD use its value in the SNI extension of the subsequent ClientHello. <del> Clients obtain these records by querying DNS for hidden server </del> <ins> Clients obtain these records by querying DNS for ESNI-enabled server </ins> domains.  Thus, servers operating in Split Mode SHOULD have DNS <del> configured to return the same A (or AAAA) record for all hidden </del> <ins> configured to return the same A (or AAAA) record for all ESNI-enabled </ins> servers they service.  This yields an anonymity set of cardinality <del> equal to the number of hidden server domains supported by a given client-facing server.  Thus, even with SNI encryption, an attacker which can enumerate the set of hidden server domains supported by a client-facing server can guess the correct SNI with probability at least 1/K, where K is the size of this hidden server anonymity set. This probability may be increased via traffic analysis or other mechanisms. </del> <ins> equal to the number of ESNI-enabled server domains supported by a given client-facing server.  Thus, even with SNI encryption, an attacker which can enumerate the set of ESNI-enabled domains supported by a client-facing server can guess the correct SNI with probability at least 1/K, where K is the size of this ESNI-enabled server anonymity set.  This probability may be increased via traffic analysis or other mechanisms. </ins> The "checksum" field provides protection against transmission errors, including those caused by intermediaries such as a DNS proxy running

Discussion:
I decided "hidden" was bad. NAME
+1 to the change. I think that this is the right direction.
Change:
An application server requests the delivery of a push message by sending a HTTP POST request to a push resource distributed to the <del> application server by a user agent.  The ciphertext of the push message is included in the body of the request. </del> <ins> application server by a user agent.  The content of the push message is included in the body of the request. </ins> 5.1.

Discussion:
"The ciphertext of the push message is included in the body of the request." The example looks like base64 - it should be clear it's binary content ( ciphertext is not base64) If we give an example with ciphertext, it should include the extra headers. Alternative is to say "The content of the push message is included", and have a "I am walrus" example" - with a link to the encryption document for proper encrypted example. But since most implementations will require encryption - I think it's better to add the extra headers and make it clear it's binary.
I prefer the "Alternative" approach to keep the webpush examples simple and uncluttered. I will add a reference to the example in to illustrate encryption.
Change:
designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page. <del> 4.5. </del> <ins> 4.4. </ins> As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running

Discussion:
PR of
I will upload a PR for this.
OK, bad merge, thanks for catching
Fixed by
E.g. "Step 5 in Section {{gathering}}" in .md becomes "Step 5 in Section Section 2.1" in .html or "Step 5 in Section Section 2.1" in the raw html source.
Was this fixed?
No, it looks to me an issue with the generator code. Or, can I fix it inline? I was assuming the html would be auto-generated, but if it is supposed to just upload a copy, I will fix it inline asap.
I was wrong. This issue is gone in the newly generated HTML (from the "here" link), but we probably need to regenerate it after merging PR
OK, will do as part of the upload
Resolved in latest HTML.
Change:
these rules and abort the handshake with an "illegal_parameter" alert if one is violated. <ins> In a HelloRetryRequest message, the "extension_data" field of this extension contains a KeyShareHelloRetryRequest value: %%% Key Exchange Messages struct { NamedGroup selected_group; } KeyShareHelloRetryRequest; The mutually supported group the server intends to negotiate and is requesting a retried ClientHello/KeyShare for. </ins> Upon receipt of this extension in a HelloRetryRequest, the client MUST verify that (1) the selected_group field corresponds to a group which was provided in the "supported_groups" extension in the

Discussion:
I tend to narrow things from the right....
Programmer habits maybe, for me a "FooTest" is a specialization of "Test", so the current "KeyShareServerHello" looks like a specialization of "ServerHello" to me. It's a minor thing though.
Fair enough, but my habit is the opposite. :)
The text refers to helloretryrequest (e.g. in IANA considerations), but the HandshakeType enum refers to helloretryrequestRESERVED. Should something be said about Server Hello being able to modify ? Should something be said about rejecting handshake messages with ? (The current seems to suggest that the wire can really contain 6.)
My syntax validator also detects this error. We need to fix this.
I guess that it is hard to express a nested . So, it seems to me that a comment is reasonable:
That comment is not easy to parse for a machine :/ (btw, the comment is for the serverhello case, not clienthello). is only defined for enumerations, so we cannot do something like: (and even the above is not accurate since interpretation of random depends on the supportedextensions value.) Maybe something like: with the intention that ServerHelloParameters is populated while preparsing the SH message (prescan for supportedversions, detect HRR vs normal SH based on Random). This is inspired by the SecurityParameters type in RFC 5246.
LGTM. As a nitpick, maybe name it "ServerHelloKeyShare" instead of "KeyShareServerHello" (likewise for CH and HRR).
Change:
parameters than they would if the connection were not under attack. <del> A record protocol (record-protocol) which uses the parameters </del> <ins> A record protocol (record-protocol) that uses the parameters </ins> established by the handshake protocol to protect traffic between the communicating peers.  The record protocol divides traffic up into a series of records, each of which is independently protected

Discussion:
Some suggested nits for s1: adding a semi-colon and swapping two whichs for thats.
Change:
Any transport protocol used MUST provide a way for the server to filter the clients that can access it by the origin RFC6454. <ins> Any transport protocol used MUST provide a way for a server endpoint location to be described using a URI RFC3986.  They can be used for integration with various Web platform features that represent resources as URIs, such as Content Security Policy CSP. </ins> 3. WebTransport session establishment is in general asynchronous,

Discussion:
This defines a new URL scheme for QuicTransport, and clarifies the use of "https" for Http3Transport.
Change:
modification in the path taken by packets that comprise a connection. Attackers are additionally categorized as either on-path attackers or <del> off-path attackers; see Section 3.5 of SEC-CONS.  An on-path attacker can read, modify, or remove any packet it observes such that it no longer reaches its destination, while an off-path attacker observes the packets, but cannot prevent the original packet from reaching its intended destination.  Both types of attackers can also transmit arbitrary packets. </del> <ins> off-path attackers.  An on-path attacker can read, modify, or remove any packet it observes such that it no longer reaches its destination, while an off-path attacker observes the packets, but cannot prevent the original packet from reaching its intended destination.  Both types of attackers can also transmit arbitrary packets.  This definition differs from that of Section 3.5 of SEC- CONS in that an off-path attacker is able to observe packets. </ins> Properties of the handshake, protected packets, and connection migration are considered separately.

Discussion:
We weren't being consistent. This should help.
NAME said:
The first here is in the process of being addressed, see . I agree regarding "strong", but also agree regarding what to do about it. My proposal is to let close this issue.
NAME said:
Proposed resolution is URL
This is an improvement. Thanks.
Change:
This document only makes use of the 'default.service.arpa' subdomain of 'service.arpa.'  Other subdomains are reserved for future use by DNS-SD or related work.  The IANA is requested to create a registry, <del> the "service.arpa Subdomain Registry".  This registry shall begin as the following table: </del> <ins> the "service.arpa Subdomain Registry".  The IETF shall have change control for this registry.  New entries may be added either as a result of Standards Action RFC8126 or with IESG approval RFC 8126, provided that a specification exists RFC8126. The IANA shall group the "service.arpa Subdomain Registry" with the "Locally-Served DNS Zones" registry.  The registry shall be a table with three columns: the subdomain name (expressed as a fully- qualified domain name), a brief description of how it is used, and a reference to the document that describes its use in detail. This registry shall begin as the following table: </ins> 9.3.

Discussion:
David Schinazi pointed out: This PR implements David's suggestion.
I noticed this during my shepherd review. Section creates a new registry but is lacking sufficient information for IANA to create the registry. In particular, the registration procedure is missing. Please refer to RFC 8126 for guidance.
Fixed by
Change:
RFC5245, Section 4.3.  Note, however, that the m= line protocol need not match the default candidate, because this protocol value must instead match what was supplied in the offer, as described <del> above.  Each "a=rtcp" attribute line MUST also be filled in with the port and address of the appropriate default candidate, either the default RTP or RTCP candidate, depending on whether RTCP multiplexing is enabled in the answer.  In each case, if no candidates of the desired type have yet been gathered, dummy values MUST be used, as described in the initial answer section </del> above. The media formats on the m= line MUST be generated in the same

Discussion:
LGTM
What needs to happen to finish this one ?
NAME NAME I think this reflects our discussion in the bug.
LGTM
NAME back at you
Ugh, git push failing due to airplane wifi. Will update when it succeeds
done
Where are we on this. Is this waiting for justin ?
yes, we are waiting for justin
Change:
4.4.1.1. <ins> RFC6066 and RFC6961 provide extensions to negotiate the server sending OCSP responses to the client.  In TLS 1.2 and below, the server sends an empty extension to indicate negotiation of this extension and the OCSP information is carried in a CertificateStatus message.  In TLS 1.3, the server's OCSP information is carried in an extension in the CertificateEntry containing the assoiciated certificate.  Specifically: The body of the "status_request" or "status_request_v2" extension from the server MUST be a CertificateStatus structure as defined in RFC6066 and RFC6961 respectively. Similarly, RFC6962 provides a mechanism for a server to send a Signed Certificate Timestamp (SCT) as an extension in the ServerHello.  In TLS 1.3, the server's SCT information is carried in an extension in CertificateEntry. 4.4.1.2. </ins> The following rules apply to the certificates sent by the server: The certificate type MUST be X.509v3 RFC5280, unless explicitly

Discussion:
This change adds a set of extensions to the Certificate message. This is intended to hold all extension messages that are certificate-specific as opposed to extensions that apply to the entire connection. This change facilitates future extensions to the protocol for post-handshake server authentication and resolves the anomaly of OCSP messages appearing before certificates in the handshake.
Changed SingleCertificate to CertificateEntry
NAME this seems ready to land from my side modulo the rename I propose. Do you have any changes to make?
Change:
Implementations MAY experiment with absolute thresholds, thresholds from previous connections, adaptive thresholds, or including RTT <del> variance.  Smaller thresholds reduce reordering resilience and </del> <ins> variation.  Smaller thresholds reduce reordering resilience and </ins> increase spurious retransmissions, and larger thresholds increase loss detection delay.

Discussion:
It's a mean deviation. This has confused at least one reader.
True-ish, but nor is smoothed_rtt a mean. And now you have a variable with a name that bears no semblance to the concept you use to describe it. You could instead play apologist and explain that this isn't a variance in the statistical sense, but variance in a purely colloquial sense.
Section 2 of RFC2988 says "To compute the current RTO, a TCP sender maintains two state variables, SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation)." It does subsequently use the term variance in one spot, but given the original definition is a better one, I'd rather use variation than variance. RFC6298 does the exact same thing, and defines RTTVAR as "round-trip time variation".
In both sentences, minrtt and smoothedrtt are described in technically accurate terms, so I think it makes sense to describe rttvar as a mean deviation, because that's the most technically accurate term. I also understand the need for consistency, so if you have suggestions on how to improve that without removing the technical description, it'd be appreciated.
Change:
determine the associated local address required by Mode 2, which we define as the source address that would be used for any packets sent to the web application host (assuming that UDP and TCP get the same <del> routing).  Use of the web application host as a destination ensures the right source address is selected, regardless of where the </del> <ins> routing treatment).  Use of the web application host as a destination ensures the right source address is selected, regardless of where the </ins> application resides (e.g., on an intranet). First, the appropriate remote IPv4/IPv6 address is obtained by

Discussion:
This reverts commit 0dac1b124828835c5785c4ae703c26ad3d19f65f.
Change:
7. <del> TBD. </del> <ins> On sending an update to the peer's "max_ack_delay", an endpoint can use this new value in later computations of its Probe Timeout (PTO) period; see Section 5.2.1 of QUIC-RECOVERY.  The endpoint MUST however wait until the ACK-FREQUENCY frame that carries this new value is acknowledged by the peer. Until the frame is acknowledged, the endpoint MUST use the greater of the current "max_ack_delay" and the value that is in flight when computing the PTO period.  Doing so avoids spurious PTOs that can be caused by an update that increases the peer's "max_ack_delay". While it is expected that endpoints will have only one ACK-FREQUENCY frame in flight at any given time, this extension does not prohibit having more than one in flight.  Generally, when using "max_ack_delay" for PTO computations, endpoints MUST use the maximum of the current value and all those in flight. </ins> 8. TBD. <ins> 9. TBD. </ins>

Discussion:
merging.
If it doesn't change it, we should say so. If it allows it to be reduced, then we need to understand what the limits are(ie: it can't be lowered to 1us presumably?). Admittedly, the way we're using maxackdelay should be safe to assuming a 0 value, since the SRTT will accrue the excess.