jiebi/CodeConvo huggingface dataset:
Change:
sent in addition to the grease_quic_bit transport parameter.  Though the value of the QUIC Bit in packets received by a peer might be set according to rules defined by the extension, they might also be <del> randomized according to the definition of the grease_quic_bit extension.  Receiving the transport parameter for the extension could be used to confirm that a peer supports the semantic defined in the extension.  To avoid acting on a randomized signal, the extension can require that endpoints set the QUIC Bit according to the rules of the extension, but defer acting on the information conveyed until the transport parameter for the extension is received. </del> <ins> randomized as specified in this document.  Receiving the transport parameter for the extension could be used to confirm that a peer supports the semantic defined in the extension.  To avoid acting on a randomized signal, the extension can require that endpoints set the QUIC Bit according to the rules of the extension, but defer acting on the information conveyed until the transport parameter for the extension is received. </ins> Extensions that define semantics for the QUIC Bit can be negotiated without using the grease_quic_bit transport parameter.

Discussion:
This was unclear as it wasn't clear which extension was operative in the sentence.
changes lgtm
Change:
which will be echoed in the client's Certificate message.  The certificate_request_context MUST be unique within the scope of this connection (thus preventing replay of client <del> CertificateVerify messages). </del> <ins> CertificateVerify messages).  Within the handshake, this field MUST be empty. </ins> A list of the signature algorithms that the server is able to verify, listed in descending order of preference.  Any

Discussion:
It's only useful during the handshake, so avoid forcing the client save that field for the in-handshake version.
I went back and forth on this, but on balance I think you're right.
Change:
Additionally, this document defines the following custom types for clarity: <ins> All timestamps and time-related values (e.g., offsets) in qlog are logged as "float64" in the millisecond resolution. Other qlog documents can define their own CDDL-compatible (struct) types (e.g., separately for each Packet type that a protocol supports). </ins> The main general CDDL syntax conventions in this document a reader should be aware of for easy reading comprehension are:

Discussion:
In the main schema document, there's a a chunk of text that says: The danger with restating things like this is that there is some subtle problem or incompatibility with the canonical CDDL source citation. I appreciate the QUIC WG might not be familiar with this syntax, so it's handy. But the long-term problems a more insidious. Consider replacing it with deep links to CDDL syntax, or sticking it behind a note that it will be removed prior to publication.
Yes, the intent is to remove this prior to publication. It's just there to make early adoption easier for now. Will look up how to properly add such a note (not sure if there's something default in the kramdown for that) and add it.
Change:
6.5. <del> To implement the DMARC mechanism, the only action required of a Domain Owner is the creation of the DMARC policy record in the DNS. However, in order to make meaningful use of DMARC, a Domain Owner must at minimum either establish an address to receive reports, or deploy authentication technologies and ensure Identifier Alignment. Most Domain Owners will want to do both. DMARC reports will be of significant size, and the addresses that receive them are publicly visible, so we encourage Domain Owners to set up dedicated email addresses to receive and process reports, and to deploy abuse countermeasures on those email addresses as appropriate. Authentication technologies are discussed in RFC6376 (see also RFC5585 and RFC5863) and RFC7208. </del> <ins> Issue 2, Original text: Issue 2, Proposed replacement text: </ins> 6.6.

Discussion:
Proposed updated ASCII art for mail flow. Proposed stripped down description of ASCII art. Proposed new text for Domain Owner actions.
Change:
3.4. <del> By definition, the Attester role creates Evidence.  An Attester may consist of one or more nested or staged environments, adding complexity to the architectural structure.  The unifying component is the root of trust and the nested, staged, or chained attestation Evidence produced.  The nested or chained structure includes Claims, collected by the Attester to aid in the assurance or believability of the attestation Evidence. </del> <ins> By definition, the Attester role generates Evidence.  An Attester may consist of one or more nested environments (layers).  The root layer of an Attester includes at least one root of trust.  In order to appraise Evidence generated by an Attester, the Verifier needs to trust the Attester's root of trust.  Trust in the Attester's root of trust can be established either directly (e.g., the Verifier puts the root of trust's public key into its trust anchor store) or transitively via an Endorser (e.g., the Verifier puts the Endorser's public key into its trust anchor store).  In layered attestation, a root of trust is the initial Attesting Environment.  Claims can be collected from or about each layer.  The corresponding claims can be structured in a nested fashion that reflects the nesting of the Attester's layers. </ins> The device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an updatable bootloader, and (C) an operating system

Discussion:
Based on Henk's proposal and Dave's comments.
NAME : This is a complete re-write of the paragraph which needs to be read in its entirety. I'm not sure whether a line-by-line diff is of any help? That said, if you really want I could do that easily.
Thomas Fossati wrote: It helps with the next edit that comes along.
OK, done in f778919
I don't understand what this para is supposed to communicate: Also, pick one of "nested", "staged" or "chained" and drop the rest.
For context: this is now https://ietf-rats-URL "Layered Attestation Environments" How about this as a new starting point: Effectively, I removed the last sentence, as I had a hard time to understand what it intended to add to the content here. My proposal is intended as a rework of this paragraph that goes beyond editorial changes. The current last sentence still seems a bit out of place to me.
Looks very good as a starting point. Thanks!
All good so far. This sentence can be confusing, since I think it could include claims about itself in Evidence, as admitted in your point below ("Claims can be collected from or about each layer, including roots of trust.") Disagree with "must be endorsed". Either the verifier has to trust the root of trust itself (e.g., put the root of trust's public key into its trust anchor store directly) OR must be endorsed (e.g., put the endorser's public key into the verifier's trust anchor store). Fine.
Change:
The RS must recognize value of the scope claim.  If that is not the case the RS MUST respond with a response code equivalent to the CoAP code 4.00 (Bad Request).  The RS MAY provide additional <del> information in the error response, in order to clarify what went wrong. </del> <ins> information in the error response, to clarify what went wrong. </ins> If the access token contains any other claims that the RS cannot process the RS MUST respond with a response code equivalent to the

Discussion:
Based on the review by Steffi I updated the text in Section 5.8.1.1 "Verifying an Access Token".
Change:
"key_share" or "pre_shared_key"). <del> This field will contain the lower of that suggested by the client in the ClientHello and the highest supported by the server. Servers MUST accept ClientHello versions higher than those supported.  For this version of the specification, the version is { 3, 4 }.  (See backward-compatibility for details about backward compatibility.) </del> <ins> This field contains the version of TLS negotiated for this session.  Servers MUST select the lower of the highest supported version and the version offered by the client in the ClientHello. In particular, servers MUST accept ClientHello messages with versions higher than those supported and negotiate the highest mutually supported version.  For this version of the specification, the version is { 3, 4 }.  (See backward- compatibility for details about backward compatibility.) </ins> This structure is generated by the server and MUST be generated

Discussion:
People will continue getting this wrong until the end of time, but add an extra MUST in the serverversion half on the off chance someone reads it. Also clarify that clientversion is a maximum version. ("The version of the TLS protocol by which the client wishes to communicate during this session" suggests it should be an exact match.)
Change:
ephemeral Diffie-Hellman and provides a key update function (see keyupdate) for lightweight application protocol rekeying.  Either of these provide forward secrecy, in the sense that compromise of the <del> private authentication keys does not compromise past session keys, and compromise of a session key does not compromise past session keys.  Frequently re-running EDHOC with ephemeral Diffie-Hellman forces attackers to perform dynamic key exfiltration where the attacker must have continuous interactions with the collaborator, </del> <ins> private authentication keys does not compromise past session keys (PRK_out), and compromise of a session key does not compromise past session keys.  Frequently re-running EDHOC with ephemeral Diffie- Hellman forces attackers to perform dynamic key exfiltration where the attacker must have continuous interactions with the collaborator, </ins> which is a significant complication. To limit the effect of breaches, it is important to limit the use of

Discussion:
Issue
Minor comment, but reading through all the security claims, they multiple times refer to the term (for instance in ), which is not per say completely defined. I am not even sure there is any ambiguity, but is it still worth adding somewhere that this relates to ?
Yes, I assume session key most often refer to PRK_out. Could maybe refer to the exported application keys in some sentence. Let's go through all instances and make it clear what it refers to.
Change:
[2] https://github.com/dskyberg/gnap <del> [3] https://github.com/interledger/rafiki </del> <ins> [3] https://github.com/interop-alliance/gnap-client-js [4] https://github.com/interledger/rafiki [5] https://github.com/aaronpk/gnap-client-php </ins> <del> [4] https://github.com/aaronpk/gnap-client-php </del> <ins> [6] https://github.com/SUNET/sunet-auth-server </ins> <del> [5] https://github.com/SUNET/sunet-auth-server </del> <ins> [7] https://verified.me/ </ins> <del> [6] https://github.com/bspk/oauth.xyz-java </del> <ins> [8] https://github.com/bspk/oauth.xyz-java </ins>

Discussion:
To edit notification comments on pull requests, go to your .
NAME and NAME -- please check these additions to the implementation section.
Change:
-configured HTTP proxies can provide a degree of protection against IP address tracking, and systems like virtual private networks and <del> the Tor network Dingledine2004 provide additional options for clients. </del> <ins> the Tor network DMS2004 provide additional options for clients. </ins> However, even when IP address tracking is mitigated using one of these techniques, each request needs to be on a completely new TLS

Discussion:
Dingledine2004 -> DMS2004 ODoH -> ODOH-PETS
Comment by NAME ODOH and ODoH seems very similar and likely to cause confusion. Rename one?
thanks
Comment by NAME Using "[Dingledine2004]" as description identifier for TOR is a bit weird :P
This is entirely appropriate given the nature of the reference. This is a reference to a paper, not a specification for Tor, so using "[TOR]" could be misleading. It's possible that we could cite a specification, but it's really hard to pin that down properly. URL seems right, but it doesn't bear a date and appears to be a rendering from URL which is in turn just a snapshot (currently URL). Aside from referential stability, the specification is less of a useful reference as it says less about what Tor is and gets buried in detail. I'm inclined to leave as-is, or switch to "[DMS2004]" to reference all author's names.
ok
Change:
PSK with (EC)DHE key establishment.  In this mode, the client and servers MUST supply "key_share" values as described in key-share. <del> 4.2.8. </del> <ins> 4.2.7. </ins> When a PSK is used, the client can send application data in its first flight of messages.  If the client opts to do so, it MUST supply an

Discussion:
This is how NSS behaves as well. This seems like a reasonable argument.
added the changes previously discussed.
I did not verify that the moved text is only move and no edits, but the other chunks seem okay.
NAME are you OK with this SHOULD?
Sounds reasonable. Mostly I just don't want to encourage servers to enforce anything about this.
Change:
key in the sender's end-entity certificate.  RSA signatures MUST use an RSASSA-PSS algorithm, regardless of whether RSASSA- PKCS1-v1_5 algorithms appear in "signature_algorithms".  SHA-1 <del> MUST NOT be used in any signatures in CertificateVerify.  (Note that rsa_pkcs1_sha1 and dsa_sha1, the only defined SHA-1 signature algorithms, are undefined for CertificateVerify signatures.) </del> <ins> MUST NOT be used in any signatures in CertificateVerify.  All SHA-1 signature algorithms in this specification are defined solely for use in legacy certificates, and are not valid for CertificateVerify signatures. </ins> Note: When used with non-certificate-based handshakes (e.g., PSK), the client's signature does not cover the server's certificate

Discussion:
I'm going to see about getting rid of it anyway, but I think, for the spec, this is probably the better text, as sad as it makes me. The revised signature algorithm mechanism left the {sha1, ecdsa} SignatureAndHashAlgorithm without a corresponding SignatureScheme defined at all. SHA-1 does not have a corresponding curve, so defining it alongside ecdsap256sha256 and friends was a nuisance. But omitting it, combined with other text, implicitly means it "MUST NOT be offered or negotiated by any implementation". Clients (ideally) send only one ClientHello, so this implies a constraint on TLS 1.2 as well. SHA-1 needs to go, but I think I was a tad overzealous here. I wouldn't be surprised {sha1, ecdsa} can be removed from TLS 1.2 right now. Certainly it will be much much easier to remove than {sha1, rsa}. But this is probably better a SHOULD NOT rather than a MUST NOT. We wouldn't like to discover after the fact that a MUST NOT in TLS 1.3 is untenable due to some ecosystem problem. Notably, old versions of some popular server software ignore signature algorithms and only sign SHA-1. This mostly affects RSA since ECDSA isn't that common, but any such ECDSA deployments would be affected. This is also a little odd for servers as TLS 1.2 says missing sigalgs means the client is assumed to support {sha1, X}. (Although, strictly speaking, the spec does not say the server must do anything useful with that advertisement.) In contrast, dsasha1 is already not offered by many major browsers but is merely a SHOULD NOT. Define ecdsasha1RESERVED as a companion to dsa*RESERVED to bring it out of the implicit MUST NOT. Then include it in the SHOULD NOT lists alongside rsapkcs1sha1 and dsasha1.
Change:
2.1. <ins> QUIC packets always include an AEAD authentication tag at the end. In general, the length of the AEAD tag depends on the TLS cipher suite, although all cipher suites used in QUIC v1 use a 16 byte tag. </ins> 2.2. A single qlog event trace is typically associated with a single QUIC

Discussion:
This field is not particularly useful, because it will always be 16, see URL it's a property of the TLS cipher suite in use, so it can be trivially looked up, if necessary
So this is a bit of a tough one for me, since I've gone through the pain of trying to determine the length of the TLS trailer for TLS-over-TCP from wireshark output that does NOT explicitly include the size and also makes it difficult to get the proper cipher name to heuristically determine it. That said, for QUIC V1 it's indeed all 16, so you -could- make an argument we can drop it here and add it back in with a V2.1/V3 if new ciphers start being used. I don't have a particularly big preference either way. If we do this change though, the prose could use tightening, because in the current version we have 2 sentences after another that indicate the aead_length depends on the cipher suite.
I'm leaning on the side of removing this field. The information is made redundant by the cipher suite. Things that care about the tag length can do a lookup or make their own assumptions based on other information
Discussed on call. NAME will make the requested prose change and should be good to go.
Rebased and tightened the text around the tag length.
Minus the comment above, this LGTM.
Change:
This specification defines the KeyPurposeId id-kp-documentSigning. Inclusion of this KeyPurposeId in a certificate indicates that the <del> Subject named in the certificate signed the document content, and the associated keys can be used by a document signing service or a software for authentication, message integrity, and non-repudiation of origin (using digital signatures, along with any usages allowed by other EKU values). </del> <ins> use of any Subject names in the certificate is restricted to use by a document signing service or a software (along with any usages allowed by other EKU values). </ins> 4.

Discussion:
This also made the references to RFCs 7229 and 8358 Informative references, as was approved by in PR. More importantly, neither of these refs are required for implementation. This also changes the line breaks in the .md hence it looks like a lot more changes than there really are. Done to aid readability. NAME please double check that the new formatting in s4 works. It seemed to the me that the paragraphs after "2." were part of the numbered item so I indented them. The .md will result in the following .txt: If there are restrictions set for the replying party and relying party software, proceed as following. Each Restriction on the EKUs can be "Excluded EKU" or "Permitted EKU" and handled. The procedure is intended to permit or prohibit presence of a certain EKU or complete absence of EKUs. It is outside the scope of this document, but the relying party can permit or prohibit conbinations of EKU. A consideration on prohibiting combination of EKUs is described in the security consideration section of this document. Excluded EKUs procedure: "Excluded EKU" is an EKU which the relying party or the relying party software prohibits. Examples of "Excluded EKU" are, presence of anyEKU or complete absence of EKU extension on a certificate. If an EKU of the certificate meets the conditions set by the "Excluded EKU" restriction, the relying party or the relying party software rejects the certificate. Permitted EKU procedure: "Permitted EKU" is an EKU which the relying party or the relying party software accepts. Examples of "Permitted EKU" are, presence of this general document signing EKU and/or protocol specific document signing-type EKUs. If an EKU of the certificate meets the condition set by a "Permitted EKU" restriction, the certificate is acceptable. Otherwise, relying party or the relying party software rejects the certificate. When a single software has capability to process various data formats, the software may choose to make the excluded and permitted decisions separately in accordance with the format it is handling (e.g. text, pdf, etc).

Also
Section 4: s/prohibit conbinations/xxclude combinations/ Section 4: s/anyEKU/anyExtendedKeyUsage/ Section 6: s/none-email purposes/purposes other than email/ Note the comment about the abstract was addressed via .
I-D Nits complains about: one line being too long: the 2nd line of the ASN.1 module the abstract containing a reference: [RFC5280]
approved. after building into txt, it seems same in my environment also.
Change:
A program "that extract[s] information from name servers in response to client requests."  (Quoted from RFC1034, Section 2.4) A resolver performs queries for a name, type, and class, and <del> receives answers.  The logical function is called "resolution". </del> <ins> receives responses.  The logical function is called "resolution". </ins> In practice, the term is usually referring to some specific type of resolver (some of which are defined below), and understanding the use of the term depends on understanding the context.

Discussion:
Thanks the authors for their work in making this draft. I'm going through and I noticed that the term "answer" (45 occurrences) and "response" (47 occurrences) are used interchangeably in the text. I am OK with that, but they should be explicitly defined IMHO, to avoid confusion. E.g.: if I: ` Is the response the entire DNS-layer packet(s), with all the RRs in it? (including flags,etc) Is an answer each line in both ANSWER and AUTHORITY section? Maybe this is clear to many ppl, but it would be nice to write it down. thanks
I do not believe that we have used these terms "interchangeably", since they're not. Some responses are answers and all answers are responses. Some answers contain an Answer Section and some (negative answers, for instance) do not. If that isn't clear, we perhaps ought to add text similar to that, though I thought we had some discussion of this. I didn't see it while looking on my phone just now, however. A
I have opened PR to fix the places where I think we are really talking about responses, not answers.
I think given how late this is in the draft, I'd like to suggest just adding a new bit of text rather than changing the terms, because the WG has been over this ground some. I think it'll be easier to get WG agreement on some text describing the differences without trying to pick each case. Dunno where to put it -- probably intro or something like that -- but here's a suggestion: This document is sometimes unclear on the terms "response" and "answer". The lack of clarity is partly because the DNS specifications themselves use the terms ambiguously. In general, a response is any DNS message with the QR bit set (see [forward reference here]). An answer is any response that attempts actually to answer the question posed in the corresponding query message. Not all answers are authoritative (see [forward reference here]). Some answers contain an Answer Section (see [xref?]), but not all do (such as a negative answer, [forward reference]). Some other responses are not an answer at all, such as an error response. Sorry not to submit this in the usual and proper githubby way, but I'm on vacation and jamming this in.
Closed with , but might be reopened during IESG review if needed.
Change:
3.1. JSEP does not specify a particular signaling model or state machine, <del> other than the generic need to exchange SDP media descriptions in the </del> <ins> other than the generic need to exchange session descriptions in the </ins> fashion described by RFC3264 (offer/answer) in order for both sides of the session to know how to conduct the session.  JSEP provides mechanisms to create offers and answers, as well as to apply them to

Discussion:
LGTM!
JSEP on two occasions says "SDP media description" where it seems "SDP session description" or similar would be more appropriate. "media description" seem to reference m-lines rather than the full SDP in other documents (4566, 3264).
agree - see if that pull request fixes it
to my understanding it does fix it!