jiebi/CodeConvo huggingface dataset:
Change:
a comparison using the operator "==" yields true if and only if the comparison is between: <del> values of the same primitive type (numbers, strings, booleans, and "null") which are equal, </del> <ins> equal primitive values, </ins> equal arrays, that is arrays of the same length where each element of the first array is equal to the corresponding

Discussion:
JSON types are not used much in the JSON spec. It is debatable whether there really is a boolean type or simply the values and . Also, the JSONPath spec doesn't really benefit from this term.
I think this reads well without breaking any semantics.
Change:
and stream types (iana-stream-types). Implementations MUST ignore unknown or unsupported values in all <del> extensible protocol elements.  Implementations MUST discard frames and abort reading on unidirectional streams that have unknown or </del> <ins> extensible protocol elements.  Implementations MUST discard data or abort reading on unidirectional streams that have unknown or </ins> unsupported types.  This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation.  However, where a known frame type is required to be in

Discussion:
NAME observed a seeming conflict in the requirements around unknown unidirectional stream types. Section 9 says: This has two problems. First and editorial, if the type is unknown/unsupported, the presence of frames can't be determined. This should refer to discarding any data, not frames specifically. Second, it appears to disagree with Section 6.2: I think the intent was MUST abort, but MAY pick an error code. Looking at the history of the commits in Section 6.2, it was first MUST abort, then SHOULD use a particular code, then became MAY use the specific code with the prohibition on blowing up the whole connection. The text should clarify the scope of the MAY.
Agree. This change would meet the intent of the text and is editorial. So it the proposal here something like:
I think I'd say "MUST either abort reading of the stream or discard incoming data without further processing. If reading is aborted, the recipient SHOULD use...."
That would work for me too, care to make a PR?
Closed in .
LGTM thank you
Change:
KeyShareEntry for any group not indicated in the "supported_groups" extension and MUST NOT send a KeyShareEntry when using the "psk_ke" PskKeyExchangeMode.  If a HelloRetryRequest was received by the <del> client, the client MUST verify that the selected NamedGroup matches one that the client sent in its supported_groups extension and MUST abort the handshake with an "illegal_parameter" alert otherwise. </del> <ins> client, the client MUST verify that the selected NamedGroup in the ServerHello is the same as that in the HelloRetryRequest.  If this check fails, the client MUST abort the handshake with an "illegal_parameter" alert. </ins> 4.2.5.1.

Discussion:
client to implement because it knows what hash the server will select. Also clarify the language about HRR and Key Shares.
NAME is this what you had in mind?
I did consider bogus binders, but dropping seems more sensible, and it seems like the only impact of the bogus binder would be that if the server didn't follow a consistent rule, then you would get a handshake failure at the server. It's not like it could pick them in any case.
(Agreed. This version feels way less weird.)
NAME comments welcome
Change:
If an endpoint receives a QUIC packet without an ECT or CE codepoint in the IP packet header, it responds per processing-and-ack with an <del> ACK frame without increasing any ECN counts.  Similarly, if an endpoint does not have access to received ECN codepoints, it does not increase ECN counts. </del> <ins> ACK frame without increasing any ECN counts.  if an endpoint does not implement ECN support or does not have access to received ECN codepoints, it does not increase ECN counts. </ins> Coalesced packets (see packet-coalesce) mean that several packets can share the same IP header.  The ECN counter for the ECN 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:
Compute the transcript hash TH_3 = H(TH_2, PLAINTEXT_2, CRED_R) where H() is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_3 is a CBOR encoded bstr and the <del> input to the hash function is a CBOR Sequence.  Note that H(TH_2, PLAINTEXT_2) can be computed and cached already in the processing of message_2. </del> <ins> input to the hash function is a CBOR Sequence.  Note that TH_3 can be computed and cached already in the processing of message_2. </ins> Compute MAC_3 as in expand, with context_3 = << ID_CRED_I, TH_3, CRED_I, ? EAD_3 >>

Discussion:
This note needs to be updated. The sentence is a remnant since TH3 was defined as H(TH2, PLAINTEXT_2)
Change:
7.1. <del> When an implementation receives a partial flight, it SHOULD generate an ACK that covers the messages from that flight which it has received so far.  Implementations have some discretion about when to generate ACKs, but it is RECOMMENDED that they do so under two circumstances: </del> <ins> When an implementation detects a disruption in the receipt of the current incoming flight, it SHOULD generate an ACK that covers the messages from that flight which it has received and processed so far. Implementations have some discretion about which events to treat as signs of disruption, but it is RECOMMENDED that they generate ACKs under two circumstances: </ins> When they receive a message or fragment which is out of order, either because it is not the next expected message or because it <del> is not the next piece of the current message.  Implementations MUST NOT send ACKs for handshake messages which they discard as out-of-order, because otherwise those messages will not be retransmitted. </del> <ins> is not the next piece of the current message. </ins> When they have received part of a flight and do not immediately receive the rest of the flight (which may be in the same UDP

Discussion:
In response to feedback on the mailing list (URL), this PR attempts to clarify (a) when to generate ACKs, and (b) which records to ACK.
This is much clearer to me. I see that you have removed the sentence I was having a problem with in the bullet: "Implementations MUST NOT send ACKs for handshake messages which they discard as out-of-order, because otherwise those messages will not be retransmitted"; logically, I believe you have captured this better by adding "and processed" above in "The ACK message is used by an endpoint to indicate which handshake records it has received and processed from the other side."
NAME Thank you for your feedback! I have removed the sentence because its content is already implied by what's stated in the previous section . See the commit description of URL
NAME thanks. This sensibly improves readability and clarity. Hi Hanno, Thank you for your clarifications. The example you gave helps a lot. I believe I now understand the text as written in this bullet (first bullet, not second--my bad). I no longer think it needs re-wording. Best regards, Jonathan Hanno Becker wrote:
Change:
how to contact it. In order to present users with the payment or AUP pages, presently a <del> captive-portal enforcement device has to intercept the user's </del> <ins> captive portal enforcement device has to intercept the user's </ins> connections and redirect the user to a captive portal server, using methods that are very similar to man-in-the-middle (MITM) attacks. As increasing focus is placed on security, and end nodes adopt a more

Discussion:
2 typos, and normalize the usage of hyphens (captive-portal vs captive portal). We use no hyphen (to match arch doc), except when referring to the option (to match the registry...) [Gahforthe_hyphens a87eb8d] 2 typos, and normalize the usage of hyphens (captive-portal vs captive portal). We use no hyphen (to match arch doc), except when referring to the option (to match the registry...)
Change:
IANA is rquested to add a new row to the "COSE Algorithms" registry. <ins> The capabilities column for this registration is to be empty. </ins> 10.3. IANA is requested to modify the description to "Public Key" for the line with "Key Type" of 2 and the "Name" of "x".  See x-table- ec1-keys which has been modified with this change. <ins> IANA is requested to update the references in the table from RFC8152 to [[This Document]]. </ins> 11. There are a number of security considerations that need to be taken

Discussion:
Add in response for IANA review on all documents SecDir review by Nancy on -algs GenArt review on -struct
Change:
Alternatively, an attacker could start a GNAP request with a known and trusted AS but include their own attack site URL as the callback <del> for the "finish" method.  The attacker would then send the </del> <ins> for the redirect "finish" method.  The attacker would then send the </ins> interaction "start" URL to the victim and get them to click on it. Since the URL is at the known AS, the victim is inclined to do so. The victim will then be prompted to approve the attacker's

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: ba30f871d34a7516b6402d161b2c9a5924eafe68 Inspect the deploy log: Browse the preview:
If the client instance can cause the AS to fetch a URL, especially if that URL is dynamic, this can be used as a means to make the AS call URLs within its own protected domain and cause errors. Will need to be addressed in new security considerations paragraph.
Change:
advance the preparation state of each report being aggregated.  This message is defined as follows: <del> The contents are the PPM task ID, the aggregation job ID, and the sequence of Transition messages corresponding to the report sequence being aggregated.  The sequences MUST have the same order. </del> <ins> The message consists of a sequence of Transition messages corresponding to the report sequence being aggregated.  The sequences MUST have the same order. </ins> Let "[aggregator]" denote the helper's API endpoint.  The leader sends a POST request to "[aggregator]/aggregate" with an Aggregate message of type "agg_cont_req" with payload AggregateContinueReq. After verifying the authentication tag as described in aggregate- <del> message-auth, the helper processes the AggregateContinueReq as follows.  It first scans "AggregateContinueReq.seq" to check for any reports that may have been dropped by the leader in the previous step. </del> <ins> message-auth, the helper begins by scanning "AggregateContinueReq.seq" to check for any reports that may have been dropped by the leader in the previous step. </ins> Next, the helper processes the Transition messages from the leader. <del> If any leader Transition contains an unrecognized nonce, the Helper sends a Transition with "tran_type = failed" and "TransitionError = unrecognized-nonce".  [CP: It may be better to go to abort rather than just fail, since this s tentamount to sending a malformed aggregate request.]  If any Transition appears out-of-order, the helper MUST abort with error "unrecognizedMessage". </del> <ins> If any message appears out of order or has an unrecognized nonce, or if any two messages have the same nonce, then the helper MUST abort with error "unrecognizedMessage". </ins> <del> Next, it constructs a transition as described in prep-helper.  If any state transition results in INVALID, the helper MUST abort with error "unrecognizedMessage". </del> <ins> Next, the helper processes each Transition as described in prep- helper.  If any state transition results in INVALID, the helper MUST abort with error "unrecognizedMessage". </ins> Next, the helper constructs an AggregateResp containing its next <del> flight of Transition messages and it updated state.  The messages </del> <ins> flight of Transition messages and its updated state.  The messages </ins> MUST appear in the same order as "AggregateContinueReq.seq".  The helper's response is an HTTP 200 OK whose body is the AggregateResp. <ins> The leader processes this message as described in aggregate-init- request. </ins> 4.4.4.3.

Discussion:
Minor changes/clarifications: Clarify how to handle empty Transition sequences Handle repeated nonces by aborting. While at it, this changes how the helper handles unrecognized nonces to be consistent with how the leader handles unrecognized nonces. Move task/job ID to top of AggregateReq
Change:
of allowed, currently open, and currently used streams when determining how to map data to streams. <del> QUIC assigns a numerical identifier to each stream, called the Stream </del> <ins> QUIC assigns a numerical identifier to each stream, called the stream </ins> ID.  While the relationship between these identifiers and stream types is clearly defined in version 1 of QUIC, future versions might change this relationship for various reasons.  QUIC implementations should expose the properties of each stream (which endpoint initiated the stream, whether the stream is unidirectional or bidirectional, <del> the Stream ID used for the stream); applications should query for these properties rather than attempting to infer them from the Stream </del> <ins> the stream ID used for the stream); applications should query for these properties rather than attempting to infer them from the stream </ins> ID. The method of allocating stream identifiers to streams opened by the application might vary between transport implementations.  Therefore, an application should not assume a particular stream ID will be assigned to a stream that has not yet been allocated.  For example, <del> HTTP/3 uses Stream IDs to refer to streams that have already been opened, but makes no assumptions about future Stream IDs or the way </del> <ins> HTTP/3 uses stream IDs to refer to streams that have already been opened, but makes no assumptions about future stream IDs or the way </ins> in which they are assigned Section 6 of QUIC-HTTP). 4.1.

Discussion:
This is the editorial convention we adopted for connection ID and what the RFC editor correctly inferred also.
Change:
the following sliding window procedure, borrowed from Section 3.4.3 of RFC4303. <del> The received packet counter for a session MUST be initialized to zero </del> <ins> The received record counter for a session MUST be initialized to zero </ins> when that session is established.  For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received during the lifetime of the session.  This check SHOULD happen after <del> deprotecting the packet; otherwise the packet discard might itself </del> <ins> deprotecting the record; otherwise the record discard might itself </ins> serve as a timing channel for the record number.  Note that decompressing the records number is still a potential timing channel for the record number, though a less powerful one than whether it was

Discussion:
NAME
I think that the older versions of the spec were good at using the term "datagram" to refer to the thing that holds DTLS records. This version now uses "packet" in a good number of places. Sometimes I think that it means "record", other times "datagram". I'm sure that this is just the influence of QUIC and it can be fixed easily.
Actually 6357 uses "packet" all over the place. I'll do an audit, but I'm not going to ones that mean IP packet.
Change:
from an RS, this can be used to derive information about the resources being protected without releasing the resources themselves. <del> 9.  References </del> <ins> 8.  References </ins> <del> 9.1.  URIs </del> <ins> 8.1.  URIs </ins> [1] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/115 [2] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/117 [3] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/116 <del> [4] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/118 </del>

Discussion:
See also related PR at ietf-wg-gnap/gnap-core-protocol
Deploy preview for gnap-resource-servers-editors-draft ready! Built with commit ec0063ea1a01f824c05137ecaaf8c7760dfee083 https://deploy-preview-26--gnap-resource-servers-editors-URL
Following the review I checked this PR too, seems fine
Change:
this authentication scheme. This authentication scheme is intended for use by an application <del> server when using the webpush protocol I-D.ietf-webpush-protocol, but it could be used in other contexts if applicable. </del> <ins> server when using the Web Push protocol I-D.ietf-webpush-protocol, but it could be used in other contexts if applicable. </ins> 4.

Discussion:
attn: NAME
Thanks !
From NAME authenticated with VAPID, all subsequent subscribe, unsubscribe, ack or monitor requests associated with the same pushset MUST be authenticated with VAPID with same public key" already needs to have code to handle EC for the e2e encryption. The main concern is an attacker 'acking' or unsubscribing - since the messages are e2e encrypted they can't read it.
This looks good to me.
Change:
10. <ins> QUIC assumes that all packets of a QUIC connection or at least with the same 5-tuple {dest addr, source addr, protocol, dest port, source port} will receive similar network treatment as feedback about loss or delay of each packet is used as input to the congestion controller.  Therefore it is not recommended to use different DiffServ Code Points (DSCPs) RFC2475 for packets belonging to the same connection.  If differential network treatment, e.g. by the use of different DSCPs, is desired, multiple QUIC connections to the same server may be used.  However, in general it is recommended to minimize the number of QUIC connections to the same server, to avoid increased overheads and, more importantly, competing congestion control. 11. </ins> Versioning in QUIC may change the protocol's behavior completely, except for the meaning of a few header fields that have been declared to be invariant QUIC-INVARIANTS.  A version of QUIC with a higher

Discussion:
(hopefully)
okay, next try. Moved some text to applicability and rewrote stuff in manageability... please review again...
Discussion in closed PR
Change:
4.3. smoothed_rtt is an exponentially-weighted moving average of an <del> endpoint's RTT samples, and rttvar is the endpoint's estimated variance in the RTT samples. </del> <ins> endpoint's RTT samples, and rttvar is the variation in the RTT samples, estimated using a mean variation. </ins> The calculation of smoothed_rtt uses path latency after adjusting RTT samples for ACK delays.  For packets sent in the ApplicationData

Discussion:
It's a mean deviation. This has confused at least one reader.
True-ish, but nor is smoothed_rtt a mean. And now you have a variable with a name that bears no semblance to the concept you use to describe it. You could instead play apologist and explain that this isn't a variance in the statistical sense, but variance in a purely colloquial sense.
Section 2 of RFC2988 says "To compute the current RTO, a TCP sender maintains two state variables, SRTT (smoothed round-trip time) and RTTVAR (round-trip time variation)." It does subsequently use the term variance in one spot, but given the original definition is a better one, I'd rather use variation than variance. RFC6298 does the exact same thing, and defines RTTVAR as "round-trip time variation".
In both sentences, minrtt and smoothedrtt are described in technically accurate terms, so I think it makes sense to describe rttvar as a mean deviation, because that's the most technically accurate term. I also understand the need for consistency, so if you have suggestions on how to improve that without removing the technical description, it'd be appreciated.
Change:
provisioned to the clients within a group.  If proposals with these sender IDs are to be accepted within a group, the members of the group MUST be provisioned by the application with a mapping between <del> these IDs and authorized signing keys.  To ensure consistent handling of external proposals, the application MUST ensure that the members of a group have the same mapping and apply the same policies to external proposals. </del> <ins> these IDs and authorized signing keys.  Recipients MUST verify that the MLSPlaintext carrying the Proposal message is validly signed with the corresponding key.  To ensure consistent handling of external proposals, the application MUST ensure that the members of a group have the same mapping and apply the same policies to external proposals. </ins> An external proposal MUST be sent as an MLSPlaintext object, since the sender will not have the keys necessary to construct an

Discussion:
This stuck out to me while reading because verification is explicitly specified for the 'newmember' sender type in the paragraph above this and not for the 'preconfigured' sender type. I think it would be better to specify this as the verification flow is different for these external proposals i.e. the KeyPackage in the proposal is used for newmember sender types, and the key corresponding to an authorized sender is used for preconfigured senders.
Change:
for an excessive time or having to promptly reestablish a path after a spurious estimate of path abandonment by the client. <ins> 3.3. fig-path-states shows the states that an endpoint's path can have. In non-final states, hosts have to track the following information. Associated 4-tuple: The tuple (source IP, source port, destination IP, destination port) used by the endhost to send packets over the path. Associated Destination Connection ID: The Connection ID used to send packets over the path. If multiple packet number spaces are used over the connection, hosts MUST also track the following information. Path Packet Number Space: The endpoint maintains a separate packet number for sending and receiving packets over this path.  Packet number considerations described in QUIC-TRANSPORT apply within the given path. In the "Active" state, hosts MUST also track the following information. Associated Source Connection ID: The Connection ID used to receive packets over the path. A path in the "Validating" state performs path validation as described in Section 8.2 of QUIC-TRANSPORT.  An endhost should not send non-probing frames on a path in "Validating" state, as it has no guarantee that packets will actually reach the peer. The endhost can use all the paths in the "Active" state, provided that the congestion control and flow control currently allow sending of new data on a path. In the "Closing" state, the endhost SHOULD NOT send packets on this path anymore, as there is no guarantee that the peer can still map the packets to the connection.  The endhost SHOULD wait for the acknowledgment of the PATH_ABANDONED frame before moving the path to the "Closed" state to ensure a graceful termination of the path. When a path reaches the "Closed" state, the endhost releases all the path's associated resources.  Consequently, the endhost is not able to send nor receive packets on this path anymore. </ins> 4. Senders MUST manage per-path congestion status, and MUST NOT send

Discussion:
Initial attempt to solve .
One more editorial comment: This section is now somehow in the middle between the cc section and the packet scheduling section. I think it would be better to have this new section as a subsection of section 3 (on Path Setup and Removal).
Indeed, let me fix that.
Given that paths are initiating/validating/active/closed, it looks like we will need at some point to specify some path state (finite state machine?) and what behavior is acceptable in each of them (e.g., we cannot send packets on a closed state,...).
Can you create a PR?