jiebi/CodeConvo huggingface dataset:
Change:
If R is blank, replace R with its left child until R is either non-blank or a leaf node <del> If R is a leaf node, the check fails </del> <ins> If R is a blank leaf node, the check fails </ins> If R.parent_hash is equal to the Parent Hash of P with Co-Path Child L, the check passes

Discussion:
Add a missing word. Fail on blank leaf.
The is currently not very well described. Depending on the reading it might also be wrong. In particular, the condition , if implemented as described makes it so that valid parent hashes are rejected. Take for example a simple tree with two leafs where the right leaf (node 2) sends a commit. In this case the other leaf will reject the parent hash because it fails when going down to the right leaf. This might be a wrong interpretation of the described verification procedure but then the description needs updating. I suggest to add a more formal description of the parent hash generation and verification (e.g. pseudocode) to reduce ambiguity.
I think that condition should read "If R is a blank leaf node, the check fails".
Agree with NAME here; the matches this interpretation. So I think we just need to adjust that text.
I agree, this was fixed in
Change:
packets. A client MAY also clear the QUIC Bit in Initial packets that are sent <del> to establish a new connection.  A client can only clear the QUIC Bit if the packet includes a token provided by the server in a NEW_TOKEN frame on a connection where the server also included the grease_quic_bit transport parameter.  To allow for changes in server configuration, clients SHOULD set the QUIC Bit if the token was provided more than 7 days prior. </del> <ins> prior to receiving transport parameters from the server.  A client can only clear the QUIC Bit if such packets include a token provided by the server in a NEW_TOKEN frame on a connection where the server also included the grease_quic_bit transport parameter.  To allow for changes in server configuration, clients SHOULD set the QUIC Bit if the token was provided more than 7 days prior. </ins> 3.2.

Discussion:
At the moment, the paragraph says "Initial packets that are sent to establish a new connection." That is unclear. It is possible to interpret this text as "all Initial packets that the client sends," because all the Initial packets are used to establish a new connection. As the paragraph right above discusses what endpoints should do once they receive transport parameters, we can be clear that this paragraph discusses what should be done until then.
Thanks Kazuho, this is definitely clearer. WDYT of the tweak?
Change:
H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to use HTTP/3 datagrams in 0-RTT packets.  When servers decide to accept 0-RTT data, they MUST send a H3_DATAGRAM SETTINGS parameter greater <del> or equal to the value they sent to the client in the connection where they sent them the NewSessionTicket message.  If a client stores the value of the H3_DATAGRAM SETTINGS parameter with their 0-RTT state, they MUST validate that the new value of the H3_DATAGRAM SETTINGS parameter sent by the server in the handshake is greater or equal to the stored value; if not, the client MUST terminate the connection with error H3_SETTINGS_ERROR. </del> <ins> than or equal to the value they sent to the client in the connection where they sent them the NewSessionTicket message.  If a client stores the value of the H3_DATAGRAM SETTINGS parameter with their 0-RTT state, they MUST validate that the new value of the H3_DATAGRAM SETTINGS parameter sent by the server in the handshake is greater than or equal to the stored value; if not, the client MUST terminate the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1. </ins> 6.

Discussion:
In layspeak I think this is saying "if a server sent the value 1 before, it MUST send 1 now. If a server sent 0 before, it MUST send 0 or 1 now". Could we maybe editorialize this to make it less likely for someone to do and end up sending ?
There is text in the doc stating that only 0 and 1 are valid. But I do agree that the current text is somewhat clunky. Can you send a PR?
Sure, I'll make a PR.
Change:
Two matchable block-wise operations are said to be "concurrent" if a block of the second request is exchanged even though the client still intends to exchange further blocks in the first operation. <del> (Concurrent block-wise request operations are impossible with the options of RFC7959 because the second operation's block overwrites </del> <ins> (Concurrent block-wise request operations from a single endpoint are impossible with the options of RFC7959 (see the last paragraphs of Sections 2.4 and 2.5) because the second operation's block overwrites </ins> any state of the first exchange.). The Echo and Request-Tag options are defined in this document.

Discussion:
Also includes changes to a paragraph that will be Section 3 after the pending intro-shoving. Rationale as in the review response mail: Reference made more precise, "from a single endpopoint" added. Split up into separate sentences for better clarity. That requirement was already kind of conditional on the client using Request-Tag for a particular purpose -- for otherwise the "unless concluded" clause makes no sense, for that's defined by the purpose. Rephrased to pull in the purpose before the MUST and make that explicit. The "that support Request-Tag" comment should be obsolete by hat, for only who supports it can use it for something. (We did, in the chat earlier, consider asking the WG whether that'd all mean that we're updating RFC7959, but as we're now back to "If you want to achieve X, do Y" wording, I don't see necessity for such an update). Added to the initial (now split up) paragraph of that section. Explicitly included as an option now. (Would have been even easier if there were a once-and-for-all definition of a "request-tag value" that can be absent or have the option's data, but that had long-winded wording in the last version that was in, and still might be mistaken by readers that don't have the precise definition at hand).
Looks good.
Change:
Terminology defined in RFC7102 applies to this document: LLN, RPL, RPL Domain and ROLL. <del> RPL-aware-node: A device which implements RPL.  Please note that the device can be found inside the LLN or outside LLN. </del> <ins> RPL Leaf: An IPv6 host that is attached to a RPL router and obtains connectivity through a RPL Destination Oriented Directed Acyclic Graph (DODAG).  As an IPv6 node, a RPL Leaf is expected to ignore a consumed Routing Header and as an IPv6 host, it is expected to ignore a Hop-by-Hop header.  It results that a RPL Leaf can correctly receive a packet with RPL artifacts.  On the other hand, a RPL Leaf is not expected to generate RPL artifacts or to support IP-in-IP encapsulation.  For simplification, this document uses the standalone term leaf to mean a RPL leaf. </ins> <del> RPL-Aware-Leaf(RAL): A RPL-aware-node which is a leaf of a (Destination Oriented Directed Acyclic Graph) DODAG. </del> <ins> RPL-aware-node (RAN): A device which implements RPL.  Please note that the device can be found inside the LLN or outside LLN. RPL-Aware-Leaf(RAL): A RPL-aware-node that is also a RPL Leaf. </ins> RPL-unaware-node: A device which does not implement RPL, thus the device is not-RPL-aware.  Please note that the device can be found inside the LLN. <del> RPL-Unaware-Leaf(RUL): A RPL-unaware-node which is a leaf of a (Destination Oriented Directed Acyclic Graph) DODAG. </del> <ins> RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf. </ins> 6LoWPAN Node (6LN): RFC6775 defines it as: "A 6LoWPAN node is any host or router participating in a LoWPAN.  This term is used when

Discussion:
RPL was missing a good definition of a LEAF. this clarifies.
updated the deprecated ref to rul draft
Change:
migration, as the peer will be unable to respond if the pool is exhausted. <ins> An endpoint that selects a zero-length connection ID during the handshake cannot issue a new connection ID.  A zero-length Destination Connection ID field is used in all packets sent toward such an endpoint over any network path. </ins> 5.1.2. An endpoint can change the connection ID it uses for a peer to

Discussion:
For all packets. For all network paths.
You are right it's not really incorrect , I just found it confusing giving potentially the impression that using multiple paths without CID is "easily" possible. How about this phrasing to be even more clear: "A zero-length Destination Connection ID field is used in all packets sent toward such an endpoint and this cannot be changed even if the network path changes."
Yes, good to call out this implicit exception.
Change:
Local Endpoint will be configured with some method of discovering NAT bindings, e.g., a Session Traversal Utilities for NAT (STUN) server. In this case, the Local Endpoint may resolve to a mixture of local <del> and server reflexive addresses.  The Resolve() method on the </del> <ins> and server reflexive addresses.  The Resolve() action on the </ins> Preconnection can be used to discover these bindings: The Resolve() call returns a list of Preconnection Objects, that

Discussion:
as I started reviewing issues in advance of the interim, I saw that was already mostly fixed, but I made a few editorial changes to the language there.
Change:
The "ACME Authorization Object Fields" registry lists field names that are defined for use in ACME authorization objects.  Fields <del> marked as "configurable" may be included in a new-authorization request. </del> <ins> marked as "configurable" may be included in a newAuthz request. </ins> Template:

Discussion:
This PR is collecting changes to make sure we address during the editing window. Editorial clarifications only, please.
Both and are also TODO's for AUTH48.
Section 7.4 says: It should say , not . NAME Would you mind fixing this typo in this PR?
NAME Turns out the RFC editor caught that one (see ), so I don't have to fix it here :)
LGTM
Change:
Choose a subset of the N iterations to check, according to local policy. <del> For each iteration, compute the Zi-value from the authorized keys object in the same way as the client. </del> <ins> For each iteration, compute the Zi-value from the key authorization in the same way as the client. </ins> Open a TLS connection to the domain name being validated on the requested port, presenting the value

Discussion:
This PR updates the new challenges so that they no longer use a JSON object dictated by the server. Instead, they use a "key authorization" string that is canonically generated from the token and key for a given challenge. (And also, while we're here, changes "authorized key object" to "key authorization".)
Change:
This message is called the Client's report.  It consists of the task ID, report metadata, the "public share" output by the VDAF's input- distribution algorithm, and the encrypted input share of each of the <del> Aggregators.  The metadata consists of the following fields: </del> <ins> Aggregators.  (Note that the public share might be empty, depending on the VDAF.  For example, Prio3 has an empty public share, but Poplar1 does not.  See VDAF.)  The header consists of the task ID and report "metadata".  The metadata consists of the following fields: </ins> A timestamp representing the time at which the report was generated.  Specifically, the "time" field is set to the number of

Discussion:
cc/ NAME
The presentation syntax is: opaque public_share; Are there ever going to be no public shares in a Report?
EDITED: Yes, Prio3 has an empty public share. This is mainly needed for Poplar1. From the :
NAME if you want, we can add text that makes sure your question is answered. Otherwise I don't think there's any action to take here.
I think the answer should be: "Yes, Prio3 doesn't need public shares."
Thanks for the update.
Change:
TCP RFC0793 to allow for packet reordering.  (Note that the intention here is that implementers use the current guidance from the IETF for MSL, as specified in RFC0793 or successors not that they attempt to <del> interrogate the MSL that the system TCP stack is using.)  Until the handshake has completed, implementations MUST accept packets from the old epoch. </del> <ins> interrogate the MSL that the system TCP stack is using.) </ins> Conversely, it is possible for records that are protected with the new epoch to be received prior to the completion of a handshake.  For

Discussion:
Deleted the following statement: "Until the handshake has completed, implementations MUST accept packets from the old epoch." because it appears to be redundant. Martin raised this issue in URL
I think that this is a vestige of renegotiation and can be removed. But we might want to say something more helpful about accepting 0-RTT and Handshake at the same time.
I think we should delete this sentence because it is redundant. We have already text in the same section saying the following: " Because DTLS records could be reordered, a record from epoch 1 may be received after epoch 2 has begun. In general, implementations SHOULD discard packets from earlier epochs, but if packet loss causes noticeable problems implementations MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP to allow for packet reordering. " NAME If you think there is someone else that should be said, we are happy to add it. Here is the PR: URL
Fixed.
Change:
seconds. This level of latency is the historically common case for segmented <del> video delivery using HLS RFC8216 and DASH MPEG-DASH.  This level of latency is often considered adequate for content like news or pre- recorded content.  This level of latency is also sometimes achieved as a fallback state when some part of the delivery system or the client-side players do not have the necessary support for the features necessary to support low-latency live streaming. </del> <ins> video delivery using HLS and DASH.  This level of latency is often considered adequate for content like news or pre-recorded content. This level of latency is also sometimes achieved as a fallback state when some part of the delivery system or the client-side players do not have the necessary support for the features necessary to support low-latency live streaming. </ins> This level of latency can typically be achieved at scale with commodity CDN services for HTTP(s) delivery, and in some cases, the

Discussion:
Also move some expansions and references to first use.
From NAME -
Hi, NAME - We've been focused on what endpoints could do to improve streaming media performance, but it does seem helpful to point that out more clearly. Please see if is helpful.
Change:
origin tokens with empty contexts can be replayed from one party by another, as shown below. <ins> Token challenges that include non-empty origin_info bind tokens to one or more specific origins.  As described in challenge, clients only accept such challenges from origin names listed in the origin_info string.  Even if multiple origins are listed, a token can only be redeemed for an origin if the challenge has an exact match for the origin_info.  For example, if "a.example.com" issues a challenge with an origin_info string of "a.example.com,b.example.com", a client could redeem a token fetched for this challenge if and only if "b.example.com" also included an origin_info string of "a.example.com,b.example.com".  On the other hand, if "b.example.com" had an origin_info string of "b.example.com" or "b.example.com,a.example.com" or "a.example.com,b.example.com,c.example.com", the string would not match and the client would need to use a different token. </ins> Context-bound token challenges require clients to obtain matching tokens when challenged, rather than presenting a token that was obtained from a different context in the past.  This can make it more

Discussion:
NAME please have a look!
From Ted Hardie in Vienna.
We should also clarify more explicitly how the client uses the origin name field for validating the context it is in.
Leaning towards allowing the being able to be a list of hostnames, with comma separation.
+1 to csv. We think this keeps the client impl's simple while allowing for the added flexibility of origin sets.
Might also have to say something about ignoring whitespace vs and then maybe just whitespace is the separator?
While I can understand the appeal, I'm not yet convinced we should do this until we have a use case and have thought through the possible privacy impacts.
perfect!
Change:
A YANG Data Model for Optical Impairment-aware Topology <del> draft-ietf-ccamp-optical-impairment-topology-yang-10 </del> <ins> draft-ietf-ccamp-optical-impairment-topology-yang-11 </ins> Abstract

Discussion:
draft-ietf-ccamp-optical-impairment-topology-URL for IETF 115 submission --> draft-ietf-ccamp-optical-impairment-topology-yang-URL Related to pull request URL Addressing and resolving .
Change:
been formed. The lifetime of the IP forwarding tunnel is tied to the IP proxying <del> request stream.  Closing that stream (in HTTP/3 via the FIN bit on a QUIC STREAM frame, or a QUIC RESET_STREAM frame) closes the associated IP tunnel. </del> <ins> request stream.  The IP proxy MUST maintain all IP address and route assignments associated with the IP forwarding tunnel while the request stream is open.  IP proxies MAY choose to tear down the tunnel due to a period of inactivity, but they MUST close the request stream when doing so. </ins> Along with a successful response, the IP proxy can send capsules to assign addresses and advertise routes to the client (capsules).  The

Discussion:
I think it would be helpful to review the lifetime text in URL more closely align with it where it makes sense. What stuck out to me first was speaking about HTTP/3 specifically sticks out because all versions are supported. Second, there's no text about if a proxy can timeout itself and close the stream.
This makes sense, we can be a bit more specific with this guidance
Change:
2.1. While informally, a group can be considered to be a set of users <del> possibly using multiple endpoint devices to interact with the Messaging Service, this definition is too simplistic. </del> <ins> possibly using multiple endpoint devices to interact with the Service Provider, this definition is too simplistic. </ins> Formally, a Client is a set of cryptographic objects composed by public values such as a name (an identity), a public encryption key

Discussion:
This PR addresses URL
Thanks!
In the context of this document, the meaning of the term Messaging Service (MS) seems a little unclear to me. The document states that the protocol is intended to be embedded in a concrete protocol such as XMPP. However, is a MS meant to be a messaging service such as SMS or MMS? Or a service on the application layer, such as FB or WhatsApp? Essentially who provides / controls the AS and DS? I would be grateful for some clarification on this. Thanks.
It is meant to mean application layer, would changing that to "service provider" work better for you?
Thank you. I do think that the term service provider is less ambiguous.
Ack, will fix soon.
I can make a PR, if you want?
Sure, please go for it.
Fixed by
Change:
a phone) or sequentially (e.g., replacing one phone with another), hence the formal definition of a Group in MLS is the set of Clients that has legitimate knowledge of the shared (Encryption) Group Key <del> established throughout the group key establishment phase of the protocol. </del> <ins> established in the group key establishment phase of the protocol. </ins> MLS has been designed to provide similar security guarantees to all Clients, for all group sizes, even when it reduces to only two Clients. <del> 2.3. </del> <ins> 2.2. </ins> The Delivery Service (DS) is expected to play multiple roles in the Messaging Service architecture.

Discussion:
A few minor edits to (hopefully) improve readability, and a few comments in square braces ([ ]).
Something looks wrong with your text editor... ;)
Arg! Will fix, sorry about this.
Change:
8.1. <ins> This document updates the "Well-Known URIs" Registry WellKnownURIs with the following values. 8.2. </ins> This document updates the "Token Type" Registry with the following values. <del> 8.2. </del> <ins> 8.3. </ins> This specification defines the following protocol messages, along with their corresponding media types:

Discussion:
While we're here, I'd like to recommend we align the name of this well-known value to align with the request/response names. In particular, what do folks think about "/well-known/private-token-issuer-directory"?
you're probably missing a registration for your well-known in the IANA considerations, the registry is URL
Change:
Phase bit alone can be used to select keys. An endpoint MAY allow a period of approximately the Probe Timeout <del> (PTO; see QUIC-RECOVERY) after receiving a packet that uses the new key generation before it creates the next set of packet protection keys.  These updated keys MAY replace the previous keys at that time. With the caveat that PTO is a subjective measure - that is, a peer could have a different view of the RTT - this time is expected to be long enough that any reordered packets would be declared lost by a peer even if they were acknowledged and short enough to allow for subsequent key updates. </del> <ins> (PTO; see QUIC-RECOVERY) after promoting the next set of receive keys to be current before it creates the subsequent set of packet protection keys.  These updated keys MAY replace the previous keys at that time.  With the caveat that PTO is a subjective measure - that is, a peer could have a different view of the RTT - this time is expected to be long enough that any reordered packets would be declared lost by a peer even if they were acknowledged and short enough to allow a peer to initiate further key updates. </ins> Endpoints need to allow for the possibility that a peer might not be able to decrypt packets that initiate a key update during the period

Discussion:
Some of this is just forward reference, but it does need a little more context. Also, there was a missing word.
This also no?
NAME said:
I'll roll this into the change for as it relates to the same basic text. I like the "promoting" idea, though I'm not going to go back and rewrite everything to use it. Here, the important thing is to have words for current, next, and "subsequent next" to avoid making this more confusing than necessary. I think that I got it.
NAME said:
I can see an obvious missing word in there at a minimum. I can see some opportunities for clarification here though, so I'll give it a go. Breaking the ordering dependencies between sections is tricky though. It might just be that we need a little redundancy.
This is a big help; thank you!
Change:
File contains one or more certificates encoded with the PEM textual encoding, according to RFC 7468 RFC7468.  In order to provide easy interoperation with TLS, the first certificate MUST be an end-entity <del> certificate.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust </del> <ins> certificate.  Each following certificate SHOULD directly certify the one preceding it.  Because certificate validation requires that trust </ins> anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates.

Discussion:
A few editorial things that Dale found.
Editorial diffs only. Merging as-is. Thanks NAME !
:shipit: