jiebi/CodeConvo huggingface dataset:
Code change:
Packet Size (MPS) as described in Datagram PLPMTUD I-D.ietf-tsvwg- datagram-plpmtud. <del> 7.1.10.3. </del> <ins> 7.1.11.3. </ins> sendMsgMaxLen

Related discussion:
text: There are many ways to do this, but this one mimics the "private browsing" paradigm" as I understand it.
Can you say more? I read as specifically about flushing state, not Connection Group vs. Connection issues generally. This is not literally "flushing" the state but I've update taps-interface to reflect this design while, I think, preserving the spirit of the original text.
Connection Groups used to be about state and context sharing as well as entanglement. Now it's about entanglement. We need to rename Connection Groups ("connection contexts"?) in the architecture to replace the existing "group" concept, and to retain "connection group" in the API for entanglement.
Seems like this could be 360 degrees of rotation in our thinking? (which could be OK, NEAT was written to specify both contexts and flow groups). Let's try some definitions here and see if we converge...
I think brings this back in synch again so no need to rename, possibly the last part of this section in architecture should be removed though as we do not have fine-grained control
Section 9.1 of taps-impl loosely refers to the need for an interface to "flush protocol state" to preserve anonymity, but such a capability is not in taps-interface.
I don't like this text: "Applications must have a way to flush protocol cache state if desired. This may be necessary, for example, if application-layer identifiers rotate and clients wish to avoid linkability via trackable TLS tickets or TFO cookies." Those of you who know me, would immediately see a "MUST"..."if desired." and a "may be necessary". My suggestion is that this digs too deep, and we should remove the text. I could also live with something more neutral though: Note: There are case where applications need to flush protocol cache state, for example, if application-layer identifiers rotate and a client wishes to avoid linkability of trackable TLS tickets or TFO cookies.
I'm fine to have the more neutral sentence proposed by Gorry. I don't think we should specify an interface for it but I think it's good to mention.
I agree that the best approach is to make it more neutral. The other option would be to say that this interface is implementation specific. For sure, we do not want it in the API I think.
Code change:
Packet Size (MPS) as described in Datagram PLPMTUD I-D.ietf-tsvwg- datagram-plpmtud. <del> 7.1.10.3. </del> <ins> 7.1.11.3. </ins> sendMsgMaxLen

Related discussion:
text: I have no opinion on Gorry's comment, but I'm a bit mystified by the "shouldn't be in the API doc" argument. Perhaps I'm not understanding the purpose of taps-interface? I thought it was a qualitative description of the controls offered to the application, which this clearly would be!
I would define taps as an interface to control network connections. So flushing state is a good thing in some scenarios for privacy but not really needed to handle network connections.
See also -- this surfaced that we have drifted on connection group versus context, which we need to fix in arch.
Martin to write a PR against API to propose a context API that would provide the intent of this functionality. Alternative is to NOP this in the API doc ("connection contexts are too implementation specific to expose in a general way" or similar)
A second alternative is a one-bit fix: a selection property that requires a given connection to be in a separate connection context (which implies a separate connection group) from other connections created in the preconnection.
A very nice approach IMO, thanks for doing thisI like this approach for the simplicity, but it still solves only half of the problem we have with connection groups vs. connection contexts. I am fine with merging this, but IMHO it does not fully Thanks NAME looks good to me now.
Code change:
left and right children, respectively.  When computing the hash of a leaf node, the hash of a "LeafNodeHashInput" object is used: <ins> Note that the "node_index" field contains the index of the leaf among the nodes in the tree, not its index among the leaves; "node_index = 2 * leaf_index". </ins> 7.6. Each member of the group maintains a GroupContext object that

Related discussion:
text: NAME - I seem to recall you had some opinions on node hashing?
Right now the LeafNodeHashInput struct uses the index of the node among the leaves, while the ParentNodeHashInput struct uses the index of the node among all nodes. This means that, for example, the index value will be the same for the second leaf and its parent ( in both cases). We should probably just use the node index in both cases.
URL is a better solution
Code change:
with an algorithm such as HMAC or an AEAD algorithm. The PublicMessage and PrivateMessage formats are defined in message- <del> framing; they represent integrity-protected and confidentiality- protected messages, respectively.  Security notions such as forward secrecy and post-compromise security are defined in security- considerations. </del> <ins> framing.  Security notions such as forward secrecy and post- compromise security are defined in security-considerations. </ins> 2.1.

Related discussion:
text: URL This definition of a handshake message is being defined in terms of a Proposal or Commit object, neither of which are defined in this session. Furthermore, PublicMessage or PrivateMessage aren’t defined either as this point in the text. To improve clarity, consider defining these key terms. The use of "respectively" in the text is suggesting that PrivateMessages don’t have integrity protection which is not accurate. (see the Cryptographic Dependencies section of the HPKE specification for more information). Is this Section 4 of RFC9180?  If so, why not say that? What would be the circumstance where the application_id extension would be treated with equal standing as something from the AS?  Why can’t this be a "MUST"? Unsaid is what to do if the proposal list is not valid.  Please clarify. Is this normative behavior required, or could it be left up to application?  The mixing of updates/removes on the same node and the SHOULD guidance already means that this "recovery from an invalid node" may not be consistent across clients/DS-es. Same observation on recovering from ReInit with any other proposals. Is there any additional retry mechanism?  Let’s say the sender of the proposal doesn’t see it reflect in the epoch after it sent proposal.  And then not in the next epoch.  Does it try resending indefinitely? This setup seems a little simplistic. If the application data is encrypted to begin with, how does the adversary know the question being posed by Alice?
Code change:
intermediary not acting as a tunnel) MUST NOT forward a malformed request or response.  Malformed requests or responses that are detected MUST be treated as a stream error (errors) of type <del> H3_GENERAL_PROTOCOL_ERROR. </del> <ins> H3_MESSAGE_ERROR. </ins> For malformed requests, a server MAY send an HTTP response indicating the error prior to closing or resetting the stream.  Clients MUST NOT

Related discussion:
text: if we want to do that. There was a hole in the error code space, so I filled it with this. I haven't pulled Push out to its own error; it doesn't seem like it belongs with this one.
We might want to add a mention of this in A.4 where we talk about PROTOCOL_ERROR
(I couldn't find anything on this, but I'm prepared to be corrected. Also, it's late, so if this is closed, I'm totally OK with that.) We're just in the process of doing full validation of pseudo-header fields (I know, seems late, what are you gonna do about that). And we realized that there is no error code for indicating this sort of error. That is, if pseudo-fields are out of order, or a request contains , or there are uppercase characters. contains lots of MUSTs, but it seems to rely entirely on the definition of "malformed" which leads to H3GENERALPROTOCOL_ERROR. This is fine, but not especially helpful in isolating problems. Could we define an error code for this specific case?
H2 just says malformed is treated as PROTOCOL_ERROR. So H3 is providing parity. There might be an argument for more fidelity but I'm not convinced it would help much. It could require more contortions in the text - do you have different error for different types of malformed?
Internally, we use a different error code. Of course, all internal error codes map to the same code for sending in RESETSTREAM/CONNECTIONCLOSE.
I'm inclined not to do much, if anything, here. They all trace back to "malformed," as you note, which leads to GENERALPROTOCOLERROR. The instances in which we use GPE are: Malformed HTTP messages Push whose request headers change across multiple promises As a substitute for more specific codes I wouldn't be opposed to splitting the first two off into a new / two new codes, because that would be consistent with our principle of indicating the general area where the failure occurred. I would push back on having separate error codes for specific ways the message could be malformed, because that's pretty expansive rabbit hole.
OK, I'm satisfied with that response. I think that we'll just have to signal extra information in the text field. Happy to close this.
Code change:
intermediary not acting as a tunnel) MUST NOT forward a malformed request or response.  Malformed requests or responses that are detected MUST be treated as a stream error (errors) of type <del> H3_GENERAL_PROTOCOL_ERROR. </del> <ins> H3_MESSAGE_ERROR. </ins> For malformed requests, a server MAY send an HTTP response indicating the error prior to closing or resetting the stream.  Clients MUST NOT

Related discussion:
text: NAME do you think an error code for "malformed message" would be useful, if we don't go into the various types of malformed?
That might be useful, yes.
This is a design change, albeit a marginal one.
NAME let's merge the associated PR but keep this issue open and marked as "call-issued"
Keeping open, as requested.
Closing this now that the IESG review of draft 33 has concluded.
In fairness, I question whether the IESG review of the HTTP drafts has concluded. But as this is not an IESG comment, I'm content to close it. People have had time to object.
Yes I agree Mike. This was due to me being over eager with the close button. The issue may not have strictly been raised in the period that the IESG were directed to review the doc, and they have yet to ballot on draft 33. But either way there was no push back from the WG on this change since draft 33 was published.
Code change:
though 1-RTT keys are available to a server after receiving the first handshake messages from a client, the server cannot consider the client to be authenticated until it receives and validates the <del> client's Finished message. </del> <ins> client's Finished message.  A server MUST NOT process 1-RTT packets until the handshake is complete.  A server MAY buffer or discard 1-RTT packets that it cannot read. </ins> The requirement for the server to wait for the client Finished message creates a dependency on that message being delivered.  A

Related discussion:
text: I realise this may be a bit out of context for this PR, but I can't find any clear definition of when the handshake is complete other than this being magically spawned from the inner workings of TLS.
Previous discussions have established the CFIN is HoL blocking, partially because even though it's not strictly necessary, if client auth is in use, it's critical to receive the client's entire Handshake flight before the server processes 1RTT packets. I don't think the current TLS text is sufficiently clear(and normative) about that. Section 4.1.1 has: "Important: Until the handshake is reported as complete, the connection and key exchange are not properly authenticated at the server. Even though 1-RTT keys are available to a server after receiving the first handshake messages from a client, the server cannot consider the client to be authenticated until it receives and validates the client's Finished message. The requirement for the server to wait for the client Finished message creates a dependency on that message being delivered. A client can avoid the potential for head-of-line blocking that this implies by sending a copy of the CRYPTO frame that carries the Finished message in multiple packets. This enables immediate server processing for those packets." URL
I agree, perhaps this section needs to say something along the lines of:
How is this not a duplicate of ?
Nevermind, I can fix this easily.
Code change:
as an asynchronous interface, they generally use a try-and-fail model.  If the application wants to read, but data has not yet been received from the peer, the call to read will fail.  The application <del> then waits for a notification to indicate when it can try again. </del> <ins> then waits and can try again later. </ins> All interaction with a Transport Services system is expected to be asynchronous, and use an event-driven model unlike sockets events.

Related discussion:
text: I guess here is not nessecarily a notification required in sychronuous communication
Merged in master to avoid conflict, and tweaked working to remove "some times", which felt a bit too colloquial in tone.
Code change:
Since the last acknowledgement was sent, "max_ack_delay" amount of time has passed. <del> reordering, congestion, and batch describe exceptions to this </del> <ins> out-of-order, congestion, and batch describe exceptions to this </ins> strategy. An endpoint is expected to bundle acknowledgements when possible.

Related discussion:
text: NAME tell me if this is sufficient, or if you wanted more references to RFC9000.
Thanks, I'm open to other suggestions if you have them, but nothing else stuck out at me. I'm reluctant to repeat the full definition of out of order in this document, given it's well defined in RFC9000.
When reviewing the draft I got caught on this part: As specified in Section 13.2.1 of [QUIC-TRANSPORT], endpoints are expected to send an acknowledgement immediately on receiving a reordered ack-eliciting packet. This extension modifies this behavior. There is an issue here in how this draft uses "reordering". Section 13.2.1 of RFC 9000 does say that ACKs should be sent immediately if: "In order to assist loss detection at the sender, an endpoint SHOULD generate and send an ACK frame without delay when it receives an ack-eliciting packet either: when the received packet has a packet number less than another ack-eliciting packet that has been received, orwhen the packet has a packet number larger than the highest-numbered ack-eliciting packet that has been received and there are missing packets between that packet and this packet." Although the first bullet clearly is reordering, the second could be caused by three different mechanisms: Reordering of packets, loss of packets, or sender intentional gap (as discussed in ) Thus, I think this section needs to be clear if actually means both of the above bullets for when to send ACK or only one of them?
Thanks Magnus, the intent was to follow the RFC9000 definition, so I'll write a PR to clarify that was the intent.
A couple of minor edits, but lgtmOk, I think this is truly the bare minimal to resolve my issue. There exist a clearer chain back towards Section 13.2.1 in RFC9000 and I guess that is sufficient.
Code change:
Removing a member. <del> Before the initialization of a group, clients publish UserInitKey </del> <ins> Before the initialization of a group, clients publish ClientInitKey </ins> objects to a directory provided to the Messaging Service. When a client A wants to establish a group with B and C, it first <del> downloads UserInitKeys for B and C.  It then initializes a group state containing only itself and uses the UserInitKeys to compute </del> <ins> downloads ClientInitKeys for B and C.  It then initializes a group state containing only itself and uses the ClientInitKeys to compute </ins> Welcome and Add messages to add B and C, in a sequence chosen by A. The Welcome messages are sent directly to the new members (there is no need to send them to the group).  The Add messages are broadcasted

Related discussion:
text: Overall, this seems OK. Just using "InitKey" would be clear and less wordy.
I tried this and that led people to confuse and
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
These keys are Client one-time use keys, so "UserInitKey" seems like a strange name.
I'm fine with ClientInitKey, as long as a client is not only a physical endpoint. Changes in the architecture doc should make this clear soon.
Code change:
choose stricter modes if desired, e.g., if a user indicates they want all WebRTC traffic to follow the default route. <del> Future versions of this document may define additional modes and/or update the recommended default modes. </del> <ins> Future documents may define additional modes and/or update the recommended default modes. </ins> Note that the suggested defaults can still be used even for organizations that want all external WebRTC traffic to traverse a

Related discussion:
text: 8445 8174 Future documents, not future versions Fix normative refs
Sure - happy to add text of this sort if we think it would be valuable. OK. :-) OK.
LGTM
Code change:
The client instance stores the continuation information from (2) for use in (8) and (10).  The client instance then interaction- <del> redirect given by the AS in (2). </del> <ins> usercode given by the AS in (2). </ins> <del> The user's directs their browser to the user code URI.  This URI is stable and can be communicated via the client software's </del> <ins> The users directs their browser to the user code URI.  This URI is stable and can be communicated via the client software's </ins> documentation, the AS documentation, or the client software itself.  Since it is assumed that the RO will interact with the AS through a secondary device, the client instance does not provide a

Related discussion:
text: Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 180278a02620d6e193b78d72e2dae6d0aa5c5c4e Inspect the deploy log: Browse the preview:
Code change:
10. <ins> [[to-be-removed: RFC Editor: please replace RFCthis with this RFC number and remove this note.]] 10.1. </ins> IANA is requested to allocate an entry to the TLS "ContentType" registry, for the "return_routability_check(TBD2)" message defined in this document.  The "return_routability_check" content type is only applicable to DTLS 1.2 and 1.3. <ins> 10.2. </ins> IANA is requested to allocate the extension code point (TBD1) for the "rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext. <ins> 10.3. IANA is requested to create a new sub-registry for RRC Message Types in the TLS Parameters registry IANA.tls-parameters, with the policy "expert review" RFC8126. Each entry in the registry must include: The initial state of this sub-registry is as follows: </ins> 11. Issues against this document are tracked at https://github.com/tlswg/

Related discussion:
text: This PR is on top of
We probably need to create a new IANA registry for RRC message types. The registry should be initialised with the 3 message types we define in the draft.
Ok.
Code change:
11. TBD. <del> 12.  References 12.1.  URIs [1] https://mailarchive.ietf.org/arch/search/?email_list=quic [2] https://github.com/quicwg/ack-frequency [3] https://github.com/quicwg </del>

Related discussion:
text: You aren't using URL, so remove it. I updated the links so that the text rendering doesn't include them twice.
Code change:
other certificate management functions, such as certificate revocation. <del> DISCLAIMER: This is a work in progress draft of ACME and has not yet had a thorough security analysis. </del> RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for this draft is maintained in GitHub.  Suggested changes should be submitted as pull requests at https://github.com/ietf-wg-acme/acme

Related discussion:
text: Addresses Martin Stiemerling's TSV-ART review
Merging based on NAME review
On the mailing list, Rifaat Shekh-Yusuf pointed out these issues: Section 7.3.5, first paragraph, second line: A "bind" word is missing between the words "to" and "an" Section 7.4.1, second paragraph, second sentence: "case" should be "cases". When the server builds the authorization object, the document is stating that the response would include "challenges" and "combinations". Remove the "combinations" as it is not being used. Section 7.5.1, the Request URIs in the examples: Should not this be /acme/authz/1234/0?
In "Responding to challenges," we use the term "response fields." These fields are defined by each challenge type, but are not described as "response fields" there. We should add a heading describing them as such in the challenge type definitions.
The other challenges don't expect you to post a payload containing a type field, so it's inconsistent for OOB-01 to do so. It should just take an empty object "{}" as its payload.
This seems fine. It seems to be protected from replay by the and parameters. I think we're OK leaving the challenge name at "oob-01", since this isn't a breaking change.
Code change:
two connection IDs to the same connection, client, or server.  In particular, all servers using a configuration MUST consistently add the same length to each connection ID, to preserve the linkability <del> objectives of QUIC-LB.  Any additional bytes SHOULD appear random unless individual servers are not distinguishable (e.g. any server using that configuration appends identical bytes to every connection ID). </del> <ins> objectives of QUIC-LB.  Any additional bytes SHOULD NOT provide any observable correlation to previous connection IDs for that connection (e.g., the bytes can be chosen at random). </ins> If there is no key in the configuration, the Connection ID is complete.  Otherwise, there are further steps, as described in the

Related discussion:
text: URL is probably not your intent, but that is what you get with this phrasing. I think that the point is that the values are not predictable to entities other than the one generating it. This appears in several places in the document.
Well URL uses "indistinguishable from random" :-) But OK, I'll seek a new formulation.