jiebi/CodeConvo huggingface dataset:
Change:
If the server wishes to present the client with terms under which the ACME service is to be used, it MUST indicate the URI where such terms <del> can be accessed in a Link header with link relation "terms-of- service".  As noted above, the client may indicate its agreement with these terms by updating its registration to include the "agreement" field, with the terms URI as its value.  When these terms change in a way that requires an agreement update, the server MUST use a different URI in the Link header. </del> <ins> can be accessed in the "terms-of-service" subfield of the "meta" field in the directory object, and the server SHOULD reject new- registration requests that do not contain "terms-of-service-agreed": true. </ins> If the client wishes to update this information in the future, it sends a POST request with updated information to the registration

Discussion:
This mitigates confusion about how clients should respond when terms of service change.
Updated based on review. Took out the echoing of the field on subsequent requests, because it makes things simpler and clearer.
Change:
include signatures generated with the RSA signature algorithm and with the Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithm.  This allows recipients to verify the signature associated <del> with one algorithm or the other.  (Source of text is RFC5652.) More detailed information on multiple signature evaluation can be found in RFC5752. </del> <ins> with one algorithm or the other.  (Source of text is RFC5652.)  More detailed information on multiple signature evaluation can be found in RFC5752. </ins> <del> The CDDL grammar structure for a signature is: ~~~~ COSE_Sign : { protected : bstr | null; unprotected : map(tstr) | null; payload : bstr | null; signatures: COSE_signature_a* | COSE_signature; } ~~~~ </del> <ins> The CDDL grammar structure for a signature message is: </ins> The fields is the structure have the following semantics:

Discussion:
Add new tables to the end of the document about parameters which talk about types and possible column for integer indexes in the future
Change:
structured in a nested fashion that reflects the nesting of the Attester's layers.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer. <del> Claims about a root of trust typically are asserted by Endorsers. </del> <ins> Claims about a root of trust typically are asserted by an Endorser. </ins> The device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an operating system kernel, and (C) an application

Discussion:
Once we added Reference Value Provider as a role, the diagram wasn't updated. The "A, B, and C" part is about reference values, not the endorsing of signing capabilities, which is just about A. Signed-off-by: Dave Thaler
Change:
TLS version, with the exception of the end-entity certificate which MUST be first. <ins> If the RawPublicKey certificate type was negotiated, then the certificate_list MUST contain no more than one CertificateEntry, which contains an ASN1_subjectPublicKeyInfo value as defined in RFC7250, Section 3. </ins> The server's certificate_list MUST always be non-empty.  A client will send an empty certificate_list if it does not have an appropriate certificate to send in response to the server's

Discussion:
Explicitly define RFC 7250 certificate support.
Seems reasonable. (I did not try to audit the rest of the text to see if there are other places that need updating.)
This captures what we talked about in Chicago.
Shucks, this hasn't landed yet, so I'll have to remember to update my editorial changes pull request that puts the numbers for these into the enumerated type definition for extensions.
Change:
not used by this specification; they MUST be checked for syntax but their values are not used. <del> The remaining lines are processed as follows: </del> <ins> The remaining non-attribute lines are processed as follows: </ins> The "v=" line MUST have a version of 0, as specified in RFC4566, Section 5.1.

Discussion:
Rewrite intro to be clearer Move table to appendix Fix some parsing instructions that were in the wrong place
LGTM (other than the little bad xml issue)
Change:
cases, the path is ordered from the leaf to the root; each node MUST be the parent of its predecessor. <del> The length of the "node_secrets" vector MUST be zero for the first node in the path.  For the remaining elements in the vector, the number of ciphertexts in the "node_secrets" vector MUST be equal to the length of the resolution of the corresponding copath node.  Each ciphertext in the list is the encryption to the corresponding node in the resolution. </del> <ins> The length of the "encrypted_path_secret" vector MUST be zero for the first node in the path.  For the remaining elements in the vector, the number of ciphertexts in the "encrypted_path_secret" vector MUST be equal to the length of the resolution of the corresponding copath node.  Each ciphertext in the list is the encryption to the corresponding node in the resolution. </ins> The HPKECiphertext values are computed according to the Encrypt function defined in I-D.barnes-cfrg-hpke.

Discussion:
NAME pointed out this disconnect in , but the fix needs to be the other way around.
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 2 issues have been closed and 0 issues are still open. :heart: , by :heart: , by - - Last week, 4 pull requests were created, updated or merged. Last week, 4 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 9 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
3.3. EDHOC includes the selection of connection identifiers (C_I, C_R) <del> identifying a connection for which keys are agreed.  Connection identifiers may be used in the ongoing EDHOC protocol (see ci-edhoc) or in a subsequent application protocol, e.g., OSCORE (see ci- oscore).  The connection identifiers do not have any cryptographic purpose in EDHOC. </del> <ins> identifying a connection for which keys are agreed. Connection identifiers may be used to correlate EDHOC messages and facilitate the retrieval of protocol state during EDHOC protocol execution (see transport) or in a subsequent application protocol, e.g., OSCORE (see ci-oscore).  The connection identifiers do not have any cryptographic purpose in EDHOC. </ins> Connection identifiers in EDHOC are byte strings or integers, encoded in CBOR.  One byte connection identifiers (the integers -24 to 23 and

Discussion:
There was quite a lot of overlap between 3.3.2 and 3.4. Tried to integrate 3.3.2 in 3.4 to avoid that.
Change:
At this time we consider only devices with web browsers, with web applications being the means of satisfying Captive Portal Conditions. <ins> An example interactive User Equipment is a smart phone. The User Equipment: </ins> None of the above requirements are mandatory because (a) we do not wish to say users or devices must seek full access to the captive

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!
Change:
in IPIM. Note that this measurement, as with passive RTT measurement for TCP, <del> includes any transport protocol delay (e.g., delayed sending of </del> <ins> includes all transport protocol delay (e.g., delayed sending of </ins> acknowledgments) and/or application layer delay (e.g., waiting for a response to be generated).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the

Discussion:
Using the Spin Bit for Passive RTT Measurement ... Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of [acm] suggest s/any/all/ ... Since the spin bit logic at each endpoint considers only samples from packets that advance the largest packet number, signal generation itself is resistant to reordering. However, reordering can cause problems at an observer by causing spurious edge detection and therefore inaccurate (i.e., lower) RTT estimates, if reordering occurs across a spin-bit flip in the stream. [acm] thanks for mentioning this! ... Raw RTT samples generated using these techniques can be processed in various ways to generate useful network performance metrics. A simple linear smoothing or moving minimum filter can be applied to the stream of RTT samples to get a more stable estimate of application-experienced RTT. RTT samples measured from the spin bit can also be used to generate RTT distribution information, including minimum RTT (which approximates network RTT over longer time windows) and RTT variance (which approximates jitter as seen by the application). [acm] (let's avoid the clocky term "jitter", and clarify) Suggest: (which over-estimates one-way packet delay variance as seen by an application end-point).
Change:
header pointing to documentation about the specific hit rate limits using the "urn:ietf:params:acme:documentation" relation. <del> 6.7. </del> <ins> 6.6. </ins> Errors can be reported in ACME both at the HTTP layer and within challenge objects as defined in identifier-validation-challenges.

Discussion:
Instead of defining a whole new key equivalence method just check the JWK verifies the inner JWS.
Change:
7. <ins> QUIC supports connection migration.  Even if lower-layer addresses (usually the 4-tuple of IP addresses and ports) changes, QUIC packets can still be associated with an existing connection based on the Connection ID (see also section connid) in the QUIC header, if present.  This supports cases where address information changes due to e.g.  NAT rebinding or change of the local interface.  Currently QUIC only supports failover cases.  Only one "path" can be used at a time, and as soon as the new path is validated all traffic will be switched over to the next path. 8. </ins> QUIC connections are closed either by expiration of an idle timeout or by an explicit indication of the application that a connection should be closed (immediate close).  While data could still be

Discussion:
addresses issue
I think the applicability draft may benefit from exploring connection migration strategies as described in: URL
Do we also need to say anything about use of 0-byte CID? See quicwg/base-drafts
The transport draft already says:
addressed by PR and one more sentence
I don’t see any text related to connection migration on that PR.
sorry wrong PR; should be and is already merged
good modulo typos
Change:
"decompression bombs", compressed data that is crafted to decompress to extremely large data items. <del> 7. </del> <ins> 8. </ins> (Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" with the RFC number of this specification and remove this note.) IANA is requested to assign new labels in the "SenML Labels" <del> subregistry of the SenML registry IANA.senml (as defined in RFC8428) </del> <ins> IANA.senml of the SenML registry IANA.senml (as defined in RFC8428) </ins> for the Content-Format indication as per tbl-senml-reg:

Discussion:
Alexey notes (Archived-At: ): Since data-ct needs almost all of the “normative” ABNF in media-content-type-format, I think the right thing to do would be to fully develop media-content-type-format and make it a normative reference. (Note that media-content-type-format probably needs to be run by httpbis and emailcore [?] soon and when it is nearing WGLC, and there may be surprises there.) This course of action would probably delay data-ct a bit; we might counteract the damage by early registration. Since data-ct only needs an “Expert Review” registration, we could decide to do this when we have processed the reviews that are now incoming.
I didn't do thorough review of the ABNF but otherwise looks good to me Hi all, Sorry for the belated review. I think the document is nearly ready for progression. I have a couple of minor related issues: Terminology Readers should also be familiar with the terms and concepts discussed in [RFC8428]. Awareness of terminology issues discussed in [I-D.bormann-core-media-content-type-format] can also be very It is expired and it is currently not a WG document. At minimum it should be revived. (Or see below) helpful. SenML Content-Format ("ct") Field I wish the document has ABNF for the "ct" field. If you want to use ABNF from draft-bormann-core-media-content-type-format-01, it should be Normative reference. If not, I think you should just cut & paste the ABNF into this document. Best Regards, Alexey
Change:
preferences and MUST only select a version of TLS present in that extension.  They MUST ignore any unknown versions.  If the extension is not present, they MUST negotiate TLS 1.2 or prior as specified in <del> RFC5246, even if ClientHello.version is {3, 4} or later. </del> <ins> RFC5246, even if ClientHello.legacy_version is {3, 4} or later. </ins> The server MUST NOT send the "supported_versions" extension.  The server's selected version is contained in the ServerHello.version

Discussion:
ClientHello.version -> ClientHello.legacy_version
Merged. Please send me a PR adding yourself to Contributors in alphabetical order
NAME Thank you! Done in PR .
Change:
4.3. <del> Verify that the protected field is empty. </del> <ins> Verify that the 'protected' field is empty. </ins> <del> Verify that the aad field is empty. </del> <ins> Verify that the 'aad' field is empty. </ins> <del> Encrypt the plain text and place in the ciphertext field. </del> <ins> Encrypt the plain text and place in the 'ciphertext' field. </ins> 5.

Discussion:
The majority of changes prior to the examples section are to address typos or what I saw as inconsistencies. I will admit I wasn't as diligent as I should have been on those, but I need to take another pass on the document. The examples were reformatted to minimize side scrolling -- and likely fit within the TXT representation.
Change:
4.1.9. <del> The canTrickleIce property indicates whether the remote side supports receiving trickled candidates.  There are three potential values: </del> <ins> The canTrickleIceCandidates property indicates whether the remote side supports receiving trickled candidates.  There are three potential values: </ins> No SDP has been received from the other side, so it is not known if it can handle trickle.  This is the initial value before

Discussion:
It has a new name.
Overall this LG, although having thought about it a bit more, .canTrickleIce seems like a not-fully-formed clause. .canTrickleIceCandidates seems like it might match better to addIceCandidate().
LGTM. NAME NAME LMK if you have any issues with this
The diff is incomprehensible due to the all the gratuitous whitespace changes. I'll make a diff I can review at some point and see if I can figure it out.
LGTM
I will manually merge this.
Change:
client or server MAY advertise support for any of these reserved versions. <del> Reserved version numbers will probably never represent a real protocol; a client MAY use one of these version numbers with the expectation that the server will initiate version negotiation; a server MAY advertise support for one of these versions and can expect that clients ignore the value. </del> <ins> Reserved version numbers will never represent a real protocol; a client MAY use one of these version numbers with the expectation that the server will initiate version negotiation; a server MAY advertise support for one of these versions and can expect that clients ignore the value. </ins> [[RFC editor: please remove the remainder of this section before publication.]]

Discussion:
This seems unnecessarily wishy-washy. Either they're reserved by definition, and therefore will never represent a real protocol, or they're available for use. We should remove the "probably" unless there's a good reason to keep it that I'm missing.
Use of that word was entirely intentional. If there is certainty about this status, then it creates a temptation to apply certain optimizations that could be disruptive. What if middleboxes cached Version Negotiation packets from servers and helpfully provided responses to greased connection attempts?
We fear that someone might ossify if they discover that these are definitely not real protocol versions. On the other hand, the thing that breaks is use of these as real protocol versions, which I don't believe we're trying to achieve. If the middlebox is generating accurate VN packets, that seems entirely reasonable (and indistinguishable from actual VN packets). If they're generating inaccurate VN packets, then our anti-downgrade protections that we've decided to implement RSN will break. On the other hand, if these ever are real protocol versions, then a junk grease packet using the reserved version will fail to parse as a valid Initial and will just fail rather than eliciting a VN response. This seems like an impossible battle to win, and a lot of subtlety to expect of middlebox vendors. Write what we mean and move on.
Change:
6. <del> RRC is not designed to counter on-path attackers.  These can never be distinguished from, for example, a genuine network device.  However, RRC can withstand off-path attackers of the type described below when the enhanced path validation algorithm (enhanced) is used. </del> <ins> RRC is not designed to counter man-in-the-middle attackers.  These can never be distinguished from a genuine network device.  Instead, the types of attacker RRC is designed to withstand are: On-path attackers that try to trigger a connection migration (on- path); Off-path attackers that try to put themselves on-path (off-path) - provided that the enhanced path validation algorithm is used, see enhanced. </ins> 6.1. <ins> An on-path attacker could make a copy of a packet, replace the source address with a spoofed one and forward it to the original destination.  If the spoofed packet arrives before the original it will be regarded as a migration, while the original packet will be flagged as a duplicate and dropped. The subsequent path validation (path-validation) will fail because the entity at the (spoofed) source address does not have the cryptographic keys needed to decode the "path_challenge" message that is sent to it, and therefore to produce the corresponding "path_response".  Since the path validation fails, the address binding is not altered, thus thwarting the attack. 6.2. </ins> An off-path attacker that can observe packets might forward copies of genuine packets to endpoints over a different path.  If the copied packet arrives before the genuine packet, this will appear as a path

Discussion:
fix/improve the "attacker model" section Signed-off-by: Thomas Fossati
CC NAME
At the top of the "Attacker model" section we say: "RRC is not designed to counter on-path attackers." What we should say instead is "RRC is not designed to counter man-in-the-middle attackers." We do take care of on-path attackers, via the challenge/response exchange, and we should say that.
I don't think the CR exchange solves the problem, because the attacker can just change the IP addresses.
Change:
server.  The client generates an asymmetric key pair and associates this key pair with a set of contact information by signing the contact information.  The server acknowledges the registration by <del> replying with a registration object echoing the client's input.  The server can also provide terms of service at this stage, which the client can present to a human user. </del> <ins> replying with a registration object echoing the client's input. </ins> Once the client is registered, there are three major steps it needs to take to get a certificate:

Discussion:
This mitigates confusion about how clients should respond when terms of service change.
Updated based on review. Took out the echoing of the field on subsequent requests, because it makes things simpler and clearer.
Change:
or more packets are sent prior to a dramatic decrease in congestion window; see persistent-congestion. <ins> 3.1.8. TCP uses a minimum congestion window of one packet.  However, loss of that single packet means that the sender needs to waiting for a PTO (pto) to recover, which can be much longer than a round-trip time. Sending a single ack-eliciting packet also increases the chances of incurring additional latency when a receiver delays its acknowledgement. QUIC therefore recommends that the minimum congestion window be two packets.  While this increases network load, it is considered safe, since the sender will still reduce its sending rate exponentially under persistent congestion (pto). </ins> 4. At a high level, an endpoint measures the time from when a packet was

Discussion:
Feel free to suggest better text or other reasons, but this is what I came up with.
QUIC spec uses kMinimumWindow of 2 MSS compared to TCP's 1 MSS. Let's state the deviation and add justifiaiton text.
LGTM, modulo one suggestion
Change:
smaller than their GET equivalents. When using the GET method the URI path MUST contain a query parameter <del> with the name of "ct" and a value indicating the media-format used for the dns parameter.  The value may either be an explicit media type (e.g. ct=application/dns-udpwireformat&dns=...) or it may be empty.  An empty value indicates the default application/dns- udpwireformat type (e.g. ct&dns=...). </del> <ins> name-value pair QUERYPARAMETER with the name of "ct" and a value indicating the media-format used for the dns parameter.  The value may either be an explicit media type (e.g. ct=application/dns- udpwireformat&dns=...) or it may be empty.  An empty value indicates the default application/dns-udpwireformat type (e.g. ct&dns=...). </ins> When using the GET method the URI path MUST contain a query parameter with the name of "dns".  The value of the parameter is the content of

Discussion:
…ry parameter
The spec refers to "query parameters", but does not specify their syntax. The most current reference for its definition is: URL
If you take , then you conveniently avoid having to normatively reference that specification :)