jiebi/CodeConvo huggingface dataset:
Change:
1. Deterministic Networking (DetNet) is a service that can be offered by <del> a network to DetNet flows.  DetNet provides these flows extremely low packet loss rates and assured maximum end-to-end delivery latency. General background and concepts of DetNet can be found in I-D.ietf- detnet-architecture. </del> <ins> a network to DetNet flows.  DetNet provides these flows extremely an low packet loss rates and assured maximum end-to-end delivery latency.  General background and concepts of DetNet can be found in I-D.ietf-detnet-architecture. </ins> This document specifies the DetNet data plane and the on-wire encapsulation of DetNet flows over an MPLS-based Packet Switched

Discussion:
I have started to address the comments as agreed on the call 2nd May. Before I do a more significant edit next week I want to test out the pull mechanism,
Merged Stewart's first three commits to the master.
I wonder why we need to have/propose two approaches for the aggregation?
Change:
SNI Encryption keys can be published in the DNS using the ESNIKeys structure, defined below. <ins> The version of the structure.  For this specification, that value SHALL be 0x0000.  Clients MUST ignore any ESNIKeys structure with a version they do not understand.  [[NOTE: This means that the RFC will presumably have a nonzero value.]] </ins> The first four (4) octets of the SHA-256 message digest RFC6234 of the ESNIKeys structure starting from the first octet of "keys" to the end of the structure.

Discussion:
Do we need it.
For ESNIKeys (the DNS record) I do not think we need a version for the following reasons: I think we would prefer adding extensions rather than making incompatible changes we always have the freedom to pick a new prefix (e.g. ) or a new RR type when making incompatible changes an incompatible change will require the client to query for two DNS records anyways For the ESNI extension, I also do not think that we need a version field. When we define an extension sometime in the future, we could the advertise the support as an extension in the ESNIKeys to instruct the clients that support that extension to send a CH extension that uses a different extension ID than the ESNI extension.
A lot of other TXT records have a version in them. It turns out that if you do that you can query for TXT records and get multiple answers back. Then, you pick those with the version you like. That's one query. I'm tempted to suggest that the first octet (or two) be used for a version number. It's cheap.
I'm concerned about how we iterate on these in the field. They're not tied to TLS version, so what if we decide to change the formats, as we are discussing in
a magic number (including version) is a pretty decent idea. right now _esni is in its own namespace but you can imagine someone doing a txt record that applies to every dns response so we would want to disambiguate that as well. take note to update the "concat multiple records" rule if we go down this path..
I think that having version is a good idea in sense that it allows to do experiments before the standardization completes.
Change:
decides to transmit packets, based on 'network measurements'. 'signaling about losses and/or repaired packets' (input control <del> plane for the FEC): refers to the information a FEC server can obtain from a FEC client about the performance of the FEC solution as seen from the client. </del> <ins> plane for the FEC): refers to the information a FEC sender can obtain from a FEC receiver about the performance of the FEC solution as seen from the receiver. </ins> 'coding rate' (output control plane for the FEC): refers to the coding rate that is used by the FEC solution.

Discussion:
I propose some rewording and talk about sender and receiver instead of server and client. The sender is not always the server and it could be confusing to assume the sender as being a server (e.g. in ssh it is the inverse). Let me know if you disagree on this.
Au contraire, I disliked the client-server thing from the beginning and thought we should move it to sender-receiver some day! So thanks a LOT for doing this!
LGTM, thanks for this!
Change:
3.5. <del> An additional sparse data type is available called enum.  A field of type enum can only assume the values declared in the definition. Each definition is a different type.  Only enumerateds of the same type may be assigned or compared.  Every element of an enumerated must be assigned a value, as demonstrated in the following example. Since the elements of the enumerated are not ordered, they can be assigned any unique value, in any order. </del> <ins> An additional sparse data type is available called enum.  Each definition is a different type.  Only enumerateds of the same type may be assigned or compared.  Every element of an enumerated must be assigned a value, as demonstrated in the following example.  Since the elements of the enumerated are not ordered, they can be assigned any unique value, in any order. Future extension or additions to the protocol may define new values. Implementations need to be able to parse and ignore them unless their definition states otherwise. </ins> An enumerated occupies as much space in the byte stream as would its maximal defined ordinal value.  The following definition would cause

Discussion:
with few possible exceptions, enumerateds will assume values different than the ones they were originally defined with. Backwards compatibility of Client Hello is dependent on implementations being able to ignore values they do not know about.
This doesn't seem quite right. Some enums are complete in the sense that you should not ignore unknown ones (HandshakeType) and some are not complete (ExtensionType, CipherSuite).
How about then "URL parse and ignore them unless the their deifnition states otherwise".?
sure that would be fine
Change:
IKEv2 <ins> OpenVPN </ins> Key Update: The handshake protocol may be instructed to update its keying material, either by the application directly or by the record protocol sending a key expiration event.

Discussion:
I'm pretty sure OpenVPN offers the following interfaces, because they are available as command line arguments in the openvpn tool: URL Identities and Private Keys: --cert option and --key Supported Algorithms (Key Exchange, Signatures, and Ciphersuites): --auth alg Pre-Shared Key Import: I think explicit import, as the application can specify the PSK explicitly: --secret key Pre-Shared Key Export: I think Explicit export, because the OpenVPN documentation mentions RFC 5705, RFC 5705 mentions DTLS-SRTP, and DTLS-SRTP is classified as explicit export: keying-material-exporter label len Connection Termination: OpenVPN allows connection restart based on signals SIGHUP and SIGUSR1
Change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP <del> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> 14 BCP14 when, and only when, they appear in all capitals, as shown here. </ins> Definitions of terms that are used in this document:

Discussion:
This includes all the updates to references in transport. This includes new code again. See URL It would be possible to cite BCP38 as an RFC and avoid this, but I think that the BCP reference is correct. Not as sure about the BCP145 reference, as we need to point to the RFC directly to get the section reference, but I think that is OK on balance.
Change:
description should reflect the current state of the system. Calling this method may do things such as generating new ICE <del> credentials, but does not trigger candidate gathering or cause a media state change.  Specifically, the answer is not applied, and does not become the current local description, until setLocalDescription is called. </del> <ins> credentials, but does not change the PeerConnection state, trigger candidate gathering, or or cause a media state change.  Specifically, the answer is not applied, and does not become the current local description, until setLocalDescription is called. </ins> 4.1.8.

Discussion:
Odd edge: The description createAnswer (in 4.1.7) leaves open the possibility that the application could call createAnswer twice (back-to-back with no intervening calls to other APIs) with different values in the options parameter. Is this ok? If not, should there be language that says not to do that somewhere?
This is explicitly OK, and the state machine makes it clear.
Not sure we need to say anything here, though, given the state machine.
NAME I forgot to mark this invalid but I think it may be.
Discussed with team and plan is to amend the paras that talk about cO/cA not changing media state to also mention that they don't change signaling state.
LGTM
Change:
subjectAltName field of the certificate (see RFC6125).  For a host that is an IP address, the client MUST verify that the address appears as an iPAddress in the subjectAltName field of the <del> certificate. </del> <ins> certificate.  If the hostname or address is not present in the certificate, the client MUST NOT consider the server authoritative for origins containing that hostname or address.  See Section 5.4 of SEMANTICS for more detail on authoritative access. </ins> Clients SHOULD NOT open more than one HTTP/3 connection to a given host and port pair, where the host is derived from a URI, a selected

Discussion:
Addresses NAME comments on . While this adds a new MUST NOT, I believe it's editorial because it's simply stating the implicit result of the "MUST verify" in that PR. If anyone disagrees, speak up and I'll change it. Separately, I think there's a case for this "MUST NOT" to be a "SHOULD NOT," as we all know there are situations in which clients proceed through a certificate warning. It's a reasonable semantic distinction whether the client does not consider the server authoritative but processes the result anyway (MUST NOT), or considers the server authoritative because the user told it to (SHOULD NOT). Opinions on the bikeshed welcome.
Change:
Importance: Extra <del> When we pass one or more UDP-level datagrams to the socket.  This is useful for determining how QUIC packet buffers are drained to the OS. </del> <ins> When one or more UDP-level datagrams are passed to the socket.  This is useful for determining how QUIC packet buffers are drained to the OS. </ins> Definition:

Discussion:
Work towards resolving , for the QUIC events document.
This is great. There are 2-3 instances in the h3 document as well that could use similar re-wording. I'll post a PR for that
Change:
The "ACME Order Object Fields" registry lists field names that are defined for use in ACME order objects.  Fields marked as <del> "configurable" may be included in a new-order request. </del> <ins> "configurable" may be included in a newOrder request. </ins> Template:

Discussion:
This PR is collecting changes to make sure we address during the editing window. Editorial clarifications only, please.
Both and are also TODO's for AUTH48.
Section 7.4 says: It should say , not . NAME Would you mind fixing this typo in this PR?
NAME Turns out the RFC editor caught that one (see ), so I don't have to fix it here :)
LGTM
Change:
4.2. <del> Reference Values used in appraisal might be specified as part of the appraisal policy itself, or might be obtained from a separate source, such as an Endorsement, and then used by the appraisal policy. </del> <ins> Reference Values used in appraisal come from a Reference Value Provider and are then used by the appraisal policy.  They might be conveyed in any number of ways, including: * as part of the appraisal policy itself, if the Verifier Owner either: acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; * as part of an Endorsement, if the Endorser either acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; or * via separate communication. </ins> The actual data format and semantics of any Reference Values are specific to claims and implementations.  This architecture document

Discussion:
Signed-off-by: Dave Thaler
` Huh? I thought a Reference Value came from a Reference Value Provider
Change:
is invalid. A variable-length integer representing an update to the peer's <del> "max_ack_delay" transport parameter (Section 18.2 in QUIC- </del> <ins> "max_ack_delay" transport parameter (Section 18.2 of QUIC- </ins> TRANSPORT).  The value of this field is in microseconds.  Any <del> value smaller than the min_ack_delay advertised by this endpoint </del> <ins> value smaller than the "min_ack_delay" advertised by this endpoint </ins> is invalid. <del> Receipt of invalid values in an ACK-FREQUENCY frame MUST be treated as a connection error of type PROTOCOL_VIOLATION. </del> <ins> Receipt of an empty ACK-FREQUENCY frame or invalid values in an ACK- FREQUENCY frame MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> ACK-FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission. <del> An endpoint MUST NOT send an empty ACK-FREQUENCY frame.  Endpoints MUST treat receipt of an empty ACK-FREQUENCY frame as a connection error of type PROTOCOL_VIOLATION. </del> An endpoint MAY send ACK-FREQUENCY frames multiple times during a connection and with different values. <del> An endpoint will have committed a max_ack_delay value to the peer, </del> <ins> An endpoint will have committed a "max_ack_delay" value to the peer, </ins> which specifies the maximum amount of time by which the endpoint will delay sending acknowledgments.  When the endpoint receives an ACK- FREQUENCY frame, it MUST update this maximum time to the value

Discussion:
merging.
If it doesn't change it, we should say so. If it allows it to be reduced, then we need to understand what the limits are(ie: it can't be lowered to 1us presumably?). Admittedly, the way we're using maxackdelay should be safe to assuming a 0 value, since the SRTT will accrue the excess.
Change:
structure, defined below. The version of the structure.  For this specification, that value <del> SHALL be 0xff01.  Clients MUST ignore any ESNIKeys structure with </del> <ins> SHALL be 0xff02.  Clients MUST ignore any ESNIKeys structure with </ins> a version they do not understand.  [[NOTE: This means that the RFC will presumably have a nonzero value.]]

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:
DNSSEC validation of answers received from a DNS API server or it may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recursive DNS <del> resolver. </del> <ins> resolver.  This capability might be affected by the response media type. </ins> caching describes the interaction of this protocol with HTTP caching. An adversary that can control the cache used by the client can affect

Discussion:
…dnssec
on list andrew s writes: Section 6 of -03 says this: Different response media types will provide more or less information from a DNS response. For example, one response type might include the information from the DNS header bytes while another might omit it. But section 9 says A DNS API client may also perform full DNSSEC validation of answers received from a DNS API server or it may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recursive DNS resolver. It seems to me that these are in tension with one another, because the AD and CD bits are in the header that the response type is permitted to throw away. Maybe it could be resolved thus: NEW A DNS API client may also perform full DNSSEC validation of answers received from a DNS API server or it may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recursive DNS resolver. This capability might be affected by the response media type a DNS API server supports.
Change:
content bitrate.  The size of the buffer is also commonly a fixed size.  The fill process needs to be at least fast enough to ensure that the buffer is never empty, however, it also can have significant <del> complexity when things like personalization or ad workflows are introduced. </del> <ins> complexity when things like personalization or advertising insertion workflows are introduced. </ins> The challenges in filling the buffer in a timely way fall into two broad categories: 1. content selection and 2. content variation.

Discussion:
Check against new main version for duplication on scope.
Discussion from editor's conference call: find a better place to put description of WebRTC (now that we have a good scope section).
From NAME
NAME - please see what you think of the new location for the mention of WebRTC.
Sure, this seems fine.
Change:
4.7. QUIC uses a probe timeout (PTO; see pto), with a timer based on TCP's <del> RTO computation; see RFC6297.  QUIC's PTO includes the peer's maximum expected acknowledgment delay instead of using a fixed minimum timeout. </del> <ins> retransmission timeout (RTO) computation; see RFC6298.  QUIC's PTO includes the peer's maximum expected acknowledgment delay instead of using a fixed minimum timeout. </ins> Similar to the RACK-TLP loss detection algorithm for TCP (RACK), QUIC does not collapse the congestion window when the PTO expires, since a

Discussion:
Addresses comments 2, 4, 7, 8, 9, and 11.
one tiny suggestion, but lgtm -- thanks for doing this!
Change:
receive Events (see receive-events), the application can query information about the local and Remote Endpoint: <del> Message Contexts can also be used to send messages in reply to other messages, see send-replies for details. </del> 8.1.2. Although most applications communicate over a network using well-

Discussion:
says: But it appears the Connection object is still required to call Send, so what value does this provide? I.e., how are you supposed to use replyMessageContext from the example?
I agree - it seems to me now that this really adds no value. What am I missing? I'm assigning NAME because he was among the first to propose this... maybe he can explain
Ping :)
Interim: We will remove all "reply/replies" from the API doc.
Change:
PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. <ins> Different types of certificates reflect different kinds of CA verification of information about the certificate subject.  "Domain Validation" (DV) certificates are by far the most common type.  For DV validation, the CA merely verifies that the requester has effective control of the web server and/or DNS server for the domain, but does not explicitly attempt to verify their real-world identity. (This is as opposed to "Organization Validation" (OV) and "Extended Validation" (EV) certificates, where the process is intended to also verify the real-world identity of the requester.) </ins> Existing Web PKI certificate authorities tend to run on a set of ad <del> hoc protocols for certificate issuance and identity verification.  A typical user experience is something like: </del> <ins> hoc protocols for certificate issuance and identity verification.  In the case of DV certificates, a typical user experience is something like: </ins> Generate a PKCS#10 RFC2986 Certificate Signing Request (CSR).

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:
%%% Updating Keys If the server sent an "early_data" extension, the client MUST send an <del> EndOfEarlyData after receiving the server Finished.  This indicates that all 0-RTT application_data messages, if any, have been transmitted and that the following records are protected under handshake traffic keys.  Servers MUST NOT send this message and clients receiving it MUST terminate the connection with an "unexpected_message" alert.  This message is encrypted under keys derived from the client_early_traffic_secret. </del> <ins> EndOfEarlyData message after receiving the server Finished.  If the server does not send an "early_data" extension, then the client MUST NOT send an EndOfEarlyData message.  This message indicates that all 0-RTT application_data messages, if any, have been transmitted and that the following records are protected under handshake traffic keys.  Servers MUST NOT send this message and clients receiving it MUST terminate the connection with an "unexpected_message" alert. This message is encrypted under keys derived from the client_early_traffic_secret. </ins> 4.6.

Discussion:
This follows naturally from the inclusion of EndOfEarlyData in the handshake transcript, but it doesn't hurt to mention it explicitly. See also, uh, 7511e2a259.
NAME I mention it explicitly because it tripped me up in implementation :)