jiebi/CodeConvo huggingface dataset:
Change:
group are identified by a "external" or "new_member" SenderType in MLSPlaintext. <del> ReInit proposals can also be sent to the group by a "external" </del> <ins> ReInit proposals can also be sent to the group by an "external" </ins> sender, for example to enforce a changed policy regarding MLS version or ciphersuite.

Discussion:
In first paragraph, the "Ratchet Tree Evolution" Section states that whenever a member initiates an epoch change, they refresh the key pair in their leaves, etc. This is not the case for partial commits, where the epoch is advanced without a key update and without achieving PCS.
Change:
12.1.1. <del> It is assumed that the Attester is located in an isolated environment of a device like a process, a dedicated chip a TEE or such that collects the Claims, formats them and signs them with an Attestation Key. The Attester must be protected from unauthorized modification to ensure it behaves correctly.  There must also be confidentiality so that the signing key is not captured and used elsewhere to forge evidence. </del> <ins> It is assumed that an Attesting Environment is sufficiently isolated from the Target Environment it collects Claims for and signs them with an Attestation Key, so that the Target Environment cannot forge Evidence about itself.  Such an isolated environment might be provided by a process, a dedicated chip, a TEE, a virtual machine, or another secure mode of operation.  The Attesting Environment must be protected from unauthorized modification to ensure it behaves correctly.  There must also be confidentiality so that the signing key is not captured and used elsewhere to forge Evidence. </ins> In many cases the user or owner of the device must not be able to modify or exfiltrate keys from the Attesting Environment of the

Discussion:
Signed-off-by: Dave Thaler
"It is assumed that the Attester is located in an isolated environment of a device like a process, a dedicated chip a TEE or such that collects the Claims, formats them and signs them with an Attestation Key." The grammar seems off to me. Should be: "It is assumed that the Attester is located in an isolated environment of a device such as; a process, a dedicated chip, a TEE, a virtual machine, a secure mode of operation or other forms of domain isolation that allows collection of Claims from the target environment where the target environment cannot lie or interfere with the claims collection function. Additionally, the Attester formats collected Claims and integrity protects them with an Attestation Key that also is domain isolated such that the target environment or some other entity other than the Attester is not able to undermine the Attester's protections"
Change:
For Connections that are Established or Closing: Transport Properties that the application specified on the Preconnection. Selection Properties indicate whether or not the Connection has or <del> offers a certain Selection Property, see selection-props </del> <ins> offers a certain Selection Property, see selection-props. </ins> The actually instantiated protocol stack might not match all Protocol Selection Properties that the application specified on the Preconnection.  For example, a certain Protocol Selection

Discussion:
In response to ... This moves the discussion of protocol instances into bullet 4, and the properties (mainly selection) into bullet 5. It does not intend to change any text, and is intended to avoid what appeared to be overlap.
Resolved issue following MW review
I do not understand the relationship between bullets four and five. They seem to overlap?
NAME : Anna, is this resolved by this PR: Re-group managing properties & protocol instances ?
LGTM, but note that I marked a nit (missing full stop).
Change:
Diffie-Hellman DH parameters for both clients and servers are encoded in the opaque key_exchange field of a KeyShareEntry in a KeyShare structure.  The opaque value contains the Diffie-Hellman public value <del> (dh_Y = g^X mod p), encoded as a big-endian integer, padded with zeros to the size of p. </del> <ins> (Y = g^X mod p), encoded as a big-endian integer, padded with zeros to the size of p. </ins> Note: For a given Diffie-Hellman group, the padding results in all public keys having the same length. <del> %%% Key Exchange Messages opaque dh_Y<1..2^16-1>; </del> 6.3.2.3.2. ECDHE parameters for both clients and servers are encoded in the the opaque key_exchange field of a KeyShareEntry in a KeyShare structure. <del> The opaque value conveys the Elliptic Curve Diffie-Hellman public value (ecdh_Y) represented as a byte string ECPoint.point. %%% Key Exchange Messages opaque point <1..2^8-1>; For secp256r1, secp384r1 and secp521r1, this is the byte string representation of an elliptic curve point following the conversion routine in Section 4.3.6 of ANSI X9.62 X962.  For x25519 and x448, this is raw opaque octet-string representation of point (in the format those functions use), 32 octets for x25519 and 56 octets for x448. </del> <ins> For secp256r1, secp384r1 and secp521r1, the contents are the byte string representation of an elliptic curve public value following the conversion routine in Section 4.3.6 of ANSI X9.62 X962. </ins> Although X9.62 supports multiple point formats, any given curve MUST specify only a single point format.  All curves currently specified in this document MUST only be used with the uncompressed point format (the format for all ECDH functions is considered uncompressed). <ins> For x25519 and x448, the contents are the byte string inputs and outputs of the corresponding functions defined in RFC7748, 32 bytes for x25519 and 56 bytes for x448. </ins> Note: Versions of TLS prior to 1.3 permitted point negotiation; TLS 1.3 removes this feature in favor of a single point format for each curve.

Discussion:
(Let me know if you think this is sufficiently non-trivial that it deserves a mailing list posting. It is a wire format change, but I think a fairly boring one.) Only the outer length prefix is necessary, not the inner one. Named groups can just as easily take a byte string with known length rather than need to parse fields out. This is consistent with the definition of DigitallySigned.signature; the signature is an opaque field which is passed as a byte string into the corresponding signature algorithm. The definition of rsapsssha256 does not define an inner u16 length prefix. It simply takes the opaque byte string and passes it into the rsapsssha256 function. (In fact, this change means KeyShareEntry and DigitallySigned structures exactly parallel.) This also fixes some references to non-existent structures like ECPoint and dh_Yc. (Those seem to be remnants of TLS 1.2.)
Change:
as specified in I-D.ietf-mmusic-sctp-sdp, Section 6, and the value stored.  Otherwise, use the specified default. <del> As required by RFC4566, Section 5.13, unknown attribute lines MUST be </del> <ins> Other attributes that are not relevant to JSEP may also be present, and implementations SHOULD process any that they recognize.  As required by RFC4566, Section 5.13, unknown attribute lines MUST be </ins> ignored. 5.7.3.

Discussion:
Not sure I love what I have done here.
Section 5.7.2 should include a statement (probably at the end) that implementations may know and process attributes other than those described in this section.
Section Media Section Parsing Text As required by [RFC4566], Section 5.13, unknown attribute lines MUST be ignored. proposal update that text to say something about OK to process things are known but not specified in JSEP.
Change:
6.1. <del> The client sends the NS query to a pre-configured resolver that is external to the network, over a secure transport.  Clients SHOULD apply whatever acceptance rules they would otherwise apply when using this resolver (e.g. checking the AD bit, validating RRSIGs). </del> <ins> This method applies only if the client is already configured with a default resolution strategy that sends queries to a resolver outside of the network over a secure transport.  That resolution strategy is considered "tamperproof" because any actor who could modify the NS response could already modify all of the user's other DNS responses. To ensure that this assumption holds, clients MUST NOT relax the acceptance rules they would otherwise apply when using this resolver. For example, if the client would check the AD bit or validate RRSIGs locally when using this resolver, it must also do so when resolving NS records for this purpose. </ins> 6.2.

Discussion:
From Paul Wouters: From Michael Richardson:
Do you think this is a client configuration that we should reasonably expect? It seems to me that that behavior would be quite strange, although it is permissible. I think it's probably clearer for our examples to represent common configurations.
NAME Can we discuss it separately? This PR is for changes in response to feedback in the ADD adoption thread. Do you approve of this PR for that purpose? Perhaps you can open a new PR if you would like to add more example text.
Yes, changes look good to me. Works for me. I proposed this text to address the comment from the WG on whether client implementations will enable DNSSEC to support the proposed mechanism.
Change:
inverse priority of this Connection relative to other Connections in the same Connection Group.  It has no effect on Connections not part of a Connection Group.  As noted in groups, this property is not <del> entangled when Connections are cloned. </del> <ins> entangled when Connections are cloned, i.e., changing the Priority on one Connection in a Connection Group does not change it on the other Connections in the same Connection Group. </ins> 11.1.4.

Discussion:
Make clearer what "Priority is not entangled" means, following . Also added a note that Clone() may result in on-the-wire signaling.
Section 11.1.3 of the API says about Priority: "As noted in Section 6.4, this property is not entangled when Connections are cloned." Not sure what this means. I though when you clone a connection you would actually take the priority of the cloned connection but then you can change it independently for each connection in a group. Or what's the priority after cloning? Back to the default of 100? We should say this explicitly. Or maybe you even want to provide the priority while cloning? Actually looking at this now again, I think we would need to specify cloning a bit better anyway. I assume that calling clone() on a multiplexing capable connection would create a new stream; in case of quic is would only create local state but no on-the-wire singling. However if you call clone on a TCP connection, is that basically an initial() call that triggers the TCP handshake? We should say this explicitly.
I'd say it's exactly as you thought: When you clone a Connection, all Properties are copied (including the Priority), but then they are not entangled: If you change the Priority on the cloned Connection, the Priority on the original Connection stays as it was. If Priority was entangled, then it would change on both Connections if you change it on one of them. But yes, perhaps this is confusing and the text should be more explicit. The part on specifying cloning better: There's text on this in the Implementation draft on what happens with Clone() for each protocol. But maybe we can say in the API document that Clone() might trigger on-the-wire signaling or it might not, depending on the protocol.
Yes, both additions/clarification would be good.
LGTM - and thanks for adding this clarification!Thank you for the clarifications!
Change:
The string "simpleHttp" <del> The value to be provisioned in the file.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any non-ASCII characters. </del> <ins> The value to be used in generation of validation JWS.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the URL-safe Base64 alphabet. </ins> A client responds to this challenge by signing a JWS object and provisioning it as a resource on the HTTP server for the domain in question.  The payload of the JWS MUST be a JSON dictionary <del> containing the fields "type", "token", "path", and "tls" from the ACME challenge and response (see below), and no other fields.  If the </del> <ins> containing the fields "type", "token", and "tls" from the ACME challenge and response (see below), and no other fields.  If the </ins> "tls" field is not included in the response, then validation object MUST have its "tls" field set to "true".  The JWS MUST be signed with the client's account key pair.  This JWS is NOT REQUIRED to have a

Discussion:
(As part of closing out the letsencrypt/acme-spec repo.)
Change:
and place in the protected field of the Enc_structure and the COSE_Encrypt structure. <del> Copy the add field from the COSE_Encrypt structure to the </del> <ins> Copy the 'aad' field from the COSE_Encrypt structure to the </ins> Enc_Structure. Encode the Enc_structure using a CBOR Canonical encoding CBOR- Canonical to get the AAD value. <del> Encrypt the plain text and place it in the ciphertext field.  The AAD value is passed in as part of the encryption process. </del> <ins> Encrypt the plain text and place it in the 'ciphertext' field. The AAD value is passed in as part of the encryption process. </ins> For recipient of the message, recursively perform the encryption algorithm for that recipient using the encryption key as the plain

Discussion:
The majority of changes prior to the examples section are to address typos or what I saw as inconsistencies. I will admit I wasn't as diligent as I should have been on those, but I need to take another pass on the document. The examples were reformatted to minimize side scrolling -- and likely fit within the TXT representation.
Change:
Once in use, UDP throws "soft errors" (ERROR.UDP(-Lite)) upon receiving ICMP notifications indicating failures in the network. <ins> Additional information can also be provided when this is available to the system (e.g.  ICMP error code and quoted packet header). </ins> LISTEN.UDP.  Calling "Listen" for UDP binds a local port and prepares it to receive inbound UDP datagrams from peers.

Discussion:
First cut at new text
UDP, ConnectionError: Would those soft errors contain additional information about the ICMP error code, and can an application expect to find the (partial) original datagram in the error?
This is a good question! - on the one hand, the additional info can be valuable - for example to validate an ICMP message, as suggested for validating ICMP for a DPLPMTUD probe - but on the other hand, this info is often not provided by existing APIs.
I figure that a practical thing to state would be that the information is provided if it is accessible on a platform. Having text that describes this as matter of implementation quality would help TAPS implementers push for (eg. MSG_ERRQUEUE style) provisions in their platforms.
If the system makes this information available, we could mention that you could pass it up.
See a proposal in
The pointer to the PR with the specific proposal to address this issue got a "thumbs up" from the NAME who wrote the review. So, this PR should have closed this issue. Doing it manually.
Change:
Permanent <del> This document. Date of registration. </del> <ins> RFC 9287 </ins> <del> QUIC Working Group (quic@ietf.org) </del> <ins> 2022-07-13 </ins> IETF (iesg@ietf.org) <ins> QUIC Working Group (quic@ietf.org) </ins> (none)

Discussion:
These are all the changes I found from the text diff, plus some extra changes about versions.
I have reviewed the changes, and I agree that they are editorial in nature.
Change:
Endpoints MUST NOT send DATAGRAM frames using a Context ID until they have either sent or received a REGISTER_DATAGRAM_CONTEXT Capsule with <del> the same Context ID.  However, due to reordering, an endpoint that receives a DATAGRAM frame with an unknown Context ID MUST NOT treat it as an error, it SHALL instead drop the DATAGRAM frame silently, or buffer it temporarily while awaiting the corresponding REGISTER_DATAGRAM_CONTEXT Capsule. </del> <ins> the same Context ID.  However, reordering can cause DATAGRAM frames to be received with an unknown Context ID.  Receipt of such frames MUST NOT be treated as an error.  Endpoints SHALL drop the DATAGRAM frame silently, or buffer it temporarily while awaiting the corresponding REGISTER_DATAGRAM_CONTEXT Capsule.  Intermediaries SHALL drop the DATAGRAM frame silently, MAY buffer it, or forward it on immediately. </ins> Endpoints MUST NOT register the same Context ID twice on the same stream.  This also applies to Context IDs that have been closed using

Discussion:
URL it clear what the spec is allowing, we should make a note in Section 4.4 that the ordering/buffering requirements of DATGRAM frames and register capsules (from sec 3) do not apply to intermediaries when forwarding. That's tangential to Luca's OP so we can spin it off separately. Originally posted by NAME in URL
Change:
The cloud registrar returned a 307 response to the voucher request. <del> The pledge should restart the process using a new voucher request </del> <ins> The pledge SHOULD restart the process using a new voucher request </ins> using the location provided in the HTTP redirect.  Note if the pledge is able to validate the new server using a trust anchor found in its Implicit Trust Anchor database, then it MAY accept another 307

Discussion:
The two occurences of lower-case "may" might be clearer as "might". "The Pledge can be done with" ???? "may" or "MAY"? There are a few occurences of "should" and "must" in these sections, and I wondered about "SHOULD" and "MUST".
Change:
a particular button, a client could report clicks when none occurred. <del> Input: The original data emitted by a client, before any encryption or secret sharing scheme is applied.  This may include multiple measurements. </del> <ins> Input: The measurement (or measurements) emitted by a client, before any encryption or secret sharing scheme is applied. </ins> Input share: one of the shares output by feeding an input into a secret sharing scheme.  Each share is to be transmitted to one of

Discussion:
The design document discusses "reports" which are a group of measurements being submitted to a DPA instantiation. There should be an entry in the "Terminology" section that explicitly defines a report and how it relates to "measurements" and "inputs".
Thanks for putting the list back in alphabetical order, too!
Change:
values included 0, 16 and 28 bits. 0 bits cannot be used when PEF or POF is configured for the service. <del> The outgoing S-Label for the service. </del> If PRF is to be provided for the service. <ins> The outgoing S-Label for each of the service's outgoing DetNet (member) flow. </ins> The forwarding sub-layer information associated with the output of the service sub-layer.  Note that when the PRF function is provisioned, this information is per DetNet member flow.

Discussion:
Clarifying S-Label procedures (i.e., allowing S-Label value per outgoing member flow after PRF).
Change:
When a client requests a QuicTransport to be created, the user agent establishes a QUIC connection to the specified address.  It verifies <del> that the the server is a QuicTransport endpoint using ALPN, and that the client is allowed to connect to the specified endpoint using "web_accepted_origins" transport parameter.  Once the verification succeeds and the QUIC connection is ready, the client can send and receive streams and datagrams. </del> <ins> that the the server is a QuicTransport endpoint using ALPN, and sends a _client indication_ containing the origin of the initiating website to the server.  At that point, the connection is ready from the client's perspective.  The server MUST wait until the indication is received before processing any application data. </ins> WebTransport streams are provided by creating an individual unidirectional or bidirectional QUIC stream.  WebTransport datagrams

Discussion:
What is the uri-scheme used in an origin? ( It may be discussed as a separate issue.
Well, the origin sent here is the origin of the webpage that created QuicTransport; so, for instance, if connects using QuicTransport to , the origin send would be . I don't think a QuicTransport connection can be an origin by itself. We are currently considering giving it its own URL scheme, but a URL can only act as an origin if a user can to it, or if the URL has storage attached to it (which QuicTransport doesn't, since it doesn't support HTTP cookies).
I misunderstood the URI schema as that of QuicTransport itself Your kind explanation made me understand. thanks
Change:
revoked: The certificate to be revoked, in the base64url-encoded version of <del> the DER format.  (Note: This field uses the same modified Base64 encoding rules used elsewhere in this document, so it is different from PEM.) </del> <ins> the DER format.  (Note: Because this field uses base64url, and does not include headers, it is different from PEM.) </ins> <del> One of the revocation reasonCodes defined in RFC 5280 RFC5280 Section 5.3.1 to be used when generating OCSP responses and CRLs. If this field is not set the server SHOULD use the unspecified (0) reasonCode value when generating OCSP responses and CRLs.  The server MAY disallow a subset of reasonCodes from being used by the user. </del> <ins> One of the revocation reasonCodes defined in RFC5280 Section 5.3.1 to be used when generating OCSP responses and CRLs.  If this field is not set the server SHOULD use the unspecified (0) reasonCode value when generating OCSP responses and CRLs.  The server MAY disallow a subset of reasonCodes from being used by the user. </ins> Revocation requests are different from other ACME request in that they can be signed either with an account key pair or the key pair in

Discussion:
Also fix an example date and fix an RFC reference to not be redundant.
Merging based on manual review, since CircleCI for PRs seems to be busted.
Change:
resource depletion and related errors are comparable to 500 type errors.) <ins> The JSON value the JSONPath query is applied to is, by definition, a valid JSON value.  The parsing of a JSON text into a JSON value and what happens if a JSON text does not represent valid JSON are not defined by this specification. </ins> 3.2. Syntactically, a JSONPath query consists of a root selector ("$"),

Discussion:
Fixes URL
NAME :
It depends. For example, the APIs of some JSONPath implementations take a rich type which represents a valid JSON value. In that case, handling invalid JSON happens before the API is called and is not a concern of the API. But other implementations could have an API which takes a string, which may or may not represent valid JSON. So, to be clear, we probably need some words in the spec which says the spec does not prescribe how invalid JSON is handled. This is better than silence. Or we could require that invalid JSON cannot result in a non-empty nodelist from a JSONPath query.
NAME But "brokenness" would apply to JSON texts, wouldn't it? As NAME noted in (URL), "JSON text is a sequence of characters, an unparsed piece of JSON for interchange, with newlines and backslashes and all that. JSONPath never looks at JSON texts. JSON value is the RFC 8259 term for what JSONPath looks at." The parser would care about "broken" JSON texts, but JSONPath should never see them.
Agree with last two points. The spec describes the application of a JSONPath expression to parsed JSON, so JSON texts are out-of-scope. As NAME says, we should make that explicit.
JSON Schema simply that it operates on the JSON data model. This section covers a range of issues that we've found in our history, including handling whitespace differences, duplicate keys, etc. I think this is a great approach.
Thanks!