jiebi/CodeConvo huggingface dataset:
Change:
NOT send more than a minimum congestion window's worth of non-probing packets to the new address before path validation is complete. <ins> A client that migrates to a new address SHOULD use a preferred address from the same address family for the server. </ins> 10. Connections should remain open until they become idle for a pre-

Discussion:
This change allows servers to send a preferred address of each address family. The previous definition of preferred_address only allowed sending one address family, and this had the disadvantage of picking the non-deterministic address family used by the Initial if the client is performing Happy Eyeballs. Clients may now use the best address family based on their network attachment.
NAME I went with this approach to minimize changes from the current design. Having a list that allows different ports and future versions of IP are fine by me, but there seemed to be more pushback when that was proposed in . As long as we have a way of communicating one IPv4 address and one IPv6 address I'm happy.
We could allow multiple PreferredAddress TPs and avoid the zero-length address problem.
NAME Thank you for the clarification. I think I'm fine with that. NAME The PreferredAddress structure includes Connection ID and Stateless Reset Token. I think we should avoid requiring the server to send them twice when it is constrained by the 3-packet rule.
I've simplified the wire-format using NAME suggestion with separate port numbers
NAME I think migration and preferred address are separate parts of the protocol. The goal of this PR is to improve preferred address. It allows the client to pick the address family it transfers to right after the handshake. If the server only provides you with a preferred address family you don't have access to, you can simply ignore it - and that's not new from this PR. I've slightly tweaked the text to clarify how clients respond to preferred_address. Does this address your concerns?
I'm good with this PR. NAME -- can you see if your concern is addressed?
NAME is there anything left for me to do so this can get merged in?
You could wait until I had time to check it, that's all.
After reading my text, I am not entirely happy with it, but I lack a better suggestion.Still LG
Change:
In addition to the improved security and privacy offered by TLS 1.3, there are other significant benefits of using EAP-TLS with TLS 1.3. <del> Privacy, which in EAP-TLS means that the peer username is not disclosed, is mandatory and achieved without any additional round- trips.  Revocation checking is mandatory and simplified with OCSP stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS. </del> <ins> Privacy, which in EAP-TLS means that no information about the underlying peer identity is disclosed, is mandatory and achieved without any additional round-trips.  Revocation checking is mandatory and simplified with OCSP stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS. </ins> This document follows the terminology from I-D.ietf-tls-rfc8446bis where the master secret is renamed to the main secret and the

Discussion:
The PR only fixed some of Alan's comments. I updated the PR to address all Alan's comments that was copied in the issue
From Alan's review: >
Also >
Looks good to merge
Change:
<del> Problem Statement of IoT integrated with Edge Computing </del> <ins> IoT Edge Computing Challenges, Model and State-of-Art Review </ins> draft-hong-t2trg-iot-edge-computing-latest Abstract

Discussion:
Main change: Merged 2 sections (IoT Integrated with Edge Computing and architecture section) into a new "model" section. Updated the architecture diagram into a model diagram including the logical functions proposed by Dirk. Heavily reworded/simplified text from the previous 2 sections - I tried to keep relevant info, but removed what was redundant with the existing challenges section. The architectures (gateway vs. distributed) are shortly listed above the figure, but the rest aims to be general. Some renaming for your consideration (feel free to ignore/change): new draft title: IoT Edge Computing Challenges, Model and State-of-Art Review challenges section ("new IoT challenges" could seem a bit general): Challenges for IoT and Impacts of Edge Computing Minor: edits in abstract
Yong-Geun, Jungha, and Dirk agreed via e-mail. Since the new version has been sent to the Datatracker, I will merge.
Change:
essential zero-trust principles. This specification updates RFC 9048, the EAP-AKA' authentication <del> method, with an optional extension.  The extension, when negotiated, provides Forward Secrecy for the session key generated as a part of the authentication run in EAP-AKA'.  This prevents an attacker who has gained access to the long-term pre-shared secret in a SIM card from being able to decrypt any past communications.  In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions.  This forces attackers to use active attacks instead. </del> <ins> method, with an optional extension.  Similarly, this specification also updates the earlier version of the EAP-AKA' specification in RFC 5448.  The extension, when negotiated, provides Forward Secrecy for the session key generated as a part of the authentication run in EAP- AKA'.  This prevents an attacker who has gained access to the long- term pre-shared secret in a SIM card from being able to decrypt any past communications.  In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions.  This forces attackers to use active attacks instead. </ins> 1.

Discussion:
Can you NAME review (and Karl)?
... since 9048 did not obsolete 5448
That is is good question. I changed "updates" from RFC 5448 to RFC 9048 as the document do not even mention RFC 5448 except in the Acknowledgments. Updating increases visability and makes it easier to find the EAP-AKA'-FS document. If it updates 5448 some more mentioning of 5448 would be needed in the introduction
Closing, fix merged to the document.
Change:
The MAX_PUSH_ID frame (type=0xD) is used by clients to control the number of server pushes that the server can initiate.  This sets the <del> maximum value for a Push ID that the server can use in a PUSH_PROMISE frame.  Consequently, this also limits the number of push streams that the server can initiate in addition to the limit maintained by the QUIC transport. </del> <ins> maximum value for a Push ID that the server can use in PUSH_PROMISE and CANCEL_PUSH frames.  Consequently, this also limits the number of push streams that the server can initiate in addition to the limit maintained by the QUIC transport. </ins> The MAX_PUSH_ID frame is always sent on the control stream.  Receipt of a MAX_PUSH_ID frame on any other stream MUST be treated as a

Discussion:
Open to discussion about whether all of these are ID_ERROR or not.
I've tried to improve the readability of this section a bit; I turned Ian's suggested parallel paragraphs around to talk about why client and server would send the frame (and the corresponding responses) instead of talking about behavior on receipt. Please take a fresh look, NAME and NAME
I think there are some edge cases with the CANCELPUSH frame that we don't explain: reception of a CANCELPUSH frame with ID greater than the current push limit reception of CANCEL_PUSH with ID that has already been used
I'd also add a CANCELPUSH from the client for a PUSHID that has not been promised.
CANCEL_PUSH with a reused ID is probably indistinguishable from receiving one for a stream that's already open; you SHOULD reset the stream (which is a no-op if the stream is already full transferred).
Change:
The leaves marked as RUL (G and J) are devices which do not speak RPL at all (not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/ <del> DAC and efficient-ND only to participate in the network RFC6775.  In </del> <ins> DAC and 6LoWPAN ND only to participate in the network RFC8505.  In </ins> the document these leaves (G and J) are also referred to as an IPv6 node.

Discussion:
This covers the text from the beginning up to Section 7.2.1. These were reviewed with Pascal on March 26th. I will continue my review from Section 7.2.2 forward. More trivial editorial suggestions to follow, as well.
Many thanks for these fixs.
Change:
procedures.  It then takes the following additional steps: Verify that the current time is within the validity interval of <del> the credential. </del> <ins> the credential and that the credential's time to live is no more than 7 days. </ins> Use the public key in the server's end-entity certificate to verify the signature on the credential.

Discussion:
This suggests some minor changes to the draft, the goal being to clarify the text without changing any semantics. Most are minor, but one of the commits changes the way the client verification procedure is presented.
thanks a lot for the fixes, I like all of these changes
Change:
Messages are the concatenation of the indicated handshake messages, including the handshake message type and length fields, but not including record layer headers.  Note that in some cases a zero- <del> length HashValue (indicated by "") is passed to HKDF-Expand-Label. </del> <ins> length Context (indicated by "") is passed to HKDF-Expand-Label. </ins> Note: with common hash functions, any label longer than 12 characters requires an additional iteration of the hash function to compute.

Discussion:
This is no longer a hash value throughout, using a different name might reduce confusion a little.
Seems like an improvement.+1
Change:
4.1. This document registers a new entry under the IETF URN Sub-namespace <del> defined in RFC3553: </del> <ins> for Registered Protocol Parameter Identifiers defined in RFC3553: </ins> <del> Captive Portal Unrestricted Identifier urn:ietf:params:capport:unrestricted </del> <ins> capport:unrestricted </ins> RFC TBD (this document) <del> RFC TBD (this document) </del> <ins> https://www.iana.org/assignments/params/params.xml#params-1 </ins> <del> Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. </del> <ins> Only one value is defined (see URN above).  No hierarchy is defined and therefore no sub-namespace registrations are possible. </ins> 4.2.

Discussion:
Looking at this now it's really not clear what I was thinking before. Fortunately, IANA folks are on top things. =)
""" First, Section 4.1 states that "This document registers a new entry under the IETF URN Sub-namespace defined in [RFC3553]" however, the registry at URL defined by RFC 3553 is actually the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers registry. In addition, neither registry's columns match the columns named in the registration. IANA Question --> The authors provide the following registration information in Section 4.1 of the draft: Registry name: Captive Portal Unrestricted Identifier URN: urn:ietf:params:capport:unrestricted Specification: RFC TBD (this document) Repository: RFC TBD (this document) Index value: Only one value is defined (see URN above). No hierarchy is defined and therefore no sub-namespace registrations are possible. The IETF URN Sub-namespaces registry records the following information: Sub-namespace Reference IANA Registry Reference And the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers provide the following information: Registered Parameter Identifier Reference IANA Registry Reference Is the registration information in Section 4.1 of the draft for a different registry; or, is the information provided different from the requirements for the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers registry? """
Per Barry: """ The way we'd normally do this sort of registration is to register "capport" in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry, and create a new registry (probably with Expert Review or Specification Required, but it also could be FCFS) for "Captive Portal URN Labels" or some name like that, and that registry would have "unrestricted" in it, resulting in the full URN we want. The "Captive Portal URN Labels" registry would be the IANA Registry Reference for the first registration. """ I propose we go for the Fully Monty registration.
Given recent discussion that capport:unrestricted may be fine on its own I will close this (again) for now.
Change:
keys indicates forward progress and the loss detection timer might have been set for a now discarded packet number space. <ins> 5.2.2.1. Until the server has validated the client's address on the path, the amount of data it can send is limited to three times the amount of data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no additional data can be sent, the server's PTO alarm MUST NOT be armed until datagrams have been received from the client, because packets sent on PTO count against the anti-amplification limit.  Note that the server could fail to validate the client's address even if 0-RTT is accepted. Since the server could be blocked until more packets are received from the client, it is the client's responsibility to send packets to unblock the server until it is certain that the server has finished its address validation (see Section 8 of QUIC-TRANSPORT).  That is, the client MUST set the probe timer if the client has not received an acknowledgement for one of its Handshake or 1-RTT packets, and has not received a HANDSHAKE_DONE frame. </ins> 5.2.3. When a server receives an Initial packet containing duplicate CRYPTO

Discussion:
As pointed out in , I think that we should assume same amount of RTT variance when there is no RTT sample and when there is one sample, because variance is unknown in both cases. This PR makes that change while keeping the initial PTO being the same (i.e. 1 second), and slightly simplifies the timeout logic.
NAME Thank you for the review. Would you ming checking if the updated text has what you have suggested?
NAME NAME Thank you for the suggestions. I've applied them.
For each connection, the loss detection timeout is defined as 2 InitialRTT. I wonder if this should be 3 InitialRTT instead, because, once you have one RTT sample, PTO is calculated as 3 * InitialRTT. I do not think we have a reason to believe that the variance of RTT (which applies as a multiplier here) increases when we obtain the first sample? PS. The other benefit of making these two consistent is that we can get rid of in SetLossDetectionTimer. It would be possible to always rely on PTO calculation.
I wasn't sure if this would be design or not, but now that the PR is complete, I believe it's editorial, as NAME PR changes the pseudocode, but proscribes exactly the same behavior as the existing text.
To be precise, there is one thing that does change, and that is the initial timeout when a connection is resumed on the same path. At the moment, the only variable we recommend to remember is SRTT, and when resuming a connection on the same path, use 2 SRTT as the initial timeout. The proposed change increases that to 3 SRTT. I think this is better than status-quo, assuming that we agree that RTTVAR should be 2 * sample when there is only one known sample.
Thanks for pointing that out, I noticed that the first time around and then forgot. I'll let NAME make the call about whether he thinks this is design then.
LGTM - thanks, NAME Can you resolve the merge conflict?
Change:
keys indicates forward progress and the loss detection timer might have been set for a now discarded packet number space. <ins> 5.2.2.1. Until the server has validated the client's address on the path, the amount of data it can send is limited to three times the amount of data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no additional data can be sent, the server's PTO alarm MUST NOT be armed until datagrams have been received from the client, because packets sent on PTO count against the anti-amplification limit.  Note that the server could fail to validate the client's address even if 0-RTT is accepted. Since the server could be blocked until more packets are received from the client, it is the client's responsibility to send packets to unblock the server until it is certain that the server has finished its address validation (see Section 8 of QUIC-TRANSPORT).  That is, the client MUST set the probe timer if the client has not received an acknowledgement for one of its Handshake or 1-RTT packets, and has not received a HANDSHAKE_DONE frame. </ins> 5.2.3. When a server receives an Initial packet containing duplicate CRYPTO

Discussion:
By not arming the alarm, we avoid the possibility of having the alarm expire, send nothing, and then be immediately re-armed over and over again. We've hit bugs like that a few times in our implementation, which is why I prefer this structure of not setting the alarm if you can't send anything.
From NAME in , this is not a nit: than three times as many bytes as the number of bytes they have received. I think that the intent was that the server limit its sending, including PTO.
Discussed in ZRH. Proposed resolution is "yes".
Repeating what I said earlier: it's not clear to me that not being able to arm the PTO timer when at the limit implies that PTO packets count against the amplification limit. The reason is that you could have already armed the PTO timer at the time you hit the limit. E.g., you might be streaming 0.5RTT and so send Initial, Handshake, arm timer, 0.5RTT.
NAME the PTO should be updated when an ack-eliciting packet is sent, since the right edge moves, so that case should already be handled correctly. I'll write an editorial PR to try to make all this extra clear. Actually, the PTO section already has "A sender computes its PTO timer every time an ack-eliciting packet is sent."
Not sure how to split the difference between the limit applying to the packet that was just sent (causing PTO to be armed) or the packet that arming the PTO timer implies. Personally, I would have put the test at the point that you send a packet, but that's not how this is structured, and you do have "because packets sent on PTO count against the anti-amplification limit", which captures the important concept neatly.
Change:
is communicating and when they are communicating is protected. However, the amount of information that is exposed can be limited. <del> "Push" URIs MUST NOT provide any basis to correlate communications for a given user agent.  It MUST NOT be possible to correlate any two "push" URIs based solely on the content of the "push" URIs.  This allows a user agent to control correlation across different applications, or over time. </del> <ins> The URIs provided for "push" resources MUST NOT provide any basis to correlate communications for a given user agent.  It MUST NOT be possible to correlate any two "push" URIs based solely on their contents.  This allows a user agent to control correlation across different applications, or over time. </ins> <del> In particular, user and device information MUST NOT be exposed through the "push" URI. </del> <ins> Similarly, the URIs provided by the push service to identify a push message MUST NOT provide any information that allows for correlation across subscriptions.  Push message URIs for the same subscription MAY contain information that would allow correlation with the associated subscription or other push messages for that subscription. </ins> <del> In addition, "push" URIs established by the same user agent MUST NOT include any information that allows them to be correlated with the user agent. </del> <ins> User and device information MUST NOT be exposed through a "push" or push message URI. In addition, "push" URIs established by the same user agent or push message URIs for the same subscription MUST NOT include any information that allows them to be correlated with the user agent. </ins> This need not be perfect as long as the resulting anonymity set (see RFC6973, Section 6.1.1) is sufficiently large.  A "push" URI

Discussion:
I realized that I hadn't done due diligence in adding the message URL. This should address that (I have hooks in here for acknowledgment too).
Change:
4. Since transmitting HTTP Datagrams using QUIC DATAGRAM frames requires <del> sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a server supports HTTP </del> <ins> sending the HTTP/3 SETTINGS_H3_DATAGRAM setting, it "sticks out".  In other words, probing clients can learn whether a server supports HTTP </ins> Datagrams over QUIC DATAGRAM frames.  As some servers might wish to obfuscate the fact that they offer application services that use HTTP datagrams, it's best for all implementations that support this <del> feature to always send this Settings parameter, see setting. </del> <ins> feature to always send this setting, see setting. </ins> Since use of the Capsule Protocol is restricted to new HTTP Upgrade Tokens, it is not accessible from Web Platform APIs (such as those

Discussion:
This looks big but it consists of some minor operations H3DATAGRAM -> SETTINGSH3_DATAGRAM SETTINGS parameter -> setting Tweak the security considerations so it is explicit and grammar ain't borke
We deviate from the usual way of referring to settings, this will likely get picked up later on so may as well fix it now.