jiebi/CodeConvo huggingface dataset:
Change:
If so, then the Aggregator MUST mark the input share as invalid with error "unrecognized_message". <ins> Check if the ExtensionType of any two extensions in PlaintextInputShare is the same.  If so, then the Aggregator MUST mark the input share as invalid with error "unrecognized_message". </ins> Finally, if an Aggregator cannot determine if an input share is <del> valid. it MUST mark the input share as invalid with error </del> <ins> valid, it MUST mark the input share as invalid with error </ins> "report_dropped".  This situation arises if, for example, the Aggregator has evicted from long-term storage the state required to perform the check.  (See reducing-storage-requirements for

Discussion:
Based on (merge that first).
As noted by NAME in URL, we need to decide how to handle duplicate extensions. One simple idea is to treat duplicate extensions as decoding failures, i.e., abort with "unrecognizedMessage".
Change:
The access requested for a given object when using these fields is the cross-product of all fields of the object.  That is to say, the object represents a request for all "action" values listed within the <del> object to be used at all "locations" values listed within the object </del> <ins> object to be used at all "location" values listed within the object </ins> for all "datatype" values listed within the object.  Assuming the request above was granted, the client instance could assume that it would be able to do a "read" action against the "images" on the first

Discussion:
Minor typos
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit b2ce64bfa924bc30b24ea9301223156ec0eb8520 https://deploy-preview-204--gnap-core-protocol-editors-URL
within (and likely other sections), the property names are plural, but the text sometimes refers to the singular property names. This should be cleaned up to be consistent one way or another.
Change:
The Source and Destination Connection ID fields are the primary means of protection against an off-path attack during the handshake; see validate-handshake.  These are required to match those set by a peer. <del> Except for Initial and Stateless Reset packets, an endpoint only </del> <ins> Except for Initial packets and Stateless Resets, an endpoint only </ins> accepts packets that include a Destination Connection ID field that matches a value the endpoint previously chose.  This is the only protection offered for Version Negotiation packets.

Discussion:
Individual commits break this down, but this is all fairly prosaic stuff..
Thanks for clarifying and for fixing the one awkward case.
Change:
TBD. <ins> While the negotiated limit on the dynamic table size accounts for much of the memory that can be consumed by a QPACK implementation, data which cannot be immediately sent due to flow control is not affected by this limit.  Implementations should limit the size of unsent data, especially on the decoder stream where flexibility to choose what to send is limited.  Possible responses to an excess of unsent data might include limiting the ability of the peer to open new streams, reading only from the encoder stream, or closing the connection. </ins> 8. 8.1.

Discussion:
with some text in the TBD Security Considerations section.
If I understand correctly, the decoder stream buffer which endpoint has to keep grows indefinitely if encoder-side app does not return back flow control credit. The number of Header Acknowledgement instruction is bounded by the number of max blocked streams which decoder can specify. On the other hand, the number of Stream Cancellation is not bounded. So if encoder-side app keeps resetting stream without sending MAXSTREAMDATA, decoder-side has to keep all closed stream in decoder stream. I'm not sure this has been discussed already.
The solution to this seems implementation-dependent, but implementations should place a bound on the amount of data waiting to be sent on the decoder stream.
Hypothetically, this limit would create a way to force the peer to kill the connection by starving the decoder stream of flow control credit and then cancelling lots of streams. However, the consumer of (and therefore the entity which could fail to read) the decoder stream is the encoder, and the encoder can trivially cause the connection to close by emitting an invalid instruction anyway. That seems fine.
NAME writes: This is incorrect: an for each header that references the dynamic table.
Change:
following primitives: o A hash function This is used for the Key derivation and frame <del> hashes for signture.  We recommend using SHA256 hash function. </del> <ins> hashes for signature.  We recommend using SHA256 hash function. </ins> o An AEAD encryption algorithm [RFC5116] While any AEAD algorithm can be used to encrypt the frame, we recommend using algorithms with safe

Discussion:
Rewrite the Key management section Add MLS subsection Update the SFrame format Fixed typos
Change:
"challenge", which contains a base64url-encoded RFC4648 TokenChallenge value.  Since the length of the challenge is not fixed, the base64url value MUST include padding.  As an <del> Authentication Parameter ("auth-param" from RFC9110), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters.  This challenge value MUST be unique for every 401 HTTP response to prevent replay attacks.  This attribute is required for all challenges. </del> <ins> Authentication Parameter ("auth-param" from RFC9110, Section 11.2), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters.  This challenge value MUST be unique for every 401 HTTP response to prevent replay attacks. This attribute is required for all challenges. </ins> "token-key", which contains a base64url encoding of the public key for use with the issuance protocol indicated by the challenge. Since the length of the key is not fixed, the base64url value MUST include padding.  As an Authentication Parameter ("auth-param" <del> from RFC9110), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters.  This attribute MAY be omitted in deployments where clients are able to retrieve the issuer key using an out-of-band mechanism. </del> <ins> from RFC9110, Section 11.2), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters.  This attribute MAY be omitted in deployments where clients are able to retrieve the issuer key using an out-of-band mechanism. </ins> "max-age", an optional attribute that consists of the number of seconds for which the challenge will be accepted by the origin.

Discussion:
Previously, the document linked to RFC 7235, whose whole purpose was to discuss HTTP Authentication. Now you kjust link to RFC 9110, which all of HTTP semantics. Suggest that you link to Section 11 of RFC 9110 to make the reader's life easier.
Change:
server_id = server_id_intermediate ^ AES-ECB(key, padded-nonce) <ins> For example, if the nonce length is 10 octets and the server ID length is 2 octets, the connection ID can be as small as 13 octets. The load balancer uses the the second through eleventh octets of the connection ID for the nonce, zero-pads it to 16 octets, uses xors the result with the twelfth and thirteenth octet.  The result is padded with 14 octets of zeros and encrypted to obtain a mask that is xored with the nonce octets.  Finally, the nonce octets are padded with six octets of zeros, encrypted, and the first two octets xored with the server ID octets to obtain the actual server ID. </ins> This three-pass algorithm is a simplified version of the FFX <del> algorithm.  It has the same connection ID length requirements as the Stream Cipher CID Algorithm, with the additional property that each encrypted nonce value depends on all server ID bits, and each encrypted server ID bit depends on all nonce bits and all server ID bits.  This mitigates attacks against stream ciphers in which attackers simply flip encrypted server-ID bits. </del> <ins> algorithm, with the property that each encrypted nonce value depends on all server ID bits, and each encrypted server ID bit depends on all nonce bits and all server ID bits.  This mitigates attacks against stream ciphers in which attackers simply flip encrypted server-ID bits. </ins> The output of the decryption is the server ID that the load balancer uses for routing. <del> 4.4.3. </del> <ins> 4.3.3. </ins> When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the

Discussion:
Although more complex, the three-pass algorithm seems strictly better.
I like it, but there is some imprecision in the text. I would like to see something about detecting corruption, probably in the load balancer actions.
Change:
addressed to: (1) the final destination (the RAL node that is the target (tgt)), (2) the "root", or (3) the 6LR parent of a RUL. <del> In cases where no IPv6-in-IPv6 header is needed, the column states as "No".  If the IPv6-in-IPv6 header is needed, the column shows "must". </del> <ins> In cases where no IPv6-in-IPv6 header is needed, the column states "No", and the destination is N/A (Not Applicable).  If the IPv6-in- IPv6 header is needed, the column shows "must". </ins> In all cases, the RPI is needed, since it identifies inconsistencies (loops) in the routing topology.  In general, the RH3 is not needed because it is not used in storing mode.  However, there is one scenario (from the root to the RUL in SM) where the RH3 can be used <del> to indicate the RUL (Storing-root2notrplnoIPIP). </del> <ins> to point at the RUL (Storing-root2notrplnoIPIP). </ins> The leaf can be a router 6LR or a host, both indicated as 6LN.  The root refers to the 6LBR (see fig_CommonTopology).

Discussion:
This covers the text from the beginning up to Section 7.2.1. These were reviewed with Pascal on March 26th. I will continue my review from Section 7.2.2 forward. More trivial editorial suggestions to follow, as well.
Many thanks for these fixs.
Change:
ppm-urn-space).  Clients SHOULD display the "detail" field of all errors.  The "instance" value MUST be the endpoint to which the request was targeted.  The problem document MUST also include a <del> "taskid" member which contains the associated PPM task ID, encoded in Base 64 using the URL and filename safe alphabet with no padding as defined in sections 5 and 3.2 of RFC4648 (this value is always known, see task-configuration). </del> <ins> "taskid" member which contains the associated PPM task ID (this value is always known, see task-configuration), encoded in Base 64 using the URL and filename safe alphabet with no padding defined in sections 5 and 3.2 of RFC4648. </ins> In the remainder of this document, we use the tokens in the table above to refer to error types, rather than the full URNs.  For

Discussion:
Defines more error types to represent various failure modes, updates protocol text to indicate when the new error types should be used, and affirms that the task ID should be encoded as base64url with no padding (since task ID has a fixed size).
NAME observes that we have an awkward MUST requirement on leaders buffering received reports: URL
We have some error codes like that aren't enumerated in the table in . We should bring that table up to date. While we're in there, I think and aren't the right types, since outdatedness or staleness aren't the only reasons that an HPKE config or report, respectively, could be rejected.
The error table was brought up to date by .
Looks great!
Change:
purposes of the Transport Services API, these are ways for applications or application frameworks to define their own Message parsing to be included within a Connection's Protocol Stack.  As an <del> example, TLS is exposed as a protocol natively supported by the Transport Services API, even though it could also serve the purpose of framing data over TCP. </del> <ins> example, TLS is exposed as a protocol that is natively supported by the Transport Services API, even though it could also serve the purpose of framing data over TCP. </ins> Most Message Framers fall into one of two categories:

Discussion:
replace DG by CL. Changed one oddity: /as to/ to /about/
"Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite))": I think the criterion is not Datagram transports but "transports without a handshake" or "connectionless protocols" as it is used later in the document.
I wrote, and I suggest we use "connectionless protocols" explicitly mentioning examples of UDP and UDP-Lite when used as a transport without a handshake.
To whoever plans to address this: I checked occurrences of the word "datagram" in the architecture and API drafts, and I found (only) one sentence that needs fixing on similar grounds, I think, in the API draft: in Section 8.1.4 "Timeout for keep alive packets". Surely the guidance regarding this matter in the UDP usage RFC is related to the fact that UDP(-Lite) is connectionless, not that it's datagram based.
Starting to fix this.
This LGTM
Change:
construct the RTP packets and encrypts it using SRTP keys for the outer encryption to the media server. <del> 3.2.4. </del> <ins> 3.3.3. </ins> The receiving clients buffer all packets that belongs to the same frame using the frame beginning and ending marks in the generic RTP

Discussion:
Add SFrame payload format including the signature block Move Ciphersuites at the end Refer to the KeyId field in the decryption section
Change:
The second form considers authentication with respect to the sender, meaning the group members can verify that a message originated from a particular member of the group.  This property is provided by digital <del> signatures on the messages under identity keys. </del> <ins> signatures on the messages under signature keys. </ins> 14.3.

Discussion:
The public key in a credential is introduced without a special name and the field in the BasicCredential is currently called public_key, which is not very expressive. A few paragraphs below, it is referenced as "Identity Key" or simply "Identity", which is a bit misleading, as Credentials are supposed to contain an additional "identity" which is not the key. I propose we clear up the terminology a bit here and refer to the public key contained in a Credential as "Signature Key".
Change:
This message does not include the TLS record layer and is therefore not encrypted with a handshake key. <del> This message is used to define the parameters in a request for an authenticator. </del> <ins> The CertificateRequest is used to define the parameters in a request for an authenticator.  The definition for TLS 1.3 is: </ins> An opaque string which identifies the certificate request and which will be echoed in the authenticator message.  The

Discussion:
There are lots of changes here. I did stage this as separate commits to some extent, so feel free to cherry-pick. There is one maybe-technical change here. It wasn't clear about the precedence between handshake and authenticator request for extensions. I've chosen to be clear about this and say that if the authenticator request exists, then it is the only thing that matters. That's 8c0b166. I can drop that from the CL and do that separately if you prefer.
Thanks for the comments. The technical clarification you made is the correct one, the request supersedes the handshake for extension choices if present.
Change:
Implementations MUST NOT implement DTLS renegotiation and MUST reject it with a "no_renegotiation" alert if offered. <ins> Endpoints MUST NOT implement TLS False Start RFC7918. </ins> The API MUST generate a new authentication key pair for every new call by default.  This is intended to allow for unlinkability.

Discussion:
Address . Wasn't sure if we should reject the connection. NAME PTAL
This was entirely motivated by ekr's issue. Just trying to move this one along.
We should prohibit false start.
Why? (Sean in the PT said "because of ekr's issue", but I can't see what the issue is here)
Because the DTLS-SRTP cipher negotiation is not protected until the Finished.
That is covered by the false start RFC adequately in my view.
Which section do you believe covers it?
Well, I guess that URL covers cipher negotiation, but I would concede that it's probably more mechanical and less about the underlying principles.
Yes, and so consider the case where you are negotiating both double and regular SRTP....
Ugh. You have convinced me :) Prohibit it. And we should maybe say why.
I tend to agree that we should include a reason in .
Why make this prohibition? The description in RFC 7918 covers most of the reasons you might choose not to false start, is there anything in that set that motivates this? I mean, clients doing false start only do so if they aren't concerned about the implications of downgrade for the parameters that are (apparently) negotiated.
Change:
WHIP endpoints and media servers MAY not be colocated on the same server so it is possible to load balance incoming requests to different media servers.  WHIP clients SHALL support HTTP redirection <del> via 307 Temporary Redirect response code. </del> <ins> via the 307 Temporary Redirect response code. </ins> <del> In case of high load, the WHIP endpoints may return a 503 (Service </del> <ins> In case of high load, the WHIP endpoints MAY return a 503 (Service </ins> Unavailable) status code indicating that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay.

Discussion:
I gave the spec a good read through and would like to propose some minor language edits as my first contribution. Most of these are straight forward such as: WebRTC not webrtc URI not uri signaling not signalling offer/answer not O/A some grammatical changes There is one somewhat significant correction here in that the header on the example WHIP endpoint reply pointed at the RFC for the extension. I believe this is incorrect and the intent is that this points at a WHIP resource. I have updated the example as such.
Change:
A Retry packet uses a long packet header with a type value of 0x3. It carries an address validation token created by the server.  It is <del> used by a server that wishes to perform a stateless retry (see validate-handshake). </del> <ins> used by a server that wishes to perform a retry (see validate- handshake). </ins> A Retry packet (shown in retry-format) does not contain any protected fields.  In addition to the long header, it contains these additional

Discussion:
ekr says there used to be stateless and stateful retry, but now there is just stateless. This is the only place the phrase is used, so instead just say "retry".
Change:
Even when the bandwidth requirements for video streams along a path are well understood, additional analysis is required to understand <del> the constraints on bandwidth at various points in the network.  This analysis is necessary because media servers may react to bandwidth constraints using two independent feedback loops: </del> <ins> the constraints on bandwidth at various points along the path between media servers and media players.  Video streams can encounter bottlenecks at many points along a path, whether the bottleneck happens at a node or at a path segment along the path, and these bottlenecks may involve a lack of processing power, buffering capacity, link speed, or any other exhaustible resource. Media servers may react to bandwidth constraints using two independent feedback loops: </ins> Media servers often respond to application-level feedback from the media player that indicates a bottleneck somewhere along the path

Discussion:
From NAME -
NAME - after thinking about this comment, I think two things need to happen - your observation about bottlenecks at different nodes/hops/layers of the protocol stack belongs at the beginning of this section, because we're drilling down on ONE layer of the protocol stack in the rest of section 3.2, and as you say, the reference to "link" is not helpful here. Please let me know if URL is responsive to this comment.
Change:
request, and therefore not stored at the RS. This specification RECOMMENDS that an RS stores only one token per <del> proof-of-possession key, meaning that an additional token linked to the same key will overwrite any existing token at the RS.  The reason is that this greatly simplifies (constrained) implementations, with </del> <ins> proof-of-possession key.  This means that an additional token linked to the same key will supersede any existing token at the RS, by replacing the corresponding authorization information.  The reason is that this greatly simplifies (constrained) implementations, with </ins> respect to required storage and resolving a request to the applicable token.

Discussion:
Feedback from implementers: Section 5.10.1 of the ACE framework uses the term "overwrite" "This specification RECOMMENDS that an RS stores only one token per proof-of-possession key, meaning that an additional token linked to the same key will overwrite any existing token at the RS. The reason is that this greatly simplifies (constrained) implementations, with respect to required storage and resolving a request to the applicable token." and this is mirrored in the OSCORE profile. However, this is not strictly an overwrite of a token because some information in the original token needs to be kept. For example, if the client requests new access rights only using the kid as reference, and the corresponding access token overwrites the original token, then information about the actual key would be lost. Proposed reformulation: "This specification RECOMMENDS that an RS stores only one token per proof-of-possession key. This means that an additional token linked to the same key will supersede any existing token at the RS, by replacing the corresponding authorization information. The reason is that ..."