jiebi/CodeConvo huggingface dataset:
Change:
that each PSK only be used with a single hash function.  This was done to simplify protocol analysis.  TLS 1.2 RFC5246, in contrast, has no such requirement, as a PSK may be used with any hash algorithm <del> and the TLS 1.2 PRF.  This means that external PSKs could possibly be re-used in two different contexts with the same hash functions during key derivation.  Moreover, it requires external PSKs to be provisioned for specific hash functions. To mitigate these problems, this document specifies a PSK Importer interface by which external PSKs may be imported and subsequently bound to a specific KDF and hash function for use in TLS 1.3.  In particular, it describes a mechanism for differentiating external PSKs by the target KDF, (D)TLS protocol version, and an optional context string.  This process yields a set of candidate PSKs, each of which are bound to a target KDF and protocol.  This expands what would normally have been a single PSK and identity into a set of PSKs and identities. </del> <ins> and the TLS 1.2 PRF.  While there is no known way in which the same external PSK might produce related output in TLS 1.3 and prior versions, only limited analysis has been done.  Applications SHOULD provision separate PSKs for TLS 1.3 and prior versions when possible. To mitigate against any interference, this document specifies a PSK Importer interface by which external PSKs may be imported and subsequently bound to a specific KDF and hash function for use in (D)TLS 1.3.  In particular, it describes a mechanism for differentiating external PSKs by the target KDF, (D)TLS protocol version, and an optional context string.  This process yields a set of candidate PSKs, each of which are bound to a target KDF and protocol, that are separate from those used in (D)TLS 1.2 and prior versions.  This expands what would normally have been a single PSK and identity into a set of PSKs and identities. </ins> 2.

Discussion:
The gist of the feedback, as I understood it, was that we made claims that were quite strong. This relaxes the language a bit and draws on RFC8446 for some example text. cc NAME NAME NAME
Hard to pick up the differences here, but I think that I got them.
Change:
The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential. <del> DelegatedCredential.cred. </del> <ins> DelegatedCredential.algorithm. </ins> DelegatedCredential.scheme.

Discussion:
Based on This adds a change log with changes from draft-01. It drops the proposed "must-use-DC" semantics from the X.509 extension. There doesn't seem to be a clean way to do this, and the complexity it adds seems to outweigh any potential benefit. The changes are as follows: Change DelegationUsage extension type to NULL. Drop support for TLS 1.2. Add the protocol version and credential signature algorithm to the Credential structure. () Specify undefined behavior in a few cases: when the client receives a DC without indicated support; when the client indicates the extension in an invalid protocol version; and when DCs are sent as extensions to certificates other than the end-entity certificate.
Not sure why CI failed ... It's building fine on my end.
Back to you NAME :)
looks great to me
Change:
in the YANG data modeling language, which are used in several YANG modules for wavelength Division multiplexing (WDM) transport networks.  The YANG module ietf-layer0-types-ext updates ietf- <del> layer0-types defined in draft-ietf-ccamp-layer0-types, which has been reduced in scope prior to publication to only cover spectrum management related aspects required for the YANG module ietf-wson- topology defined in draft-ietf-ccamp-wson-yang. </del> <ins> layer0-types defined in RFC9093, which has been reduced in scope prior to publication to only cover spectrum management related aspects required for the YANG module ietf-wson-topology defined in RFC9094. </ins> To be completed

Discussion:
draft-ietf-ccamp-layer0-types-URL for IETF 112 submission --> draft-ietf-ccamp-layer0-types-ext-URL This revision of the I-D includes the latest YANG model update - see
Submission checks passed (URL):
Thanks!Minor editorial OLD  NEW file "EMAIL"
Change:
are supported by the server. Since network addresses may change, a client SHOULD NOT assume that <del> extended token lengths are supported by a server later than 60 minutes after receiving the most-recent response with an extended token length. </del> <ins> extended token lengths are supported by a server for an unlimited duration.  Unless additional information is available, the client should assume that addresses (and therefore extended token lengths) are valid for a minimum of 1800s, and for a maximum of 86400s (1 day).  A client may use additional forms of input into this determination.  For instance a client may assume a server which is in the same subnet as the client has a similiar address lifetime as the client.  The client may use DHCP lease times or Router Advertisements to set the limits.  For servers which is not local, if the server was looked up using DNS, then the DNS resource record will have a Time To Live, and the extended token length should be kept for only that amount of time. </ins> If a server supports extended token lengths but receives a request with a token of a length it is unwilling or unable to handle, it MUST

Discussion:
This pull request tries to motivate why ~60min is about right.
section 2.2.2: doc> Since network addresses may change, a client SHOULD NOT assume that doc> extended token lengths are supported by a server later than 60 doc> minutes after receiving the most-recent response with an extended doc> token length. 60 minutes for address changes? Out of curiosity, upon what was this based? I lack a good deal of context, but this kind of feels like the kind of constant that will get baked into code and come to govern some behaviour that later might need updating.
The number indeed sounds arbitrary. We could make use of the parameter mechanics that RFC 7252 has (ACK_TIMEOUT and friends) and set the default to 1800 s.
Change:
The Server Name Indication (SNI), if any is to be used <del> As shown in tls-0-rtt, the Zero-RTT data is just added to the 1-RTT </del> <ins> As shown in tls-0-rtt, the 0-RTT data is just added to the 1-RTT </ins> handshake in the first flight.  The rest of the handshake uses the same messages as with a 1-RTT handshake with PSK resumption.

Discussion:
Reading through the spec again I found a few tiny things to fix. I'm suggesting to replace "Zero-RTT" with "0-RTT" in the paragraph because I found "Zero-RTT" used only in headlines, but "0-RTT" consistently in paragraphs.
NAME Please provide a PR to add yourself to acknowledgements.
Change:
values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-223 as "Reserved". <ins> Despite the fact that the HashAlgorithm and SignarureAlgorithm registries are orphaned, it is still import to warn implementers of pre-TLS1.3 implmentations about the dangers of blinding implementing cryptographic algorithms.  Therefore, IANA [SHALL add/has added] the following warning to the HashAlgorithm and SignatureAlgorithm: WARNING: Cryptographic algorithms and parameters will be broken or weakened over time.  Blindly implementing cipher suites listed here is not advised.  Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security. </ins> 16. Specification Required RFC8126 registry requests are registered after

Discussion:
Addresses .
MT suggested that we add the same warnings we have for cipher suites and named groups to all crypto-related registries. The two remaining crypt-related registries are HashAlgorithm and SignatureAlgorithm and both are being orphaned. Despite the fact they are being orphaned we should still add similar text. NAME Are there any others that should include the warning?
merged
Change:
out-of-order, congestion, and batch describe exceptions to this strategy. <del> An endpoint is expected to bundle acknowledgements when possible. Every time an acknowledgement is sent, bundled or otherwise, all counters and timers related to delaying of acknowledgments are reset. The receiver of an ACK_FREQUENCY frame can continue to process multiple available packets before determining whether to send an ACK frame in response, as stated in Section 13.2.2 of QUIC-TRANSPORT. </del> 7.1. As specified in Section 13.2.1 of QUIC-TRANSPORT, endpoints are

Discussion:
Also moves text about batch processing of packets into an existing section.
Section 7 "Sending Acknowledgments" says: I'm not sure what this means... like sending the same ACK twice in the same QUIC packet? Or generally sending two different ACK frames in the same QUIC packet? Does that really make sense in any case? Can't you always just send the more recent ACK or create one combined ACK frame with all information?
Change:
by the Attesting Environment that has the key material that protects the conveyance channel <del> The Root of Trust protects both the conveyance channel key </del> <ins> The root of trust protects both the conveyance channel key </ins> material and the Attesting Environment with equivalent strength protections.

Discussion:
Per design team meeting today Signed-off-by: Dave Thaler
I think it should be root of trust because it is not a defined term like Attester or Verifier.
Lower case is fine, I think. Any objections?
Change:
If packets sent prior to the largest acknowledged packet cannot yet be declared lost, then a timer SHOULD be set for the remaining time. <del> Using max(SRTT, latest_RTT) protects from the two following cases: </del> <ins> Using max(smoothed_rtt, latest_rtt) protects from the two following cases: </ins> <del> the latest RTT sample is lower than the SRTT, perhaps due to reordering where the acknowledgement encountered a shorter path; </del> <ins> the latest RTT sample is lower than the smoothed RTT, perhaps due to reordering where the acknowledgement encountered a shorter path; </ins> <del> the latest RTT sample is higher than the SRTT, perhaps due to a sustained increase in the actual RTT, but the smoothed SRTT has not yet caught up. </del> <ins> the latest RTT sample is higher than the smoothed RTT, perhaps due to a sustained increase in the actual RTT, but the smoothed RTT has not yet caught up. </ins> The RECOMMENDED time threshold (kTimeThreshold), expressed as a round-trip time multiplier, is 9/8.

Discussion:
In section "Time Threshold", is used for the first time. I guess that would reference the same value before called ? If that's the case they should be named the same. Further down in the same paragraph "smoothed SRTT" is used which is even more confusing. SRTT is used a few more times further down.
There was a cleanup a while ago to ensure definitions such as SRTT happened before use, but that might have been lost in recovery to transport migration?
:+1:
Change:
security.  The Media Distributor MAY change some of the RTP header information that would impact the end-to-end integrity.  In that case, the original value of any RTP header field that is changed is <del> included in a new RTP header extension called the Original Header Block.  The new RTP packet is encrypted with the hop-by-hop cryptographic algorithm before it is sent.  The receiving endpoint decrypts and checks integrity using the hop-by-hop cryptographic algorithm and then replaces any parameters the Media Distributor changed using the information in the Original Header Block before decrypting and checking the end-to-end integrity. </del> <ins> included in an "Original Header Block" that is added to the packet. The new RTP packet is encrypted with the hop-by-hop cryptographic algorithm before it is sent.  The receiving endpoint decrypts and checks integrity using the hop-by-hop cryptographic algorithm and then replaces any parameters the Media Distributor changed using the information in the Original Header Block before decrypting and checking the end-to-end integrity. </ins> One can think of the double as a normal SRTP transform for encrypting the RTP in a way where things that only know half of the key, can

Discussion:
This PR responds to IESG review comments from Magnus Westerlund, except for his comments on RED, which I haven't quite figured out how to address yet.
LGTM with nits
Change:
6. <ins> The following modules extends the RFC8995 Voucher Request to include a signed artifact from the registrar agent. 7. </ins> This section map the requirements to support proof of possession and proof of identity to selected existing enrollment protocols.  Note that that the work in the ACE WG described in I-D.selander-ace-coap-

Discussion:
Do we augment 8995? Do we augment 8366? Do we need to do both? What does it mean to augment something that augments something?
Hi, I'm working on that pull request right now. . I don't know how to manage YANG stuff in a bare MT / XML Makefile. We extend 8995 for the voucher-request. There are some practical YANG practices that I'm missing.
I enhanced the voucher-request with two additional leafs for the agent-sign-cert and the agent-provided-proximity-certificate.
YANG module for the extension of the voucher request will be put into the next update of the draft. The will need more investigation by the YANG doctor.
I guess this is fine as far as it goes, but I will admit to being nervous about augmenting a voucher-request (because it in itself is a voucher), but beyond that we also have to add a new assertion enumeration.
Change:
4.1.2. <del> A resource directory can advertise its resources in DNS-SD using the service names "_rd._udp", "_rd-lookup-res._udp" and "_rd_lookup- ep._udp" defined in this document for its Directory Resource, its resource lookup and endpoint lookup resource, respectively.  A "path" key SHOULD be set, and indicate the path on the server (starting with a slash). </del> <ins> A resource directory can advertise its presence in DNS-SD using the service name "_core-rd._udp" defined in this document. </ins> <del> The use of those service names implies that CoAP-over-UDP is used. With that information, the host name and port given in the SRV record and the path from the TXT record, the discovering client can perform RD and URI discovery in a single step. </del> <ins> The use of that service names implies that CoAP-over-UDP is used. The SRV record points the client to a host name and port to use as a starting point for the URI discovery steps of discovery. </ins> <del> When the "path" key is absent, the client MUST discovery the URIs on the server according to discovery. This section is a concrete application of the more generic mechanism that is being developed as I-D.ietf-core-rd-dns-sd. </del> <ins> This section is a simplified concrete application of the more generic mechanism specified in I-D.ietf-core-rd-dns-sd. </ins> 4.2.

Discussion:
Reviewing the discussion in [1] and [2], my original patch seems to have overshot. [1]: URL [2]: URL
Much more sensibleless ambitious and more correct. The outcome in discussion in the Friday meeting was that the resource-directory specification should simply define the small number of DNS-SD service types that are needed for resource directory discovery. We said details were to be taken to the list, which I want to initiate now. In the meeting, I gave the three examples core-URL, core-rd-URL, and core-URL — noting that while core-rd is a proper RD service type, core-rd-tls isn’t. To cover the six transports we have for CoAP today (coap, coaps, coap+tcp, coaps+tcp, coap+ws, coaps+ws), we would need four service types on top of tcp and could use two of them over udp? Grüße, Carsten
Change:
11. Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran, <del> Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, and Will Law for very helpful suggestions, reviews and comments. </del> <ins> Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Linda Dunbar, Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra, and Will Law for very helpful suggestions, reviews and comments. </ins> 12.  References

Discussion:
Also add Linda to ACKs and add stream: IETF (this is now an XML2RFCv3 thing)
From NAME
responding to the application-level feedback that indicates a bottleneck link somewhere along the path. We agree that "link" is ambiguous. In this section, we're talking about a bottleneck, so we don't need to to say "link", BUT we will clean up other occurrences of "link" in the document - one is actually a URL. implementing some forms of congestion control that probe for bandwidth. The conclusion says that the QoE is poorer when the two methods don't coordinate. Question 2: Both methods are implemented on the Media server, they should coordinate by nature, aren't they? You might think so, but they don't, for various reasons (transport protocols being implemented by OS vendors, and media servers and players are implemented by completely different people. We say that in 3.2, but we describe media servers as "implementing transport protocols". That should have been "rely on". This might change, with transport protocols being implemented in user space and packaged as libraries that are shipped media servers, but that's the case today.
Change:
As a result of sharing the media streams, the application will end up with N parallel PeerConnection sessions, each with a local and remote description and their own local and remote addresses.  The media flow <del> from these sessions can be managed by specifying SDP direction attributes in the descriptions, or the application can choose to play </del> <ins> from these sessions can be managed using setDirection (see sec.transceiver-set-direction), or the application can choose to play </ins> out the media from all sessions mixed together.  Of course, if the application wants to only keep a single session, it can simply terminate the sessions that it no longer needs.

Discussion:
LGTM
Section 3.8.2 - "the media flow from these sessions can be managed by specifying SDP direction attributes in the descriptions". This seems out of place. Surely flipping URL is a much simpler way of managing them if the problem is what to play to the user? Suggestion: Remove text.
Change:
the reports in sub-batches of 10.  Each sub-batch takes two round- trips to process. <del> [OPEN ISSUE: Should there be an indication of whether a given aggregate request is a continuation of a previous sub-batch?] </del> The aggregation flow can be thought of as having three phases for transforming each valid input report share into an output share:

Discussion:
This PR includes several text cleanups previously folded into : The upload section explicitly describes the call to An obsolete TODO in the aggregation section is removed Text that incorrectly instructed leaders to abort if the helper finishes aggregation is corrected.
Change:
proposing and comparing FEC coding solutions in communication systems.  As one example, this draft proposes discussions on the impact of the proposed FEC solution on the congestion control, <del> especially loss-based congestion control such as CUBIC. </del> <ins> especially loss-based congestion control such as CUBIC.  When a research work aims at improving the throughput by hiding the packet loss signal from the congestion control, the authors should 1) discuss the advantages of using the proposed FEC solution compared to replacing the congestion control by one that ignores a portion of the encountered losses, 2) critically discuss the impact of hiding packet loss from the congestion control mechanism. </ins> 8.

Discussion:
Added some precisions on the research section. When authors improve throughput by hiding the congestion signal, I propose to compare using FEC to hide the congestion signal with replacing the current congestion control by one that similarly ignores the loss signal without using any FEC. Concerning the solutions proposing to disambiguate the ACKs from the recoveries, I cited QUIC-FEC. We should also cite TENTET. NAME do you have a reference of an article about TENTET ? Do not hesitate to suggest changes before merging.
That looks very fine to me! We may just be missing the reference to tentet before merging the branch
Change:
Version Negotiation packet and the Version Information was missing, the client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of <del> type "VERSION_NEGOTIATION_ERROR". </del> <ins> type VERSION_NEGOTIATION_ERROR. </ins> If the client received and acted on a Version Negotiation packet, the <del> client MUST validate the server's "Other Versions" field.  The "Other Versions" field is validated by confirming that the client would have </del> <ins> client MUST validate the server's Other Versions field.  The Other Versions field is validated by confirming that the client would have </ins> attempted the same version with knowledge of the versions the server supports.  That is, the client would have selected the same version if it received a Version Negotiation packet that listed the versions <del> in the server's "Other Versions" field, plus the negotiated version. </del> <ins> in the server's Other Versions field, plus the negotiated version. </ins> If the client would have selected a different version, the client MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type <del> "VERSION_NEGOTIATION_ERROR".  This connection closure prevents an </del> <ins> VERSION_NEGOTIATION_ERROR.  This connection closure prevents an </ins> attacker from being able to use forged Version Negotiation packets to force a version downgrade. <del> This validation of "Other Versions" is not sufficient to prevent </del> <ins> This validation of Other Versions is not sufficient to prevent </ins> downgrade.  Downgrade prevention also depends on the client ignoring Version Negotiation packets that contain the original version; see incompat-vn. After the process of version negotiation in this document completes, the version in use for the connection is the version that the server <del> sent in the "Chosen Version" field of its Version Information.  That </del> <ins> sent in the Chosen Version field of its Version Information.  That </ins> remains true even if other versions were used in the Version field of long headers at any point in the lifetime of the connection; endpoints MUST NOT change the version that they consider to be in use

Discussion:
In , NAME points out that the backticks don't render nicely in the TXT version, so let's remove them
Change:
9. <del> At any point, the application can query Connection Properties.  It can also set per-connection Protocol Properties. </del> <ins> The application can set per-connection Protocol Properties (see protocol-props).  Certain Procotol Properties may be read-only, on a protocol- and property-specific basis.  ~~~ Connection.SetProperty(property, value) ~~~ At any point, the application can query Connection Properties.  ~~~ ConnectionProperties := Connection.GetProperties() ~~~ </ins> Depending on the status of the connection, the queried Connection Properties will include different information:

Discussion:
Rather than saying "this can only be queried" everywhere, I split this into setting and querying now, and I also moved SoftErrors in there. It's not precisely "querying" for a Property, but it's the closest match - better than "Connection Termination", I think (this is where SoftErrors were before).
NAME what about "Connection Maintenance: Setting Properties and Obtaining Information" ?
Maintenance sounds a bit strange to me, "Managing Connections: Setting Properties and Obtaining Information" ?
I like it (and I agree about "maintenance" being slightly strange)
Managing sounds good to me too.
Ack, done
lgtm, thanks!