jiebi/CodeConvo huggingface dataset:
Change:
merge compression contexts that the original encoder had specifically kept separate. <del> Simply removing entries corresponding to the field from the dynamic table can be ineffectual if the attacker has a reliable way of causing values to be reinstalled.  For example, a request to load an image in a web browser typically includes the Cookie header field (a potentially highly valued target for this sort of attack), and websites can easily force an image to be loaded, thereby refreshing the entry in the dynamic table. </del> 7.1.3. Implementations can also choose to protect sensitive fields by not

Discussion:
Addresses most of the open RFC Editor questions.
Need to update Buck's contact information to .
Fixed in .
This is a change in the RFC Editor diff that I don't think works; pulling out for separate discussion. Original: Proposed but incorrect: The intended reading is: For... HTTP/3 servers (always, regardless of 0-RTT) and HTTP/3 clients when 0-RTT is not attempted or is rejected URL maximum table capacity is 0.
Fixed in .
Should the following text be formatted using ? See the definition at . Original: Note: Padding schemes only provide limited protection against an attacker with these capabilities, potentially only forcing an increased number of guesses to learn the length associated with a given guess. Padding schemes also work directly against compression by increasing the number of bits that are transmitted. Original: Note: Simply removing entries corresponding to the field from the dynamic table can be ineffectual if the attacker has a reliable way of causing values to be reinstalled. For example, a request to load an image in a web browser typically includes the Cookie header field (a potentially highly valued target for this sort of attack), and websites can easily force an image to be loaded, thereby refreshing the entry in the dynamic table.
Probably yes.
Fixed in .
May we update "Huffman-coded" with "Huffman encoded" in this text to match other uses? Original: They begin with a single bit flag, denoted as 'H' in this document (indicating whether the string is Huffman-coded), followed by the Length encoded as a 7-bit prefix integer, and finally Length bytes of data.
Fixed in .
Change:
In order to create a new WebTransport session, a client can send an HTTP CONNECT request.  The ":protocol" pseudo-header field (RFC8441) <del> MUST be set to "webtransport" (Section 7.1 WEBTRANSPORT-H3).  The </del> <ins> MUST be set to "webtransport" (Section 7.1 of WEBTRANSPORT-H3).  The </ins> ":scheme" field MUST be "https".  Both the ":authority" and the ":path" value MUST be set; those fields indicate the desired WebTransport server.  An "Origin" header RFC6454 MUST be provided

Discussion:
There was a local reference that was just typed out. The references to other documents cargo-culted from QUIC, but that only works if the documents are in the same repo. You have to pull references from the datatracker. Use the nice reference format in a few places.
Change:
flight which the endpoint has received and either processed or buffered, in numerically increasing order. <del> Implementations MUST NOT acknowledge records containing non- duplicative handshake messages or fragments which have not been processed or buffered.  Otherwise, deadlock can ensue. </del> <ins> Implementations MUST NOT acknowledge records containing handshake messages or fragments which have not been processed or buffered. Otherwise, deadlock can ensue.  As an example, implementations MUST NOT send ACKs for handshake messages which they discard as out-of- order. </ins> During the handshake, ACKs only cover the current outstanding flight (this is possible because DTLS is generally a lockstep protocol).

Discussion:
In response to feedback on the mailing list (URL), this PR attempts to clarify (a) when to generate ACKs, and (b) which records to ACK.
This is much clearer to me. I see that you have removed the sentence I was having a problem with in the bullet: "Implementations MUST NOT send ACKs for handshake messages which they discard as out-of-order, because otherwise those messages will not be retransmitted"; logically, I believe you have captured this better by adding "and processed" above in "The ACK message is used by an endpoint to indicate which handshake records it has received and processed from the other side."
NAME Thank you for your feedback! I have removed the sentence because its content is already implied by what's stated in the previous section . See the commit description of URL
NAME thanks. This sensibly improves readability and clarity. Hi Hanno, Thank you for your clarifications. The example you gave helps a lot. I believe I now understand the text as written in this bullet (first bullet, not second--my bad). I no longer think it needs re-wording. Best regards, Jonathan Hanno Becker wrote:
Change:
handles act as shared secrets, though they can be combined with a requirement to provide proof of a key as well. <del> 8. </del> <ins> 7. </ins> [[ TBD: There are a lot of privacy considerations to add. ]]

Discussion:
See also related PR at ietf-wg-gnap/gnap-core-protocol
Deploy preview for gnap-resource-servers-editors-draft ready! Built with commit ec0063ea1a01f824c05137ecaaf8c7760dfee083 https://deploy-preview-26--gnap-resource-servers-editors-URL
Following the review I checked this PR too, seems fine
Change:
The process of creating new packet protection keys for receiving packets could reveal that a key update has occurred.  An endpoint MAY <del> perform this process as part of packet processing, but this creates a timing signal that can be used by an attacker to learn when key updates happen and thus the value of the Key Phase bit in certain packets.  Endpoints MAY instead defer the creation of the next set of receive packet protection keys until some time after a key update completes, up to three times the PTO; see old-keys-recv. </del> <ins> generate new keys as part of packet processing, but this creates a timing signal that could be used by an attacker to learn when key updates happen and thus leak the value of the Key Phase bit. Endpoints are generally expected to have current and next receive packet protection keys available.  For a short period after a key update completes, up to the PTO, endpoints MAY defer generation of the next set of receive packet protection keys.  This allows endpoints to retain only two sets of receive keys; see old-keys-recv. </ins> Once generated, the next set of packet protection keys SHOULD be retained, even if the packet that was received was subsequently

Discussion:
Some of this is just forward reference, but it does need a little more context. Also, there was a missing word.
This also no?
NAME said:
I'll roll this into the change for as it relates to the same basic text. I like the "promoting" idea, though I'm not going to go back and rewrite everything to use it. Here, the important thing is to have words for current, next, and "subsequent next" to avoid making this more confusing than necessary. I think that I got it.
NAME said:
I can see an obvious missing word in there at a minimum. I can see some opportunities for clarification here though, so I'll give it a go. Breaking the ordering dependencies between sections is tricky though. It might just be that we need a little redundancy.
This is a big help; thank you!
Change:
6. <del> The security considerations of DetNet in general are discussed in RFC8655 and I-D.ietf-detnet-security.  DetNet IP data plane specific considerations are summarized in I-D.ietf-detnet-ip.  Encryption may provided by an underlying sub-net using MACSec IEEE802.1AE-2018 for DetNet IP over TSN flows. </del> <ins> Security considerations for DetNet are described in detail in I- D.ietf-detnet-security.  General security considerations are described in RFC8655.  DetNet IP data plane specific considerations are summarized in I-D.ietf-detnet-ip.  This section considers exclusively security considerations which are specific to the DetNet IP over TSN sub-network scenario. The sub-network between DetNet nodes needs to be subject to appropriate confidentiality.  Additionally, knowledge of what DetNet/ TSN services are provided by a sub-network may supply information that can be used in a variety of security attacks.  The ability to modify information exchanges between connected DetNet nodes may result in bogus operations.  Therefore, it is important that the interface between DetNet nodes and TSN sub-network are subject to authorization, authentication, and encryption. The TSN sub-network operates at Layer-2 so various security mechanisms defined by IEEE can be used to secure the connection between the DetNet nodes (e.g., encryption may be provided using MACSec IEEE802.1AE-2018). </ins> 7.

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
When sending a DetNet flow, zero or more F-Labels MAY be pushed on top of an S-Label by the node pushing an S-Label.  The F-Label(s) to be pushed when sending a particular DetNet service MUST be <del> provisioned per DetNet service via configuration, e.g., via the </del> <ins> provisioned per outgoing S-Label via configuration, e.g., via the </ins> controller plane discussed in I-D.ietf-detnet-data-plane-framework. F-Label(s) can also provide context for an S-Label.  To allow for the omission of F-Label(s), an implementation SHOULD also allow an <del> outgoing interface to be configured. </del> <ins> outgoing interface to be configured per S-Label. </ins> <del> When PRF is supported, the same app-flow data will be sent over </del> <ins> Note, when PRF is supported, the same app-flow data will be sent over </ins> multiple outgoing DetNet member flows using forwarding sub-layer <del> LSPs.  To support PRF an implementation MUST support the setting of different sets of F-Labels per DetNet member flow.  To allow for the omission of F-Labels, an implementation SHOULD also allow multiple outgoing interfaces to be provisioned. </del> <ins> LSPs.  This means that implementation may be sending different sets of F-Labels per DetNet member flow, each with a different S-Label. </ins> When a single set of F-Labels is provisioned for a particular outgoing S-Label, that set of F-labels MUST be pushed after the

Discussion:
Clarifying S-Label procedures (i.e., allowing S-Label value per outgoing member flow after PRF).
Change:
flight, the timer MUST be set to the earlier value of the Initial and Handshake packet number spaces. <del> An endpoint MUST NOT set its PTO timer for the application data </del> <ins> An endpoint MUST NOT set its PTO timer for the Application Data </ins> packet number space until the handshake is confirmed.  Doing so prevents the endpoint from retransmitting information in packets when either the peer does not yet have the keys to process them or the

Discussion:
For this document, I believe the best option is to use "Application Data" when referring to the packet number space, and "application data" when referring to generic application data, such as when discussing being app-limited due to lack of application data. 6) [rfced] Throughout the text, the following term appears to be used inconsistently. Please review these occurrences and let us know if/how they may be made consistent. application data / Application Data Note that RFC-to-be 9000 uses the lowercase form consistently. We raised a similar question for RFC-to-be 9001; the authors decided on the following: (see URL)
Change:
the most preferred media format from the remote description that is also present in the answer, as described in RFC3264, Sections 6.1 and 7, and start transmitting RTP media once the <del> underlying transport layers have been established.  If a SSRC </del> <ins> underlying transport layers have been established.  If an SSRC </ins> has not already been chosen for this outgoing RTP stream, <del> choose a random one. </del> <ins> choose a random one.  If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as specified in RFC7160, Section 3.1. </ins> The payload type mapping from the remote description is used to determine payload types for the outgoing RTP streams, including

Discussion:
URL
This doesn't affect SDP, but we could add some text to the para below indicating a SSRC switch is needed when changing to a codec with a different clockrate: If the directional attribute in the answer is of type "sendrecv" or "sendonly", choose the media format to send as the most preferred media format from the remote description that is also present in the answer, as described in [RFC3264], Sections 6.1 and 7, and start transmitting RTP media once the underlying transport layers have been established. If a SSRC has not already been chosen for this outgoing RTP stream, choose a random one.
(and add a reference)
Closing per
Change:
version.  Endpoints have no need to generate the keying material that would allow them to decrypt or authenticate these packets. <del> If the server's version_information transport parameter does not contain a Chosen Version field equivalent to the version in the server's Handshake packet headers, the client MUST terminate the connection with a VERSION_NEGOTIATION_ERROR. </del> The client MUST NOT send 0-RTT packets using the negotiated version, even after processing a packet of that version from the server. Servers can apply original version 0-RTT packets to a connection

Discussion:
, ,
It would be nice to have the references use a consistent format (e.g. all having a name instead of the RFC number for some)
OK, I've only left document number references where the subject is indicated beforehand, e.g. Alt-Svc {{?RFC7838}}
fixed by
Draft currently states: This repeats the QUIC VN document, should we remove it?
Yes, good catch.
fixed by
The draft currently says: Could we add a note to be removed by the RFC editor that clarifies whether or not we're going to change the version number before publication or not?
fixed by
The abstract currently contains: I'm pretty sure the second one won't be included, but there's no note saying so. I don't know if the first one is meant to stay. Can we add a note to make this explicit? Markdown can do it for you for the second one.
Actually the second note can be removed entirely because it repeats the paragraph that's autogenerated.
Thanks!
Change:
5.3. <del> At several points in the protocol, it is necessary for the server to </del> <ins> At some points in the protocol, it is necessary for the server to </ins> determine whether two JSON Web Key (JWK) RFC7517 objects represent the same key.  In performing these checks, the server MUST consider two JWKs to match if and only if they have the identical values in

Discussion:
Previously, each authenticated POST included a copy of its public key in the JWS protected header. Servers were required to canonicalize this key in some way and look it up in a database, then verify the payload. However, servers also had the option of verifying the payload, and then looking up the key in the database. This opened up a category of potential bugs based on truncated database fields or hash collisions, where an attacker could craft a key pair the would potentially be matched to someone else's account. Incidental benefits: Switching to kid makes payloads somewhat smaller, and removes the need to define key equality in the ACME spec.
Updated based on feedback.
Updated. Rather than have a switch/case about how to authenticate revoke-cert, I split it into two resources, authenticated different ways: one by account, one by cert key.
Change:
Inputs: <del> "s_cfg": A "ServerConfig" struct. </del> <ins> "srv_cfg": A "ServerConfig" struct. </ins> <del> "issuance_message": A "ClientIssuanceMessage" struct. </del> <ins> "issuance_request": A "ClientIssuanceRequest" struct. </ins> Outputs:

Discussion:
Rename IssuanceMessage and RedemptionMessage to IssuanceRequest and RedemptionRequest, respectively. Rename SecretKey to PrivateKey. Change to an integer value, rather than opaque vector. I also removed company-specific information, which is not really relevant for the document. (That's useful information, but not appropriate for a standards document, I think.) cc NAME NAME
Change:
2. <del> A CoRE Problem Details is a CoRAL document with the following elements: </del> <ins> A Concise Problem Details data item is a CBOR data item with the following structure (notated in CDDL RFC8610): </ins> <del> "type" (id) - The problem type.  This is a mandatory element. </del> <ins> A number of problem detail entries, the Standard Problem Detail entries, are predefined (more predefined details can be registered, see new-spdk): </ins> <del> "title" (text) - A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem. </del> <ins> Note that, unlike RFC7807, Concise Problem Details data items have no explicit type. </ins> <del> "detail" (text) - A human-readable explanation specific to this occurrence of the problem. </del> <ins> Both "title" and "detail" can use either an unadorned CBOR text string ("text") or a language-tagged text string ("tag38"); see tag38 for the definition of the latter. </ins> <del> "instance" (uri) - A URI reference that identifies the specific occurrence of the problem.  It may or may not yield further information if dereferenced. Consumers MUST use "type" as primary identifiers for the problem type; the "title" string is advisory and included only for consumers who are not aware of the semantics of the "type" value.  An initial set of "type"s and corresponding "title"s is defined in sec-response- code-types. </del> <ins> The "title" string is advisory and included to give consumers a shorthand for the category of the error encountered. </ins> The "detail" member, if present, ought to focus on helping the client correct the problem, rather than giving debugging information.

Discussion:
This PR provides the write-up of the discussed at the interim. Note that it branches off Carsten's "bundled" PR ()
I did a little bit of editing. Comments welcome...
Change:
then the relaying entity should not expect to have access to the Evidence. <del> 12.3. </del> <ins> The RATS architecture allows for an entity to function in multiple roles (rolesentities) and for composite devices (compositedevice). Implementers need to evaluate their designs to ensure that the assumed security properties of the individual components and roles still hold despite the lack of separation, and that emergent risk is not introduced.  The specifics of this evaluation will depend on the implementation and the use case and hence is out of scope for this document.  Isolation mechanisms in software or hardware that separate Attesting Environments and Target Environments twotypes can support an implementer's evaluation and resulting design decisions.  ## Epoch ID-based Attestation {#epochids-sec} </ins> Epoch IDs, described in epochfreshness, can be tampered with, replayed, dropped, delayed, and reordered by an attacker.

Discussion:
insert text suggested by Roman about how deep down the security properties
[github said: URL] ==[ snip ]== We need to acknowledge that there is a deep hole (not infinitely deep, but not trivial) where we need to look at integrity of all of the different platforms. The way that the compositions are composed is a bit tricky, and the results are sometimes different than other people would naively assume. Are there references here to other papers that we should include? ==[ snip ]== I completely agree, that's why I mentioned it. Composition is hard and can alter the security assumptions of the individual components and introduce emergent risk. I don't think it can be solved generically. However, we do need cautionary text here. Perhaps: NEW (roughly) The RATS architecture allows for an entity to function in multiple roles (Section 6) and for composite devices (Section 3.3). Implementers need to evaluate their designs to ensure that the assumed security properties of the individual components and roles still holds despite the lack of separation, and that emergent risk is not introduced. The specifics of this evaluation will depend on the implementation and use case is out of scope for this document.
Change:
Endpoint.  When receiving Messages, Message Properties can contain information about the received Message, such as metadata generated at the receiver and information signalled by the remote endpoint. <ins> For example, a Message can be marked with a Message Property indicating that it is the final message on a connection if the peer sent a TCP FIN. </ins> Send: The action to transmit a Message over a Connection to the remote system.  The interface to Send MAY include Message

Discussion:
arch doc sec 4.1.4: "When receiving Messages, Message Properties can contain information about the received Message, such as metadata generated at the receiver and information signalled by the remote endpoint." Maybe provide an example here...?
Suggestion: ECN, which is information given from UDP in the form of such metadata.
QUIC stream identifier example works
Final message is in API, just use that
LGTM modulo one nit - but see if you agree with my suggestion. If you don't, I'm ok with this anyway.
Change:
The maximum datagram size is defined as the largest size of UDP payload that can be sent across a network path using a single UDP <del> datagram. QUIC depends upon a minimum IP packet size of at least 1280 bytes. This is the IPv6 minimum size (IPv6) and is also supported by most modern IPv4 networks.  Assuming the minimum IP header size of 40 bytes for IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this results in a maximum datagram size of 1232 bytes for IPv6 and 1252 bytes for IPv4. The maximum datagram size MUST be at least 1200 bytes. </del> <ins> datagram.  QUIC MUST NOT be used if the network path cannot support a maximum datagram size of at least 1200 bytes. QUIC assumes a minimum IP packet size of at least 1280 bytes.  This is the IPv6 minimum size (IPv6) and is also supported by most modern IPv4 networks.  Assuming the minimum IP header size of 40 bytes for IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this results in a maximum datagram size of 1232 bytes for IPv6 and 1252 bytes for IPv4.  Thus, modern IPv4 and all IPv6 network paths will be able to support QUIC. </ins> Any maximum datagram size larger than 1200 bytes can be discovered using Path Maximum Transmission Unit Discovery (PMTUD; see pmtud) or

Discussion:
On endpoints.
This is the IPv6 minimum size ([IPv6]) and is also supported by most modern IPv4 networks. Assuming the minimum IP header size of 40 bytes for IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this results in a maximum datagram size of 1232 bytes for IPv6 and 1252 bytes for IPv4. The previous two paras are quite confusing. I think the first para refers to the max packet size in the network layer, but the second para is not clear, nor is the next para.
The paragraph preceding the first is this: So it is clear what the second paragraph means. QUIC doesn't operate if the network is incapable of carrying a datagram payload of 1200 bytes. I think that rewording that way might help. What is less clear is where the extra 32 (or 52) bytes go. In that we've been very generous in providing for header extensions or UDP extensions. But I don't see a need to explain that aspect.
I found this to still be very confusing, FWIW. It's unclear why the limit would be 1200 bytes when the text very clearly explains that at least 1232 can be relied upon, or alternatively why the text claims "QUIC assumes a minimum IP packet size of at least 1280 bytes." when in fact it appears to only mandate a 32 bytes smaller figure. It reads like someone forgot to update a constant. NAME above suggests that this was intentional, to leave space for unspecified future use by lower layers. I think some allusion to this is justified, just to clarify the otherwise seeming inconsistency.
A sentence to tie it together but LGTM