jiebi/CodeConvo huggingface dataset:
Change:
Post-compromise security is provided between epochs by members regularly updating their leaf key in the ratchet tree.  Updating their leaf key prevents group secrets from continuing to be encrypted <del> to previously compromised public keys. </del> <ins> to public keys whose private keys had previously been compromised. </ins> Forward secrecy between epochs is provided by deleting private keys from past versions of the ratchet tree, as this prevents old group

Discussion:
Comment by NAME I personally don't like the underscored words in the html rendering of the document It "blank" the new American spelling of "blanc" ? I find "summarizes" a strange word here. It is not the hash contains a summary one can read. [SECG] has no IETF equivalent? Should it? proposaland -> proposal and I would say "after removing member C" (avoid ambiguity about "every third") I read this wrong the first way, the "," vanishes due to the unscores. Maybe: This section defines tree hashes, the next section defines parent hashes. Or alternatively, leave onlthe the first sentence in 8.8, then put the remainder and next section in two subsections (so 8.8.1 and 8.8.2) Maybe: For example, a malicious group member could otherwise send Maybe: to public keys whose private key was previously compromised. This reads a little odd as "new groups" would have no history and thus no previous compromise.
Filed I think it's important to emphasize the terms being defined, and this seems more readable than a definition list. Note that a hash function is often called a "message digest", in the same sense as the "Weekly github digest" that goes to the mailing list. I think referring to SECG is still pretty state-of-the-art. But apparently RFC 8446 moved on from that, so I updated to use that representation.
Change:
Each entry in the registry must include: <del> Initial entries in this sub-registry are as listed in pre-reg: </del> <ins> Initial entries in this sub-registry are as listed in pre-reg; the Column "Change Controller" always has the value "IESG" and the column "Reference" always has the value "fnex of RFCthis": </ins> 4.

Discussion:
Fixes URL NAME Any advice on how to format the table so that line length warnings are not produced (by or )?
(1) we could shorten unwieldy monsters such as or (2) we could strip the columns "Change Controller" and "Reference" and just add to the caption that the column value for all of these are "IESG" and "Section 2.6 of RFCthis".
I made a commit for (2). I'd still like to tame the type names as well..
The Function Extensions section of the IANA Considerations section should use the defined type system terminology rather than talking about "kinds", "values", and "nodelists".
Change:
3. The signature structure allows for one or more signatures to be <del> applied to a message payload.  There are provisions for there to be attributes about the content and about the signature to be carried </del> <ins> applied to a message payload.  There are provisions for attributes about the content and attributes about the signature to be carried </ins> along with the signature itself.  These attributes may be authenticated by the signature, or just present.  Examples of attributes about the content would be the type of content, when the

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:
Each endpoint independently verifies and enables use of ECN by setting the IP header ECN codepoint to ECN Capable Transport (ECT) <del> for the path from it to the other peer.  Even if ECN is not used on the path to the peer, the endpoint MUST provide feedback about ECN markings received (if accessible). </del> <ins> for the path from it to the other peer.  Even if not setting ECN codepoints on packets it transmits, the endpoint SHOULD provide feedback about ECN markings received (if accessible). </ins> To verify both that a path supports ECN and the peer can provide ECN <del> feedback, an endpoint MUST set the ECT(0) codepoint in the IP header of all outgoing packets RFC8311. </del> <ins> feedback, an endpoint sets the ECT(0) codepoint in the IP header of all outgoing packets RFC8311. </ins> If an ECT codepoint set in the IP header is not corrupted by a network device, then a received packet contains either the codepoint

Discussion:
Implementations are free to enable sending or not. 2, Implementations MAY read the ECN code points if they can and send ECN ACKs. Implementations MUST accept the 0x03 ACK type and if they are sending ECN SHOULD use the ECN section. I recognize that some people want to have stronger language here, based on this discussion I think this is where we are. I'll defer to the chairs to judge whether more is needed here and can change the PR as required.
I took the discussion to be "MAY" but obviously this is easily changed if the chairs judge consensus otherwise.
Change:
to be interpreted as in URI. The terms "node", "alias node", "anchor" and "named anchor" in this <del> document are to be intepreded as in YAML. </del> <ins> document are to be interpreted as in YAML. </ins> 1.2.

Discussion:
Fix typical media type template problems Typos
In general, LGTM. About change controller, I was waiting for the feedback from the media type mailing list.
Change:
Calling "Abort" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close". <del> 10.4. </del> <ins> Calling "CloseGroup" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all Connections in the same ConnectionGroup. Calling "AbortGroup" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all Connections in the same ConnectionGroup.  ## UDP-Lite </ins> Connectedness: Connectionless

Discussion:
So, for a multiplexing protocol (SCTP, QUIC), CloseGroup and AbortGroup has a specific meaning to treat the group vs a single connection/stream. For TCP/UDP I wrote it to be a no-op, but I can say that it affects any other connections that were cloned out? But I wonder if that might be a little weird too.
I think we need the system to treat it that way for consistency. Clearly, for a mux'ing protocol this is the obvious choice - but the application is not aware of the protocol below... so if it creates a group of TCP connections, with or without congestion control coupling, it will expect: that changing a connection property on one of the connections will affect the others (so that also must be implemented - because it WILL happen with a mux'ing protocol), that closing the group will close them all. Imagine an application getting QUIC once, and not getting it another time... surely we need a consistent behavior towards the app for both of these cases?
NAME sounds good, please check the updated text (or suggest text if you have further ideas!)
This is probably fine as is, but I suggested alternative phrasing which might be even more clear.Great, thanks!!LGTM with the updates, thanks!
Change:
how employers and volunteer organizations perform background checks. In this model, the attestation sequence is initiated by a Relying Party.  The Attester conveys Evidence to the Relying Party, which <del> does not process its payload, but realys the message and optionally check its signature against a policed trust anchor store.  Upon receiving the evidence the Relying Party initiates a session with the Verifier.  Once session is established, it forwards the received Evidence to the Verfier.  The Verifier, appraises the received Evidence according to its appraisal policy for Evidence and returns a corresponding Attestation Result to the Relying Party.  The Relying Party then checks the Attestation Result against its own appraisal policy to conclude attestation. </del> <ins> does not process its payload, but relays the message and optionally checks its signature against a policed trust anchor store.  Upon receiving the Evidence, the Relying Party initiates a session with the Verifier.  Once the session is established, it forwards the received Evidence to the Verifier.  The Verifier appraises the received Evidence according to its appraisal policy for Evidence and returns a corresponding Attestation Result to the Relying Party.  The Relying Party then checks the Attestation Result against its own appraisal policy to conclude attestation. </ins> 7.2.

Discussion:
fix some typos and optimize the newly added diagrams to adapt to the width limitation
Thanks Wei! My humongous backlog told me "you'll fix this later" and now you did. Awesome!
Change:
This token is used in the ":protocol" psuedo-header field to indicate that the endpoint wishes to use the WebTransport protocol on the new <del> stream.  If successful, the resulting stream established via the extended CONNECT handshake is referred to as a WebTransport Connect Stream, or simply a Connect Stream. </del> <ins> stream. </ins> <del> 3.2. </del> <ins> 3.4. </ins> <del> A new HTTP/2 frame called "WTHEADERS" is introduced for establishing streams in a bidirectional manner.  A stream opened by a "WTHEADERS" frame is referred to as a WebTransport Stream, and it MAY be continued by CONTINUATION and DATA frames.  WebTransport Streams can be initiated by either clients or servers via a "WTHEADERS" frame that refers to the corresponding client-initiated extended CONNECT stream on which the WebTransport protocol was negotiated. </del> <ins> Clients or servers use a WTHEADERS frame to initate a new WebTransport Stream. </ins> The WTHEADERS frame (type=0xfb) has all the fields and frame header flags defined by HEADERS frame in HEADERS RFC7540, Section 6.2.

Discussion:
Landing this now and applying subsequent comments directly to speed things up
Will file issues for the ones indicated, otherwise I made the suggested edits. Thanks for reviewing this, NAME
Change:
End IP Address of A MUST be strictly less than the Start IP Address of B. <del> If an endpoint received a ROUTE_ADVERTISEMENT capsule that does not </del> <ins> If an endpoint receives a ROUTE_ADVERTISEMENT capsule that does not </ins> meet these requirements, it MUST abort the IP proxying request stream.

Discussion:
"The ADDRESS_REQUEST capsule contains a sequence of zero or more Requested Addresses." In cases there are zero Requested Addresses what does this mean? It appears that this is an even less determined form than the all zero block , that at least indicates an address family support or preference as well as prefix length by including one or two all-zero address of the families the endpoint want assigned? Should this be explicitly stated?
Change:
5. The Privacy Pass issuance protocol is a two message protocol that <del> takes as input a challenge from the redemption protocol and produces a token, as shown in the figure below. </del> <ins> takes as input a TokenChallenge from the redemption protocol AUTHSCHEME, Section 2.1 and produces a Token AUTHSCHEME, Section 2.2, as shown in the figure below. </ins> Issuers provide a Private and Public Key, denoted skI and pkI, respectively, used to produce tokens as input to the protocol.  See

Discussion:
There's and . I'm guessing these should be collapsed to just one.
table 2 says: -- | -- and Section 8.1 says: What is the Token Type registry and what are the constraints on values in the registry? It's implied that values should be integers but JSON numbers are quite flexible, so would it be valid for me to register e.g. a negative integer. If the "Token Type" registry already exists, I'm not able to find it and a link would be useful. If it doesn't exist and this document wishes to create it, then more work is needed to establish that registry and it's procedures.
We're missing a link to the HTTP auth document, where the registry is defined. Good catch!
Change:
have each other's stateless reset token unless that key has changed in the interim. <del> The encrypte mode needs to generate different cipher text for each </del> <ins> The encrypted mode needs to generate different cipher text for each </ins> generated Connection ID instance to protect the Server ID.  To do so, at least four octets of the CID are reserved for a nonce that, if used only once, will result in unique cipher text for each Connection

Discussion:
Discuss Distinguishing Attack in security section. Fix specification of Four Passes decryption Fix number of kramdown issues.
NAME I think this simple PR is ready.
Thank you, this is perfect.
We're awaiting more data to fully understand this, but we may need to allow 4, 6, or 12 passes as configuration options.
Fixed by , but we're instead going to go with in lieu of doing this.
The analysis in the second crypto review should be in the security considerations.
I believe there is an edge case where a partially chosen plaintext is possible. 1) The load balancer is supporting both an encrypted and unencrypted config, on different codepoints, that happen to use the same server ID mapping 2) The server is generating encrypted CIDs. 3) The attacker sends an initial packet sends an unencrypted CID. 4) Any server generated CID is therefore using the unencrypted server ID as plaintext. The random nonce should generally protect us, but maybe not? Anyway, security considerations could say something like "unencrypted and encrypted CIDs MUST NOT use the same server ID assignments because...".
Fixed by
Change:
likely contain padding frames.  Endpoints can use information about their receipt as input to congestion control for that path. Applications could use information learned from probing to inform a <del> decisions to switch paths. </del> <ins> decision to switch paths. </ins> Only the client can actively migrate in version 1 of QUIC.  However, servers can indicate during the handshake that they prefer to

Discussion:
All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions.
Change:
5. <ins> The SenML mandatory to understand fields extensibility mechanism (see section 4.4 in RFC8428) does not apply to Patch Packs, i.e., unknown fields MUST NOT generate an error but such fields are treated like any other field (e.g., added to Patch target records where applicable). This specification allows only a small subset of SenML fields in Fetch Records but future specifications may enable new fields for Fetch Records and possibly also new fields for selecting targets for Patch Records. 6. </ins> The security and privacy considerations of SenML apply also with the FETCH and (i)PATCH methods.  CoAP's security mechanisms are used to provide security for the FETCH and (i)PATCH methods.

Discussion:
more details for security consideration on record names noted this applies to SenSML too updated extensibility mechanism
The CI checks fail because this PR has still year 2019 in the draft. The PR fixes that too.
Change:
size.) The "right" edge of the window represents the highest validated <del> sequence number value received on this session.  Records that contain </del> <ins> sequence number value received on the session.  Records that contain </ins> sequence numbers lower than the "left" edge of the window are rejected.  Packets falling within the window are checked against a list of received packets within the window.  An efficient means for

Discussion:
I do understand that the text is consistent with the one in , but I think that it could benefit from some rework.
Change:
RFC8839.  Note that this field does not contain an "a=" prefix, as indicated in the following example: <del> The IceCandidate object contains a field to indicate which ICE ufrag it is associated with, as defined in RFC8839.  This value is used to determine which session description (and thereby which gathering phase) this IceCandidate belongs to, which helps resolve ambiguities during ICE restarts.  If this field is absent in a received IceCandidate (perhaps when communicating with a non-JSEP endpoint), the most recently received session description is assumed. </del> <ins> The IceCandidate object contains a field to indicate which ICE username fragment (ufrag) it is associated with, as defined in RFC8839.  This value is used to determine which session description (and thereby which gathering phase) this IceCandidate belongs to, which helps resolve ambiguities during ICE restarts.  If this field is absent in a received IceCandidate (perhaps when communicating with a non-JSEP endpoint), the most recently received session description is assumed. </ins> The IceCandidate object also contains fields to indicate which "m=" section it is associated with, which can be identified in one of two

Discussion:
…or already fixed. NAME Change in normative text (previous ART AD requested it), please review.
LGTM, approved.
eom
LGTMOne minor comment.
Change:
"supported_groups" extension.  In this case the client should send a new ClientHello with a "key_share" that the EAP-TLS server supports. <del> The case of a successful EAP-TLS mutual authentication after the EAP- TLS server has sent a HelloRetryRequest message is shown in fighelloretryrequest.  Note the extra round-trip as a result of the </del> <ins> fighelloretryrequest shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication and HelloRetryRequest.  Note the extra round-trip as a result of the </ins> HelloRetryRequest. 2.1.7.

Discussion:
Some of the text describing the figures indicated that TLS 1.3 only has one possible message flow. This pull request change the text to make it is clear that the message flows are examples. Based on discussion on the List initiated by Alan.
Change:
The resource access protocol between the Attester and Relying Party includes Evidence rather than an Attestation Result, but that <del> Evidence is not processed by the Relying Party.  Since the Evidence is merely forwarded on to a trusted Verifier, any serialization format can be used for Evidence because the Relying Party does not need a parser for it.  The only requirement is that the Evidence can be _encapsulated in_ the format required by the resource access protocol between the Attester and Relying Party. </del> <ins> Evidence is not processed by the Relying Party. Since the Evidence is merely forwarded on to a trusted Verifier, any serialization format can be used for Evidence because the Relying Party does not need a parser for it.  The only requirement is that the Evidence can be _encapsulated in_ the format required by the resource access protocol between the Attester and Relying Party. </ins> However, like in the Passport model, an Attestation Result is still consumed by the Relying Party.  Code footprint and attack surface

Discussion:
related to There is something foundational I am not following about this section. The interactions described here do not conform behaviors described in the terminology in Section 4 or the high-level reference architecture of Figure 1. I'm not sure how to reconcile this discrepancy. Minimally, these discrepancies in Figure 5 and 6 are not consistent with the roles defined in Section 4. [restated here but same feedback on -13] -- Figure 5. Shows the Attester consuming Attestation Results -- Figure 5. Shows the Attester producing Attestation Results -- Figure 6: Shows Relying party consuming Evidence -- Figure 6: Shows the Relying Party producing/passing Evidence The introductory text states that "[t]he discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns." I don't follow what is being illustrated in the context of RATS. What is the takeaway for implementers or designers from this section? [Author's response] URL [Roman's response on -15] The above github comment addressed a few issues from the -13 review, but not this one.
Reply by email: "The Attester does not consume the Attestation Result, but might cache it. "
The text explains the intent correctly regardless of how the lines are drawn. I can convince myself that it is correct draw the line through the box (or not). The important clarifying point should be that the end-to-end message flow as described in the conceptual architecture is preserved through the various topology models that may exist. Second point is there can be a large variety of topology models (aka hybrids) but none of these hybrids changes the expectation of end-to-end message flow.
also helps.
Change:
A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an <del> acknowledgement.  Values of 0 and 2^24 or greater are invalid, and </del> <ins> acknowledgement.  Values of 2^24 or greater are invalid, and </ins> receipt of these values MUST be treated as a connection error of type PROTOCOL_VIOLATION.

Discussion:
I think minackdelay=0 should be allowed? It means there is no delay sending ack, which is a current behavior.
0 is equivalent to 1 as a value for the "Packet Tolerance" field I believe, so I agree that declaring it invalid seems unnecessary. Also, 0 and 1 are extremely similar given this is in microseconds, and 1 is valid.
0 and 1 are different, since 0 is immediate, and 1 involves a timer. Though, yeah, it seems silly to disallow immediate.
Change:
5.3. Several protocols allow sending higher-level protocol or application <del> data within the first packet of their protocol establishment, such as TCP Fast Open RFC7413 and TLS 1.3 RFC8446.  This approach is referred to as sending Zero-RTT (0-RTT) data.  This is a desirable property, but poses challenges to an implementation that uses racing during connection establishment. </del> <ins> data during their protocol establishment, such as TCP Fast Open RFC7413 and TLS 1.3 RFC8446.  This approach is referred to as sending Zero-RTT (0-RTT) data.  This is a desirable property, but poses challenges to an implementation that uses racing during connection establishment. The amount of data that can be sent as 0-RTT data varies by protocol and can be queried by the application using the "Maximum Message Size Concurrent with Connection Establishment" Connection Property.  An implementation can set this property according to the protocols that it will race based on the given Selection Properties when the application requests to establish a connection. </ins> If the application has 0-RTT data to send in any protocol handshakes, it needs to provide this data before the handshakes have begun.  When

Discussion:
Removed phrasing that implies 0-RTT data is just one packet and added a reference to the Maximum Message Size with Connection Establishment property. Added a sentence on how/when an implementation can set this property.
The opening para reads to me like there is just one first packet. ... or is this actually more than one packets before the handshake complete?
It is one packet for TCP, but it can be more for QUIC, TLS 1.3 (etc)
Reference Connection Property "Maximum Message Size Concurrent with Connection Establishment"
Seems like a useful addition that resolves my issue.