jiebi/CodeConvo huggingface dataset:
Change:
Revocation requests are different from other ACME requests in that they can be signed either with an account key pair or the key pair in <del> the certificate.  Before revoking a certificate, the server MUST verify that the key used to sign the request is authorized to revoke the certificate.  The server MUST consider at least the following accounts authorized for a given certificate: </del> <ins> the certificate. Example using an account key pair for the signature: Example using the certificate key pair for the signature: Before revoking a certificate, the server MUST verify that the key used to sign the request is authorized to revoke the certificate. The server MUST consider at least the following accounts authorized for a given certificate: </ins> the account that issued the certificate.

Discussion:
The example was misleading in case a certificate is revoked by signing the revocation request with the certificate's private key. I assume "jwk" should be the public key from the certificate in this case and not the account key; see URL
Merging because it looks like the issue raised by NAME has been addressed.
Change:
be used to facilitate interaction with the end user.  To initiate an interaction start method indicated by the response-interact from the AS, the client instance follows the steps defined by that interaction <del> method.  The actions of the client instance required for the </del> <ins> start mode.  The actions of the client instance required for the </ins> interaction start modes defined in this specification are described <del> in the following sections. </del> <ins> in the following sections.  Interaction start modes defined in extensions to this specification MUST define the expected actions of the client software. If the client instance does not start an interaction start mode within an AS-determined amount of time, the AS SHOULD reject attempts to use the interaction start modes.  If the client instance has already begun one interaction start mode, the AS SHOULD reject attempts to use other interaction start modes. </ins> 4.1.1.

Discussion:
Allows interaction responses from the AS to have an explicit timeout, with instructions on how the client instance can recover (do a modification).
To edit notification comments on pull requests, go to your .
When an AS creates a set of of interaction artifacts, like a user code or interaction URI, these artifacts aren't likely to be available perpetually. The AS will likely want to purge these after some time. It might be useful for the AS to indicate to the client a timeout for the "interact" return block so that the client has some idea of how much time it has to use the interaction methods.
Change:
packets it sends to the server.  These do not relate to the ECN markings of packets sent between client and proxy in any way. <del> 6. </del> <ins> 7. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad

Discussion:
This is one potential design for the identifier at the start of the CONNECT-UDP datagram payload. Note that this PR is against the design team consensus branch, not main. . .
During the HTTP Datagrams Design Team meeting on 2022-01-20, we reached consensus to move forward with the dynamic approach, so I'm merging this PR.
Change:
and Commits refer to Proposals they cover.  These identifiers are computed as follows: <ins> Where RefHashInput is defined as: And its fields set to: </ins> For a KeyPackageRef, the "value" input is the encoded KeyPackage, and the ciphersuite specified in the KeyPackage determines the KDF used. For a ProposalRef, the "value" input is the MLSAuthenticatedContent

Discussion:
This PR fixes some minor issues with the presentation language. Moving and to their own block is required so that the can now detect them.
Change:
calls to createOffer and createAnswer. When creating offers, the transceiver direction is directly reflected <del> in the output, even for reoffers.  When creating answers, the </del> <ins> in the output, even for re-offers.  When creating answers, the </ins> transceiver direction is intersected with the offered direction, as explained in the sec.generating-an-answer section below.

Discussion:
Section 3.2 has a paragraph starting "Lastly, while the actual media parameters are only know after an offer..."; the entire contents of this paragraph appear to be actually false if both ICE and DTLS are in use. I know there's conversation underway on MMUSIC and the WebRTC mailing lists on this topic, but none of them have yet described a situation in which this paragraph is actually true. Please remove it or add a sequence diagram showing how it arises.
It may not be able to receive media (due to lack of DTLS fingerprint), but it can certainly receive ICE checks. We should clarify accordingly.
Change:
[TODO: Decide how to provide mutual authentication in leader-to- helper and collector-to-leader connections.  One option is to use client certificates for TLS; another is to have the leader sign its <del> messages directly, as in Prio v2.  For collector-to-leader connections, we may just have this be up to deployment.  (For instance, the collector might authenticate themselves by logging into a website that has some trust relationship with the leader.)] </del> <ins> messages directly.  For collector-to-leader connections, we may just have this be up to deployment.  (For instance, the collector might authenticate themselves by logging into a website that has some trust relationship with the leader.)] </ins> 11.

Discussion:
Remove terms which are infrequently used (and in a few cases, remove the unnecessary references) Clean up a few terms which appear to be defined incorrectly.
Change:
Initial contents: The fields and descriptions defined in authorization-objects. <ins> [[ RFC EDITOR: Please replace XXXX above with the RFC number assigned to this document ]] </ins> 9.7.4. This registry lists values that are used within URN values that are

Discussion:
Also, add some more "replace RFC XXXX with this document" notes, for clarity. Thanks to NAME for noticing that this was missing.
Merging based on r+ from NAME
The new registry looks good :+1: - no changes to request there. The existing directory registry () should probably have a "meta" entry:
Change:
3.7.1. <ins> "$["u00b1"]" is normalized into (noise in the table and lack of typewriter font is due to RFCXMLv3 limitations). </ins> 4. 4.1.

Discussion:
NAME and NAME Thanks for your help. I verified cut'n'past works correctly.
Some of these are split across lines in awkward places: ! We could either fix the rendering somehow to split at a more acceptable point or change the examples to avoid these awkward splits.
NAME Do you know how to fix the rendering? E.g. I think it would be better not to split the lines in the middle of a quoted string, but splitting after would be ok.
Please check my little tweak to
What if we reduce each aspect to minimal necessary ... ?
This seems to work ...
This is essentially what URL does, except that it uses native nbsps.
ahh ... fine ...
There are two considerations I have in mind: Ease of future editing - may need to add a comment about invisible special characters. Cut'n'paste - need to be able to run the examples and get the same results when clipped from either text or HTML.
Left an editing note. Copy/paste works for me in TXT (which has an ASCII space) and HTML (which has an NBSP, but that gets reduced in copy/paste).
Fixed as part of e82ce1f521e94ee2cd5b93d14726875e94a4a8e7.
Change:
queries example.com, the ESNI TXT name is _esni.example.com.  Servers SHOULD configure DNS such that, upon querying a domain name with ESNI support, at most one A, AAAA, TXT ESNI, and ALTSVC I-D.schwartz- <del> httpbis-dns-alt-svc Resource Record is returned.  Providing more address options and ESNI keys could lead a client to choose an incorrect key for an address.  Alt-Svc records may be used to inform the client of the plaintext (fronting) SNI Also, servers operating in Fronting Mode SHOULD have DNS configured to return the same A (or AAAA) record for all hidden servers they </del> <ins> httpbis-dns-alt-svc Resource Record is returned.  Alt-Svc records may be used to inform the client of the plaintext (fronting) SNI.  Also, servers operating in Fronting Mode SHOULD have DNS configured to return the same A (or AAAA) record for all hidden servers they </ins> service. The Resource Record TTL determines the lifetime of the published ESNI

Discussion:
Instead of a Fronting SNI field, we should just re-use the Alt-Svc record, which already carries an SNI value to be used.
Change:
even if the underlying stack supports it, there is no guarantee that a soft error will be signaled. <del> 10.3. </del> <ins> 10.4. </ins> This event notifies the application of excessive retransmissions, based on a configured threshold (see conn-excss-retransmit).  This

Discussion:
Btw why do we have (only) properties for the TCP UTO?
I didn't get that this is only an example, so yes we should say this more explicitly. Not sure where to put that though. Maybe we can just merge this PR for now and have a separate PR to add this somewhere.
I actually also just added "as an example for a protocol-specific property" in that section but maybe we want to say it somewhere else again...?
It isn't just an example. The reasons it's there go back to minset (if you remove it, you lose this functionality forever), yet there were arguments for this being a special TCP thing only, and being too awkward to include as general functionality - much like there are now arguments that might lead to ECN becoming UDP-specific.
Some more explanations: why is this included? From appendix C, we can see that it relates to "Suggest timeout to the peer" in minset. The argument for including this, in appendix A of the minset draft, is: "Functional because this is closely related to potentially assumed reliable data delivery." Indeed, the last paragraph of section 1 in RFC 5482 gives examples where communication might just fail for applications expecting their connections to stay up. in reality, this doesn't seem to be needed much, and so this is hardly implemented (if at all!).why is it TCP specific? This was discussed in issue : URL The key statement against having this as a general thing is probably this sentence from NAME "If we had a timeout on overall connection establishment, from Initiate() to Ready(), then that's trying to set a timeout not just on TCP, but on DNS, racing, proxies, TLS, and who knows what else."
Okay, let's merge this and then think about how to motivate that we specify UTO. If we do it because it's in minset, that means that implementations have to expose UTO to be TAPS-compliant because TAPS requires that implementations at least expose the features in minset. Also, I think we should say is that there's more Protocol-Specific Properties and we don't specify all of them here, but implementations are free to add their own.
Change:
isolating a single location within a JSON document.  Path is a query syntax that can also be used to pull multiple locations. <del> [no-dot-length] We probably want to use an expression that does not use </del>

Discussion:
There does not seem to be an appetite for doing the necessary spec work. This PR will test that assertion. Filter expressions are still supported, but not "container expressions", of the form [(...)].
I think this can be added later, similar to the consensus for . Personally I still see value in having it.
Change:
COSE supports two different encryption structures.  COSE_Encrypted is used when a recipient structure is not needed because the key to be <del> used is known implicitly.  COSE_Enveloped is used the rest of time time.  This includes cases where there are multiple recipients, a recipient algorithm other than direct is to be used, or the key to be used is not known. </del> <ins> used is known implicitly.  COSE_Enveloped is used the rest of time. This includes cases where there are multiple recipients, a recipient algorithm other than direct is to be used, or the key to be used is not known. </ins> 5.1.

Discussion:
Deemed not used in enough locations - counter signatures suffer because of this but the group did not care.
Change:
2. <del> A server that supports this protocol on one or more URIs is called a "DNS API server" to differentiate it from a "DNS server" (one that uses the regular DNS protocol).  Similarly, a client that supports this protocol is called a "DNS API client". </del> <ins> A server that supports this protocol is called a "DNS API server" to differentiate it from a "DNS server" (one that uses the regular DNS protocol).  Similarly, a client that supports this protocol is called a "DNS API client". </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

Discussion:
This isn't necessary. I realize that this reverts a deliberate change as part of , but if it is important to describe - which I don't think helps - then I don't think that this is the right approach. Adding an explicit statement would be better.
hmm.. I think this was committed a little prematurely.. as martin says, the change was originally deliberate to emphasize that uris are the primitive and not the server. Happy to make that an explicit statement - but don't want to leave it out.
Change:
that adopt certificate compression.  Because of that, the extension is only supported in the versions of TLS where the certificate message is encrypted in a way that prevents middleboxes from <del> intercepting it, that is, TLS version 1.3 I-D.ietf-tls-tls13 and higher. </del> <ins> intercepting it, that is, TLS version 1.3 RFC8446 and higher. </ins> 7. 7.1. Create an entry, compress_certificate(27), in the existing registry <del> for ExtensionType (defined in I-D.ietf-tls-tls13), with "TLS 1.3" column values being set to "CH, CR", and "Recommended" column being set to "Yes". </del> <ins> for ExtensionType (defined in RFC8446), with "TLS 1.3" column values being set to "CH, CR", and "Recommended" column being set to "Yes". </ins> 7.2. Create an entry, compressed_certificate(25), in the existing registry <del> for HandshakeType (defined in RFC5246). </del> <ins> for HandshakeType (defined in RFC8446). </ins> 7.3.

Discussion:
When running idnits, it reports a couple of issues: RFC1950 and RfC7932 are the zlib and brotli RFCs. I'm guessing the way to fix this would to remove the related MUSTs and downgrade the references, though I haven't come up with appropriate wording yet. /cc NAME (any suggestion?)
fixes a couple more errors that are not listed here btw.
Note that downref "nits" can be handled via documented procedures in . In summary, we can identify them in the IETF LC (when we get there) and see who objects to referring to an informative RFC from this draft, which is intended for standards track. For zlib there are a ton of these already and it looks like somebody just didn't update the downref registry (i.e., I suspect there will be no strenuous objections from anybody). For brotli, it's newer but I am not too worried about the uproar. I'd just leave the MUST and the normative references in.
Ok, thanks NAME I'll close this then.
Change:
9. This document makes no requests of IANA. <ins> 10. This section provides a set of test vectors that implementations can use to verify that they correctly implement SFrame encryption and decryption.  For each ciphersuite, we provide: [in] The "base_key" value (hex encoded) [out] The "secret", "key", and "salt" values derived from the "base_key" (hex encoded) A plaintext value that is encrypted in the following encryption cases A sequence of encryption cases, including: [in] The "KID" and "CTR" values to be included in the header [out] The resulting encoded header (hex encoded) [out] The nonce computed from the "salt" and "CTR" values The ciphertext resulting from encrypting the plaintext with these parameters (hex encoded) An implementation should reproduce the output values given the input values.  Encryption with the input values and the plaintext should produce the ciphertext.  Decryption with the input values and the ciphertext should produce the plaintext. Line breaks and whitespace within values are inserted to conform to the width requirements of the RFC format.  They should be removed before use.  These test vectors are also available in JSON format at TestVectors. 10.1. 10.2. 10.3. 10.4. </ins>

Discussion:
This PR adds test vectors for SFrame encryption. A Go script is provided that implements the header encoding and the relevant encryption routines, generates test vectors for salient cases, and serializes them as Markdown or JSON. The Markdown version is included in the specification directly.
Change:
This key exchange algorithm is the same as ECDHE_ECDSA except that the server's certificate MUST contain an RSA public key authorized for signing, and that the signature in the ServerKeyExchange message <del> must be computed with the corresponding RSA private key.  The server certificate MUST be signed with RSA. </del> <ins> must be computed with the corresponding RSA private key. </ins> 2.3.

Discussion:
TLS 1.1 and earlier required the signature algorithm in the certificate to match that of the public key. TLS 1.2 removed this restriction. Since RFC 4492 predated TLS 1.2 it reflected the same restriction. Here we remove it.
Change:
the remote side supports, specifies what the remote side should send. However, not all parameters follow this rule; some parameters are declarative, and the remote side MUST either accept them or reject <del> them altogether.  An example of such a parameter is the DTLS fingerprints RFC8122, which are calculated based on the local certificate(s) offered and are not subject to negotiation. </del> <ins> them altogether.  An example of such a parameter is the TLS fingerprints RFC8122 as used in the context of DTLS RFC6347; these fingerprints are calculated based on the local certificate(s) offered and are not subject to negotiation. </ins> In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an

Discussion:
clarified TLS fingerprints, removed comments, issue 7
7) [rfced] Section 3.2: We do not see any mention of DTLS in RFC 8122; we only see "TLS." Will this citation be clear to readers? Original: An example of such a parameter is the DTLS fingerprints [RFC8122], which are calculated based on the local certificate(s) offered, and are not subject to negotiation. Possibly: An example of such a parameter is the TLS fingerprints [RFC8122] as used in the context of DTLS [RFC6347]; these fingerprints are calculated based on the local certificate(s) offered and are not subject to negotiation.
Comment is correct, suggestion seems reasonable.
NAME please close this issue once you consider it resolved.
Change:
A Manifest Information Model for Firmware Updates in IoT Devices <del> draft-ietf-suit-information-model-10 </del> <ins> draft-ietf-suit-information-model-11 </ins> Abstract

Discussion:
Section 4 We should probably mention the URI security considerations (RFC 3986) somewhere, as well as that remote resources need to receive an equal amount of cryptographic protection as the manifest itself, when dereferencing URIs.
Addressed in URL
Addressed in draft-ietf-suit-information-model-11
It might also be worth reiterating the topic that came up during one of the other review threads: firmware update is by definition remote code execution, so if you trust an entity to provide your firmware, you are trusting them to do the right thing. Many classes of attack involving malicious or modified payloads then become irrelevant, so we are left with just needing to verify that it did come from a trusted party and is not going backwards, topics that are covered quite well already (including TOCTOU).
Addressed in URL
Addressed in draft-ietf-suit-information-model-11
Change:
the end of the identified fields MUST be treated as a connection error of type HTTP_MALFORMED_FRAME. <ins> When a stream terminates cleanly, if the last frame on the stream was truncated, this MUST be treated as a connection error (errors) of type HTTP_MALFORMED_FRAME.  Streams which terminate abruptly may be reset at any point in a frame. </ins> 7.2. 7.2.1.

Discussion:
Until now, only bidirectional streams were specified to treat a truncated last frame on a cleanly terminated stream as an error. With this pr, the same logic applies to push streams as well. I just slightly reworded the text from the bidirectional streams section and put it into the push stream section. Not sure if this is the best solution but I'm also not sure where to put the text if the text for both the bidirectional streams and push streams had to be combined.
already contains this text: That's intended to cover any stream type with frames. Perhaps we should consolidate the language from both sections into that, possibly leaving behind cross-references.
I hadn't seen that paragraph yet. I'd propose to drop the text in the Bidirectional Streams section. The reasoning is that when searching for what to do when a stream is closed with a truncated frame, I found (or rather was pointed to) the text in the Bidirectional Streams section. After finding a paragraph like that, I didn't expect to find any other text in the rfc related to truncated frames (which led to this pr). Without the text in the Bidirectional Streams section, I might have found the text in the Frame Layout section first which would have immediately answered my question. This would also consolidate errors related to frames in the HTTP Framing Layer section which seems like the first place to go looking for frame related errors. Should I make another pr (if this sounds like a good idea) or update this one with the proposed change?
Fine to just update this one. Thanks!
This is the best I could come up with. I had to relax the text from Frame Layout to allow truncated frames on abruptly closed streams. Maybe abruptly closed stream should be clarified better (I'm not sure if this is done elsewhere already?).
Reworded so as to not change the original text as much. The pr now just moves the truncation section from the streams section to the frames section.