jiebi/CodeConvo huggingface dataset:
Change:
forwarding re-encrypted media content (in this document referred to as "hop-by-hop media encryption"). <del> Both "hop-by-hop" and "end-to-end" encrypted transport may carry media that is, in addition, encrypted at the application layer. </del> <ins> In this document, we will focus on media encrypted at the transport layer, whether encrypted "hop-by-hop" or "end-to-end".  Because media encrypted at the application layer will only be processed by application-level entities, this encryption does not have transport- layer implications.  Of course, both "hop-by-hop" and "end-to-end" encrypted transport may carry media that is, in addition, encrypted at the application layer. </ins> Each of these encryption strategies is intended to achieve a different goal.  For instance, application-level encryption may be

Discussion:
From NAME Based on the title it is unclear whether this section also covers "app layer encryption", I guess no but this should be made clear (perhaps high in section 7 by stating that this doc does not cover app layer encryption).
This paragraph appears later in the document - I can move this up under the bullet points and make that clearer.
Fixed as in my previous comment.
BTW, unsure how the authors want me to mark "I have read the change and I like it" ? Currently, simply using a "thum up" emoticon on the solution comment. Let me know if you prefer another marking.
NAME If I can't hear you either giggling or screaming all the way to Texas, and I see a "thumbs up" emoticon, that's clear enough to me!
LGTM
Change:
7.6. The steps are the same as specified in Section 6.4 of RFC7252 with <del> the following changes: </del> <ins> minor changes. This step from RFC7252: is updated to: </ins> <del> If |url| does not have a <scheme> component whose value, when converted to ASCII lowercase, is "coap+tcp", "coaps+tcp", "coap+ws", or "coaps+ws" then fail this algorithm. </del> <ins> This step from RFC7252: </ins> <del> If |port| does not equal the request's destination TCP port, include a Uri-Port Option and let that option's value be |port|. </del> <ins> is updated to: </ins> 7.7. The steps are the same as specified in Section 6.5 of RFC7252 with <del> the following changes: </del> <ins> minor changes. </ins> <del> For CoAP over TCP, if the request is secured using TLS, let |url| be the string "coaps+tcp://".  Otherwise, let |url| be the string "coap+tcp://".  For CoAP over WebSockets, if the request is secured using TLS, let |url| be the string "coaps+ws://".  Otherwise, let |url| be the string "coap+ws://". </del> <ins> This step from RFC7252: </ins> <del> If the request includes a Uri-Port Option, let |port| be that option's value.  Otherwise, let |port| be the request's destination TCP port. </del> <ins> is updated to: This step from RFC7252: is updated to: </ins> 8.

Discussion:
URL - WGLC review by Esko Dijk • Page 22: "contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block)" -> Why can't the final block be 1024 bytes? I assume a final BERT block of 1024 bytes is allowed; it would be strange to switch back to SZX=6 for that purpose. What about below text -> "contain a multiple of 1024 bytes (non-final BERT block) or more than 1023 bytes (final BERT block)"
NAME - would you review and validate?
The text explains what is allowed with SZX=7 that is not allowed with SZX=6. As correctly noted, 1024 final is already allowed for SZX=6 (as is 1023, 1022, ...), so this is not explicitly listed in the list of additionally allowed cases. Maybe make clearer that this extends what has been allowed before instead of just saying that this is now allowed: s/is allowed/is also allowed/ or s//is additionally allowed/.
That seems like a simpler (if more subtle) edit.
Change:
4.6. <del> Quality of Service (QoS) mechanisms for flow specific traffic </del> <ins> Quality of Service (QoS) mechanisms for flow-specific traffic </ins> treatment typically includes a guarantee/agreement for the service, and allocation of resources to support the service.  Example QoS mechanisms include discrete resource allocation, admission control,

Discussion:
New section 5, and capitalized headings.
Lou, Yes, I'll make that change. Cheers, Andy
And done.
Thanks.... Lou PS you might want to turn off line wrap in your editor...
Lou, I just checked the settings and I don't believe it's doing any hard wrapping. What are you seeing? Cheers, Andy
right - it's best to use hard wrapping for maximum editor independence as well as github reviews. Lou
Balázs, This is similar to the text in the MPLS document, but that document references SR-MPLS. In the IP case, I figured that SR-MPLS was off the table, so I changed the reference to SRv6. The earlier part of the sentence already references control plane signaling, centralized management, and hybrid solutions. In addition to those, I wanted to include the fact that SRv6 is also a valid solution here. If there's anything else that you would like to include, we can certainly add that. Cheers, Andy
Change:
ClientHelloInner from EncodedClientHelloInner, as described in outer- extensions. <del> Upon determining the true SNI, the client-facing server then either serves the connection directly (if in Shared Mode), in which case it executes the steps in the following section, or forwards the TLS connection to the backend server (if in Split Mode).  In the latter case, it does not make any changes to the TLS messages, but just blindly forwards them. </del> <ins> Upon determining the ClientHelloInner, the client-facing server then forwards the ClientHelloInner to the appropriate backend server, which proceeds as in backend-server-behavior.  If the backend server responds with a HelloRetryRequest, the client-facing server forwards it, decrypts the client's second ClientHelloOuter using the modified procedure in server-hrr, and forwards the resulting second ClientHelloInner.  The client-facing server forwards all other TLS messages between the client and backend server unmodified. </ins> 7.1.1.

Discussion:
This fixes a few issues with the "Upon determining the true SNI" paragraph: It talkes about determining the "true SNI", but we should probably talk about the ClientHelloInner more generally. It refers to behavior in "the following section" which no longer matches. This is a remnant of before Shared Mode was described as a special case of Split Mode, so remove it. It says the server forwards messages unmodified, which isn't true. It needs to forward the decrypted ClientHello. It also needs to process HRR. I've cited the HRR section for the modified decryption procedure, which doesn't really exist right now, but is handling that.
Yup, this aligns with my understanding!
Change:
("low path") goes directly between the browsers, so it has to be conformant to the specifications of the WebRTC protocol suite; the signaling path ("high path") goes via servers that can modify, <del> translate or massage the signals as needed. </del> <ins> translate or manipulate the signals as needed. </ins> If the two Web servers are operated by different entities, the inter- server signaling mechanism needs to be agreed upon, either by

Discussion:
Mirja had the following comment/nit: massage the signals": not sure if "massage" is actually a meaningful word here…
Change:
shown below. The derivation process is as follows, where L denotes the length of <del> the underlying hash function for HKDF. </del> <ins> the underlying hash function for HKDF RFC5869. </ins> The traffic keys are computed from xSS, xES, and the master_secret as described in traffic-key-calculation below.

Discussion:
Use refs for HKDF & HMAC in the document and drop the unused AES CBC RFC ref in favor of the AES GCM RFCs (refs already in use). Caught via Travis warnings that they were all unused. It also notes that RFC 2246 (TLS 1.0) isn't referenced directly and RFC 5705 isn't used, either. NAME You probably wanted to reference RFC 5705 somewhere in your recent work, but it's not currently used. Travis also complains about I-D.ietf-tls-session-hash, though that is referenced in the credits. It probably should be referenced somewhere too.
I've also added an update to the "obsoletes" line. We don't need to list TLS 1.1 (TLS 1.2 & 1.3 don't list 1.0), its extensions RFC, or AES CBC, as they've already been obsoleted by TLS 1.2 (also obsoleted old AES RFC) and the newer extensions RFC.
Change:
as shown here. This document follows terminology defined in Section 1.2 of OVERVIEW. <ins> The diagrams describe encoding following the conventions described in Section 1.3 of QUIC-TRANSPORT. </ins> 2.

Discussion:
What is the uri-scheme used in an origin? ( It may be discussed as a separate issue.
Well, the origin sent here is the origin of the webpage that created QuicTransport; so, for instance, if connects using QuicTransport to , the origin send would be . I don't think a QuicTransport connection can be an origin by itself. We are currently considering giving it its own URL scheme, but a URL can only act as an origin if a user can to it, or if the URL has storage attached to it (which QuicTransport doesn't, since it doesn't support HTTP cookies).
I misunderstood the URI schema as that of QuicTransport itself Your kind explanation made me understand. thanks
Change:
4.3.1. <del> Each client creates a secret key "base_key" and shares it with the other participants via an E2E secure channel.  From "base_key", we derive the following values using HKDF RFC5869: </del> <ins> Each SFrame encryption or decryption operation is premised on a single secret "base_key", which is labeled with an integer KID value signaled in the SFrame header. The sender and receivers need to agree on which key should be used for a given KID.  The process for provisioning keys and their KID values is beyond the scope of this specification, but its security properties will bound the assurances that SFrame provides.  For example, if SFrame is used to provide E2E security against intermediary media nodes, then SFrame keys MUST be negotiated in a way that does not make them accessible to these intermediaries. For each known KID value, the client stores the corresponding symmetric key "base_key".  For keys that can be used for encryption, the client also stores the next counter value CTR to be used when encrypting (initially 0). When encrypting a frame, the application specifies which KID is to be used, and the counter is incremented after successful encryption. When decrypting, the "base_key" for decryption is selected from the available keys using the KID value in the SFrame Header. A given key MUST NOT be used for encryption by multiple senders. Such reuse would result in multiple encrypted frames being generated with the same (key, nonce) pair, which harms the protections provided by many AEAD algorithms.  Implementations SHOULD mark each key as usable for encryption or decryption, never both. Note that the set of available keys might change over the lifetime of a real-time session.  In such cases, the client will need to manage key usage to avoid media loss due to a key being used to encrypt before all receivers are able to use it to decrypt.  For example, an application may make decryption-only keys available immediately, but delay the use of encryption-only keys until (a) all receivers have acknowledged receipt of the new key or (b) a timeout expires. </ins> <del> A Salt key used to calculate the IV An encryption key to encrypt the media frame </del> <ins> 4.3.2. </ins> <del> An authentication key to authenticate the encrypted frame and the media metadata </del> <ins> SFrame encrytion and decryption use a key and salt derived from the "base_key" associated to a KID.  Given a "base_key" value, the key and salt are derived using HKDF RFC5869 as follows: </ins> <del> Each SFrame KID value identifies a "base_key", and thus both the "sframe_secret" and "sframe_salt" values to be used for encryption and decryption. </del> <ins> The hash function used for HKDF is determined by the ciphersuite in use. </ins> <del> 4.3.2. </del> <ins> 4.3.3. </ins> After encoding the frame and before packetizing it, the necessary media metadata will be moved out of the encoded frame buffer, to be

Discussion:
This PR attempts to capture the spirit of the original key management provisions with a little more clarity about assumptions. It also adds a more more explicit construction for connecting SFrame to MLS.
Change:
server can promise.  A server SHOULD use Push IDs sequentially, starting at 0.  A client MUST treat receipt of a push stream with a Push ID that is greater than the maximum Push ID as a connection <del> error of type HTTP_PUSH_LIMIT_EXCEEDED. </del> <ins> error of type HTTP_LIMIT_EXCEEDED. </ins> The header of the request message is carried by a PUSH_PROMISE frame (see frame-push-promise) on the request stream which generated the

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:
Applications that need to combine representations of zero or more different media types into one, e.g., EST-CoAP <del> N/A </del> <ins> The syntax and semantics of fragment identifiers specified for "application/multipart-core" is as specified for "application/ cbor".  (At publication of this document, there is no fragment identification syntax defined for "application/cbor".) </ins>

Discussion:
Carsten adds:
Yes. (Where is the rest of that change?)
As we speak there's no PR, only this issue.
NAME would you mind writing the missing text? I'm not comfortable messing around with media type registration procedures :-)
Change:
Clients will ignore a Version Negotiation packet if it contains the original version attempted by the client.  The client also ignores a Version Negotiation packet that contains incorrect connection ID <del> fields; see INV. </del> <ins> fields; see QUIC-INVARIANTS. </ins> Upon receiving the Version Negotiation packet, the client will search for a version it supports in the list provided by the server.  If it

Discussion:
editorial nit: for consitency with RFC 9000, consider changing you reference name from [INV] -> [QUIC-INVARIANTS]
Change:
The following metadata items are defined, all of which are OPTIONAL: <del> A string containing a URI identifying the current terms of service. </del> <ins> A URI identifying the current terms of service. </ins> <del> String containing an HTTP or HTTPS URL locating a website providing more information about the ACME server. </del> <ins> An HTTP or HTTPS URL locating a website providing more information about the ACME server. </ins> <del> If present, MUST be an array of strings.  Each string MUST be a lowercase hostname which the ACME server recognises as referring to itself for the purposes of CAA record validation as defined in RFC6844.  This allows clients to determine the correct issuer domain name to use when configuring CAA record. </del> <ins> Each string MUST be a lowercase hostname which the ACME server recognises as referring to itself for the purposes of CAA record validation as defined in RFC6844.  This allows clients to determine the correct issuer domain name to use when configuring CAA record. </ins> Clients access the directory by sending a GET request to the directory URI.

Discussion:
(Re-adding the editorial changes that got lumped in )
r+; thanks for pulling these out alone
Change:
ticket_lifetime. A randomly generated 32-bit value that is used to obscure the age <del> of the ticket that the client includes in the "early_data" </del> <ins> of the ticket that the client includes in the "pre_shared_key" </ins> extension.  The client-side ticket age is added to this value modulo 2^32 to obtain the value that is transmitted by the client.

Discussion:
Fix incorrect suggestion that of NST affects extension.
NAME merged. Please provide a PR adding yourself to the acknowledgements list in alphabetical order.
Change:
2.1. Flow identifiers represent bidirectional flows of datagrams within a <del> single QUIC connection.  These are conceptually similar to UDP ports and allow basic demultiplexing of application data.  The primary role of flow identifiers is to provide a standard mechanism for demultiplexing application data flows, which may be destined for different processing threads in the application, akin to UDP sockets. </del> <ins> single QUIC connection.  These are conceptually similar to streams in the sense that they allow multiplexing of application data.  Of course flows lack any of the ordering or reliability guarantees of streams. </ins> Beyond this, a sender SHOULD ensure that DATAGRAM frames within a single flow are transmitted in order relative to one another.  If

Discussion:
The comparison to UDP sockets is not as good as a comparison to streams. UDP sockets are sometimes spun up in the fashion described, but they are also often a fixed thing, such as the socket that a DNS server listens on. That evokes the wrong model in which the caller chooses and there is some possibility of persistence.
Change:
This is the most general deployment model, and is necessary for some types of issuance protocols where the Attester plays a role in token <del> issuance; see [rate-limited] for one such type of issuance protocol. </del> <ins> issuance; see RATE-LIMITED for one such type of issuance protocol. </ins> In this model, the Attester, Issuer, and Origin have a separate view of the Client: the Attester sees potentially sensitive Client identifying information, such as account identifiers or IP addresses,

Discussion:
cc NAME
draft-ietf-privacypass-architecture says in section 3.2: Is that correct? Isn't the 'token-key' in draft-ietf-privacypass-auth-scheme providing the pub key? Or do I misunderstand something here?
Oops, yep, good catch! We'll fix this.
Change:
can have multiple aliases set. In order to scope an alias to a specific transport protocol, an <del> Endpoint can specify a protocol identifier.  These identifiers MUST only be set for aliases. </del> <ins> Endpoint can specify a protocol identifier. </ins> The following example shows a case where "example.com" has a server running on port 443, with an alternate port of 8443 for QUIC.

Discussion:
Interface, section 4.1.2: Why the limitation to aliases? Specifying a protocol might limit the utility of connection racing, so should perhaps be discouraged, but does it break anything to specify a protocol for a non-alias Endpoint?
Interim: suggest to remove the second sentence.
They are currently just called "Table"
In the interface draft, Section 1.1: Where is the event sent? Perhaps ?
Interim: add "to the application" (but double check, related to framers)
Could alternatively say the same another way around: "Applications can use these events..." (i.e. avoid saying only applications do this).
Section 6 in impl-draft has the parts where the framer objects receive events. There is no terminology section in implementation, so not sure if the terminology section in API should cover it as well.
We already say this in the intro text to this section, but I can tweak the structure and add some additional text to make this more clear.
The appendix text about convenience functions talks about "implementations should" provide various things. This reads strangely to me. I think these are not requirements and the text should be more in the form of it can be useful for implementations to provide various things.
How about: " implementations can provide special actions for adding each preference level i.e, TransportProperties.Set(someproperty, avoid) would be equivalent to TransportProperties.Avoid(someproperty):..."
EstablishmentError. Fixed in an upcoming PR.
Change:
array of the MUD file. Second, the "mud" container is augmented with a container that points <del> to where to report and how often. </del> <ins> to where to report. The frequency of reporting is impelementation dependent. Impelemntations are encouraged to report when ever packet drops are noticed at the enforcement point; however, this is not a strict requirement. </ins> This is done as follows:

Discussion:
Added a default packet classification. Removed the generated txt file ( can always be generated from Makefile). Please reject pull request if you disagree. Thanks.
Reworked yang model. Mostly implemented (except for json serialization).
Reduced the amount of information in the YANG model to something manageable. Mostly implemented (except for some JSON serialization issues). At least it is feasible to implement this. Removed frequency (should be left to administrator - not manufacturer).
Change:
willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. However, not all parameters follow this rule; for example, the <del> fingerprints I-D.ietf-mmusic-4572-update sent to a remote party are calculated based on the local certificate(s) offered; the remote party MUST either accept these parameters or reject them altogether, with no option to choose different values. </del> <ins> fingerprints RFC8122 sent to a remote party are calculated based on the local certificate(s) offered; the remote party MUST either accept these parameters or reject them altogether, with no option to choose different values. </ins> In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an

Discussion:
I don't know why build of ghpages is failing travis. It works for me on my machine so going to ignore this for a bit.
Here is the diff of the change.
BLOCKER: The nits tool reports (and a cursory hand check supports this) that six of the references are unused, and RFC4572 has been (recently) obsoleted. The remaining references are largely out of date by many versions, which I believe the current tools will automatically handle if version numbers are simply pulled out of the source. Finally, a large number of the referenced working group documents still use the individual name (e.g., draft-nandakumar-rtcweb-sdp instead of draft-ietf-rtcweb-sdp).
Need to verify section numbers when these refs change, but otherwise seems fine.
LGTMLG, assuming this generates the equivalent text.
Change:
caching discusses the relationship between DNS and HTTP response caching. <del> A DNS API server MUST be able to process application/dns- udpwireformat request messages. </del> <ins> A DNS API server MUST be able to process message/dns request messages. </ins> A DNS API server SHOULD respond with HTTP status code 415 (Unsupported Media Type) upon receiving a media type it is unable to

Discussion:
The media type has been the subject of some debate. The above might be the best I've seen.