jiebi/CodeConvo huggingface dataset:
Change:
9. <del> TODO </del> <ins> 9.1. This document requests creation of a new registry for extensions to the Upload protocol.  This registry should contain the following columns: [TODO: define how we want to structure this registry when the time comes] </ins> 10.  References

Discussion:
One possible extension would be an opaque blob to carry client attestation information (for ), if desired. The current set is empty, but I suspect we'll need freedom to extend here as this gets used without totally changing the protocol version. If folks are generally supportive of this, it should probably land after , which touches and renames PDAUploadReq to PDAReport.
Both (1) and (2) are external to the protocol. The purpose of extensions is to allow whatever mechanism exists for addressing them to be bound to the report, as is done here. This is done in the change. This is not meant to close the attestation issue. It's meant to give us the mechanics to address it later.
Right you are. What threw me off was the following statement: The "then these extensions are required to be echoed..." makes it sound as if they're not echoed, which they are. I'm happy with this PR modulo fixing this statement.
Change:
between the ServerHello and the EncryptedExtensions encrypted- extensions message.  The ServerHello MUST only include extensions which are required to establish the cryptographic context. <ins> Currently the only such extensions are "key_share" and "pre_shared_key".  Clients MUST check the ServerHello for the presence of any forbidden extensions and if any are found MUST terminate the handshake with a "illegal_parameter" alert. </ins> 6.3.1.3.

Discussion:
Does it make sense to just have a tri-state column for TLS 1.3 on the extensions registry: "key" - key determining parameters "encrypted" - encrypted "forbidden" - not for use in TLS 1.3
"go" as in whether they are plaintext or go into the EncryptedExtensions block.
Change:
Obviously, an implementation can still fail when executing a JSONPath query, e.g., because of resource depletion, but this is not modeled <del> in the present specification.  However, the implementation MUST NOT silently malfunction.  Specifically, if a valid JSONPath query is evaluated against a structured value whose size doesn't fit in the range of exact values, interfering with the correct interpretation of the query, the implementation MUST provide an indication of overflow. </del> <ins> in this document.  However, the implementation MUST NOT silently malfunction.  Specifically, if a valid JSONPath query is evaluated against a structured value whose size doesn't fit in the range of exact values, interfering with the correct interpretation of the query, the implementation MUST provide an indication of overflow. </ins> (Readers familiar with the HTTP error model may be reminded of 400 type errors when pondering well-formedness and validity, while

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:
rebinding leads to connection failure, with the resulting cost of a new handshake. <del> This document defines an extension to DTLS to add a connection ID to the DTLS record layer.  The presence of the connection ID is </del> <ins> This document defines an extension to DTLS to add a connection ID (CID) to the DTLS record layer.  The presence of the connection ID is </ins> negotiated via a DTLS extension. 2.

Discussion:
This is pretty trivial, but the first use of CID in the draft isn't mated to the expanded "connection ID". Probably more seriously, that first mention is actually to cite a struct: The structure is called .
Change:
that can be applied here.  Furthermore, an on-path attacker would have access to the raw data, negating any other TCP-level security mechanisms.  Also a change from RFC6824 has removed the subflow <del> identifer from the MP_PRIO option (sec_policy), to remove the </del> <ins> identifier from the MP_PRIO option (sec_policy), to remove the </ins> theoretical attack where a subflow could be placed in "backup" mode by an attacker.

Discussion:
Reading through the draft I noticed a few typos so I wanted to propose a small change to fix.
Change:
expectations of being hijacked - this may improve security by making users more reluctant to accept TLS hijacking, which can be performed from beyond the network associated with the captive portal. <del> By simplifying the interaction with the captive portal systems, and doing away with the need for interception, we think that users will be less likely to disable useful security safeguards like DNSSEC validation, VPNs, etc.  In addition, because the system knows that it is behind a captive portal, it can know not to send cookies, credentials, etc.  By handing out a URI which is protected with TLS, the captive portal operator can attempt to reassure the user that the captive portal is not malicious. </del>

Discussion:
""" — Section 5 — Purely a judgment thing here, so do what you hink is best: it seems to me that the Security Considerations in 7710 rather buried the lede. The bottom line is that by removing the MitM interception, this mechanism improves security by making the portal and its actions visible, rather than hidden, and that vulnerabilities that exist here also existed before and are now lessened. I would say something like that up front, in a new first paragraph, and then continue with the existing text as is. But, again, as you judge best; this is just a comment. """
Change:
process is complete. Note that gathering phases only gather the candidates needed by <del> new/recycled/restarting m= lines; other m= lines continue to use their existing candidates.  Also, when bundling is active, candidates are only gathered (and exchanged) for the m= lines referenced in BUNDLE-tags, as described in I-D.ietf-mmusic-sdp-bundle-negotiation. </del> <ins> new/recycled/restarting m= sections; other m= sections continue to use their existing candidates.  Also, when bundling is active, candidates are only gathered (and exchanged) for the m= sections referenced in BUNDLE-tags, as described in I-D.ietf-mmusic-sdp- bundle-negotiation. </ins> 3.5.2.

Discussion:
S 5.2.1 says: Attributes that are common between all m= sections MAY be moved to session-level, if explicitly defined to be valid at session-level. This seems like it would be better as a should
Discussed in DC: Some concerns that things that appear at the session level have, in the past, missed by bad implementations.
Dc - decdie to change to SHOULD NOT and for things that are big, like idientiy, will put MUST
Change:
contain the final size of the stream.  Setting this bit indicates that the frame marks the end of the stream. <del> An endpoint that receives a STREAM frame for a send-only stream MUST terminate the connection with error STREAM_STATE_ERROR. </del> <ins> An endpoint MUST terminate the connection with error STREAM_STATE_ERROR if it receives a STREAM frame for a locally- initiated stream that has not yet been created, or for a send-only stream. </ins> The STREAM frames are shown in fig-stream.

Discussion:
I assume this has been the intention all along, but I do not find normative language in the current draft.
Change:
it is possible for a context ID with the same numeric value to be simultaneously allocated in distinct requests, potentially with different semantics.  Context IDs MUST NOT be re-allocated within a <del> given HTTP namespace but MAY be allocated in any order.  Once allocated, any context ID can be used by both client and proxy - only allocation carries separate namespaces to avoid requiring synchronization. </del> <ins> given HTTP namespace but MAY be allocated in any order.  The context ID allocation restrictions to the use of even-numbered and odd- numbered context IDs exist in order to avoid the need for synchronisation between endpoints.  However, once a context ID has been allocated, those restrictions do not apply to the use of the context ID: it can be used by any client or proxy, independent of which endpoint initially allocated it. </ins> Registration is the action by which an endpoint informs its peer of the semantics and format of a given context ID.  This document does

Discussion:
Section 4, second paragrap: 'The context ID namespace is tied to a given HTTP request: it is possible for a context ID with the same numeric value to be simultaneously assigned different semantics in distinct requests, potentially with different semantics. Context IDs MUST NOT be re-allocated within a given HTTP namespace but MAY be allocated in any order.' I found this text initially confusing. I think what I was missing initially was a reminder that the HTTP datagram will be either in the communication context of the HTTP Request (HTTP 1.x) or the HTTP datagram will contain the quarter stream ID, and thus be in context. So an potential improvement here would be to add a clarification before this to remind that HTTP datagram will always be in context of a given HTTP request.
Fixed by
Section 4 last sentence 2 paragraph is: Why is there a "-"? Actually not sure what the second is supposed to say. Is there anything missing?
The dash has meaning similar to parentheses: it is equivalent to (see ). This parenthetical clause adds context to the main clause: allocation is separate but usage is not.
Do you have a suggestion for text that would be better?
I find the use of namespace in the quoted text unhelpful. You might editorialize this sentence a bit anyway to improve the clarity. Something like "Context ID allocation depends on restrictions to the use of even- and odd-numbered context IDs in order to avoid the need for synchronisation. However, once a context has been allocated, those restrictions no longer apply and context IDs can be used by any client or proxy, independent of who initially allocated them.
Lucas thanks that's much better! (I think this "allocation carries" wording confused me a bit)
:shipit:
Change:
21.1.1. The QUIC handshake incorporates the TLS 1.3 handshake and inherits <del> the cryptographic properties described in Appendix E.1 of TLS13. Many of the security properties of QUIC depend on the TLS handshake </del> <ins> the cryptographic properties described in Section E.1 of TLS13.  Many of the security properties of QUIC depend on the TLS handshake </ins> providing these properties.  Any attack on the TLS handshake could affect QUIC.

Discussion:
to make RFC Editor diffs smaller
These are manual; if only there were a tool... Diffs in the are all very small, and in each case reflects correction of an existing error or slight adjustment to accommodate limitations in XML (in one case); happy to suppy (CI is broken because of URL).
I just uploaded this to a branch on this repository so that a diff is generated in CI (assuming that I have a little more luck in getting a build to stick). The changes should be visible at URL if CI ever passes. Which of course it has not at this point...
Seems to be working occasionally; I fixed a lint problem, and diffs are now at URL
NAME I'd strongly prefer to keep this PR focused on behind-the-scenes tidying, rather than making an editorial wording choice. Beyond keeping the PR focused, doing this piecemeal is going to miss a large number of instances of "see..." because the changes represented here are only where a specific section is called out; you'd do much better to adjust that language consistently after this PR is applied (when you can do a search for and it should consistently show all instances, whether or not there's a section being referenced). If that's sensible to everyone, I think this is ready; tell me if I missed one of the comments.
NAME Fair enough. This LGTM.
Here are the diffs, since tools is failing so badly (I plan to work around that, but that will take some time). URL I've spotted one problem there already, but it does look good so far.
NAME and NAME I have learned something new about kramdown-rfc2629. Cheers.
NAME
NAME and NAME should approveThanks for doing this, recovery LGTM
Change:
cannot be successfully decrypted using the key. A server MUST ensure that the HPKE keys it uses are not valid for any <del> other protocol that uses HPKE with the "ohttp request" label. </del> <ins> other protocol that uses HPKE with the "message/bhttp request" label. </ins> Designers of other protocols, especially new versions of this protocol, can ensure key diversity by choosing a different label in <del> their use of HPKE.  The "ohttp response" label was chosen for </del> <ins> their use of HPKE.  The "message/bhttp response" label was chosen for </ins> symmetry only as it provides key diversity only within the HPKE <del> context created using the "ohttp request" label. </del> <ins> context created using the "message/bhttp request" label. </ins> 8.4.

Discussion:
Test vectors generated from the .
With , we're enforcing a 1:1 mapping between message/ohttp-req and message/bhttp, but we don't have any cryptographic enforcement of this pairing. If someone were to reuse the encapsulation mechanism in this document with another message type, say, to encapsulate application/dns-message values with a application/oblivious-dns-message wrapper, then we'd probably want to ensure that targets can't get confused between these two types. We could use the HPKE info string to separate these two protocols. (This is related to .)
The encapsulated payload could be something other than HTTP. We should be clear about our decision to do that and how alternative payloads might be carried if people wanted to do that.
The clear example here would be allowing just a DNS message body. As long as the client and target agreed, they could use that without the proxy knowing. We could just loosen the restrictions on what the body is, or we could use different content types (if you want the proxy to know what it is?).
I think that the way you would do that is to define a new media type for DNS and then just go for it. (Of course, you need to debate whether to include a length field and a transaction ID field.) Maybe we don't need to do that in this draft, but we could explain how that might look.
I'd do the following here (in line with ): Replace as the HPKE info string with the content-type of the inner message, be it or . That way, both client and target must agree on the type of encapsulated payload to actually use it. Thoughts?
That might work. We have "ohttp response" as the label for HKDF expansion on the response. What would you include there? Maybe you should just extend with "message/bhttp request" and "message/bhttp response" and then the swapping in the media type becomes trivial.
Yeah, that's what I had in mind.
Sorry about that. Misremembered how this worked; I should have double-checked.
Change:
RFCs have been written refining TCP decisions about what to send, how much to send, and when to send it, since 1988 Jacobson-Karels the signals available for TCP senders remained unchanged - end-to-end <del> acknowledgments for packets that were successfully sent and received, and packet timeouts for packets that were not. </del> <ins> acknowledgements for packets that were successfully sent and received, and packet timeouts for packets that were not. </ins> The success of the largely TCP-based Internet is evidence that the mechanisms TCP used to achieve equilibrium quickly, at a point where

Discussion:
This definitely needs more work!
NAME and NAME - I have three notes in the section I've added. I'll hit this again later in the week, but if you can express opinions about any of them, that would be very helpful.
NAME In the call we discussed this and we feel like we don't need to say anything about this in addition to what we already said in Section titled "Bitrate Detection Challenges". So, maybe we can drop and close this?
I actually like NAME suggestions - let me spend a couple of hours on this, and then you two can either merge it or reject it.
NAME and NAME see what you think. I'm also ok with closing as wontfix, but wanted to give it a try.
NAME and NAME any thoughts on this PR? I tried to reflect Jake's high-level comments, which were even more helpful and actionable than usual ...
This reads much better than the initial version, thanks.
Pulling the TBD out of the draft text and capturing it here instead. Suggestion from mic at IETF 106 (Mark Nottingham) in response to call for help on capturing the mismatch between supply and demand of bandwidth with regard to video: Dive into the different constraints coming from different parts of the network or distribution channels. (regarding questions about how to describe the disconnect between demand vs. capacity, while keeping good archival value.) "These are big numbers, but the internet has grown over time, and CDN capacities have grown over time. Is it last mile? Probably not--Is it middle mile? Maybe that's more interesting. It it CPU? Is it network cards? Is it the economics of your peering relationships? Unpicking those bits might help a bit. URL
For many, poor Wifi is the culprit. For many others, the ISP aggregation links are the culprit during the prime times (since most such links are oversubscribed/oversold). For some, the CDN issues create problems and for rare cases, the origin drowns and everybody gets upset. For certain environments like student dorms, campus networks, libraries, airport cafes, it is just lack of bandwidth for the power users.
Thanks, this version reads much better to me. I have no objections.
Change:
Section 7.5 of QUIC-TRANSPORT. Once the TLS handshake is complete, this is indicated to QUIC along <del> with any final handshake bytes that TLS needs to send.  TLS also provides QUIC with the transport parameters that the peer advertised during the handshake. </del> <ins> with any final handshake bytes that TLS needs to send.  At this stage, the transport parameters that the peer advertised during the handshake are authenticated; see quic_parameters. </ins> Once the handshake is complete, TLS becomes passive.  TLS can still receive data from its peer and respond in kind, but it will not need

Discussion:
This is OK, but only in a limited fashion.
NAME said: parameters are not delivered until the handshake is complete. In 8.2 it says that the TPs are "available" but "not fully trusted" before completion. The latter is certainly true; but the server can't send 0.5-RTT packets (e.g. a SETTINGS frame) without any indication of the client transport parameters. I would suggest a clarification in 4.1.3 and letting the language in 8.2 stand.
Proposed resolution is
I think the limitations could be a be clearer, but heading in a good direction.I think the changes add clarity.
Change:
4.1. <del> SATCOM systems typically feature Performance Enhancement Proxy (PEP) RFC3135.  PEP usually split TCP end-to-end connections and forward </del> <ins> SATCOM systems typically feature Performance Enhancing Proxy (PEP) RFC3135.  PEPs usually split TCP end-to-end connections and forward </ins> TCP packets to the satellite baseband gateway that deals with layer-2 and layer-1 encapsulations.  PEP contributes to mitigate congestion in a SATCOM systems.  PEP could host coding mechanisms and thus

Discussion:
section 4.1 - PEP is Enhancing, not Enhancement. PEPs usually split... section 4.2 - quickly varying channel conditions - if on the satellite link (where discussing channel conditions is out of scope?) that's what ACM, which is defined in the glossary, does -- and where network coding does not do as well. ASMS - spell out the conference name. No need to abbreviate journal names - this isn't an academic paper with a page limit. Do provide document object idenitifiers (DOIs) of papers where they exist
Thanks for the nits on the PEP. For the comment on ACM, we have updated the text (PR ) : "This problem has been tackled in the past for physical-layer code, but there remains questions on how to adapt the overhead for, e.g., the quickly varying channel conditions use-case where ACM may not be reacting quickly enough." We have updated the conference in PR and PR
Change:
3.1. <del> A problem details object can have the following members: </del> <ins> Problem detail objects can have the following members.  If the type of a member's value does not match the specified type, the member MUST be ignored - i.e., processing will continue as if the member had not been present. </ins> 3.1.1.

Discussion:
From URL : JSON objects with a null "type" are syntactically correct, but there is no information on how it should be handled. { "type": null, "status": 404, "title": "Not Found" } It makes sense to treat null as an alias of "about:blank" and that's how I think it should be documented.
Note that the errata above is only . My .02 -- if is , it's invalid, not "syntactically correct"; it's specified to be a string, and if someone assumes that has semantics, that's not currently specified behaviour. So the real question here is whether the default of is assumed when the value is invalid, or whether some other error handling comes into play. I think the safest thing to do would not be to assume that implies -- i.e., no change to the spec.
Since this is a specification of a format for error messages, I believe it is important that the processing of the error message is clear and lenient so the processing itself does not cause errors, possibly shrouding the initial error that caused the response in the first place. I therefore think the specification should be explicit that all erroneous values (such as , , , etc.) should be ignored and treated as the default value of each member, which for equals to , but for other members equal to an empty string(?).
I think I agree; changing issue title.
Change:
records without knowing how long the Connection ID is. In order to allow a receiver to determine whether a record has CID or <del> not, connections which have negotiated this extension use new record types for all protected records. new-cid-content-types shows the record types to use: </del> <ins> not, connections which have negotiated this extension use a distinguished record type tls12_cid(25).  Use of this content type has the following two implications: The CID field is present The true content type is inside the encryption envelope, as described below. </ins> 5. <del> The CID value, when present, is included in the MAC calculation for the DTLS record.  The MAC algorithm described in Section 4.1.2.1 of RFC6347 and Section 6.2.3.1 of RFC5246 is extended as follows: </del> <ins> When CID is being used, the DTLSCompressed value is first wrapped along with the true content type and padding into a DTLSWrappedCompressed value prior to encryption.  The DTLSWrappedCompressed value is then encrypted. The value of DTLSCompressed.fragment The true content type. Padding, as defined in RFC8446. In addition, the CID value is included in the MAC calculation for the DTLS record as shown below.  The MAC algorithm described in Section 4.1.2.1 of RFC6347 and Section 6.2.3.1 of RFC5246 is extended as follows: </ins> 6.

Discussion:
discussed in YUL. NAME
URL Still contains the content types removed in PR . alertwithcid(25) handshakewithcid(26) applicationdatawithcid(27) heartbeatwithcid(28) I guess, it should be updated towards PR ? tls12cid(25)
The PR can be found here: URL
The PR will fix it.
If you subscribe to the theory that DTLS has to mux with the realtime protocols, this takes a good slice of the remaining codepoints space. Though TLS has between 20 and 63, DTLS 1.3 takes 32-63 and the registration of 4 more would leave just 3: 29, 30, and 31. I submit that we might be better considering the TLS 1.3 record construction with a single codepoint. That would get us content type encryption and arbitrary padding as a secondary benefit. All for the modest cost of one octet.
If DTLS 1.3 used a demux prefix scheme like the one proposed , this should be no longer an issue.
Addressed in