jiebi/CodeConvo huggingface dataset:
Change:
Internet when a NAT is on path, larger values are preferable if the deployment can consistently survive NAT rebinding, or is known to be in a controlled environments like e.g.  data centres in order to <del> lower network and computational load.  Sending PING frames more frequently than every 30 seconds over long idle periods may result in excessive unproductive traffic in some situations, and to unacceptable power usage for power-constrained (mobile) devices. Additionally, time-outs shorter than 30 seconds can make it harder to handle trasient network interruptions, such as VM migration or coverage loss during mobilty. </del> <ins> lower network and computational load. Sending PING frames more frequently than every 30 seconds over long idle periods may result in excessive unproductive traffic in some situations, and to unacceptable power usage for power-constrained (mobile) devices.  Additionally, time-outs shorter than 30 seconds can make it harder to handle transient network interruptions, such as VM migration or coverage loss during mobilty. </ins> Alternatively, the client (but not the server) can use session resumption instead of sending keepalive traffic.  In this case, a

Discussion:
These are pretty big. If you would prefer that I create a PR for each individual commit, that can be done. It turns out that there were a lot of things I found needed work. For instance, this completely redoes the 0-RTT advice.
It did kinda snowball, for which I apologize. I was trying to get something under your nose before I got swamped by meetings. I am also on vacation next week. I'm reading through and there is some really good stuff in the doc. I have started to open issues where I don't think the fixes are so simple.
Aside from the keep-alive tweak and the idempotence change, these are all editorial and LGTM, thanks! The keepalive tweak is also good. Having looked at URL, the text here is a good applicability-appropriate view on what's there now. assuming discussion there converges to mostly the same thing, I'd be happy to merge this. (in the future, no need to make tiny PRs, but splitting into "editorial-rollup" and "substantive editorial changes" would be nice to separate discussion, since the former shouldn't need much of it)Changes look all ready good. Thanks! I just have left one minor comment/question to double-check before we merge.
Change:
therefore allow clients to detect and recover from this situation (see esni-resolution for more details). <del> Content providers operating in Split Mode SHOULD ensure that the A and AAAA records for ESNI-enabled server names do not allow identifying the server name from the IP address.  This can for example be achieved by always returning the same records for all ESNI-enabled names, or by having the function that picks addresses from a pool not depend on the server name.  This yields an anonymity set of cardinality equal to the number of ESNI-enabled server domains supported by a given client-facing server.  Thus, even with SNI encryption, an attacker which can enumerate the set of ESNI-enabled domains supported by a client-facing server can guess the correct SNI with probability at least 1/K, where K is the size of this ESNI- enabled server anonymity set.  This probability may be increased via traffic analysis or other mechanisms. </del> <ins> Content providers SHOULD ensure that the A and AAAA records for ESNI- enabled server names do not allow identifying the server name from the IP address.  This can for example be achieved by always returning the same records for all ESNI-enabled names, or by having the function that picks addresses from a pool not depend on the server name.  This yields an anonymity set of cardinality equal to the number of ESNI-enabled server domains supported by a given client- facing server.  Thus, even with SNI encryption, an attacker which can enumerate the set of ESNI-enabled domains supported by a client- facing server can guess the correct SNI with probability at least 1/ K, where K is the size of this ESNI-enabled server anonymity set. This probability may be increased via traffic analysis or other mechanisms. </ins> The following sections describe a DNS record format that achieve these goals.

Discussion:
Based on comments in Montreal, I believe that the authors no longer intend to document the partial-split configuration.
Change:
IESG <del> 8.2.2. </del> <ins> 8.3.2. </ins> application

Discussion:
While we're here, I'd like to recommend we align the name of this well-known value to align with the request/response names. In particular, what do folks think about "/well-known/private-token-issuer-directory"?
you're probably missing a registration for your well-known in the IANA considerations, the registry is URL
Change:
be completed using HTTP/1.1, where HTTP/2 is necessary, the more verbose frame format from RFC7540 is used. <ins> Examples do not include specific methods for push message encryption or application server authentication because the protocol does not define a mandatory system.  The examples in I-D.ietf-webpush-vapid and I-D.ietf-webpush-encryption demonstrate the approach adopted by the API for its requirements. </ins> 2. A general model for push services includes three basic actors: a user

Discussion:
"The ciphertext of the push message is included in the body of the request." The example looks like base64 - it should be clear it's binary content ( ciphertext is not base64) If we give an example with ciphertext, it should include the extra headers. Alternative is to say "The content of the push message is included", and have a "I am walrus" example" - with a link to the encryption document for proper encrypted example. But since most implementations will require encryption - I think it's better to add the extra headers and make it clear it's binary.
I prefer the "Alternative" approach to keep the webpush examples simple and uncluttered. I will add a reference to the example in to illustrate encryption.
Change:
Services are: the Preconnection, the bundle of Properties that describes the <del> application constraints on the transport; </del> <ins> application constraints on, and preferences for, the transport; </ins> the Connection, the basic object that represents a flow of data as Messages in either direction between the Local and Remote

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:
retransmission of the 0-RTT data may cause the remote application to receive the Message multiple times. <ins> Note that for protocols that do not protect against duplicated messages, e.g., UDP, all messages MUST be marked as Idempotent.  In order to enable protocol selection to choose such a protocol, Idempotent MUST be added to the TransportProperties passed to the Preconnection.  If such a protocol was chosen, disabling Idempotent on individual messages MUST result in a SendError. </ins> 7.3.5. Boolean

Discussion:
This came up in a dinner among some of us yesterday: all UDP messages should be understood as being idempotent, because UDP doesn't protect the receiver against getting duplicates. This is different from unreliable transmission with, e.g., SCTP (or, probably, a future such extension of QUIC?), where you can be sure you're not getting a duplicate.
wfm
Change:
Abstract The organizational separation between the operator of a TLS server <del> and the certificate authority that provides it credentials can cause problems, for example when it comes to reducing the lifetime of certificates or supporting new cryptographic algorithms.  This document describes a mechanism to allow TLS server operators to create their own credential delegations without breaking </del> <ins> and the certificate authority can create limitations.  For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certificate authority.  This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking </ins> compatibility with clients that do not support this specification. 1.

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:
request. In order to support multiple "classes" of clients (e.g.  IPv4 only, <del> IPv6 only with DHCPv6 (RFC3315), and IPv6 only with RA) the captive </del> <ins> IPv6 only with DHCPv6 (RFC8415), and IPv6 only with RA) the captive </ins> network can provision the client with the URI via multiple methods (IPv4 DHCP, IPv6 DHCP, and IPv6 RA).  The captive portal operator SHOULD ensure that the URIs provisioned by each method are equivalent to reduce the chance of operational problems.  The maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer <del> than 255 bytes should not be provisioned via IPv6 DHCP or IPv6 RA either. </del> <ins> than 255 bytes should not be provisioned via IPv6 DHCP nor IPv6 RA options. </ins> In all variants of this option, the URI MUST be that of the captive portal API endpoint, conforming to the recommendations for such URIs

Discussion:
Additionally: Update DHCPv6 reference from RFC 3315 to RFC 8415. Include reference to DHCPv6 option format text. Include reference to DHCPv4 option format text in RFC 2132. The DHCPv4 and v6 diagrams are not harmonized in this change. Each option format has sever documents using the style currently depicted. Issue:
""" — Sections 2.1 and 2.2 — Why aren’t the diagrams for the two in the same format? And neither explicitly says what the length of the “len” field is. In the v4 version, one has to guess that it’s the same size as the “code” field, 1 byte. In the v6 version, one can look at the diagram. I suggest making the diagrams the same format (calibrated with bit/byte markings) and explicitly specifying in the text the size of the “len” field. """ I rather suspect this goes back to whichever source documents from which the option format text was copied. Nevertheless, harmonizing them seems reasonable.
Additionally: we should restate the 255 byte limit from DHCPv4 in each option's description.
Change:
Abstract <del> The Messaging Layer Security (MLS) protocol I-D.ietf-mls-protocol </del> <ins> The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol) </ins> specification has the role of defining a Group Key Agreement protocol, including all the cryptographic operations and serialization/deserialization functions necessary for scalable and

Discussion:
According to I-D Nits: Checking nits according to URL : The abstract seems to contain references ([I-D.ietf-mls-protocol]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 557: 'URL forked group states MUST be deleted...'
TY!
Thanks NAME
Change:
The payload of a UDP datagram carrying the first Initial packet MUST be expanded to at least 1200 bytes, by adding PADDING frames to the <del> Initial packet and/or by combining the Initial packet with a 0-RTT packet (see packet-coalesce).  Sending a UDP datagram of this size ensures that the network path supports a reasonable Maximum Transmission Unit (MTU), and helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address; see address-validation. </del> <ins> Initial packet and/or by coalescing the Initial packet (see packet- coalesce).  Sending a UDP datagram of this size ensures that the network path supports a reasonable Maximum Transmission Unit (MTU), and helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address; see address- validation. </ins> The datagram containing the first Initial packet from a client MAY exceed 1200 bytes if the client believes that the Path Maximum

Discussion:
It doesn't matter what an Initial is coalesced with. It could be a 0-RTT packet, it could be an (invalid) Handshake packet, or the bytes after the Initial packet could be completely random. The only thing that matters is that the resulting UDP datagram has at least 1200 bytes.
CI failure isn't my fault. The faulty commit seems to be bbe2b80d490c39c1d5900a5f00b4bbe11a29c4df.
Change:
4.3. <del> Non-low-latency live delivery of media is defined here as a live stream that does not have a latency target shorter than 10 seconds. </del> <ins> Non-low-latency live delivery of media is defined here as a livestream that does not have a latency target shorter than 10 seconds. </ins> This level of latency is the historically common case for segmented video delivery using HLS RFC8216 and DASH MPEG-DASH.  This level of

Discussion:
From NAME
NAME - thank you for this review. You caught a lot more things than I was hoping were still in there. :grinning:
PR should address these issues (and more).
Agree with NAME that this fixed lots of stuff. I'd like to leave it open so we can run this tool again after addressing more issues.
Change:
an Attester, which enables Relying Parties, for example, to assess an Attester's trustworthiness. <ins> 7.1.1. According to the RATS Architecture, two reference models for Challenge/Response Attestation have been proposed.  This section highlights the information flows bewteen the Attester, Verifier and Relying Party undergoing Remote Attestation Procedure, using these models. Passport Model The passport model is so named because of its resemblance to how nations issue passports to their citizens.  In this Model, the attestation sequence is a two step procedure.  In the first step, an Attester conveys Evidence to a Verifier which compares the Evidence against its appraisal policy.  The Verifier then gives back an Attestation Result to the Attester, which simply caches it.  In the second step, the Attester presents the Attestation Result (and possibly additional Claims/evidence) to a Relying Party, which then compares this information against its own appraisal policy to establish the trustworthiness of the attestor. BackGround Check Model The background-check model is so named because of the resemblance of how employers and volunteer organizations perform background checks. In this model, the attestation sequence is initiated by a Relying Party.  The Attester conveys Evidence to the Relying Party, which does not process its payload, but realys the message and optionally check its signature against a policed trust anchor store.  Upon receiving the evidence the Relying Party initiates a session with the Verifier.  Once session is established, it forwards the received Evidence to the Verfier.  The Verifier, appraises the received Evidence according to its appraisal policy for Evidence and returns a corresponding Attestation Result to the Relying Party.  The Relying Party then checks the Attestation Result against its own appraisal policy to conclude attestation. </ins> 7.2. Uni-Directional Remote Attestation procedures can be initiated both

Discussion:
NAME : Please let me know, your views as to how is the information flow and anything else, we need to add?
Change:
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. <del> The following terms are used across the documents specifying the WebRTC suite, in the specific meanings given here.  Not all terms are used in this document.  Other terms are used in their commonly used meaning. The list is in alphabetical order. Undefined term.  See "SDP Agent" and "ICE Agent". Application Programming Interface - a specification of a set of calls and events, usually tied to a programming language or an abstract formal specification such as WebIDL, with its defined semantics. Used synonymously with "Interactive User Agent" as defined in the HTML specification W3C.WD-html5-20110525.  See also "WebRTC User Agent". An abstraction that allows data to be sent between WebRTC endpoints in the form of messages.  Two endpoints can have multiple data channels between them. An implementation of the Interactive Connectivity Establishment (ICE) I-D.ietf-ice-rfc5245bis protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166). Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another party, and the reaction can be observed by the first party, with the total time required for the action/reaction/observation is on the order of no more than hundreds of milliseconds. Audio and video content.  Not to be confused with "transmission media" such as wires. The path that media data follows from one WebRTC endpoint to another. A specification of a set of data units, their representation, and rules for their transmission, with their defined semantics.  A protocol is usually thought of as going between systems. Media where generation of content and display of content are intended to occur closely together in time (on the order of no more than hundreds of milliseconds).  Real-time media can be used to support interactive communication. The protocol implementation involved in the Session Description Protocol (SDP) offer/answer exchange, as defined in RFC3264 section 3. Communication that happens in order to establish, manage and control media paths and data paths. The communication channels used between entities participating in signaling to transfer signaling.  There may be more entities in the signaling path than in the media path. </del> 3. For browser-based applications, the model for real-time support does

Discussion:
ekr had the following comment: S 2.4. Why do you have two terminology sections? I would merge them.
Most of my comments are consequential.
Change:
The sender can use the Max-Message-Size elective option to indicate the maximum message size in bytes that it can receive. <del> As per Section 4.6 of RFC7252, the default value (and the value used </del> <ins> As per Section 4.6 of RFC7252, the base value (and the value used </ins> when this option is not implemented) is 1152.  A peer that relies on this option being indicated with a certain minimum value will enjoy limited interoperability.

Discussion:
Consistent language for empty messages. Edits to Signaling section - including replacing Default Value in tables with Base Value for clarity.
Change:
11. <del> A group is always created with a single member, the "creator".  The other members are added when the creator effectively sends itself Add proposals, commits them, and then sends the corresponding Welcome message to the new participants.  These processes are described in detail in add, commit, and joining-via-welcome-message. </del> <ins> A group is always created with a single member, the "creator".  Other members are then added to the group using the usual Add/Commit mechanism. The creator of a group is responsible for setting the group ID, ciphersuite, and initial extensions for the group.  If the creator intends to add other members at the time of creation, then it SHOULD Fetch KeyPackages for the members to be added, and select a ciphersuite and extensions according to the capabilities of the members.  To protect against downgrade attacks, the creator MUST use the "capabilities" information in these KeyPackages to verify that the chosen version and ciphersuite is the best option supported by all members. Group IDs SHOULD be constructed in such a way that there's an overwhelmingly low probability of honest group creators generating the same group ID, even without assistance from the Delivery Service. For example, by making the group ID a freshly generated random value of size "KDF.Nh".  The Delivery Service MAY attempt to ensure that group IDs are globally unique by rejecting the creation of new groups with a previously used ID. </ins> The creator of a group MUST take the following steps to initialize the group: <del> Fetch KeyPackages for the members to be added, and select a version and ciphersuite according to the capabilities of the members.  To protect against downgrade attacks, the creator MUST use the "capabilities" information in these KeyPackages to verify that the chosen version and ciphersuite is the best option supported by all members. </del> Initialize a one-member group with the following initial values: Ratchet tree: A tree with a single node, a leaf containing an

Discussion:
This PR is an alternative to . This PR updates the group creation process so that epoch 0 is a "full-fledged" epoch, with an epoch secret (and all the derivatives) instead of just an init secret. One implication of that is that the interim transcript hash can now be computed in the usual way, by extending the confirmed transcript hash with a confirmation tag: This has the nice side effect of immediately mixing the epoch secret into the transcript hash, helping the group diverge (a concern NAME raised on the call today). While I was editing the group creation section, I also rationalized the requirements a bit. One reason that came up is that the group creation section currently assumes you're always starting with multiple members. So the MUST-level requirement to fetch key packages has been downgraded to a SHOULD. Finally, I updated the specification of GroupInfo to explain the fields, in particular explaining how you get the confirmation tag in epoch 0 or later epochs.
Since this PR clarifies more than and the solution is equally good, I'd suggest closing and merging this one.
Change:
This document adds an entry to the "HTTP/2 Frame Type" registry, the "HTTP/2 Settings" registry, and the "HTTP/2 Error Code" registry, all <del> defined in RFC7540.  It also registers a HTTP upgrade token in the </del> <ins> defined in RFC7540.  It also registers an HTTP upgrade token in the </ins> registry established by RFC7230. 6.1.

Discussion:
Landing this now and applying subsequent comments directly to speed things up
Will file issues for the ones indicated, otherwise I made the suggested edits. Thanks for reviewing this, NAME
Change:
share of controlled resources, both when sending data and opening new streams. <del> 6. </del> <ins> 7. </ins> This document adds an entry to the "HTTP/2 Frame Type" registry, the "HTTP/2 Settings" registry, and the "HTTP/2 Error Code" registry, all defined in RFC7540.  It also registers an HTTP upgrade token in the registry established by RFC7230. <del> 6.1. </del> <ins> 7.1. </ins> The following entry is added to the "HTTP/2 Frame Type" registry established by Section 11.2 of RFC7540.

Discussion:
Add brief section describing Http2Transport's stance on the properties enumerated in the WebTransport Overview. We can move this around later as necessary, but wanted to get the text in to document which optional properties are supported and which are not.
From the : We should enumerate the position that Http2Transport takes on each of these items. Specifically: No stream independenceNo partial reliabilityYes pooling supportNo connection mobility