jiebi/CodeConvo huggingface dataset:
Change:
For example: <ins> When a single-bit field is referenced in prose, the position of that field can be clarified by using the value of the byte that carries the field with the field's value set.  For example, the value 0x80 could be used to refer to the single-bit field in the most significant bit of the byte, such as One-bit Field in fig-ex-format. </ins> 2. Streams in QUIC provide a lightweight, ordered byte-stream

Discussion:
are encoded as variable-length integers; see Section 16. A QUIC endpoint MUST NOT reuse a stream ID within a connection. This was a common problem throughout the text. I found the use of (0x1) and similar confusing in the text. Where you use this notation you mean the bit manipulated by the mask 0x1 (and similar). It would be helpful to the reader to be a little more pedantic in the use of the term in each case. We will get to it later, in the comments but a lot of readers would be helped by the use of the classic ASCII art style representation of bit fields.
slightly more text
Change:
coerce an aggregator into diverting from the protocol specified (e.g., by divulging its input shares to the attacker). <del> In the presence of this adversary, DAP aims to achieve the following high-level secure aggregation goals: Privacy.  Clients trust that some aggregator is honest.  That is, as long as at least one aggregator executes the protocol faithfully, the parties learn nothing beyond the aggregate result (i.e., the output of the aggregation function computed over the honest measurements). Correctness.  The collector trusts that the aggregators execute the protocol correctly.  That is, as long as the aggregators execute the protocol faithfully, a malicious client can skew the aggregate result only by reporting a false (untruthful) measurement.  The result cannot be influenced in any other way. </del> <ins> In the presence of this adversary, DAP aims to achieve the privacy and robustness security goals described in VDAF's Security Considerations section. </ins> Currently, the specification does not achieve these goals.  In particular, there are several open issues that need to be addressed

Discussion:
NAME let's squash-then-merge this change.
contains a nice definition and discussion of the notions of privacy (meaning protecting any individual client's measurement from being seen) and robustness (meaning that the aggregates delivered to a collector are accurate aggregations over the inputs). DAP's security considerations has definitions of privacy and correctness, and we refer to robustness and soundness in a few places. We should align our definitions with VDAF (or just refer to VDAF's definitions) and consistently use the term "robustness" throughout DAP.
PR, please!
I'm going to get this done for draft-02, hopefully early next week.
Change:
Decode the payload of the JWS as UTF-8 encoded JSON Verify that there are exactly three fields in the decoded object, <del> and that: * The "type" field is set to "proofOfPossession" * The </del> <ins> and that: * The "type" field is set to "proof-of-possession" * The </ins> "identifier" field contains the identifier for which authorization is being validated * The "accountKey" field matches the account key for which the challenge was issued

Discussion:
awesome thanks :+1:
Any reason for the inconsistent naming of the challenge types? Specifically vs Wouldn't it make sense to stick to dash delimited words? or just camelCase, not that it matter as long as its consistent. I would personally avoid camelcase in that context since there is already a lot acronyms.
Change:
Because DTLS records could be reordered, a record from epoch M may be received after epoch N (where N > M) has begun.  In general, <del> implementations SHOULD discard packets from earlier epochs, but if </del> <ins> implementations SHOULD discard records from earlier epochs, but if </ins> packet loss causes noticeable problems implementations MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP RFC0793 to allow for packet reordering.  (Note that

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:
Remove the authentiction tag for encryption algorithms as a separate item. <ins> Remove the flattened mode of encoding.  Forcing the use of an array of recipients at all times forces the message size to be two bytes larger, but one gets a corresponding decrease in the implementation size that should compenstate for this. </ins> 1.2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Discussion:
Following discussions on the mailing list. Removing the ability to have flattened encoding for signers and recipients.
Closes issue
JOSE now allows for a single recipient to be encoded at the same level as the content. While COSE does not allow for quite the same way of encoding this it would be possible to do something similar. Current syntax is "recipients : COSEencrypta null;" Do so would allow for a single recipient to be appended to the end of the current array of values rather than creating two array sub-encodings in CBOR. This encoding saves 2 bytes in the event of a single recipient at the expense of needing to pass in an offset in the array structure when parsing it. Not really that hard to do from a programmers point of view.
Open for group discussion
Based on the messages, there seems to be no support for combining the two maps together into a single map. I have therefore removed that from my working copy of the draft. There was one request for allowing option b (where a single recipient can be represented as a single map entry rather than as an array of a single map). I have looked at code size, and there does not seem to be a lot of code associated with this option, but as there was no outcry for this option I have not included it. Unless others have opinions that they believe need to be expressed, I am closing this issue.
Change:
descendants -- uniquely defined by a relative path -- is tested against a boolean expression "boolean-expr". <del> The current item is selected if and only if the result is "true". </del> <ins> The current item is selected if and only if the boolean expression yields true. </ins> Paths in filter expressions are Singular Paths, each of which selects at most one node.

Discussion:
Fixes URL
Let's continue in URL
Currently the syntax section of the "Filter Selector" section describes some semantics. These descriptions should be folded into the semantics section.
I'm not sure we are done with this yet. See comments.The reordering looks good to me.
Change:
A server that sends large responses to unauthenticated peers SHOULD mitigate amplification attacks such as described in Section 11.3 of RFC7252 (where an attacker would put a victim's <del> address in the source address of a CoAP request).  The RECOMMENDED way to do this is to ask a client to Echo its request to verify its source address.  This needs to be done only once per peer and limits the range of potential victims from the general Internet to endpoints that have been previously in contact with the server. For this application, the Echo option can be used in messages that are not integrity protected, for example during discovery. </del> <ins> address in the source address of a CoAP request).  A new way to do this is to ask a client to Echo its request to verify its source address.  This needs to be done only once per peer and limits the range of potential victims from the general Internet to endpoints that have been previously in contact with the server.  For this application, the Echo option can be used in messages that are not integrity protected, for example during discovery. </ins> In the presence of a proxy, a server will not be able to distinguish different origin client endpoints.  Following from

Discussion:
I think it make sense to make a subsection
This is only mentioned in Abstract and intro. I think it need there needs to be some text in the body as well. The other Update has it's own subsection. "4.2. Updated Token Processing Requirements for Clients"
I added text on server requirements in
updated with one more commit: Shorten amplification-mitigateion-recommendation paragraph, align text The "RECOMMENDED" wording is removed from the description of the mechanism (it was under-explained there, the new section does it right, and there's no need to make readers wonder about updating at this point) Reference updated simplified (we're already talking about server side in the paragraph) Comment about moving text here removed, and replaced with a more precise reference I've toyed with moved text, but it rips the use cases up to the point where we'd have to re-do all the items as subsections for consistency. ... and merging (comments still appreciated, but I need the branches consolidated for futher editing)
(... and that comment should have gone to ... anyway)
Some reformulations in febc426. I think this is ready to close.
Has long been ready, and recently gotten a more explicit cross-reference too.
Change:
The first byte in the SFrame header has a fixed format and contains the header metadata: <del> Reserved (R): 1 bit This field MUST be set to zero on sending, and MUST be ignored by receivers.  Counter Length (LEN): 3 bits This field indicates the length of the CTR field in bytes, minus one (the range of possible values is thus 1-8).  Extended Key Id Flag (X): 1 bit Indicates if the key field contains the key id or the key length. Key or Key Length: 3 bits This field contains the key id (KID) if the X flag is set to 0, or the key length (KLEN) if set to 1. If X flag is 0 then the KID is in the range of 0-7 and the counter </del> <ins> This field MUST be set to zero on sending, and MUST be ignored by receivers. This field indicates the length of the CTR field in bytes, minus one (the range of possible values is thus 1-8). Indicates if the key field contains the key id or the key length. This field contains the key id (KID) if the X flag is set to 0, or the key length (KLEN) if set to 1. If X flag is 0, then the KID is in the range of 0-7 and the counter </ins> (CTR) is found in the next LEN bytes: <del> if X flag is 1 then KLEN is the length of the key (KID).  The KID is </del> <ins> If X flag is 1 then KLEN is the length of the key (KID).  The KID is </ins> encoded in the KLEN bytes following the metadata byte, and the counter (CTR) is encoded in the next LEN bytes:

Discussion:
This PR addresses a few outstanding formatting cleanup issues: Fixes the list formatting problems identified in ... as well as a few others Wraps paragraphs to 80 columns
Merging on my own since these are just formatting changes.
This : ... is probably not a single paragraph. Similar problems and . It might be worth a more thorough proof-read of the document for others similar formatting problems.
Change:
endpoint and the certification authority can create limitations.  For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the <del> certification authority.  This document describes a mechanism by which operators may delegate their own credentials for use in (D)TLS, without breaking compatibility with peers that do not support this specification. </del> <ins> certification authority.  This document describes a mechanism to to overcome some of these limitations by enabling operators to delegate their own credentials for use in (D)TLS without breaking compatibility with peers that do not support this specification. </ins> 1.

Discussion:
Editorial changes from AD review.
Modulo adding the hyphen in between the I and the D (my bad) to make sure we get a normative reference to DTLS 1.3. This is good to go.
Change:
HTTP/3 does not use server-initiated bidirectional streams, though an extension could define a use for these streams.  Clients MUST treat receipt of a server-initiated bidirectional stream as a connection <del> error of type HTTP_GENERAL_PROTOCOL_ERROR unless such an extension has been negotiated. </del> <ins> error of type HTTP_STREAM_CREATION_ERROR unless such an extension has been negotiated. </ins> 6.2.

Discussion:
There are presently several kinds of very similar error when creating streams: HTTPUNKNOWNSTREAMTYPE MAY be used to tell a peer to STOPSENDING on a stream type that is unknown by the local peer. It is not a connection error. HTTPWRONGSTREAMCOUNT MUST be used if a peer tries to open more than one critical stream (control, QPACK). Connection error. HTTPWRONGSTREAMDIRECTION MUST be used if a client tries to open a push stream. More generally this could be used if a peer attempts to open a stream type that is not allowed to, but push is the only example today. Connection error. The suggestion is to rationalize these into a single error code - HTTPSTREAMCREATIONERROR - that can be used in STOPSENDING or CLOSECONNECTION. The impact of merging COUNT and DIRECTION is minimal because implementations fundamentally have to open streams correctly in order to interop. PS. The eagle eyes will notice I omitted the HTTPDUPLICATE_PUSH creation error. This is on the chopping block in . I class it differently because it is about parsing information after the stream type.
Should a client respond with STREAMCREATIONERROR when it sees the server opening a bidirectional stream? At the moment the designated error code is HTTPGENERALPROTOCOLERROR, but STREAMCREATIONERROR might be a better fit. Or if we are not going to use STREAMCREATIONERROR for server-initiated bidirectional streams, I think we should better rename it to UNIDIRECTIONALSTREAMCREATIONERROR to avoid confusion.
This relates to some earlier discussion on URL and its now-merged PR URL We only recently added text to specify the use of HTTPGENERALPROTOCOLERROR in this case, I think it fits to modify this to STREAMCREATION_ERROR.
Changed in URL
Change:
protection for all 0-RTT packets because the same key and nonce could be used to protect different content. <del> Receiving a Retry packet, especially a Retry that changes the connection ID used for subsequent packets, indicates a strong possibility that 0-RTT packets could be lost.  A client only receives acknowledgments for its 0-RTT packets once the handshake is complete. Consequently, a server might expect 0-RTT packets to start with a packet number of 0.  Therefore, in determining the length of the packet number encoding for 0-RTT packets, a client MUST assume that all packets up to the current packet number are in flight, starting from a packet number of 0.  Thus, 0-RTT packets could need to use a longer packet number encoding. </del> <ins> A client only receives acknowledgments for its 0-RTT packets once the handshake is complete.  Consequently, a server might expect 0-RTT packets to start with a packet number of 0.  Therefore, in determining the length of the packet number encoding for 0-RTT packets, a client MUST assume that all packets up to the current packet number are in flight, starting from a packet number of 0. Thus, 0-RTT packets could need to use a longer packet number encoding. </ins> A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets from the server.  This means that 0-RTT packets cannot

Discussion:
Retry always changes the connection ID.
NAME The paragraph 2 before this one says exactly that.
Ah... I missed that. Thanks for pointing it out NAME
Change:
12.4. As noted in trustmodel, Verifiers and Relying Parties have trust <del> anchor stores that must be secured.  Specifically, a trust anchor </del> <ins> anchor stores that must be secured.  RFC6024 contains more discussion of trust anchor store requirements.  Specifically, a trust anchor </ins> store must resist modification against unauthorized insertion, deletion, and modification.

Discussion:
Section 12.4. Is there any read sensitivity for the trust anchor store? Section 12.4. Since RFC5280 is being invoked here, is there an expectation that certificates in RATS would confirm to this profile?
-> "For example, see Section 6 of [RFC5280]" Discussion ensued about whether there is read sensitivity vs audit requirements, and whether this is even specific to RATS at all.
RFC6024 URL ?
"As noted in Section 7, Verifiers and Relying Parties have trust anchor stores that must be secured. RFC6024 contains more discussion of trust anchor store requirements."
Change:
7.2.2. <del> The Key Phase bit update process for QUIC v1 is specified in </del> <ins> The Key Phase bit update process for QUIC version 1 is specified in </ins> Section 6 of QUIC-TLS.  The general principles of key update are not <del> changed in this specification.  Following QUIC v1, the Key Phase bit is used to indicate which packet protection keys are used to protect the packet.  The Key Phase bit is toggled to signal each subsequent key update.  Because of network delays, packets protected with the older key might arrive later than the packets protected with the new key.  Therefore, the endpoint needs to retain old packet keys to allow these delayed packets to be processed and it must distinguish between the new key and the old key.  In QUIC V1, this is done using packet numbers so that the rule is made simple: Use the older key if packet number is lower than any packet number frame the current key phase. </del> <ins> changed in this specification.  Following QUIC version 1, the Key Phase bit is used to indicate which packet protection keys are used to protect the packet.  The Key Phase bit is toggled to signal each subsequent key update.  Because of network delays, packets protected with the older key might arrive later than the packets protected with the new key.  Therefore, the endpoint needs to retain old packet keys to allow these delayed packets to be processed and it must distinguish between the new key and the old key.  In QUIC version 1, this is done using packet numbers so that the rule is made simple: Use the older key if packet number is lower than any packet number frame the current key phase. </ins> When using multiple packet number spaces on different paths, some care is needed when initiating the Key Update process, as different

Discussion:
Be consistent with RFC9000
In order to be consistent with RFC9000, use "QUIC version 1" instead of "QUIC v1" through the document.
Change:
document) and an abstract protocol MLSPROTO for providing end-to-end security in this setting.  MLS is not intended as a full instant messaging protocol but rather is intended to be embedded in a <del> concrete protocol such as XMPP RFC3920.  In addition, it does not </del> <ins> concrete protocol such as XMPP RFC6120.  In addition, it does not </ins> specify a complete wire encoding, but rather a set of abstract data structures which can then be mapped onto a variety of concrete encodings, such as TLS I-D.ietf-tls-tls13, CBOR RFC7049, and JSON

Discussion:
Change reference to XMPP to the current RFC. Change heading of "Deniability" section, which also discusses non-repudiation, to "Non-Repudiation and Deniability". I wondered if that latter section should note that a third-party (ie, non-Member) cannot identify a sender from a given encrypted message, but then I wondered if that was the case or not.
Thanks NAME !
Change:
The size of the dynamic table is the sum of the size of its entries. The size of an entry is the sum of its name's length in bytes, its <del> value's length in bytes, and 32.  The size of an entry is calculated using the length of its name and value without Huffman encoding applied. </del> <ins> value's length in bytes, and 32 additional bytes.  The size of an entry is calculated using the length of its name and value without Huffman encoding applied. </ins> 3.2.2.

Discussion:
I opted to reframe the language from HTTP/3 endpoint to decoder, since encoder and decoder instances are what this spec primarily talks about. We already say that HTTP/3 endpoints contain both an encoder and a decoder. I also added a comment that encoders track the contents of the table at the decoder. I specifically did not say that they keep a full copy of the table, however; they might not.
NAME said:
NAME said:
Change:
The values "token_input" and "blinded_element" are stored locally and used later as described in private-finalize.  The Client then generates an HTTP POST request to send to the Issuer, with the <del> TokenRequest as the body.  The media type for this request is </del> <ins> TokenRequest as the content.  The media type for this request is </ins> "application/private-token-request".  An example request is shown below.

Discussion:
... I think. I'm double checking to see if there is any other improper HTTP usage.
The Issuance protocol depends on HTTP, so I'd expect this to be cited. Then we get into the HTTP terminology alignment game. For example, where the document says something like should be substituted for as per URL
Change:
which it points to communicate local network policies. The Captive Portal Enforcement function MAY send Captive Portal <del> Signals when disallowed User Equipment attempts to send to the network.  These signals MUST be rate-limited to a configurable rate. </del> <ins> Signals when User Equipment that has not satisfied the Captive Portal Conditions attempts to send traffic to the network.  These signals MUST be rate-limited to a configurable rate. </ins> The signals MUST NOT be sent to the destinations/peers that the User Equipment is restricted from accessing.  The indications are only to

Discussion:
Happy to elaborate on them if the motivation is not clear from the changes, let me know!
Thanks NAME b1dc7ba4e26ab17ed12d8a5a2408fe8063b1177a accepts the suggestion. 509d855e5ddba7dd1c5db58646c85516d0b40987 corrects the mistake I had made, which your question was about.
Looks great. Thanks for the PR!
Change:
figure below compares the message flows for these two mechanisms with TLS 1.3 I-D.ietf-tls-tls13. <del> These two classes of mechanism can be complementary.  A server could use credentials for clients that support them, while using LURK to </del> <ins> These two mechanisms can be complementary.  A server could use credentials for clients that support them, while using LURK to </ins> support legacy clients. It is possible to address the short-lived certificate concerns above

Discussion:
This suggests some minor changes to the draft, the goal being to clarify the text without changing any semantics. Most are minor, but one of the commits changes the way the client verification procedure is presented.
thanks a lot for the fixes, I like all of these changes