jiebi/CodeConvo huggingface dataset:
Change:
and therefore distinct from the hostname transport address of the associated mDNS candidate, and as such MUST NOT be considered redundant per the guidance in RFC8445, Section 5.1.3.  To avoid <del> accidental IP address, this server-reflexive candidate MUST have its raddr field set to 0.0.0.0 and its rport field set to 0. </del> <ins> accidental IP address disclosure, this server-reflexive candidate MUST have its raddr field set to "0.0.0.0"/"::" and its rport field set to "9", as discussed in ICESDP, Section 9.1. </ins> Once an address has been identified as public, the ICE agent MAY cache this information and omit mDNS protection for that address in

Discussion:
ping
NAME , PTAL
LGTM too
Currently it contains: c=IN IP4 address/ttl Obviously, putting one of the candidate's IP address there would defeat the purpose of use mDNS. Options: Can this be omitted? Should it have a fake IP address of the right address family? Should it be allowed to have an mDNS name?
Just use the mDNS name.
If we run into issues, we could use 0.0.0.0:9 as we do when there are no candidates, but that starts to get complicated (i.e. may require updates to other specs)
mDNS name with IP4?
good point - shouldn't matter that much, but IP4 seems like the safest choice.
Agreed to use mDNS + IP4. We'll reevaluate if this causes problems.
Fixed by
We have observed an interop issue in the experimental deployment. Endpoints can fail to parse the SDP when the c= line contains a FQDN. This is the current solution.
Well, at least we thought of the solution already :)
Change:
There are key differences between the architecture of the Transport Services system and the architecture of the Socket API: the Transport Services API is asynchronous and event-driven; it uses messages for <del> representing data transfer to applications; and it assumes an implementation that can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams. </del> <ins> representing data transfer to applications; and it describes how implementations can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams. </ins> 2.1.

Discussion:
Address
I think the word /assumes/ is not a good choice of word in the arch draft. OLD: and it assumes an implementation that can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams NEW: and it can provide benefit when an implementation can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams.
Done
Exactly what I expected to see!
Change:
's popular JSONPath proposal dated 2007-02-21 JSONPath-orig, builds on the experience from the widespread deployment of its <del> implementations, and provides a normative definition for it. </del> <ins> implementations, and provides a normative specification for it. </ins> inspired-by-xpath describes how JSONPath was inspired by XML's XPath XPath. JSONPath was intended as a light-weight companion to JSON <del> implementations on platforms such as PHP and JavaScript, so instead of defining its own expression language like XPath did, JSONPath delegated this to the expression language of the platform.  While the languages in which JSONPath is used do have significant commonalities, over time this caused non-portability of JSONPath expressions between the ensuing platform-specific dialects. The present specification aims to remove platform dependencies and serve as a common JSONPath specification that can be used across 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, as long as that does not jeopardize the objective of obtaining a usable, stable JSON query language. </del> <ins> implementations in programming languages such as PHP and JavaScript, so instead of defining its own expression language, like XPath did, JSONPath delegated parts of a query to the underlying runtime, e.g., JavaScript's "eval()" function.  As JSONPath was implemented in more environments, JSONPath expressions became decreasingly portable.  For example, regular expression processing was often delegated to a convenient regular expression engine. This document aims to remove such implementation-specific dependencies and serve as a common JSONPath specification that can be used across programming languages and environments.  This means that backwards compatibility is not always achieved; a design principle of this document is to go with a "consensus" between implementations even if it is rough, as long as that does not jeopardize the objective of obtaining a usable, stable JSON query language. </ins> 1.3.

Discussion:
Generally, use "this document" rather than "this specification". Then use the term specification judiciously. Prefer the term "language" to "platform".
Yep, environment is a nice synonym of platform. Thank you for addressing my concern!
Change:
yet seen significant (or really any) security analysis.  It should not be used as a basis for building production systems. <del> Although TLS 1.3 I-D.ietf-tls-tls13 encrypts most of the handshake, including the server certificate, there are several other channels that allow an on-path attacker to determine the domain name the client is trying to connect to, including: </del> <ins> Although TLS 1.3 RFC8446 encrypts most of the handshake, including the server certificate, there are several other channels that allow an on-path attacker to determine the domain name the client is trying to connect to, including: </ins> Cleartext client DNS queries.

Discussion:
Replace "It only affects connection routing, server certificate selection, and client certificate verification." with "It may affect connection routing, server certificate selection, and client certificate verification."
URL It is relative to "This design has no impact on application layer protocol negotiation.", so "only" is more explicit.
This was fixed in and I forgot to close.
Change:
sending at a higher rate. In order to avoid these types of situations, which can potentially <del> affect all the users whose streaming media traverses a bottleneck link, there are several possible mitigations that streaming operators can use, but the first step toward mitigating a problem is knowing when that problem occurs. </del> <ins> affect all the users whose streaming media traverses a bottleneck, there are several possible mitigations that streaming operators can use, but the first step toward mitigating a problem is knowing when that problem occurs. </ins> 3.2.1.

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:
IANA is requested to create the following three entries in the existing registry for ExtensionType (defined in RFC8446): <del> encrypted_client_hello(0xfe0a), with "TLS 1.3" column values set </del> <ins> encrypted_client_hello(0xfe0b), with "TLS 1.3" column values set </ins> to "CH, HRR, EE", and "Recommended" column set to "Yes". ech_outer_extensions(0xfd00), with the "TLS 1.3" column values set

Discussion:
cc/ NAME
I don't think we need to also bump echouterextensions but just in case... S
ECHConfig is defined as but the text below it says The intention was to bump ECHConfig.version from 0xfe0a to 0xfe0b for draft-11, but this got missed by URL (I wrote the PR, so I apologize for my part in missing this.) How do folks think we should resolve this? Do we need to cut a new draft with the ambiguity fixed?
Oh whoops, nice catch! Using definitely won't work since the format and corresponding ClientECH extension has changed. I suppose all the implementors could just agree to mentally fix this typo when reading the draft, but may as well cut draft-12. Draft numbers are cheap.
We could try to pick up some editorial changes, too, like those suggested in .
I'd also personally be pretty happy to have in there, but also fine to skip it for what's supposed to be a small bugfix draft snapshot.
+1 I've not checked recent editorial changes but they're probably fine too. S
I'd be happy to take in draft-12 as well, though I'm inclined to think this should strictly be a bugfix/editorial draft. I'd say let's wait until Chris W. gets off back from PTO and let him make the call. Unless we're in a hurry, in which case we could ping one of the other authors to merge our changes and cut a draft.
Closing as resolved.
Change:
A frame was received which was not permitted in the current state. <ins> A server rejected a request without performing any application processing. </ins> Peer violated protocol requirements in a way which doesn't match a more specific error code, or endpoint declines to use the more specific error code.

Discussion:
This change sounds good to me, but to make sure I understand: is the only purpose of this change to split HTTPREQUESTCANCELLED in two; client to server stays HTTPREQUESTCANCELLED and server to client now becomes HTTPREQUESTREJECTED? And is the goal to add clarity when parsing connection logs later?
NAME basically. In the previous text, CANCELLED had specific semantics when sent server->client. However, with the change to make RESETSTREAM reflect back the error code in STOPSENDING, the client->server STOPSENDING(CANCELLED) would provoke a RESETSTREAM(CANCELLED) in the server->client direction with that error code that didn't necessarily match those semantics. Hence the split -- one code has specific semantics when sent by a server, and clients are instructed to use the other code. (I would prohibit clients from sending it, but if the server sends a STOP_SENDING, the client would reflect it back and violate the prohibition, so....)
Change:
efficient than logging the observed CID with each packet in the .header field of the "packet_sent" or "packet_received" events. <del> This is viewed from the perspective of the one applying the new id. As such, if we receive a new connection id from our peer, we will see the dst_ fields are set.  If we update our own connection id (e.g., NEW_CONNECTION_ID frame), we log the src_ fields. </del> <ins> This is viewed from the perspective of the endpoint applying the new id.  As such, when the endpoint receives a new connection id from the peer, it will see the dst_ fields are set.  When the endpoint updates its own connection id (e.g., NEW_CONNECTION_ID frame), it logs the src_ fields. </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 0-RTT data.  The amount of 0-RTT protected data is limited by the initial congestion window, typically around 10 packets RFC6928. <del> 2.4. </del> <ins> 2.5. </ins> As soon as the cryptographic context is established, all information in the QUIC header, including information exposed in the packet

Discussion:
also to address issue
Copying from URL There's no requirement that servers use a particular UDP port for HTTP/QUIC or any other QUIC traffic. Using Alt-Svc, the server is able to pick and advertise any port number and a compliant client will handle it just fine. That's already the case, and isn't part of this issue. updates the HTTP draft to highlight this, increasing the odds that implementations will test and support that case. This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically (though that requires coordination with their Alt-Svc advertisements and lifetimes, which could be challenging) in order to make it more difficult for a network observer to classify traffic (and therefore more difficult to ossify). On the other hand, as we're wrestling with in each of these privacy/manageability debates, removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly, which could result in even worse ossification. (E.g. indexing into the TLS ClientHello to find the ALPN list, then panicking on a different handshake protocol.) There's further discussion on the original issue, but this belongs in the ops drafts, not the protocol drafts.
this kind-of-but-not-really-duplicates , which I'll go ahead and close.
Actually, it's an exact duplicate, given that it points to the same issue. ;-) My bad.
NAME can you check if PR addresses this issue sufficiently? At least for the applicability doc...
Now also PR for the manageability statement.
and are a (ready for -03) treatment of this; however, we should consider if we want to say more, e.g. such as general guidance / recommendations for using ALPN in QUIC mappings, for instance? Keeping this open to track.
created new issue for ALPN
Change:
a minimum) the GitHub account of the user so that their contributions could be tracked more easily. <ins> Some working groups choose to have more than one draft in a repository, particularly for drafts that are tightly linked with significant cross-references.  In such a case, the README for the repository needs to say that clearly so that a participant understands that changes might be made to multiple drafts at once. </ins> 3.2. IETF working group mailing lists are automatically backed up by the

Discussion:
The document currently assumes that there is one document per repository. That's not always the best structure. It's not uncommon for there to be tight clusters of related documents. QUIC does this (even though it is likely an outlier in the process), but there are also frequent occasions where working groups develop overview documents along with a protocol, or split a document into separate logical pieces (tokbind did this for TLS bits and HTTP bits). URL is something of a train wreck, but there is plenty of middle-ground here.
Change:
When a PRIORITY frame claims to reference a request, the associated ID MUST identify a client-initiated bidirectional stream.  A server <del> MUST treat receipt of PRIORITY frame with a Stream ID of any other type as a connection error of type HTTP_MALFORMED_FRAME. </del> <ins> MUST treat receipt of a PRIORITY frame identifying a stream of any other type as a connection error of type HTTP_MALFORMED_FRAME. </ins> <del> A PRIORITY frame that references a non-existent Push ID or a Placeholder ID greater than the server's limit MUST be treated as an HTTP_MALFORMED_FRAME error. </del> <ins> A PRIORITY frame that references a non-existent Push ID, a Placeholder ID greater than the server's limit, or a Stream ID the client is not yet permitted to open MUST be treated as an HTTP_LIMIT_EXCEEDED error. </ins> A PRIORITY frame received on any stream other than a request or control stream MUST be treated as a connection error of type

Discussion:
Generalizes HTTPPUSHLIMITEXCEEDED to HTTPLIMIT_EXCEEDED and mandates use of that error code where a PRIORITY frame attempts to prioritize a stream the client isn't permitted to open yet. This has the effect of bounding priority tree state to requests the client could initiate (though might not have yet).
RFC 7540 at some length, especially what to do with priority information after a stream is closed. In addition to this, in HTTP/3, we have to deal with priority information before a stream is opened. That is: just how large is the tree allowed to grow before the referenced streams' frames begin to come in? The draft should provide some recommendations. I can think of two ways to do limit this "front-loaded" state: Open the stream when a PRIORITY frame referencing it arrives on the control stream. This will invoke the stream limit checks. Limit number of priority entries to number -- perhaps a function of the total number of maximum unidirectional and bidirectional streams.
Just clarifying: this would be advice to implementations, nothing normative, right?
I don't know. I think I will be happy as long as something is put into the draft.
Assuming that PRIORITY can only reference a stream that already "exists" client-side, the maximum number would be the number of permitted client-initiated bidirectional streams. Perhaps the requirements should simply be that PRIORITY cannot reference a stream that the client isn't permitted to open? I don't really want to "actually open" the stream when the PRIORITY frame arrives, but checking that it's less than the MAXSTREAMID on receipt seems like a reasonable server-side check.
Change:
authentication) provided that the client has sent the "post_handshake_auth" extension (see post_handshake_auth). <del> 4.3.2.1. The "oid_filters" extension allows servers to provide a set of OID/ value pairs which it would like the client's certificate to match. This extension MUST only be sent in the CertificateRequest message. %%% Server Parameters Messages A list of certificate extension OIDs RFC5280 with their allowed values, represented in DER-encoded X690 format.  Some certificate extension OIDs allow multiple values (e.g., Extended Key Usage). If the server has included a non-empty certificate_extensions list, the client certificate included in the response MUST contain all of the specified extension OIDs that the client recognizes. For each extension OID recognized by the client, all of the specified values MUST be present in the client certificate (but the certificate MAY have other values as well).  However, the client MUST ignore and skip any unrecognized certificate extension OIDs.  If the client ignored some of the required certificate extension OIDs and supplied a certificate that does not satisfy the request, the server MAY at its discretion either continue the connection without client authentication, or abort the handshake with an "unsupported_certificate" alert.  PKIX RFCs define a variety of certificate extension OIDs and their corresponding value types.  Depending on the type, matching certificate extension values are not necessarily bitwise-equal.  It is expected that TLS implementations will rely on their PKI libraries to perform certificate selection using certificate extension OIDs. This document defines matching rules for two standard certificate extensions defined in RFC5280: The Key Usage extension in a certificate matches the request when all key usage bits asserted in the request are also asserted in the Key Usage certificate extension. The Extended Key Usage extension in a certificate matches the request when all key purpose OIDs present in the request are also found in the Extended Key Usage certificate extension. The special anyExtendedKeyUsage OID MUST NOT be used in the request. Separate specifications may define matching rules for other certificate extensions. </del> 4.4. As discussed in protocol-overview, TLS generally uses a common set of

Discussion:
This was the one extension that wasn't in the extensions section, which made it hard to find. Note I've also removed the indent on the trailing paragraphs to avoid the walloftext problem with the existing text.
Does the part that says need to be updated to point to this new location instead of {{certificate-request}}?
Good catch. Fixed.
lgtm
merge this when ready
Change:
in-IPv6 header to the root.  Thus, the root removes the RPI and send the packet to the Internet. <del> No IPv6-in-IPv6 header is required. </del> Note: In this use case, it is used a node as a leaf, but this use case can be also applicable to any RPL-aware-node type (e.g. 6LR)

Discussion:
This covers the text from the beginning up to Section 7.2.1. These were reviewed with Pascal on March 26th. I will continue my review from Section 7.2.2 forward. More trivial editorial suggestions to follow, as well.
Many thanks for these fixs.
Change:
on the underlying hash constructions Transcript-Collision.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates <del> RFC5246 and RFC7525 in such as way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. </del> <ins> RFC5246 and RFC7525 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. </ins> 1.1.

Discussion:
As per discussion on mailing list.
NAME can you please float this change on the mailing list?
Change:
7. Clients that act upon a request to rate limit are potentially re- <del> identifiable (see Section 7.1 of DNS-PRIVACY) because they react to </del> <ins> identifiable (see Section 5.2.1 of PRIVACY) because they react to </ins> information that might only be given to them.  Note that this might apply to other fields too (e.g.  Retry-After).

Discussion:
RFC6973 Section 5.2.1 would be a better reference.
Ok, thanks URL
Change:
If the CA participates in Certificate Transparency (CT) RFC6962, then they may want to provide the client with a Signed Certificate Timestamp (SCT) that can be used to prove that a certificate was <del> submitted to a CT log.  An SCT can be included as a extension in the </del> <ins> submitted to a CT log.  An SCT can be included as an extension in the </ins> certificate or as an extension to OCSP responses for the certificate. The server can also provide the client with direct access to an SCT for a certificate using a Link relation header field with relation

Discussion:
editorial change
These LGTM as editorial. I note that the inclusion of "revoked" in URL is on the edge, but I think it was intended and could be merged as a result.
I did think the mentioned change might be an edge case, too, but came to the same conclusion. Happy to be of any help.
LGTM as well. Thanks NAME