jiebi/CodeConvo huggingface dataset:
Change:
resumption_count commensurate with the number of parallel sessions would be used. <ins> Priming of the ticket cache need not happen all at once.  Clients that anticipate opening frequent connections to a given server can ask for 2 or 3 tickets on each full handshake, and attain the requisite steady-state cache size after a few initial full handshakes, without substantial risk of "overshoot" or need to accurately predict the connection concurrency. When a client presenting a previously obtained ticket finds that the server nevertheless negotiates a fresh session, the client should assume that any other tickets associated with the same session as the presented ticket are also no longer valid for resumption.  This includes not only the tickets obtained during the initial full handshake, but all tickets subsequently obtained as part of subsequent resumptions.  Requesting more than one ticket in case a full handshake is forced by the server helps to keep the session cache primed. </ins> On the other hand, with e.g. server-to-server traffic with fixed <del> source addresses and no connection racing, ticket reuse may be appropriate.  Clients that wish to reuse tickets when possible should send an extension with the resumption_count set to 0, and the </del> <ins> source addresses and no connection racing, ticket reuse may be an option (ticket reuse is NOT RECOMMENDED per Section C.4 of RFC8446, and is only appropriate when replay and privacy concerns do not apply).  Clients that wish to reuse tickets when possible should send an extension with the resumption_count set to 0, and the </ins> new_session_count set to the value desired for a full handshake (typically 1).

Discussion:
This improves both happy eyeballs and ticket reuse.
I am significantly skeptical re complexity. The server looks at one counter when resuming and the other when doing a full handshake. Where's the complexity? I am sorry to say that to me personally, the complexity objection sounds rather like reluctance to reconsider the design than a response on the merit.
I still don't think that the additional count is warranted. The rationale here is reasonable, and does provide a degree of justification for the change, but I would prefer not to take on the additional complexity.Thanks for making the updatesThanks for putting this down in writing! I think a separate counter is fine given the rationale, but I disagree with all text on re-use. I think that should happen elsewhere. So, requesting changes for now, though if the WG decides to address ticket re-use here then we will revisit!
Change:
Optional parameters: none Encoding considerations: Must be encoded as using a subset of the <del> encoding allowed in RFC8259.  See RFC-AAAA for details.  This simplifies implementation of very simple system and does not impose any significant limitations as all this data is meant for machine to machine communications and is not meant to be human readable. </del> <ins> encoding allowed in RFC8259.  This simplifies implementation of a very simple system and does not impose any significant limitations as all this data is meant for machine to machine communications and is not meant to be human readable. </ins> Security considerations: See seccons of RFC-AAAA.

Discussion:
using "(i)PATCH" to refer to both PATCH methods Clarified defaulting rules Clarified name resolving rules Clarified use of "resource" Added note that application of Patch Packs is idempotent Removed "more details in RFC-AAA" from media type encoding considerations (there are no more details actually)
Change:
These requirements are satisfied by the DetNet over MPLS Encapsulation described in I-D.ietf-detnet-mpls and they are partly <del> satisfied by the DetNet IP data plane defined in I-D.ietf-detnet-ip </del> <ins> satisfied (i.e., IP flows can be identified however no DetNet sequence number is carried) by the DetNet IP data plane defined in I- D.ietf-detnet-ip </ins> 2.

Discussion:
IESG review comments resolved in this version
MPLSoUDP
MPLSoUDP: all 01-27 changes done.
can be merged once comments integrater, per Jan 27th meeting
Change:
"application" // e.g., HTTP/3's GOAWAY frame <ins> "stateless_reset" // because a stateless reset was received </ins> 5.1.7. e.g., path_updated

Discussion:
Partially Main change is adding as a PacketType. The is added as a field to packetsent and packetreceived. Any of the "unpredictable bits" can be logged as Added a trigger to to indicate if a connection goes into draining/closing because a valid statelessreset was received. Backwards compatibility break: renamed to on the NewConnectionID frame definition (for consistency). Been thinking about a way to signal an "invalid" stateless reset, but figured there is no way to distinguish it from an otherwise garbage datagram, so decided it was impossible. Not 100% sure about the "looping case" where you continually lower the packet size. Maybe that's solved by adding a generic "packetsize" trigger value to though?
LGTM!
These concepts were in flux when -01 was made and are now much more settled. Any thoughts on how to best approach this are more than welcome.
For stateless reset, I can see two options: make it a new PacketType and then simply use / make it a new event type with custom semantics At least one implementer has indicated a preference for (1), since their stack only intends to support the core events.
For stateless reset, both works for me. Most important thing is to get a way to log it at all, since this would be an interesting signal in production.
Change:
to the attacker address and thus allow an observer to break the connection. <del> 4.9. </del> <ins> 4.10. </ins> RFC4787 describes possible packet filtering behaviors that relate to NATs.  Though the guidance there holds, a particularly unwise

Discussion:
addresses
Should this ID have some mention of ICMP, because support for ICMP with UDP is a known issue for many stacks, and QUIC seems to have thought this through and we can pass that on. So, I think some mention of the use of ICMP would be helpful - at least to refer to the appropriate sections in the QUIC transport spect
I would think this would be handled by the QUIC implementation transparently and therefore it's not in the applicability statement that is directed at application designers who rather use an existing QUIC library. Or what exactly is the advise you would like to see here?
Actually, I was suggesting somewhere just to say something about ICMP because some endpoints didn't traditionally pass ICMP to UDP - this could be manageability rather than applicability?: "QUIC stacks can be designed to receive and safely utilise received ICMP messages when these are provided by the endpoint (e.g to assist PMTUD), but do not rely upon them to function."
Okay, let me think we anything like this belongs. I believe, as you say, manageability might make more sense.
We merged the PR as it seems uncontroversial but I leave the issue open for now, so we don't forget to mention this new section in the meeting.
Change:
the equipment. At minimum, the API MUST provide the state of captivity.  Further the <del> API MUST be able to provide a URI for the User Portal. </del> <ins> API MUST be able to provide a URI for the User Portal.  The scheme for the URI MUST be https so that the User Equipment communicates with the User Portal over TLS. </ins> A caller to the API needs to be presented with evidence that the content it is receiving is for a version of the API that it supports.

Discussion:
We never talked about TLS for the user portal. Add a bit of language related to that. To discuss: Should this be a MUST? Existing solutions often don't use https, but that may not be a good reason to loosen the requirement. Have I properly mentioned the URI scheme as being https? Do we even need to do that? I'm trying to put a requirement on the API that it provide a URI that lends itself to tls-based communication, which is why I took that approach.
NAME using MUST makes sense. I've taken your suggestion.
Benjamin writes: I would at least like to recommend that it's TLS, so it's considered. Discussion continuing on list.
Change:
is important to note that acknowledgement of a DATAGRAM frame only indicates that the transport-layer handling on the receiver processed the frame, and does not guarantee that the application on the <del> receiver successfully processed the data.  Thus, this signal SHOULD NOT replace application-layer signals that indicate successful </del> <ins> receiver successfully processed the data.  Thus, this signal cannot replace application-layer signals that indicate successful </ins> processing. 5.3.

Discussion:
The use of "SHOULD NOT" implies that a) this is discretionary, and b) that applications might be able to rely on it in some cases. I don't believe that either is true unless the protocol were specified entirely differently. (And that alternative specification wouldn't be practical anyway.)
Change:
1.1. <del> MLS is designed to operate in the context described in I-D.ietf-mls- architecture.  In particular, we assume that the following services are provided: An Authentication Service (AS) that enables group members to authenticate the credentials presented by other group members. A Delivery Service (DS) that routes MLS messages among the participants in the protocol.  The following types of delivery are typically required (where KeyPackage, Proposal, Commit, and Welcome are defined below): Pre-publication of KeyPackage objects for clients Broadcast delivery of Proposal and Commit messages to members of a group Unicast delivery of Welcome messages to new members of a group Sequencing of Commit messages (see sequencing) The DS and AS may also apply additional policies to MLS operations to obtain additional security properties.  For example, MLS enables any participant to add or remove members of a group; a DS could enforce a policy that only certain members are allowed to perform these operations.  MLS authenticates all members of a group; a DS could help ensure that only clients with certain types of credential are admitted.  MLS provides no inherent protection against denial of service; A DS could also enforce rate limits in order to mitigate these risks. 1.2. </del> RFC EDITOR PLEASE DELETE THIS SECTION. draft-15

Discussion:
This removes the following graf: The DS and AS may also apply additional policies to MLS operations to obtain additional security properties. For example, MLS enables any participant to add or remove members of a group; a DS could enforce a policy that only certain members are allowed to perform these operations. MLS authenticates all members of a group; a DS could help ensure that only clients with certain types of credential are admitted. MLS provides no inherent protection against denial of service; A DS could also enforce rate limits in order to mitigate these risks. My sense is this belongs in Security Considerations, not here.
This looks good to me. Please do move the removed paragraph to the security considerations, either here or in .
Change:
4.2. <del> The basic encapsulation approach is to treat a TSN Stream as an app- </del> <ins> The basic encapsulation approach is to treat a TSN Stream as an App- </ins> flow from the DetNet MPLS perspective.  The corresponding example shown in fig_tsn_mpls_ex.

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
_siblings_ if they share the same parent. A _subtree_ of a tree is the tree given by the descendants of any <del> node, the _head_ of the subtree The _size_ of a tree or subtree is </del> <ins> node, the _head_ of the subtree.  The _size_ of a tree or subtree is </ins> the number of leaf nodes it contains.  For a given parent node, its _left subtree_ is the subtree with its left child as head (respectively _right subtree_).

Discussion:
NAME Hi Brendan ! Would you mind please revert the last of the 3 changes. Even though the sentence is not amazing and your change correct, I find it better to keep explicit the fact that the root should not be included, instead of having to infer it from the fact it has no siblings :) Thanks !
You don't have to infer it -- direct paths are defined to never include the root node in the sentence just before.
Change:
the origin of the proxy. the request SHALL include a single "Connection" header field with <del> value "Upgrade". </del> <ins> value "Upgrade" (note that this requirement is case-insensitive as per HTTP). </ins> the request SHALL include a single "Upgrade" header field with value "connect-udp".

Discussion:
This is really about case-sensitivity. The Connection header field value is case-insensitive - URL The requirement is uppercase but example uses lowercase. Without citing or mentioning the case sensitivity, readers might be confused, and pedants might complain
Change:
authentication mechanisms, ciphersuites, and infrastructure functionalities. <del> 5.9. </del> <ins> 5.10. </ins> It is important that multiple versions of MLS be able to coexist in the future.  Thus, MLS offers a version negotiation mechanism; this

Discussion:
As discussed in today's interim. This is essentially repushing which should not have been reverted.
URL
Interim 2022-06-09: Informational refence from RFC to a draft is allowed Agreement to just un-revert / re-land
Fixed in
Change:
authentication mechanisms, ciphersuites, and infrastructure functionalities. <del> 5.9. </del> <ins> 5.10. </ins> It is important that multiple versions of MLS be able to coexist in the future.  Thus, MLS offers a version negotiation mechanism; this

Discussion:
I added a short section after discussing architectural issues for content framing and negotiation. It suggests [1] if the application doesn't have a more specific proposal. [1] URL
URL
Interim 2022-06-09: Informational refence from RFC to a draft is allowed Agreement to just un-revert / re-land
Fixed in
Change:
by the endpoints and network load.  An endpoint's loss detection and congestion control mechanisms however need to be tolerant of this delay at the peer.  An endpoint signals its tolerance to its peer <del> using an ACK-FREQUENCY frame, shown below: </del> <ins> using an ACK_FREQUENCY frame, shown below: </ins> Following the common frame format described in Section 12.4 of QUIC- <del> TRANSPORT, ACK-FREQUENCY frames have a type of 0xXX, and contain the </del> <ins> TRANSPORT, ACK_FREQUENCY frames have a type of 0xAF, and contain the </ins> following fields: A variable-length integer representing the sequence number <del> assigned to the ACK-FREQUENCY frame by the sender to allow </del> <ins> assigned to the ACK_FREQUENCY frame by the sender to allow </ins> receivers to ignore obsolete frames, see multiple-frames. A variable-length integer representing the maximum number of ack-

Discussion:
Also rename ACK-FREQUENCY to ACK_FREQUENCY to
Use instead of following naming convention in the transport draft.
Change:
the deletion attacks that EndOfEarlyData prevents in TLS.  Servers SHOULD aggressively age out the epoch 1 keys upon receiving the first epoch 2 record and SHOULD NOT accept epoch 1 data after the first <del> epoch 3 record is received. </del> <ins> epoch 3 record is received.  (See dtls-epoch for the definitions of each epoch.) </ins> 5.6.

Discussion:
I read through the draft and amassed a number of comments. This PR resolves the easy stuff. I'll send an email to the WG list with the more interesting ones shortly. Grammar fixes.The text describing sequence number encryption doesn't say how the receiver handles short ciphertexts. It's also phrased oddly. It says "In some (rare) cases the ciphertext may be less than 16 bytes", but the whole point of the text is to ensure it cannot be less than 16 bytes. Reword it. Whether there's a Certificate message is no longer a function of the ciphersuite, but of parameters in general. (With resumption that was already true.) The bits talking about epoch 1-3 so far before the definitions of those epochs should link to the section. Remove some remnants of EndOfEarlyData. They're still in the definition of the Handshake struct. I wasn't sure how to handle that since it was in the HandshakeType enum and we probably shouldn't call it RESERVED when it exists in TLS? Spell out [sender]applicationtrafficsecret since trafficsecret isn't defined.
This looks good to me.
These changes look good to me! NAME can you please have a look?
Change:
MessageContext object can be passed to the Send action and is retuned by each Send and Receive related events. <del> Message properties can be set and queried using the Message Context: </del> <ins> Message Properties can be set and queried using the Message Context: </ins> To get or set Message Properties, the optional scope parameter is left empty, for framing meta-data, the framer is passed.

Discussion:
This also addresses two inline [EDITOR's NOTE] items. One was about the per-message override capacity profile being inconsistent with the other one; this was solved by removing details, such that the other one defines the possible choices. Another was about selection vs. connection properties, with broken text. There was no need to add the references as the editor's note says, I thought.
this LGTM, thanks!
Change:
An acts as a gateway for requests to the (see HTTP).  The one exception is that any information it might forward in a response MUST <del> be encapsulated, unless it is responding to errors it detects before removing encapsulation of the request; see errors. </del> <ins> be encapsulated, unless it is responding to errors that do not relate to processing the contents of the encapsulated request; see errors. </ins> An , if it receives any response from the , sends a single 200 response containing the encapsulated response.  Like the request from

Discussion:
This is based on the observation from NAME that we're presuming a specific processing order at the gateway, which is unnecessary.
Change:
those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity. <del> 6. </del> <ins> 7. </ins> <del> IANA is requested to allocate an entry to the existing TLS "ContentType" registry, for the return_routability_check(TBD) defined in this document. </del> <ins> IANA is requested to allocate an entry to the TLS "ContentType" registry, for the return_routability_check(TBD) defined in this document. </ins> <del> 7. </del> <ins> IANA is requested to allocate an entry to the TLS Flags registry in the tls_flags type: Value: [[IANA please assign a value from the 32-63 value range.]] Flag Name: RRC Message: CH,SH Recommended: Y Reference: [[This document]] 8. </ins> Issues against this document are tracked at https://github.com/tlswg/ dtls-rrc/issues <del> 8. </del> <ins> 9. </ins> We would like to thank Achim Kraus, Hanno Becker and Manuel Pegourie- Gonnard for their input to this document.

Discussion:
Updated draft based on feedback from the working group. The following changes have been made: Usage of the TLS flags extension Enhanced IANA consideration section Expanded example section
added a few inline suggestions
Change:
Upon receipt of an "ech_is_inner" extension in a ClientHello, if the backend server negotiates TLS 1.3 or higher, then it MUST confirm ECH acceptance to the client by computing its ServerHello as described <del> here.  If both the "ech_is_inner" and "encrypted_client_hello" extensions are present in the ClientHello, the backend server MUST abort with an "illegal_parameter" alert. </del> <ins> here. </ins> The backend server begins by generating a message ServerHelloECHConf, which is identical in content to a ServerHello message with the

Discussion:
The text for servers rejecting both extensions present is under Backend Server, but the Server Behavior text gates that section under just the one extension. Likewise, the client-facing server text allows for both extensions to be present. Move the illegal_parameter text around and write out the four cases.
Change:
phase.  If an ICE gathering phase has already started or completed, the 'needs-ice-restart' bit will be set.  Either way, changes to the policy have no effect on the candidate pool, <del> because pooled candidates are not surfaced to the application until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. </del> <ins> because pooled candidates are not made available to the application until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. </ins> The ICE candidate pool size MUST NOT be changed after applying a local description.  If a local description has not yet been

Discussion:
The verb "surfaced" appears three times in the document without support or definition. Can you replace them with simpler language?
I don't see a reason to change this. It seems like relatively straightforward langauge.
I don't care. FWIW ... I asked a few developers what surfaced in an API meant and it did not seem a common term they used but given context they all read it the way we mean in spec..
The first two, which are about errors, will be changed to "raised" The last one, which is about candidates will be changed to "made available"
LGTM
Change:
Block-wise Transfer Option.  If a Max-Message-Size Option is indicated with a value that is greater than 1152 (in the same or a different CSM message), the Block-wise Transfer Option also indicates <del> support for BERT (see bert). </del> <ins> support for BERT (see bert).  Subsequently, if the Max-Message-Size Option is indicated with a value equal or less than 1152, BERT support is no longer indicated. </ins> 4.4.

Discussion:
2/1 Conference call with Signaling authors BERT support can be enabled and then disabled: Max-Message-Size=1153 + Block-wise Transfer => Block-wise on + BERT on Max-Message-Size=1152 => Block-wise on + BERT off This should be noted.