jiebi/CodeConvo huggingface dataset:
Change:
*RECOMMENDATION:* Select the strongest MLS Credential type available among the target members of an MLS group. <del> While the Authentication Service is often very well protected from external attackers, it might be the case that this service is compromised.  In such infrastructure, the AS could validate a (or generate a new) signature keypair for an identity which is not the expected one.  Because a user can have many MLS clients running the MLS protocol, it possibly has many signature keypairs for multiple devices.  Note that when a "basic" Credential is used, the Authentication Service also needs an out-of-band mechanism to verify the identity asserted in the Credential. With some Authentication Service designs, a private or centralized authority is trusted to validate signature keypairs used in the MLS protocol.  This is typically the case in some of the biggest messaging infrastructures. </del> <ins> If the AS is compromised, it could validate a (or generate a new) signature keypair for an attacker.  Because a user can have many MLS clients running the MLS protocol, it possibly has many signature keypairs for multiple devices.  These attacks could be very difficult to detect. *RECOMMENDATION:* Provide a key transparency mechanism for the Authentication Services to allow public verification of the credentials authenticated by this service. Note that when a "basic" Credential is used, the Authentication Service also needs an out-of-band mechanism to verify the identity asserted in the Credential. </ins> In the case where an adversarial keypair is generated for a specific identity, an infrastructure without any transparency mechanism or

Discussion:
The Section has three recommendations, but the discussion rambles. The proposed text places topics related to each recommendation before that recommendation.
Thanks!
Comment by NAME Why allow this in the MLS protocol? How can this "typically" be the case of some of the biggest messaging infrastructures? Clearly those don't run the MLS protocol? Perhaps you meant to compare a similar function to the AS in other messaging protocols? That is, I would clarify what is the issue, what is possible in MLS and how it compares to non-MLS existing deployments.
At a high level, MLS was designed to be agnostic about the authentication design, so I don't think there's much normative for MLS to say here. With that said, it seems to me that there are two practices here: A centralized/private authority. As the text says, this is very common and seems like a fairly natural design, whether we like it or not. That authority generating keys rather than signing them. That seems bad, and I guess we could discourage it, but it can't be enforceably prohibited
That was probably meant to be a comparison, yes, but this entire block has been removed through the multiple changes already made anyway. The important part was to describe things as ekr suggested which is already the case and there is already a recommendation to not design a system which generates the keys in the section about the AS.
Change:
Compared to the ACK frame specified in QUIC-TRANSPORT, the following field is added. <del> Packet Number Space Identifier: An identifier of the path packet number space, which is the sequence number of Destination Connection ID of the 1-RTT packets which are acknowledged by the ACK_MP frame. </del> <ins> The identifier of the path packet number space of the 1-RTT packets which are acknowledged by the ACK_MP frame. </ins> If an endpoint receives an ACK_MP frame with a packet number space ID which was never issued by endpoints (i.e., with a sequence number larger than the largest one advertised), it MUST treat this as a

Discussion:
Since , we now define the Path ID as (Section 1.1) And the definition of the as the field of PATHABANDON and PATHSTATUS frames directly maps to that identifier path (i.e., the sequence number of the destination Connection ID used for sending packets on that particular path, Sections 8.1 and 8.2). But in Section 6.2, the example states that I believe the current text is unclear and should be fixed. Yet, I see two possible ways of doing so. We should either state that the field of these frames refer to the Path ID used by the receiver of the frame, or add some information to indicate that it refers to the Path ID viewed from the sender's/receiver's viewpoint (that could be encoded as a bit in the frame's type)
Is there any use case for either using the sender's or receiver's ID? If not, I'd prefer we simply choose one and define it clearly.
(P.S.: I think the text in the example is just wrong. I think I messed this up in .)
IMHO it makes more sense to me to use the sender's ID by default, especially if we consider only client-initiated paths.
From PR by NAME
Looks good to me
Change:
The status of this account.  Possible values are: "valid", "deactivated", and "revoked".  The value "deactivated" should be <del> used to indicate user initiated deactivation whereas "revoked" should be used to indicate administratively initiated deactivation. </del> <ins> used to indicate client-initiated deactivation whereas "revoked" should be used to indicate server-initiated deactivation. </ins> An array of URIs that the server can use to contact the client for issues related to this account.  For example, the server may wish

Discussion:
This pull request includes changes to: Consistently use "header parameter" when referring to JWS header parameters. Insert a missing right curly bracket in a section reference. Use "server-initiated" instead of "administratively initiated" for clarity. Use parallel sentence structure for clarity/readability.
Change:
The setDirection method sets the direction of a transceiver, which affects the direction property of the associated m= section on future <del> calls to createOffer and createAnswer. </del> <ins> calls to createOffer and createAnswer.  The permitted values for direction are "recvonly", "sendrecv", "sendonly", and "inactive", mirroring the identically-named directional attributes defined in RFC4566, Section 6. </ins> When creating offers, the transceiver direction is directly reflected in the output, even for re-offers.  When creating answers, the

Discussion:
talks about setting direction properties, but the values that can be set aren't called out (and even then only by inference from a list in an example) in section 4.2.5. Should there be explicit pointers to the api doc here? (And in section 4.2.6?)
Yes, I think a pointer to the API doc is what's needed here.
The more I look at it, I think it is the SDP, not the API doc that effectively defines the allow values of the direction.
LGTM
Change:
Handshake space: All Handshake packets (packet-handshake) are in this space. <del> Application data space: All 0-RTT (packet-0rtt) and 1-RTT (short- header) encrypted packets are in this space. </del> <ins> Application data space: All 0-RTT (packet-0rtt) and 1-RTT (packet- 1rtt) encrypted packets are in this space. </ins> As described in QUIC-TLS, each packet type uses different protection keys.

Discussion:
This PR restructures 17.3 to be aligned with 17.2. Note that while the diff seems to show whole paragraphs changed in the section, all I've done is replaced with . Note that I've not replaced all uses of . I've retained it where it is used alongside , for symmetry. This still touches more text than I had hoped, but it makes the structure of Section 17 clearer.
NAME Thanks for the note. I've updated the tls doc, but I've left most uses of as they are. I've retained them for symmetry, since in all the ones I've retained, it appears alongside .
While the transport draft talks a lot about "1-RTT packets", the term is not defined. We also have a sentence that seem to imply that a long-header variant of 1-RTT packets might exist (URL). We refer to the packet less frequently as "short header packets" or "packet with a short header." As a resolution, I think we might want to change the title of section 17.3 from "Short Header Packets" to "1-RTT Packets". Rest of the text can remain the same, as the first sentence of that section says that it is the only type of short header packet that we define.
Update: I think we might want to make corresponding changes to the TLS draft. Re TLS draft, I think we can replace all the occurrences of "short header packet(s)", "packet(s) with (a) short header" in the TLS draft with "1-RTT packet(s)", as well making necessary changes to table 1.This looks good. The actual changes are much smaller than the diff appears, and I think the symmetry with 17.2 helps readability despite the extra layer.
Change:
11.3. <del> QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new connection ID in that packet and the client will retry by sending another Client Initial packet with the server-selected connection ID. This mechanism can be used to redirect a connection to a different server, e.g. due to performance reasons or when servers in a server pool are upgraded gradually, and therefore may support different versions of QUIC.  In this case, it is assumed that all servers belonging to a certain pool are served in cooperation with load balancers that forward the traffic based on the connection ID.  A server can choose the connection ID in the Server Retry packet such that the load balancer will redirect the next Client Initial packet to a different server in that pool.  Alternatively the load balancer can directly offer a Retry service as further described in QUIC-LB. </del> <ins> QUIC provides a Retry packet that can be sent by a server in response to the client Initial packet.  The server may choose a new connection ID in that packet and the client will retry by sending another client Initial packet with the server-selected connection ID.  This mechanism can be used to redirect a connection to a different server, e.g., due to performance reasons or when servers in a server pool are upgraded gradually, and therefore may support different versions of QUIC. In this case, it is assumed that all servers belonging to a certain pool are served in cooperation with load balancers that forward the traffic based on the connection ID.  A server can choose the connection ID in the Retry packet such that the load balancer will redirect the next Initial packet to a different server in that pool. Alternatively the load balancer can directly offer a Retry service as further described in QUIC-LB. </ins> Section 4 of RFC5077 describes an example approach for constructing TLS resumption tickets that can be also applied for validation

Discussion:
No real changes here, just noting that "Server Retry" isn't really a thing. Retry is, and servers use it, that's all.
Change:
3. A needs to acquire information about the of the in order to send <del> encapsulated requests.  In order to ensure that do not encapsulate </del> <ins> Encapsulated Requests.  In order to ensure that do not encapsulate </ins> messages that other entities can intercept, the MUST be authenticated and have integrity protection.

Discussion:
We weren't always capitalizing "Encapsulated Request". This does more, in direct opposition to the changes in . If we don't take that (it seems we at an impasse there), then we should at least be consistent.
NAME I resolved conflicts, but please double check the intro paragraph that had Mark's proposed changes.
Change:
or the intended Verifier roles, then the relaying entity should not expect to have access to the Evidence. <ins> 12.3. Handles, described in epochfreshness, can be tampered with, dropped, delayed and reordered by an attacker. An attacker could be either external or belong to the distribution group, for example if one of the Attester entities have been compromised. An attacker who is able to tamper with handles can potentially lock all the participants in a certain epoch of choice for ever, effectively freezing time.  This is problematic since it destroys the ability to ascertain freshness of Evidence and Attestation Results. To mitigate this threat, the transport should be at least integrity protected and provide origin authentication. Selective dropping of handles is equivalent to pinning the victim node to a past epoch.  An attacker could drop handles to only some entities and not others, which will typically result in a denial of service due to the permanent staleness of the Attestation Result or Evidence. Delaying or reordering handles is equivalent to manipulating the victim's timeline at will.  This ability could be used by a malicious actor (e.g., a compromised router) to mount a confusion attack where, for example, a Verifier is tricked into accepting Evidence coming from a past epoch as fresh, while in the meantime the Attester has been compromised. Reordering and dropping attacks are mitigated if the transport provides the ability to detect reordering and drop.  However, the delay attack described above can't be thwarted in this manner. </ins> 13. This document does not require any actions by IANA.

Discussion:
Discuss the impact that altering the distribution of handles (e.g., delaying, suppressing) has on the security of the protocol. Add relevant text to the Security Consideration section.
Is this more than just finishing ? If so, what?
The scope is different: deals with the example in the appendix, this one is for text that belongs to the security considerations. Regarding the "what": is the issue description insufficient? If so, do you have any suggestion on how to make it clearer?
Change:
validation query to a server of the attacker's choosing.  There are a few different mitigations that ACME servers can apply: <del> Checking the DNSSEC status of DNS records used in ACME validation (for zones that are DNSSEC-enabled) </del> <ins> Always querying the DNS using a DNSSEC-validating resolver (enhancing security for zones that are DNSSEC-enabled) </ins> Querying the DNS from multiple vantage points to address local attackers

Discussion:
I approve of this change.
This looks good to me. I would like to tighten up the language a bit to clarify that this applies to validation of DNS identifiers, but will do that in a follow-on PR.
Change:
A member of the group applies a Remove message by taking the following steps: <del> Identify a leaf node matching "removed".  This lookup MUST be done on the tree before any non-Remove proposals have been applied (the "old" tree in the terminology of commit), since proposals such as Update can change the LeafNode stored at a leaf.  Let L be this leaf node. </del> <ins> Identify the leaf node matching "removed".  Let L be this leaf node. </ins> Replace the leaf node L with a blank node

Discussion:
The part about doing the lookup in the old tree was added in , it was relevant here because of the hash references. This is not a problem anymore since we came back to referencing with leaf index.
Change:
take 48 octets each, and for P-521 they take 66 octets each. For the curves secp256r1, secp384r1 and secp521r1, peers MUST <del> validate each other's public value Y by ensuring that the point is a </del> <ins> validate each other's public value Q by ensuring that the point is a </ins> valid point on the elliptic curve.  The appropriate validation procedures are defined in Section 4.3.7 of X962 and alternatively in Section 5.6.2.3 of KEYAGREEMENT.  This process consists of three <del> steps: (1) verify that the point (X, Y) is not the point at infinity (O), (2) verify that both X and Y are integers in the correct interval, (3) ensure that (X, Y) is a correct solution to the elliptic curve equation.  For these curves, implementors do not need </del> <ins> steps: (1) verify that Q is not the point at infinity (O), (2) verify that for Q = (x, y) both integers x and y are in the correct interval, (3) ensure that (x, y) is a correct solution to the elliptic curve equation.  For these curves, implementers do not need </ins> to verify membership in the correct subgroup. For X25519 and X448, the contents of the public value are the byte

Discussion:
I might do "both integers x and y" but I can see how it would be okay as-is.
Change:
5.8. As described in ratchet-tree-updates, each MLS message needs to <del> transmit node values along the direct path from a leaf to the root. The path contains a public key for the leaf node, and a public key and encrypted secret value for intermediate nodes in the path.  In both cases, the path is ordered from the leaf to the root; each node MUST be the parent of its predecessor. </del> <ins> transmit node values along the direct path of a leaf.  The path contains a public key for the leaf node, and a public key and encrypted secret value for intermediate nodes in the path.  In both cases, the path is ordered from the leaf to the root; each node MUST be the parent of its predecessor. </ins> The length of the "node_secrets" vector MUST be zero for the first node in the path.  For the remaining elements in the vector, the

Discussion:
The very first commit from PR (6ba86ff561484a9eb96012e3b55b49f23cb8f9e9) was removed and a separate Issue is filled for unifying the use of "`" and "_".
We inconsistently use the backtick, the underscore or nothing for messages fields or specific operations in the draft. This needs a fix, currently the opinion is to use the TLS style (aka remove everything)
Change:
accordingly.  Note that more than one connection ID can be associated with a connection; see connection-id. <del> If the Destination Connection ID is zero length and the packet matches the local address and port of a connection where the endpoint used zero-length connection IDs, QUIC processes the packet as part of that connection. </del> <ins> If the Destination Connection ID is zero length and the addressing information in the packet matches the addressing information the endpoint uses to identify a connection with a zero-length connection ID, QUIC processes the packet as part of that connection.  An endpoint can use just destination IP and port or both source and destination addresses for identification, though this makes connections fragile as described in connection-id. </ins> Endpoints can send a Stateless Reset (stateless-reset) for any packets that cannot be attributed to an existing connection.  A

Discussion:
Make the rules on matching packets to connections consistent with our existing advice on use of zero-length connection IDs. cc NAME for review
: : If only the local address is used, the described multiplexing is impossible. Multiplexing zero-length connection IDs is useful for reducing overhead when remote clients are known to not use the described features, so I think this language should be updated to refer to the 4-tuple rather than only the local connection.
I don't think that these are completely inconsistent, though there is an unstated section in those quotes from Section 5.2: that the implementation has followed the advice and provided a unique local address where it uses a zero-length connection ID. This needs a little care, but we could just remove "local" and this would be OK, but it's probably best to be a little less crude.
I think literally "the packet matches the address and port of a connection" would be much too vague, particularly due to the singular forms used.
Thanks!
Change:
carried in an X.509 certificate, it MUST use the RSASSA-PSS OID RFC5756.  When used in certificate signatures, the algorithm parameters MUST be DER encoded.  If the corresponding public key's <del> parameters present, then the parameters in the signature MUST be identical to those in the public key. </del> <ins> parameters are present, then the parameters in the signature MUST be identical to those in the public key. </ins> Indicates algorithms which are being deprecated because they use algorithms with known weaknesses, specifically SHA-1 which is used

Discussion:
NAME I did not: 1) add the "Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS " reference because it's already in the [JSS15] reference that's later in the sentence. 2) I also didn't made [AEAD-LIMITS] normative.
Change:
the decoder limits and constraints is used to specify its minimum and maximum x= and y= values.  If the intersection is the null set, i.e., there are no resolutions that are permitted by both the decoder and <del> the mandatory constraints, this SHOULD be represented by x=0 and y=0 </del> <ins> the mandatory constraints, this MUST be represented by x=0 and y=0 </ins> values. The rules here express a single set of preferences, and therefore,

Discussion:
Section 3.6.1 "no resolutions .. SHOULD be represented by x=0 and y=0 values". Is there any reason not to make this a MUST?
Makes sense.
+1
Change:
IANA is also to add the following note: <del> 11. </del> <ins> 12. </ins> IANA is to add the following entry to the TLS Alert Registry (the entry was omitted from the IANA instructions in RFC7301): <del> 12. </del> <ins> 13. </ins> To make it clear that (D)TLS 1.3 has orphaned certain extensions (i.e., they are only applicable to version of (D)TLS prior to 1.3), IANA is to add the following to the TLS ExtensionType Values registry: <del> 13. </del> <ins> 14. </ins> To make it clear that (D)TLS 1.3 has orphaned certain registries (i.e., they are only applicable to version of (D)TLS protocol

Discussion:
"Supported Groups" also needed a "Recommended" column.
NAME We've also got FF DHE groups in this registry. Got a feeling for which should be "Yes"?
Much like the ciphers we need to add a "recommended" column for curves/groups. Adding this column was suggested during review of 4492bis.
Change:
standardized media-relevant information to the CDNs while they are fetching data.  CTA-5004 was developed exactly for this purpose. <del> 4.5. </del> <ins> 4.6. </ins> In contrast to segmented delivery, several applications use unreliable UDP or SCTP with its "partial reliability" extension

Discussion:
This is in existing text, but I'd put a paragraph break after "Some receive-side ABR algorithms such as {{ELASTIC}} are designed to try to avoid this effect." and before "Another way to mitigate this effect is by the help of two simultaneous TCP connections, as explained in {{MMSys11}} for Microsoft Smooth Streaming. In some cases, the system-level TCP slow-start restart can also be disabled, for example as described in {{OReilly-HPBN}}."
Works for me. Updated...
The editors are 2:1 in favor of dropping ECN. Spencer is graciously in the rough. We should be talking more broadly about what happens when you lose any packets, If ECN belongs in the draft, it belongs somewhere else. "Coming improvements in transport behaviors" more broadly - we're talking about BBR and about end-to-end transport encryption now. Maybe we should talk about things like edge computing, etc ... but NAME will talk to the working group about this before we start a major refactor.
The point of these sections (4.3.1 Idle Time Between Segments and 4.3.2 Head of Line Blocking) was to explain how and why your bandwidth measurements can go wrong when you're trying to do ABR things with your bandwidth measurements. By name this seems like perhaps a better fit in the 4.4 Measurement Collection section, there might be a reason to merge some of the discussion there or reorganize the 2 sections together.
We maybe should also add a section along these lines on the wide variability in bitrates as things move, both for wi-fi and LTE and 5g. (or paths in general, with those as examples?)
Note also: "Refactor" here means provide a coherent story for why your ABR measurements can go wrong and what you can do about it.
Change:
In this document, the semantics of a JSONPath query define the required results and do not prescribe the internal workings of an <del> implementation. </del> <ins> implementation.  This document may describe semantics in a procedural step-by-step fashion, but such descriptions are normative only in the sense that any implementation MUST produce an identical result, but not in the sense that implementors are required to use the same algorithms. </ins> The semantics are that a valid query is executed against a value, the

Discussion:
Signed-off-by: Tim Bray Nothing fancy here, just like the title says.
LGTM, thanks.