jiebi/CodeConvo huggingface dataset:
Change:
request with a failure, or if the datagrams are received by the proxy before the request. <ins> Endpoints MUST NOT send HTTP Datagrams with payloads longer than 65527 using Context ID zero.  An endpoint that receives a DATAGRAM capsule using Context ID zero whose payload is longer than 65527 MUST abort the stream.  If a proxy knows it can only send out UDP packets of a certain length due to its underlying link MTU, it SHOULD discard incoming DATAGRAM capsules using Context ID zero whose payload is longer than that limit without buffering the capsule contents. </ins> 6. Proxies SHOULD strive to avoid increasing burstiness of UDP traffic:

Discussion:
When the client proxy hop is HTTP/3, and HTTP/3 datagrams are in use, the practical limit of datagrams is the maximum size of a QUIC packet minus header overheads. When DATAGRAM capsules are used, the logical limit is increased to that of an entire data stream. For the UDP proxying use case, a proxy that converts capsules into UDP datagrams will have a practical limit to the size of UDP datagrams that it can send. And it most likely wants to avoid fragmentation. When fragmentation is to be avoided, I would expect many proxy implementations to have a practical limit of less than 2000 for the size they would be willing to send. Such proxies can drop the contents of too-large datagrams but they would be required to drain them completely in order to continue reading the data stream. This seems like a possible avenue for DoS, because a client could send a verylarge datagram in theory, it would need to buffer the entirety of the datagram before sending it. We might be tempted to try to create some way for endpoints to communicate the practical limit of datagram capsules. But that could be hard due to the end-to-end version-indendent design. Instead we might just provide some guidance that $very_large capsules might cause problems for implementations, and that receivers might have local (or implementation-specific) limits that they want to enforce, which they could do by closing the stream or closing the connection.
According to RFC 768, the maximum length of a UDP payload is 65527. I would add some text to draft-ietf-masque-connect-udp along the lines of: Additionally, I think we could add some guidance text to draft-ietf-masque-h3-datagram along the lines of: I would leave the communication of actual limits to an extension.
Yeah we don't need to be 100% prescriptive, just spelling out foothold WFM
Change:
scheme and authority information about an Endpoint.  The Registration Base URI is provided by the Endpoint at registration time, and is used by the Resource Directory to resolve relative <del> references inside the registration into absolute URIs. </del> <ins> references inside the registration into URIs. </ins> The target of a link is the destination address (URI) of the link.

Discussion:
The previous text did not match my intentions, back when I thought of "absolute URIs" as "URI references that are already in URI form", where actually they are a construct intended for protocols to express that the fragment part does not take part in the dereferencing process. Closes: URL Will merge soon unless it conflicts with someone's private branches or draws other negative comments.
+1 for awareness of the difference between a URI and a reference to a URI
Oh, I see. But then I've been using the term wrong. In ABNF terminology for RFC3986, there's a "URI" (thing-with-scheme), a "relative-ref" and a "URI-reference" (which can be relative or not). I had thought it wise to talk of absolute URIs when I mean thing-with-scheme to disambiguate "URI" from "URI-reference", unaware that "absolute-URI" is even stricter. As we are not designing a communication protocol, we should not use the term "absolute URI", but talk of "URI" or (if ambiguous) a "complete URI". I'll need to patch that in the draft, sorry for the mess and thanks for pointing it out.
Change:
The glossary of this memo extends the glossary of the taxonomy document RFC8406 as follows: <del> ACM : Adaptative Coding and Modulation; </del> <ins> ACM : Adaptive Coding and Modulation; </ins> BBFRAME: Base-Band FRAME - satellite communication layer 2 encapsulation work as follows: (1) each layer 3 packet is

Discussion:
ACM : Adaptative Coding and Modulation; -- Adaptive. This error repeats. CPE: Customer Premise Equipment; -- Premises. (My premise is that this is unfortunate.) FEC: Forward Erasure Correction;-- FEC is traditionally Error. Redefining industry terms to suit your network coding case won't help. FLUTE: File Delivery over Unidirectional Transport;-- just ref RFC6726. bit of a pointless inclusion imo. PEP: Performance Enhanced Proxy [RFC3135]-- the title of RFC3135 is perfectly clear that it's Enhancing and the word 'Enhanced' does not appear in that document. This is not the sort of thing WGLC is for. PLFRAME - see below. Odd to see mention of PLFRAME but not FECFRAME, which is a more direct translation of the packet data.
I have corrected the accronyms in PR We do not mention FECFRAME because it is an internal format and we focus on what is exchanged between access and physical gateways.
Change:
for connections made by the endpoint and for other users of the network. <del> An endpoint that is only sending ACK frames will not receive acknowledgments from its peer unless those acknowledgments are included in packets with ack-eliciting frames.  An endpoint SHOULD send an ACK frame with other frames when there are new ack-eliciting packets to acknowledge.  When only non-ack-eliciting packets need to be acknowledged, an endpoint MAY wait until an ack-eliciting packet has been received to include an ACK frame with outgoing frames. A receiver MUST NOT send an ack-eliciting frame in all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgments. </del> 13.2.2. A receiver determines how frequently to send acknowledgments in

Discussion:
For those drafts that are in AUTH48.
This PR makes me happy.9000! Very cool!
Change:
that means ALPN, QUIC transport settings, etc., must be provisioned alongside these EPSKs. <del> 5. </del> <ins> 6. </ins> For clarity, the following table specifies PSK importer labels for varying instances of the TLS handshake. <del> 6. </del> <ins> 7. </ins> If a client or server wish to deprecate a hash function and no longer use it for TLS 1.3, they may remove this hash function from the set of hashes used during while importing keys.  This does not affect the KDF operation used to derive concrete PSKs. <del> 7. </del> <ins> 8. </ins> Recall that TLS 1.2 permits computing the TLS PRF with any hash algorithm and PSK.  Thus, an external PSK may be used with the same

Discussion:
Discussed in Singapore; will merge and add security considerations motivation in a followup to .
The document says: Aside from this statement needing update in light of the changes to the binder label, the core statement here isn't expanded upon. The document needs to very clearly say that the PSK ID that is sent in the psk extension is literally the serialized content of .
Fixed in .
This seems harmless, but it is predicated on a need to separate keys that I don't understand. Is there more rationale somewhere?
Change:
5. A interacts with the by constructing an .  This is included as the <del> content of a POST request to the .  This request MUST only contain those fields necessary to carry the : a method of POST, a target URI of the , a header field containing the content type (see (iana-req), and the as the request content.  In the request to the , MAY include additional fields.  However, those fields MUST be independent of the and MUST be fields that the will remove before forwarding the towards the target, such as the Connection or Proxy-Authorization header fields HTTP. </del> <ins> content of a POST request to the .  This request only needs those fields necessary to carry the : a method of POST, a target URI of the , a header field containing the content type (see (iana-req), and the as the request content.  In the request to the , MAY include additional fields.  However, additional fields MUST be independent of the and MUST be fields that the will remove before forwarding the towards the target, such as the Connection or Proxy-Authorization header fields HTTP. </ins> The role in this protocol acts as an HTTP client both with respect to the and the .  For the request the makes to the , this diverges from

Discussion:
Remove a "MUST" in this sentence and lean more heavily on the requirement later.
From NAME It seems to me these two sentences contraddict each other: MUST only contain these fields, and MAY include additional fields. Do I read this wrong? (and same for the response later in the section)
Change:
future connections.  The client includes this token in Initial packets to provide address validation in a future connection.  The client MUST include the token in all Initial packets it sends, unless <del> a Retry replaces the token with a newer token.  The client MUST NOT use the token provided in a Retry for future connections.  Servers MAY discard any Initial packet that does not carry the expected token. </del> <ins> a Retry or NEW_TOKEN frame replaces the token with a newer one.  The client MUST NOT use the token provided in a Retry for future connections.  Servers MAY discard any Initial packet that does not carry the expected token. </ins> Unlike the token that is created for a Retry packet, there might be some time between when the token is created and when the token is

Discussion:
Although not super-important, the biggest decision in here is that the packet number of the response to a RETRY is 1. Based on interop experience, I believe this is the semi-consensus of implementers.
Should there be normative text mandating that the packet number be increased?
I think we need a new issue on that. The information about this is scattered around issuing CID's, path validation, retransmission of Initial. It would be good with a clear statement of when the packet number starts counting. I also believe that there is somewhere text to the effect that a CID cannot have the same PN twice, but that does not apply to Retry.
Change:
UDP Connections can only generate errors on initiation due to port conflicts on the local system. <del> Once in use, UDP throws errors upon receiving ICMP notifications indicating failures in the network. </del> <ins> Once in use, UDP throws "soft errors" (ERROR.UDP(-Lite)) upon receiving ICMP notifications indicating failures in the network. </ins> <del> Calling "Listen" for UDP binds a local port and prepares it to receive inbound UDP datagrams from peers. </del> <ins> LISTEN.UDP.  Calling "Listen" for UDP binds a local port and prepares it to receive inbound UDP datagrams from peers. </ins> UDP Listeners will deliver new connections once they have received traffic from a new Remote Endpoint.

Discussion:
(SCTP mapping) This uses a new approach for such text for TCP, UDP and SCTP. Also: updates appendix D of interface.
We've updated Implementation mapping details for most protocols with , but we didn't tackle SCTP yet.
I'm fine with this being assigned to me. However, it's more than just writing the SCTP text. Here's the relevant part of what I wrote in PR : I don't suggest to delete much of the text that's there but definitely amend it with the RFC reference at least for what's covered in RFC 8303. There's a very direct line from this type of text in RFC 8303 to the original specs, so I do believe that should be helpful. That's (obviously) post-Montreal though!
NAME please send a PR along these lines.
Change:
This specification defines the KeyPurposeId id-kp-documentSigning. Inclusion of this KeyPurposeId in a certificate indicates that the <del> use of any Subject names in the certificate is restricted to use by a document signing. </del> <ins> use of the certified public key is allowed to be used for verifying the signature on a document. </ins> <del> Term of "Document Sign" in this document is digitally sign contents </del> <ins> Term of "Document Sign" in this document is digitally signes contents </ins> that are consumed by humans.  To be more precise, contents are intended to be shown to human with printable or displayable form by means of services or software, rather than processed by machines.

Discussion:
This PR contains corrections to more accurate expression. This PR does not contains modification related to backwards compatibility and interoperability.
Thanks Sean I approved all above modifications.
Change:
these parameters (hex encoded) An implementation should reproduce the output values given the input <del> values: * An implementation should be able to encrypt with the input values and the plaintext to produce the ciphertext.  * An implementation must be able to decrypt with the input values and the ciphertext to generate the plaintext. </del> <ins> values: An implementation should be able to encrypt with the input values and the plaintext to produce the ciphertext. An implementation must be able to decrypt with the input values and the ciphertext to generate the plaintext. </ins> Line breaks and whitespace within values are inserted to conform to the width requirements of the RFC format.  They should be removed

Discussion:
This PR addresses a few outstanding formatting cleanup issues: Fixes the list formatting problems identified in ... as well as a few others Wraps paragraphs to 80 columns
Merging on my own since these are just formatting changes.
This : ... is probably not a single paragraph. Similar problems and . It might be worth a more thorough proof-read of the document for others similar formatting problems.
Change:
8. Handshake and application messages use a common framing structure. <del> This framing provides encryption to assure confidentiality within the </del> <ins> This framing provides encryption to ensure confidentiality within the </ins> group, as well as signing to authenticate the sender within the group.

Discussion:
I don't like the pattern of having a marker byte followed by zero-padding. It has to be parsed manually, backwards, unlike every other object in the protocol which all follow a common format.
Agreement at the interim was that people don't care about the overhead (for now), so we're going to go with the simpler, TLS-syntax-based structure.
Here's the Weekly Digest for : - - Last week 18 issues were created. Of these, 3 issues have been closed and 15 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 5 comments. - - Last week, 10 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 4 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: :bustin_silhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
A bundle is logically a set of HTTP representations (Section 3.2 of I-D.ietf-httpbis-semantics), themselves represented by HTTP response messages (Section 3.4 of I-D.ietf-httpbis-semantics).  The bundle can <del> include an optional URL identifying the primary resource within the bundle and can include other optional metadata.  Particular applications can require that the primary URL and/or other metadata is present. </del> <ins> include optional metadata, which may be required by particular applications. </ins> While the order of the representations is not semantically meaningful, it can significantly affect performance when the bundle

Discussion:
This PR removes the primary URL section. The motivation is to factor the "core" Web Bundles specification to include just the minimal amount needed to support cases like subresource loading. This and other removed sections can be defined in other documents in the future.
The subresource loading doesn't need a primary URL, but I think "Navigate to Bundle" use case still needs it. URL NAME NAME Please correct me if I am wrong. I'm assuming "Navigate to Bundle" uses a primary URL as a main resource URL.
That's correct. For a bundle to be navigable into, it needs to be possible to specify its main resource URL.
Yes, to open the web bundle file in the browser (eg: Drag and drop) we need either the primary URL or the manifest's . So, we need to keep either as an optional section.
The idea of this PR is that a primary URL could be defined in a separate section. However, it is outside the scope of the "core" bundle specification to define this section.
Thanks for making a PR! Could we see a path to having other document more clearly? Since we need a primary URL defined somewhere, it might be difficult to remove a primary URL section without a clear path how a primary URL is defined.
(Just in case if someone missed it) It seems this PR is one of agenda points at IETF 111 Wpack. URL
NAME : I just opened URL to discuss the possibility of creating an extension of the spec as a separate document.
LGTM (just for record). Thanks for working on this. Hello WPACK, My name is Felipe Erias. I am working on Web bundles at Igalia together with Dan Ehrenberg. I have just created several PRs at wpack-wg/bundled-responses and I am writing this email to request the addition of a point to discuss them to the agenda for the group's upcoming meeting at the end of July. These PRs address the removal of the primary URL section, the manifest section, and content negotiation. Most of this has been adapted from previous work by Dan on the WICG/webpackage repo. The overarching goal is to simplify the "core" Web Bundles specification so it includes just the minimal amount needed to support use cases like subresource loading. The removed sections may be defined in other documents in the future. These are the PRs: URL URL URL Best, Felipe
Change:
network byte (big-endian) order; the uint32 represented by the hex bytes 01 02 03 04 is equivalent to the decimal value 16909060. <del> Note that in some cases (e.g., DH parameters) it is necessary to represent integers as opaque vectors.  In such cases, they are represented as unsigned integers (i.e., additional leading zero octets are not used even if the most significant bit is set). </del> 3.5. An additional sparse data type is available called enum.  A field of

Discussion:
It looks like this is carried over from TLS 1.2---seems I was wrong and TLS 1.2 did actually say whether there were leading zeros in front of DHE parameters---but I believe it is no longer used. Instead our crypto primitives all act on byte strings. Any conversion between byte strings and the primitive's internal structures is handled by the primitive itself. (RFC 7748 natively acts on byte strings, specifies how FFDHE is encoded, RSA-PSS comes with a byte string form, etc.)
Change:
3.2.1. There are many reasons why path characteristics might change <del> suddenly, for example, "cross traffic" that traverses part of the path, especially if this traffic is "inelastic", and does not, itself, respond to </del> <ins> suddenly, but we can divide these reasons into two categories: If the path topology changes.  For example, routing changes, which can happen in normal operation, may result in traffic being carried over a new path topology that that is partially or entirely disjoint from the previous path, especially if the new path topology includes one or more path segments that are more heavily loaded, offer lower total bandwidth, change the overall Path MTU size, or simply cover more distance between the path endpoints. If "cross traffic" that also traverses part or all of the same path topology increases or decreases, especially if this new "cross traffic" is "inelastic", and does not, itself, respond to </ins> indications of path congestion. <del> routing changes, which can happen in normal operation, especially if the new path now includes path segments that are more heavily loaded, offer lower total bandwidth, or simply cover more distance. </del> In order to recognize that a path carrying streaming media is "not behaving the way it normally does", having an expected baseline that describes "the way it normally does" is fundamental.  Analytics that

Discussion:
From NAME Section 3.2.1 says, "There are many reasons why path characteristics might change suddenly...". It may be good to mention MTU changes as part of the path changes, since changes in the maximum packet sizes supported by paths can be disruptive to traffic (requiring new PMTUD, etc).
FWIW, I agree with this. I may try to think of others that we should also add.
Change:
store system security measurement Evidence.  And each TPM is used as a root of trust for reporting (RTR) in order to retrieve attestation Evidence.  This is done by using a YANG RPC to request a quote which <del> exposes a rolling hash the security measurements held internally </del> <ins> exposes a rolling hash of the security measurements held internally </ins> within the TPM. Specific terms imported from I-D.ietf-rats-architecture and used in

Discussion:
NAME I did what I could in the time remaining. Please check and I think there are only two comments left unaddressed.
Change:
The endpoint that accepts a QUIC connection. <ins> A complete processable unit of QUIC that can be encapsulated in a UDP datagram.  One or more QUIC packets can be encapsulated in a single UDP datagram. A QUIC packet that contains frames other than ACK, PADDING, and CONNECTION_CLOSE.  These cause a recipient to send an acknowledgment; see sending-acknowledgements. A unit of structured protocol information.  There are multiple frame types, each of which carries different information.  Frames are contained in QUIC packets. </ins> When used without qualification, the tuple of IP version, IP address, and UDP port number that represents one end of a network path.

Discussion:
I struggled with this a little. Happy to take suggestions.
I'm going to say that the IP Packet vs. QUIC Packet text is not necessary. We carefully qualify where there is any potential for confusion.
On the other issue, it might be worth simply stating the terminology upfront. Something like


Datagram Size There is some confusion in the text between packets, frames and datagrams. That could be helped by earlier clarification.
This is a duplicate of .
12.4. Frames and Frame Types Packet Payload { Frame (8..) ..., } Version Negotiation, Stateless Reset, and Retry packets do not contain frames. At this point (page 82) I am still not sure what a packet or a frame is and have no idea what is going on on the wire.
Probably a duplicate of . These terms should be added to the definitions, with possibly some additional explanatory text in Section 12.
Section 1 is the first place that you introduce the term "Frame". I got very confused about frames and packets, and I thing the taxonomy needs to be clearly explained. You have UDP/IP packets that carry one or more QUIC PDUs, but the frame/packet notation made it unclear what was being discussed and whether the terms were being used consistently. Some clarification would be useful, or if it is in the text then making it more obvious would help.
Perhaps "frame" and "datagram" should be added as defined terms in Section 1.2. On a related note, the defined term is "QUIC packet" but in the text we don't always specify what type of "packet." Perhaps we should define "packet" as generally referring to QUIC, with a note that IP packets will be indicated as such. (I believe all instances of "packet" that refer to IP explicitly say "IP packet," but we should verify that.)
One small suggestion, which you can ignore if you don't like it.