jiebi/CodeConvo huggingface dataset:
Change:
generated using the latest Appraisal Policy for Evidence. Freshness is assessed based on the Appraisal Policy for Evidence or <del> Attestation Results, that compares the estimated epoch against an </del> <ins> Attestation Results that compares the estimated epoch against an </ins> "expiry" threshold defined locally to that policy.  There is, however, always a race condition possible in that the state of the Attester, and the appraisal policies might change immediately after the Evidence or Attestation Result was generated.  The goal is merely to narrow their recentness to something the Verifier (for Evidence) or Relying Party (for Attestation Result) is willing to accept.  Some <del> flexibility on the freshness requirement, however, is a key component for enabling caching and reuse of both Evidence and Attestation Results, which is especially valuable in cases where their computation uses a substantial part of the resource budget (e.g., energy in constrained devices). </del> <ins> flexibility on the freshness requirement is a key component for enabling caching and reuse of both Evidence and Attestation Results, which is especially valuable in cases where their computation uses a substantial part of the resource budget (e.g., energy in constrained devices). </ins> <del> There are two common approaches for determining the epoch of an Evidence or Attestation Result. </del> <ins> There are three common approaches for determining the epoch of Evidence or an Attestation Result. 10.1. </ins> The first approach is to rely on synchronized and trustworthy clocks, and include a signed timestamp (see I-D.birkholz-rats-tuda) along with the Claims in the Evidence or Attestation Result.  Timestamps <del> can be added on a per-Claim basis, to distinguish the time of </del> <ins> can also be added on a per-Claim basis to distinguish the time of </ins> creation of Evidence or Attestation Result from the time that a specific Claim was generated.  The clock's trustworthiness typically requires additional Claims about the signer's time synchronization mechanism. <ins> 10.2. </ins> A second approach places the onus of timekeeping solely on the <del> Verifier (for Evidence), or the Relying Party (for Attestation </del> <ins> Verifier (for Evidence) or the Relying Party (for Attestation </ins> Results), and might be suitable, for example, in case the Attester does not have a reliable clock or time synchronization is otherwise impaired.  In this approach, a non-predictable nonce is sent by the

Discussion:
Per last week's design team discussion. Signed-off-by: Dave Thaler
In general, I like the re-introduction of the "timekeeping" subsections a lot. +1
Change:
When migrating, the new path might not support the endpoint's current sending rate.  Therefore, the endpoint resets its congestion <del> controller, as described in migration-cc. </del> <ins> controller and RTT estimate, as described in migration-cc. </ins> The new path might not have the same ECN capability.  Therefore, the endpoint verifies ECN capability as described in ecn.

Discussion:
(Broken out of .) I assert the new path may not have the same RTT, because the path could traverse a different set of network devices or be subject to different policies that influence forwarding behaviour. These are not currently listed here, but are the basis for some later text in 9.3.1. Can we mention here?
Is the RTT not included in the reset of the congestion controller?
Section 9.4 reads: "The capacity available on the new path might not be the same as the old path. Packets sent on the old path MUST NOT contribute to congestion control or RTT estimation for the new path."
I sent a PR to add "and RTT estimate" to the sentence NAME quoted to make this completely clear.
Change:
According to the RATS Architecture, two reference models for Challenge/Response Attestation have been proposed.  This section <del> highlights the information flows bewteen the Attester, Verifier and </del> <ins> highlights the information flows bewteen the Attester, Verifier, and </ins> Relying Party undergoing Remote Attestation Procedure, using these models.

Discussion:
fix some typos and optimize the newly added diagrams to adapt to the width limitation
Thanks Wei! My humongous backlog told me "you'll fix this later" and now you did. Awesome!
Change:
the request SHALL include a single "Upgrade" header with value "connect-udp". <del> For example, if the client is configured with URI template </del> <ins> For example, if the client is configured with URI Template </ins> "https://proxy.example.org/.well-known/masque/ udp/{target_host}/{target_port}/" and wishes to open a UDP proxying tunnel to target 192.0.2.42:443, it could send the following request:

Discussion:
-> a URI Template
but also is it "URI Template" or "URI template"? this seems inconsistent through the document
Change:
SETTINGS frame MUST NOT reduce any limits or alter any values that might be violated by the client with its 0-RTT data.  The server MUST include all settings which differ from their default values.  If a <del> server accepts 0-RTT, but then sends a SETTINGS frame which reduces a setting the client understands or omits a value that was previously specified to have a non-default value, this MUST be treated as a connection error of type H3_SETTINGS_ERROR. </del> <ins> server accepts 0-RTT but then sends settings that are not compatible with the previously specified settings, this MUST be treated as a connection error of type H3_SETTINGS_ERROR.  If a server accepts 0-RTT but then sends a SETTINGS frame that omits a setting value that the client understands (apart from reserved setting identifiers) that was previously specified to have a non-default value, this MUST be treated as a connection error of type H3_SETTINGS_ERROR. </ins> 7.2.5.

Discussion:
The HTTP draft currently specifies Is it intentional that a client MUST remember SETTINGS values that it doesn't support (to check that the server didn't omit a setting)?
The comment about checking for omitted settings says ... "omits a value that was previously specified to have a non-default value". In order for a client to know what the default value is for that setting, surely the client must support that setting, right?
You're right that for the client to know whether or not it's the default value it needs to support the setting (or at least know about it). Suppose the server sends SETTING BLORP (which the client knows nothing about) with value X in the original SETTINGS, but omits it on the 0-RTT resumed connection. As currently specified, if value X is not the default value, the client MUST close the connection, but if it is the default value, then that's fine. (Meaning the client needs to know all possible default values for all possible settings.) I think this needs an editorial fix to apply something like "a setting the client understands" to the bit about omitting a value as well.
Oh, I see your reading now. Interesting! Good point about an editorial tweak.
I think this could affect reserved settings (aka grease) too, just in a slightly different way. Some editorial tweak to address the problem would be good.
Change:
The default format of the certificate is DER (application/pkix-cert). The client may request other formats by including an Accept header in <del> its request. </del> <ins> its request.  For example, the client may use the media type application/x-pem-file to request the certificate in PEM format. </ins> The server provides metadata about the certificate in HTTP headers. <del> In particular, the server MUST include a Link relation header field RFC5988 with relation "up" to provide a certificate under which this certificate was issued, and one with relation "author" to indicate the registration under which this certificate was issued. </del> <ins> In particular, the server send MUST one or more link relation header fields RFC5988 with relation "up", each indicating a single certificate resource for the issuer of this certificate.  The server MAY also include the "up" links from these resources to enable the client to build a full certificate chain. The server MUST also provide a link relation header field with relation "author" to indicate the registration under which this certificate was issued. </ins> If the CA participates in Certificate Transparency (CT) RFC6962, then they may want to provide the client with a Signed Certificate

Discussion:
As PHB noted in his presentation at IETF 95, the examples in the doc should indicate clearly the start and end of payload of the JWS object, e.g.:
The spec indicates that it’s possible to request certificates of types other than DER; however, there is no indication of what those MIME types are. PEM would be a very useful format; would it be useful to indicate in here what that MIME type is, or at least where to find a list of MIME types that would work here?
The answer is :) But I can agree that it would be good to remind people of this in the spec.
CA certificates are
The documentation seems unclear as to how certificate “up” links are to handle the case of multiple intermediate certificates between root and the issued certificate. Are both certificates part of the payload of the “up” link? Does each “up” link whose payload is not a root certificate (or “last-before-root”) have its own “up” link? Thank you!
It seems pretty clear to me that the right answer is to have one "up" link per parent cert, but allow multiple links per cert. We can add some text to clarify this.
Change:
intensive, and reducing acknowledgement frequency reduces this cost at a data sender. <del> For severely asymmetric link technologies, such as DOCSIS, LTE, and satellite links, connection throughput in the forward path can become constrained when the reverse path is filled by acknowledgment packets.  When traversing such links, reducing the number of acknowledgments can achieve higher connection throughput. </del> <ins> For asymmetric link technologies, such as DOCSIS, LTE, and satellite, connection throughput in the forward path can become constrained when the reverse path is filled by acknowledgment packets RFC3449.  When traversing such links, reducing the number of acknowledgments can achieve higher connection throughput, lower the impact on other flows or optimise the overall use of transmission resources Cus22. </ins> The rate of acknowledgment packets can impact link efficiency, <del> including transmission opportunities or battery life. </del> <ins> including transmission opportunities or battery life, as well as transmission opportunities available to other flows sharing the same link. </ins> As discussed in implementation however, there can be undesirable consequences to congestion control and loss recovery if a receiver

Discussion:
This is an alternative to with the intent of fixing
There's a concrete example of one way you can arrange ACKs that has benefit in: URL This likely helps in many common scenarios. We could make a pull-request based on summarising some of this into an annexe?
Gorry -- can you point to the concrete example in the draft? I couldn't find it. Generally, I'd prefer not to spend a lot more text in the draft motivating its value; I think we've got enough in Section 2 already.
What I was hoping for was something that unpicks a little how an ACK Ratio of (say) 10 (8 if we prefer, ?) impacts the traffic. I don't see the draft body needing to specify numbers, but I know there is experience by some implementations with this approach, so a short (<1 page) explanation might be good guidance for anyone who has not worked out something better ... but I'd prefer it to be in an annexe, because such things can, and will, change as well as new CCs emerging that can have new requirements, etc.
Discussion at IETF 114: Don't need to fix. (Do we need to write some better guard rails?)
I motivated at IETF-114 that we should be able to construct an example based on this.... and that a least that would give use some guard rails to guide use.
We now merged PR which adds the references as proposed in PR . We will close this issue for now. Please open a new issue if there is something left that needs to be further addressed!
Change:
provide the same mechanisms that connected protocols do to offer Connection objects.  Implementations should wait for incoming packets for unconnected protocols on a listening port and should perform <del> five-tuple matching of packets to either existing Connection objects </del> <ins> four-tuple matching of packets to either existing Connection objects </ins> or the creation of new Connection objects.  On platforms with facilities to create a "virtual connection" for unconnected protocols implementations should use these mechanisms to minimise the handling

Discussion:
These are mostly wording changes for clarification. Feel free to cherry pick.
Can't find any problems here - this looks good.
This LGTM, many thanks!
Change:
expressions between the ensuing platform-specific dialects. The present specification intends to remove platform dependencies and <del> server as a common JSONPath specification that can be used across </del> <ins> serve as a common JSONPath specification that can be used across </ins> platforms.  Obviously, this means that backwards compatibility could not always be achieved; a design principle of this specification is to go with a "consensus" between implementations even if it is rough,

Discussion:
There does not seem to be an appetite for doing the necessary spec work. This PR will test that assertion. Filter expressions are still supported, but not "container expressions", of the form [(...)].
I think this can be added later, similar to the consensus for . Personally I still see value in having it.
Change:
this connection (thus preventing replay of client CertificateVerify messages).  This field SHALL be zero length unless used for the post-handshake authentication exchanges <del> described in Section 4.5.2. </del> <ins> described in post-handshake-authentication. </ins> A list of the signature algorithms that the server is able to verify, listed in descending order of preference.  Any

Discussion:
Fix a reference to a section that's directly citing a section number in plain text. (not linkified and will break if sections change) I assume this is a copy/paste error.
Change:
terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session. <del> 9. The WebTransport capsulework OVERVIEW defines a set of optional transport properties that clients can use to determine the presence of features which might allow additional optimizations beyond the common set of properties available via all WebTransport protocols. Below are details about support in Http2Transport for those properties. Http2Transport does not support stream independence, as HTTP/2 inherently has head of line blocking. Http2Transport does not support partial reliability, as HTTP/2 retransmits any lost data.  This means that any datagrams sent via Http2Transport will be retransmitted regardless of the preference of the application.  The receiver is permitted to drop them, however, if it is unable to buffer them. Http2Transport supports pooling, as multiple transports using Http2Transport may share the same underlying HTTP/2 connection and therefore share a congestion controller and other transport context. Http2Transport does not support connection mobility, unless an underlying transport protocol that supports multipath or migration, such as MPTCP MPTCP, is used underneath HTTP/2 and TLS. Without such support, Http2Transport connections cannot survive network transitions. 10. </del> <ins> 8. </ins> WebTransport over HTTP/2 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a

Discussion:
Moved the later section up, fixed up some sections, and consolidated some of the text.
When I did , I hadn't read Section 8. My suggestion is that this be merged into the material from the (current) Sections 4 and 5. Also, this is the first use of Http2Transport. I think that we should remove that. It's a fine class name for a C++ implementation, but we don't use it elsewhere.
Just to make sure I understand, the idea is for this "what properties do we provide and how do they satisfy the WT requirements" part to be up front with 4/5? Seems good to me. Yeah, that's mostly leftover from previous versions where we had a more defined name. Can clean up and not lose anything of value, I think.
Change:
DNS requests, in practice, that was rare enough that DNS included few mechanisms to resolve contention between DNS users and other users (whether they are also using DNS, or using other application <del> protocols). </del> <ins> protocols that share the same pathways). </ins> In recent times, the usage of UDP-based applications that were not simple query-response protocols has grown substantially, and since

Discussion:
I've edited NAME suggested text a bit, but the proposed structure was WAY more coherent than what I had assembled. Thank you for that!
From NAME Unsure whether this section really belongs to section 5 based on its contents vs. section 5 title. Especially when placed just before section 6, which is about transport protocols.
Hi, NAME I'm actually pretty sure Section 5.7 doesn't below in Section 5. :rofl: I moved the text from Section 5.7 INTO the section on UDP in Section 6, with minimal editing. I need to think about whether I need to do some more editing, but at least it's where it ought to be now.
Change:
process can be represented and performed by Internet protocols with no out-of-band human intervention. <del> When deploying a current HTTPS server, an operator generally gets a prompt to generate a self-signed certificate.  When an operator deploys an ACME-compatible web server, the experience would be something like this: </del> <ins> At time of writing, when deploying an HTTPS server, an operator typically gets a prompt to generate a self-signed certificate.  If the operator were instead deploying an ACME-compatible web server, the experience would be something like this: </ins> The ACME client prompts the operator for the intended domain name(s) that the web server is to stand for.

Discussion:
Several comprehensibility improvements to the first three sections of the draft RFC. For clarity about the contents of this pull request, please consider using the option (git CLI) or the "rich diff" option (GitHub web interface) to evaluate it, in preference to a traditional line-based diff.
NAME - I think these changes are valuable. Thank you! I don't personally have any qualms/feedback having read through the diff but it would help get more eyes on this if you emailed the ACME mailing list with a brief mention of your PR (even though it's strictly editorial I think more folks monitor the list than the Github repo).
LGTM. Thanks NAME !
Change:
8.1. <del> IANA is requested to Create an entry, encrypted_server_name(0xffce), </del> <ins> IANA is requested to create an entry, encrypted_server_name(0xffce), </ins> in the existing registry for ExtensionType (defined in RFC8446), with "TLS 1.3" column values being set to "CH, EE", and "Recommended" column being set to "Yes". 8.2. <ins> IANA is requested to create an entry, esni_required(121) in the existing registry for Alerts (defined in RFC8446), with the "DTLS-OK" column being set to "Y". 8.3. </ins> IANA is requested to create an entry in the DNS Underscore Global Scoped Entry Registry (defined in I-D.ietf-dnsop-attrleaf) with the "RR Type" column value being set to "TXT", the "_NODE NAME" column

Discussion:
(WG email coming shortly.) ESNI has different compatibility characteristics than most TLS extensions. It involves client state, and encrypting the SNI makes the ClientHello unusable for servers that do not have the key or do not implement ESNI. This breaks common rollout and rollback strategies and places strong requirements on DNS/server consistency. This makes deploying ESNI risky for servers. This change aims to reduce these deployment risks. ESNI is much more useful if widely deployed. Moreover, if ESNI is unreliable due to complex requirements on the server, clients will be disincentivized to implement it. The DNS/server consistency requirements also disincentivize rotating keys (section 7.2.5). This change introduces the notion of a "public name" which allows the client to receive authenticated signals from the server that the ESNIKeys are out of sync, so clients can safely repair key mismatches. It also aligns with existing server behavior before ESNI, so partial rollouts and rollbacks can also be handled. The fix for the latter also handles MITM scenarios, replacing the existing client recommendation: The public name notion fixes a bug in that text: an attacker could disable ESNI on all servers, given the existence of any such server.
And, as I write this, I realize I forgot to deal with Stephen's comment on the thread about the middlebox stuff! It's quite late here, so I will reword that tomorrow morning.
Currently, the connect fails when a mismatch occurs. An alternative strategy might be to return a new ESNI key that is then used for a subsequent connection.
How to understand the reliability of the public key from server?
I see that I missed something about disabling. I think that this could be a lot more explicit about the three primary cases that I talk about in the comments below.Looks mostly good, but added some nits and clarification questions.
Change:
TCP and UDP in the kernel send and receive data over the available network layer interfaces. <del> The Transport Services architecture maintains this general model of interaction, but aims to both modernize the API surface exposed for transport protocols and enrich the capabilities of the transport system implementation. </del> <ins> Sockets are bound directly to transport-layer and network-layer addresses, obtained via a separate resolution step, usually performed by a system-provided stub resolver. The Transport Services architecture evolves this general model of interaction, aiming to both modernize the API surface presented to applications by the transport layer and enrich the capabilities of the transport system implementation.  It combines interfaces for multiple interaction patterns into a unified whole.  By combining name resolution with connection establishment and data transfer in a single API, it allows for more flexible implementations to provide path and transport protocol agility on the application's behalf. </ins> The Transport Services API I-D.ietf-taps-interface defines the mechanism for an application to create network connections and

Discussion:
This is a lightweight proposal to address .
Especially in section 2, we should make it explicit that resolution is blended with connection establishment in a way that it is not in traditional sockets.
Yip - I like