jiebi/CodeConvo huggingface dataset:
Change:
This architecture expects the User Equipment to query the API when the User Equipment attaches to the network and multiple times thereafter.  Therefore the API MUST support multiple repeated queries <del> from the same User Equipment, returning the current state of captivity for the equipment. </del> <ins> from the same User Equipment and return the state of captivity for the equipment. </ins> <del> At minimum the API MUST provide: (1) the state of captivity and (2) a URI for a browser to present the portal application to the user.  The API SHOULD provide evidence to the caller that it supports the present architecture. </del> <ins> At minimum, the API MUST provide: (1) the state of captivity and (2) a URI for the Captive Portal Server.  The API SHOULD provide evidence to the caller that it supports the present architecture. </ins> When user equipment receives Captive Portal Signals, the user equipment MAY query the API to check the state.  The User Equipment

Discussion:
Happy to elaborate on them if the motivation is not clear from the changes, let me know!
Thanks NAME b1dc7ba4e26ab17ed12d8a5a2408fe8063b1177a accepts the suggestion. 509d855e5ddba7dd1c5db58646c85516d0b40987 corrects the mistake I had made, which your question was about.
Looks great. Thanks for the PR!
Change:
octets, up to the server ID length.  If this server ID matches a known server ID for that configuration, it forwards the packet accordingly and takes no further action.  If it does not match, it <del> routes using an arbitrary algorithm and adds the new server ID to </del> <ins> routes using a fallback algorithm and adds the new server ID to </ins> that server's table entry. <del> If the sole reason for non-compliance is that the server ID is not </del> <ins> If the sole reason for unroutability is that the server ID is not </ins> in the load balancer's table, the load balancer routes the packet <del> with an arbitrary algorithm.  It adds the decoded server ID to table entry for the server the algorithm chooses and forwards the packet accordingly. </del> <ins> with a fallback algorithm.  It adds the decoded server ID to table entry for the server the algorithm chooses and forwards the packet accordingly. </ins> 4.3.2.3.

Discussion:
and
I'd suggest 'Fallback' or another word than arbitrary. A definition of Arbitrary is: "Based on random choice or personal whim, rather than any reason or system." In fact, there are sensible constraints on this algorithm to ensure routing works correctly for non-compliant CIDs and connections don't fail.
Agreed.
In PR I suggested non-routable, though I realize non-conformant may also be an option. The sentence which caused me to suggest non-routable is: URL I'm happy to write a PR if others find non-compliant potentially confusing as well.
I like it. Let's go with it.
Thanks, this is a lot easier to read for me.
Change:
constraints using two independent feedback loops: Media servers often respond to application-level feedback from the <del> media player that indicates a bottleneck link somewhere along the path, by adjusting the amount of media that the media server will send to the media player in a given timeframe.  This is described in greater detail in sec-abr. </del> <ins> media player that indicates a bottleneck somewhere along the path, by adjusting the amount of media that the media server will send to the media player in a given timeframe.  This is described in greater detail in sec-abr. </ins> <del> Media servers also typically implement transport protocols with </del> <ins> Media servers also typically rely on transport protocols with </ins> capacity-seeking congestion controllers that probe for bandwidth, and adjust the sending rate based on transport mechanisms.  This is described in greater detail in sec-trans.

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:
If the 'key_ops' field is present, it MUST be empty for the public key. <ins> 12.4.2. Some method of checking that points provided from external entities are valid.  For the 'EC2' key format, this can be done by checking that the x and y values form a point on the curve.  For the 'OKP' format, there is no simple way to do point validation. Consideration was given to requiring that the public keys of both entities be provided as part of the key derivation process.  (As recommended in section 6.1 of RFC7748.)  This was not done as COSE is used in a store and forward format rather than in on line key exchange.  In order for this to be a problem, either the receiver public key has to be chosen maliciously or the sender has to be malicious.  In either case, all security evaporates anyway. A proof of possession of the private key associated with the public key is recommended when a key is moved from untrusted to trusted. (Either by the end user or by the entity that is responsible for making trust statements on keys.) </ins> 12.5. Key Agreement with Key Wrapping uses a randomly generated CEK.  The

Discussion:
Response to note from Göran Selander 1) we need to say where the secret is derived from 2) how it is formatted, and 3) why we are not using KA and KB in the KDF step.
Change:
2.1. <del> An encoder converts a header or trailer field section into a series of representations by emitting either an indexed or a literal </del> <ins> An encoder converts a header or trailer section into a series of representations by emitting either an indexed or a literal </ins> representation for each field line in the list; see field-line- representations.  Indexed representations achieve high compression by replacing the literal name and possibly the value with an index to

Discussion:
HTTP Semantics refers to the field sections used at particular locations using terms "header section" and "trailer section." However, the HTTP/3 draft sometimes calls them "header field section" and "trailer field section." This PR addresses the inconsistency. It also fixes one instance "fields section."
NAME Of course I did (not). Done in 18c0242.
Have you checked to make sure QPACK matches as well?
Change:
Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. <ins> Path Required: Whether a Commit covering a proposal of this type is required to have its "path" field populated (see commit). </ins> Reference: The document where this extension is defined Initial contents:

Discussion:
the "MLS Proposal Types" section defines a table with columns Value Name Recommended Path Required Reference But the template directly above the table only mentions four of the five columns. It does not mention or describe what "Path Required" means. It should probably at least make clear that the field should be either or , and reference section "Commit" where the path requirement is discussed.
Change:
3.1. The QUIC wire image is not specifically designed to be <del> distinguishable from other UDP traffic. </del> <ins> distinguishable from other UDP traffic by a passive observer in the network. </ins> The only application binding defined by the IETF QUIC WG is HTTP/3 QUIC-HTTP at the time of this writing; however, many other

Discussion:
NAME thank you for your help with this.
It is specifically designed to allow for multiplexing of QUIC with real-time protocols. See RFC 7983.
NAME is this issue conflating what endpoints can distinguish and what anyone else can distinguish? I'm guessing that's the case, but it would be good to be clear about this, especially in the ops drafts. Again, I'm being informed here about what NAME issue being addressed in URL in MOPS should say. So thank you for opening the issue here!
NAME you are right to point that out. If we consider this about observers, then this text is probably OK. I would say that it needs qualification to be properly correct though. We might reasonably assume that the statement applies only to "a passive observer in the network", as noted in the top of the section, but the risk that this statement be taken out of context is strong (it's a nice clear sound bite). The same section later mentions RFC 7983. That text could also be improved in this regard.
Change:
document. Each leaf node of the tree represents a single, coherent connection <del> attempt, with an endpoint, a path, and a set of protocols that can directly negotiate and send data on the network.  Each node in the tree that is not a leaf represents a connection attempt that is either underspecified, or else includes multiple distinct options. </del> <ins> attempt, with an endpoint, a network path, and a set of protocols that can directly negotiate and send data on the network.  Each node in the tree that is not a leaf represents a connection attempt that is either underspecified, or else includes multiple distinct options. </ins> For example, when connecting on an IP network, a connection attempt to a hostname and port is underspecified, because the connection attempt requires a resolved IP address as its Remote Endpoint.  In

Discussion:
After reading , I reviewed the latest text. I'm unsure I want to make changes to Arch/API: I see path as "network path", that is the set of hops through which the packet is forwarded (the local interface being the first local hop, and PvD information/PMTU/etc relating to something non-local). This changes the examples using interface to align with this.
Impl draft, section 4.1.2: "Each node will be summarized by a tuple of three elements: Endpoint, Path, and Protocol. The above example can now be written more succinctly as: 1 [URL, Any, TCP] 1.1 [URL, Wi-Fi, TCP] 1.1.1 [192.0.2.1:80, Wi-Fi, TCP] 1.2 [URL, LTE, TCP] 1.2.1 [192.0.2.1:80, LTE, TCP] 1.2.2 [2001:DB8::1.80, LTE, TCP]" looking at the example I would not call this "Endpoint, Path, and Protocol" but "Remote Endpoint, Local Endpoint or interface, and Protocol". Not sure we have defined the term Path well but I would consider a path to consists of both the local and remote endpoint plus optionally maybe even some more information about the path characteristics that might be known for this endpoint pair.
Yeah, it is "remote endpoint", "interface/local endpoint", and "protocol".
note that the wording needs to be fix at least in a few more places, so whoever puts the PR in should probably reach for the word path and ensure it's used correctly...
especially 4.1.3.2. (Alternate Paths) wouldn't fit that well anymore and would probably need some rewriting...
Change:
layer. X.509 semantics are very rich.  This can cause unintended <del> consequences if a service owner creates a proxy cert where the properties differ from the leaf certificate.  For this reason, </del> <ins> consequences if a service owner creates a proxy certificate where the properties differ from the leaf certificate.  For this reason, </ins> delegated credentials have very restricted semantics which should not conflict with X.509 semantics. Proxy certificates rely on the certificate path building process to establish a binding between the proxy certificate and the <del> server certificate.  Since the cert path building process is not cryptographically protected, it is possible that a proxy </del> <ins> server certificate.  Since the certificate path building process is not cryptographically protected, it is possible that a proxy </ins> certificate could be bound to another certificate with the same public key, with different X.509 parameters.  Delegated credentials, which rely on a cryptographic binding between the entire certificate and the delegated credential, cannot. <del> Delegated credentials are bound to specific versions of TLS.  This prevents them from being used for other protocols if a service owner allows multiple versions of TLS. </del> <ins> Each delegated credential is bound to a specific version of TLS and signature algorithm.  This prevents them from being used for other protocols or with other signature algorithms than service owner allows. </ins> 2.2.

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:
it mitigates the risk related to thundering herd when too many clients are serviced with the same timestamp. <del> This field MUST NOT occur multiple times and can be sent in a trailer section. </del> <ins> This field can be sent in a trailer section. </ins> An example of RateLimit-Reset field use is below.

Discussion:
According to URL there is no need to specify that information.
This text appears in relation to Item fields. By their nature Items can only occur on one field line (the proper terminology, btw), so this requirement is extraneous, and should be removed.
... and it's also on RateLimit-Policy, even though that is a List field.
Change:
information stored in the RD.  This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove <del> information on resources.  Furthermore, new link attributes useful in conjunction with an RD are defined. </del> <ins> information on resources.  Furthermore, new target attributes useful in conjunction with an RD are defined. </ins> 1.

Discussion:
None of those meant any of (anchor,rel,rev), and all the other attributes that come from serializations should be called by what they are. Closes: URL
Working with RFC8288 in CoRAL I noticed that we're a bit sloppy on some concepts of web linking. This manifests in two related issues: We're talking of link attributes, where that's a term nowhere defined. (Used by RFC6690, but possibly they mean "attributes of CoRE links" and not "Core's use of link attributes", and even there only in the chapter name.) The information model we describe is more the model of the serialized data; the data model makes no distinction, for example, between and . The latter is something we can IMO let slide on account of practical readers having both in mind. The former poses the danger of aggravating the careless use of "link attributes" that'd describe the link-as-a-whole (something not covered by the data model, and thus incompatible with different serializations), but can easily be fixed in a search-and-replace PR coming right up.
Change:
initial_max_stream_data_bidi_remote, or initial_max_streams_uni and initial_max_stream_data_uni. <ins> A server MAY store and recover the previously sent values of the max_idle_timout, max_udp_payload_size, and disable_active_migration parameters and reject 0-RTT if it selects smaller values.  Lowering the values of these parameters while also accepting 0-RTT data could degrade the performance of the connection.  Specifically, lowering the max_udp_payload_size could result in dropped packets leading to worse performance compared to rejecting 0-RTT data outright. </ins> A server MUST either reject 0-RTT data or abort a handshake if the implied values for transport parameters cannot be supported.

Discussion:
The section for "Values of Transport Parameters for 0-RTT" specifies which parameters a client MUST or MUST NOT remember. It does not do the same for a server. (It implies that ones a client MUST NOT remember also don't need to be remembered by a server, and it lists a subset of the remaining as ones the server MUST remember.) This commit adds the remaining parameters to a list that the server need not remember.
This still looks good with the latest commit Jana pushed.
The "Values of Transport Parameters for 0-RTT" section lists some, but not all, of the transport parameters defined in the spec. As currently written, it is ambiguous whether a server needs to remember the parameters not listed. (A list of parameters that the client MUST NOT remember, and therefore the server need not remember, is provided, as well as a list that the server MUST remember so it doesn't lower limits.) As far as I understand the definitions of the remaining parameters, there isn't any need for a server to remember them. However, instead of requiring implementors to read through all of the transport parameter definitions and infer this on their own, it would be easier on implementors to spell this out in this section. (This is required for definitions of new parameters.)
I like the latest text!
Change:
Negotiation Packet, are both inspectable and invariant QUIC- INVARIANTS. <del> This document describes version 1 of the QUIC protocol, whose wire </del> <ins> This document addresses version 1 of the QUIC protocol, whose wire </ins> image is fully defined in QUIC-TRANSPORT and QUIC-TLS.  Features of the wire image described herein may change in future versions of the protocol, except when specified as an invariant QUIC-INVARIANTS, and

Discussion:
The RFC 9000 term is "long header packet"; I'm not a fan of adding hyphenation
ah, right. should we change "long packet header" to "long header" instead?
yes please! That would be consistent with how the terms are used in RFC 9000 (and elsewhere in this document)
done...
Change:
short-term consistency between the PMTU for flows can help avoid an endpoint using a PMTU that is inefficient.  The IP cache can also influence the PMTU value of other IP flows that use the same path <del> RFC8899, including IP packets carrying protocols other than QUIC. </del> <ins> DPLPMTUD, including IP packets carrying protocols other than QUIC. </ins> The representation of an IP path is implementation-specific RFC8201. 5.

Discussion:
as well
There are some outdated references those I goes will go away with further revisions. However, there are duplicate references those I believe need to be fixed manually. -- Duplicate reference: draft-ietf-quic-applicability, mentioned in 'QUIC-APPLICABILITY', was also mentioned in 'I-D.ietf-quic-applicability'. -- Duplicate reference: RFC8899, mentioned in 'RFC8899', was also mentioned in 'DPLPMTUD'.
I noticed that there are references to QUIC I-Ds. Applicability even references both -34 and RFC9000 :smile:
Change:
Proof share: A share of a proof, used by an aggregator during the input-validation protocol. <del> Measurement: A single value (e.g., a count) being reported by a client.  Multiple measurements may be grouped into a single protocol input. </del> <ins> Report: Uploaded to the leader from the client.  A report contains the secret-shared and encrypted input and proof. </ins> 2.

Discussion:
The design document discusses "reports" which are a group of measurements being submitted to a DPA instantiation. There should be an entry in the "Terminology" section that explicitly defines a report and how it relates to "measurements" and "inputs".
Thanks for putting the list back in alphabetical order, too!
Change:
start the Capsule Protocol; see HTTP-DGRAM. If any of these requirements are not met, the client MUST treat this <del> proxying attempt as failed and abort the connection. </del> <ins> proxying attempt as failed and close the connection. </ins> For example, the IP proxy could respond with:

Discussion:
In the abstract, the word 'proxy' is used without qualification. It would be better to use the term 'IP proxy'. In 4.3. HTTP/1.1 Response, 'abort the connection' is not typical usage (e.g., in RFC9112); suggest 'close the connection'.
Change:
dependent on the CA's willingness to issue certificates with sufficiently short lifetimes.  It also fails to address the issues with algorithm support.  Nonetheless, existing automated issuance <del> APIs like ACME may be useful for provisioning credentials, within an </del> <ins> APIs like ACME may be useful for provisioning credentials within an </ins> operator network. 3.

Discussion:
No substantive changes, just grammatical nits and suggestions for clarifying the exposition. In the "Client Behavior" section (Section 3.1), I added a sentence explaining how to check the time-to-live to the first of the DC-validation steps. This might be helpful, as folks have been confused in the past about how to determine if a DC has expired.
LGTM
Change:
an endpoint and a Media Distributor, as well between Media Distributors.  The authentication key used for hop-by-hop authentication is derived from an SRTP master key shared only on the <del> respective hop (HBH Key(j); j={a given hop}).  Each HBH Key(j) is distinct per hop and no two hops ever intentionally use the same SRTP master key. </del> <ins> respective hop.  Each HBH key is distinct per hop and no two hops ever intentionally use the same SRTP master key. </ins> Using hop-by-hop authentication gives the Media Distributor the ability to change certain RTP header values.  Which values the Media

Discussion:
This is a first-draft at sections to help clarify key usage and packetization format.
Overall this looks like pretty good and I think much of what I don't like could be fixed simply by deleting two sub sections.
Impressive you were able to put "Overall this looks like pretty good" and "much of what I don't like" into the same sentence. :) OK, I'll remove the section(s) with the steps. It gets a bit into the weeds, though it might be useful to figure out how to replace this. The issue is I hear people getting confused over how to use the keys. That's why I thought that an informative section might help. A library hides all this, but if you're writing the library, you need to understand these steps. I'll leave this here until the weekend (or later this week), as I have other stuff to get done. But, I'll come back to it.
I just pushed a set of changes, squashing the changes into a single PR. Otherwise, the changes look to be even larger than they really are since I removed many additions from the first commit.
LGTM
Change:
The tokens have the following fields: ODCIL: The original destination connection ID length.  Tokens in <del> NEW_TOKEN frames SHOULD set this field to zero. </del> <ins> NEW_TOKEN frames MUST set this field to zero. </ins> Original Destination Connection ID: This is copied from the field in the client Initial packet.

Discussion:
Fixes URL
Some load balancers today switch based on the SNI. Obviously, this is not version-invariant. We should add some language about this. What should such an LB when it encounters an unknown version? It probably has no choice but to forward it based on CID and hope for the best.
If the differing domains trust each other, the servers could helpfully generate Retry packets to redirect the client to the right place. This assumes a bunch of shared state, and that those servers support the same version while the LB does not. Of course, if version support differs, the VN process has serious problems.
Maybe encrypt sni will be the real standard later(see URL), I just think that there is no need for quic lb considering sni