jiebi/CodeConvo huggingface dataset:
Change:
The following messages are defined in this section and are used to aggregate a number of reports simultaneously: <del> [CP: Since these parameters are required for all variants, I think we should consider moving task_id and job_id to precede the message type.] </del> As discussed in aggregation-flow, the leader may choose to shard the task of aggregating a large number of reports into any number of sub- batches.  The process of aggregating the reports in a leader-defined

Discussion:
Minor changes/clarifications: Clarify how to handle empty Transition sequences Handle repeated nonces by aborting. While at it, this changes how the helper handles unrecognized nonces to be consistent with how the leader handles unrecognized nonces. Move task/job ID to top of AggregateReq
Change:
3.3. <del> HTTP/3 relies on QUIC as the underlying transport.  The QUIC version being used MUST use TLS version 1.3 or greater as its handshake </del> <ins> HTTP/3 relies on QUIC version 1 as the underlying transport.  The use of other QUIC transport versions with HTTP/3 MAY be defined by future specifications. QUIC version 1 uses TLS version 1.3 or greater as its handshake </ins> protocol.  HTTP/3 clients MUST indicate the target domain name during the TLS handshake.  This may be done using the Server Name Indication (SNI) RFC6066 extension to TLS or using some other mechanism.

Discussion:
As discussed in Singapore, this ties HTTP/3 to QUIC version 1 until someone writes down how another QUIC version is used.
We've removed the text saying that application protocols can constrain which QUIC versions they can run over. We need to discuss where the correlation between ALPN tokens and version numbers gets considered. Some proposals discussed in Cupertino: ALPN tokens imply one specific QUIC version. This leads to a possible error case, where an ALPN token is offered/accepted over another QUIC version. Application protocols can restrict which QUIC versions they run over. This implies that the QUIC version being spoken must be considered when selecting an ALPN token.
Discussed with NAME this is fine in the TLS draft, but the HTTP/3 draft needs to have a firmer opinion. Right now it says "anything with TLS 1.3".
The discussion in Singapore seemed to end with the conclusion that HTTP/3 would be defined to refer to QUIC version 1 exclusively. But we decided not to answer the broader question of what ALPN actually refers to. That was considered too broad a topic for the QUIC WG to address without involving TLS, HTTP, and others.
Change:
An Add proposal requests that a client with a specified KeyPackage be added to the group. <del> An Add proposal is invalid if any of the following is true: The KeyPackage is invalid according to keypackage-validation. The Credential in the KeyPackage represents a client already in the group according to the application. </del> <ins> An Add proposal is invalid if the KeyPackage is invalid according to keypackage-validation. </ins> An Add is applied after being included in a Commit message.  The position of the Add in the list of proposals determines the leaf node

Discussion:
In , it was pointed out that we previously had a clause: But this was amplified in to say that we also can't send Add proposals for users that are already in the group. I think we should talk about if this is the actual desired behavior or not.
I agree with Brendan. Specifically I want to make sure an MLS client can replace itself. My other concern is that because we have no guidance yet on identity, we need to make sure that multiple instances/clients of the same user are allowed.
Interim 2022-05-26: We want to: Avoid having multiple appearances of the same device Allow a device to resync itself Text at issue here is "An Add proposal is invalid if ... The Credential in the KeyPackage represents a client already in the group according to the application" It sounds like changing to "... The KeyPackage represents a client already in the group according to the application" would address the immediate concern NAME to write a PR
Change:
3.5.4.2.1. <del> This section is non-normative. </del> <ins> This section is informative. </ins> Array slicing is inspired by the behavior of the "Array.prototype.slice" method of the JavaScript language as defined

Discussion:
Non-normative may be a better option, throughout, because surely normative sections are informative too? NAME WDYT?
Given we use Informative for the non-normative references, I guess we should do the same throughout. Hopefully no-one will misunderstand...
Change:
pvd <del> Set (Preference, Enumeration) </del> <ins> Collection of (Preference, Enumeration) </ins> <del> Empty set (not setting a preference for any PvD) </del> <ins> Empty (not setting a preference for any PvD) </ins> Similar to interface instances and types (see prop-interface), this property allows the application to control path selection by

Discussion:
I should have said: I approve this, modulo the changes requested by NAME
Thanks for incorporating my suggested changes. I think this can be merged now.
Change:
table are registered in the "HTTP/3 Settings" registry established in HTTP3. <ins> For fomatting reasons, the setting names here are abbreviated by removing the 'SETTING_' prefix. </ins> 8.2. This document specifies two stream types.  The entries in the

Discussion:
NAME said
I think we can change to SHOULD NOT. I'd rather not be so prescriptive here, since a QPACK implementation might well cut this corner and ignore flow control constraints and rely on higher levels of the stack to ensure the necessary flow control is available? I guess I could be convinced otherwise.
NAME
NAME said
Even though newlines are not really allowed (unescaped) in field values, we can add a note to this effect.
NAME said
Yes, that's why they're not there.
Propose to close with no action then? Or is there a way to reformat the table to include the longer names?
I see a couple options in addition to "close with no change", namely to add a note below the table that the names are abbreviated, or to write out the IANA directives in prose without a table at all. I don't have a particular preference among those three options, though.
We need to come to a decision on this. Since this is from an IESG COMMENT (and not a DISCUSS), the editors can IMO go ahead with their preferred resolution.
NAME said
I agree it's not worth mitigating technically. I question whether it's worth documenting, personally, but it does no harm.
Maybe just a sentence that this mitigation has limits when traversing multiple intermediaries?
That seems like it would strike a reasonable balance.
NAME said
This table appears before the general discussion of indexing. One thought is to add something along the top of the table, like this: ?
Your proposal does improve the clarity of the figure, but I am hoping for more. While it is true that the dedicated sections that discuss indexing appear later in the document, the introductory text alongside the figure uses language such as "smallest absolute index", increases the draining index", and "with an absolute index lower than the draining index" that imply a numerical ordering and directionality of the indices. Interpreting the figure would be easier with the direction of that ordering stated explicitly, as might be done via "Newer Entries (larger index)"/etc..
We need to come to a decision on this. Since this is from an IESG COMMENT (and not a DISCUSS), the editors can IMO go ahead with their preferred resolution.
Change:
The semantics of regular expressions are as defined in I-D.draft- bormann-jsonpath-iregexp. <ins> 3.4.8.2.4. </ins> The logical AND, OR, and NOT operators have the normal semantics of Boolean algebra and consequently obey these laws (where "P", "Q", and "R" are any expressions with syntax "logical-and-expr", "T" is any

Discussion:
Editorial improvements Correct != comparison involving at least one empty nodelist.
I'm not sure that is so obviously false, so maybe mentioning that a structured value on one side spoils the comparison may be needed.
Ok, I can see how someone might read that into the spec. I'll add something.
Please see the comparison examples I just added. These should help to draw out the implications of the semantics.
Change:
6.4. To verify a token, a verifier checks that Token.authenticator is a <del> valid signature over the remainder of the token input as described below.  The function "RSASSA-PSS-VERIFY" is defined in Section 8.1.2 of RFC8017, using SHA-384 as the Hash function, MGF1 with SHA-384 as the PSS mask generation function (MGF), and a 48-byte salt length (sLen). </del> <ins> valid signature over the remainder of the token input using the Issuer Public Key. The function "RSASSA-PSS-VERIFY" is defined in Section 8.1.2 of RFC8017, using SHA-384 as the Hash function, MGF1 with SHA-384 as the PSS mask generation function (MGF), and a 48-byte salt length (sLen). </ins> 6.5.

Discussion:
Hexadecimal constants are used as strings without specifying the length or byte order. For example, "0x0001" might be interpreted in a couple of ways. Usually the correct interpretation is clear in context, but I'm not sure it always is.
[ ] Overall: The document is inconsistent about capitalization after colon (":"). [ ] Abstract: I'm not sure the distinction between public/private verifiability is common knowledge. It might be helpful to say plainly who is doing the verifying. E.g.: "one [variant] providing tokens whose validity can be verified by the issuer only; and another for which token validity can be verified by any party with the issuer public key." [ ] 2 Terminology: "We assume that all protocol messages are encoded into raw byte formatt before being sent across the wire" This doesn't need to be mentioned, in my opinion. [ ] 5.1 Client-To-Issuer Request: The psedocode for computing "client_context" hard-codes a particular OPRF suite (0x0004). Is this the only suite that is permitted/recommended by the document? I don't think this is clear until the token types are defined in Section 8.1. [ ] 5.3 Finalization: Constants hardcoded instructs don't a semi-colon after the constant. (See "Token" in this section, for example.) Is this intentional? It looks a bit odd, and I'm wondering if this is "syntactically" correct. [ ] 5.4 Token Verification: I think it's worth pointing out here that creating the server context requires the Issuer Private Key, which is why VOPRF is not publicly verifiable. [ ] 7 Security Considerations: "All security considerations described in the VOPRF document also apply in the Privacy Pass use-case." What about security considerations for BLINDRSA? It might be a bit cleaner to write something like this: "Each protocol described here inherits the security considerations of its base document: For Section 5, this is [VOPRF]; ... " [ ] Acknowledgements: Sofi is acknowledged, but is also a co-author.
I think I caught all of these. Addressed in . Yes, this is much better! Addressed in .

This is addressed by . We explain the constant in the sentence immediately following the pseudocode, so I don't think further clarification is needed. The semi-colon was missing, but we updated this to match what's done in RFC8446. Addressed in . Addressed in . Good catch. This has already been fixed on the editor's branch to say "All security considerations described in the VOPRF and blind RSA documents also apply in the Privacy Pass use-case."
Change:
which token key to use based on the order of keys in the list, with preference given to keys earlier in the list. <del> Altogether, the Issuer's JSON directory could look like: </del> <ins> Altogether, the Issuer's directory could look like: </ins> Issuer directory resources have the media type "application/json" and are located at the well-known location /.well-known/token-issuer-

Discussion:
The configuration section lists several requirements that depend on JSON, but a JSON specification is not given. I'm guessing you probably want URL
Issuers MUST provide a configuration , so what spec should they be referring to in order to ensure that this URI is well formed? I started wondering about how percent-encoding might apply, and that got me on to thinking whether you really want to support something like `"issuer-request-uri": "https://EMAIL:123/forum/questions/?tag=networking&order=newest#top",
Unless I'm missing something, I don't think there should be any constraints on how the URI is constructed. We should say something about how it's encoded, though. That's a good point.
Change:
Message (i.e., whether it has actually been transmitted, moved into a buffer on the network interface, moved into a kernel buffer, and so on) when the Sent Event occurs is implementation-specific.  The Sent <del> Event contains a reference to the Message to which it applies. </del> <ins> Event contains a reference to the Message Context of the Message to which it applies. </ins> Sent Events allow an application to obtain an understanding of the amount of buffering it creates.  That is, if an application calls the

Discussion:
Also spotted some further small nits while reviewing the document, will create a pull request for those.
Change:
In order to update the state of the group such as adding and removing participants, MLS messages are used to make changes to the group's ratchet tree.  The participant proposing an update to the tree <del> transmits a representation of a set of tree nodes along the direct path from a leaf to the root.  Other participants in the group can use these nodes to update their view of the tree, aligning their copy of the tree to the sender's. </del> <ins> transmits a set of values for intermediate nodes in the direct path of a leaf.  Other participants in the group can use these nodes to update their view of the tree, aligning their copy of the tree to the sender's. </ins> To perform an update for a leaf, the sender transmits the following <del> information for each node in the direct path from the leaf to the root: </del> <ins> information for each node in the direct path of the leaf: </ins> The public key for the node <del> Zero or more encrypted copies of the node's secret value </del> <ins> Zero or more encrypted copies of the node's parent secret value </ins> The secret value is encrypted for the subtree corresponding to the <del> node's non-updated child, i.e., the child not on the direct path. There is one encrypted secret for each public key in the resolution of the non-updated child.  In particular, for the leaf node, there are no encrypted secrets, since a leaf node has no children. </del> <ins> parent's non-updated child, i.e., the child on the copath of the leaf node.  There is one encrypted secret for each public key in the resolution of the non-updated child.  In particular, for the leaf node, there are no encrypted secrets, since a leaf node has no children. </ins> The recipient of an update processes it with the following steps: Compute the updated secret values * Identify a node in the direct path for which the local participant is in the subtree of the non- <del> updated child * Identify a node in the resolution of the non- updated child for which this node has a private key * Decrypt the secret value for the direct path node using the private key from </del> <ins> updated child * Identify a node in the resolution of the copath node for which this node has a private key * Decrypt the secret value for the parent of the copath node using the private key from </ins> the resolution node * Compute secret values for ancestors of that node by hashing the decrypted secret

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:
Otherwise, the record MUST be rejected as if it had failed deprotection, as described in handling-invalid-records. <ins> demux shows this demultiplexing procedure graphically taking DTLS 1.3 and earlier versions of DTLS into account. </ins> 4.2. DTLS uses an explicit or partly explicit sequence number, rather than

Discussion:
I have re-drawn the figure to take Ekr's comments into account. I hope the new figure is better.
LGTM
Change:
The server ID will start in the second octet of the decrypted connection ID and occupy continuous octets beyond that. <del> They server ID length MUST be no more than 16 octets and SHOULD be no more than 12 octets, to provide servers adequate space to encode their own opaque data. </del> <ins> The server ID length MUST be no more than 12 octets, to provide adequate entropy in the encrypted block. </ins> The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption.

Discussion:
Make sure each algorithm always provides 2-3 octets for server use. The current SID limits don't do that.
Change:
The AuthenticationChain structure is composed of a sequence of uncompressed wire format DNS resource record sets (RRset) and <del> corresponding signatures (RRSIG) records. </del> <ins> corresponding signatures (RRSIG) record sets. </ins> This sequence of native DNS wire format records enables easier generation of the data structure on the server and easier

Discussion:
Draft 05. Tried to address all the outstanding comments during the WGLC. Draft cutoff for IETF100 is Monday evening - hopefully we can submit a new version.
Change:
Downgrade protection; <del> Forward secrecy with respect to long-term keys; </del> <ins> Forward secrecy with respect to long-term keys; and </ins> <del> Key Compromise Impersonation (KCI) resistance; and </del> <ins> Key Compromise Impersonation (KCI) resistance. </ins> <del> Endpoint identity protection. </del> <ins> To achieve these properties, the external PSK authentication mechanism implicitly assumes one fundamental property: each PSK is known to exactly one client and one server, and that these never switch roles.  If this assumption is violated, standard TLS 1.3 security properties are invalidated.  Section violations discusses attacks that are possible when this occurs. </ins> <del> A naive sharing of PSKs, even assuming only honest but curious participants know the key, can violate all these properties, bar one. Endpoint Identity Protection holds vacuously, because the client and server do not use certificates in PSK mode.  (This is not true with use of the "tls_cert_with_extern_psk" extension I-D.ietf-tls-tls13- cert-with-extern-psk.) </del> <ins> 4.1. As discussed in use-cases, there are use cases where multiple clients or multiple servers share a PSK.  In such cases, TLS only authenticates the entire group.  Not only can a compromised group member impersonate another group member, but a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways.  A naive sharing of PSKs, even assuming only honest but curious participants know the key, can violate all these properties, bar one.  Endpoint Identity Protection holds vacuously, because the client and server do not use certificates in PSK mode. (This is not true with use of the "tls_cert_with_extern_psk" extension I-D.ietf-tls-tls13-cert-with-extern-psk.) </ins> In the following sub-sections, we list attacks that demonstrate violations of these properties when the fundamental PSK assumption

Discussion:
Addresses , , and .
... and don’t prohibit or otherwise interfere with PAKEs. (Though we may want to state that PAKEs should produce PSKs that adhere to this limit if run out of band.)
Fixed in .
Fixed in .
Start with the general recommendation and invariant: Identities should be unique across all nodes, roles, and keys. For each use case, how a part of the invariant is violated and leads to one of the known attacks.
Fixed in .
Change:
The following metadata items are defined, all of which are OPTIONAL: <del> A URI identifying the current terms of service. An HTTP or HTTPS URL locating a website providing more information about the ACME server. </del> <ins> A string containing a URI identifying the current terms of service. </ins> <del> Each string in this array MUST be a lowercase hostname which the ACME server recognises as referring to itself for the purposes of CAA record validation as defined in RFC6844.  This allows clients to determine the correct issuer domain name to use when configuring CAA record. </del> <ins> String containing an HTTP or HTTPS URL locating a website providing more information about the ACME server. </ins> <del> An HTTP or HTTPS URI indicating a website where a user can perform account-managment functions.  For example, this website might allow a user to associate a new account key pair to an account by proving possession of a registered contact, in the event that the user loses the account private key. </del> <ins> If present, MUST be an array of strings.  Each string MUST be a lowercase hostname which the ACME server recognises as referring to itself for the purposes of CAA record validation as defined in RFC6844.  This allows clients to determine the correct issuer domain name to use when configuring CAA record. </ins> Clients access the directory by sending a GET request to the directory URI.

Discussion:
This reverts commit 5ea8bb3afe51fa14b34593341b895e0262b454ca, reversing changes made to 278c6e8ab49e3013708cbf544c76df868973635f.
Change:
detection proceeds as dictated by packet and time threshold mechanisms; see ack-loss-detection. <del> 5.4. </del> <ins> 5.3. </ins> A Retry packet causes a client to send another Initial packet, effectively restarting the connection process.  A Retry packet

Discussion:
I believe this section was mistakenly on the wrong level. I also added a reference to a later section to the last sentence. Alternatively this sentence could just be removed as this is normatively specified later on.
Change:
hostnames.  Each of these hostnames might resolve to one or more addresses, which would create multiple layers of branching. <ins> Applications can influence which derived endpoints are allowed and preferred via Selection Properties set on the Preconnection.  For example, setting a preference for "useTemporaryLocalAddress" would prefer the use of IPv6 over IPv4, and requiring "useTemporaryLocalAddress" would eliminate IPv4 options, since IPv4 does not support temporary addresses. </ins> 4.1.1.2. If a client has multiple network paths available to it, e.g., a

Discussion:
In the impl draft, I'm supposed to build a tree based on, in order (1) "path": AFAICT this means "interface". The -api draft provides in interface preference framework in 4.2.11. (BTW if it really means interface maybe we should say 'interface'). (2) Protocol: almost all of 4.2 in -api explains how to express this. (with an assist in -impl 4.1.3 explaining how to handle PREFER vs. AVOID) (3) "derived endpoint" I gather this is basically multiple addresses coming back from remote endpoint resolution. But where is the construct in -api that allows applications to express a preference here?
I'm not sure we want to add anything to the API here. There are existing preferences that can bias towards IPv6, such as preferring or requiring . I think we can just detail that in the implementation draft.
Thanks, LGTM!
Change:
a clear, interoperable definition and does not overlap with existing validation methods.  That is, it should not be possible for a client and server to follow take the same set of actions to fulfill two <del> different validation mechanisms. </del> <ins> different validation methods. </ins> Validation methods do not have to be compatible with ACME in order to be registered.  For example, a CA might wish to register a validation

Discussion:
As suggested by Felipe Gasper
NAME fixed. Note, also standardized on "validation method" (vs. "mechanism"). Hello, I’ve been looking over the -09 draft and have created a Perl client module against Pebble as well as LE’s new testing endpoint. I’m curious about whether the specification intends to define Challenge objects. They appear to exist, of course, but they’re not defined as objects per se in section 7.1 of the draft. Thank you! -Felipe Gasper Mississauga, ON