jiebi/CodeConvo huggingface dataset:
Change:
Do53: Unencrypted DNS over UDP port 53, or TCP port 53 RFC1035. <del> Equivalent: See equivalence. </del> <ins> Designated: See designation. Designator: The network or resolver that issued the designation. </ins> 3. It is often the case that a client possesses no specific configuration for how to operate DNS, and at some point joins a <del> network that it has no previous knowledge about.  In such a case the usual existing behaviour is to dynamically discover the network's recommended Do53 resolver and use it.  This long-standing practice </del> <ins> network that it cannot authenticate.  It may have no prior knowledge of the network, or it may have connected previously to a network that looked the same.  In either case the usual behaviour, because of lack of specific configuration, is to dynamically discover the network's designated Do53 resolver and use it.  This long-standing practice </ins> works in nearly all networks, but presents a number of privacy and security risks that were the motivation for the development of encrypted DNS. <del> The network's recommended unencrypted resolver may have a number of </del> <ins> The network's designated Do53 resolver may have a number of </ins> properties that differ from a generic resolver.  It may be able to answer names that are not known globally, it may exclude some names (for positive or negative reasons), and it may provide address

Discussion:
This PR simplifies further by removing any mention of properties of the encrypted resolvers, or properties of the relationship between the Do53 and the encrypted resolver. It now purely focusses on the ability of an untrusted network or resolver to designate other encrypted resolvers. This is an assertion that the encrypted resolver is safe and appropriate to use, but little else. Clients will of course make their own decisions about whether to use designated resolvers or not. Other drafts will look at trusted networks, and communicating information that can be useful to clients as part of the untrusted decision-making.
comments
comments on the draft02
It was pointed out that this should be limited to IETF-standardised encrypted DNS protocols rather than potentially including DNSCrypt and being very open-ended.
Change:
provides the motivations for each of the manifest information elements. <ins> Note that it is worthwhile to recall that a firmware update is, by definition, remote code execution.  Hence, if a device is configured to trust an entity to provide firmware, it trusts this entity to do the "right thing".  Many classes of attacks can be mitigated by verifying that a firmware update came from a trusted party and that no rollback is taking place.  However, if the trusted entity has been compromised and distributes attacker-provided firmware to devices then the possibilities for deference are limited. </ins> 4.1. The following sub-sections aim to provide information about the

Discussion:
Section 4 We should probably mention the URI security considerations (RFC 3986) somewhere, as well as that remote resources need to receive an equal amount of cryptographic protection as the manifest itself, when dereferencing URIs.
Addressed in URL
Addressed in draft-ietf-suit-information-model-11
It might also be worth reiterating the topic that came up during one of the other review threads: firmware update is by definition remote code execution, so if you trust an entity to provide your firmware, you are trusting them to do the right thing. Many classes of attack involving malicious or modified payloads then become irrelevant, so we are left with just needing to verify that it did come from a trusted party and is not going backwards, topics that are covered quite well already (including TOCTOU).
Addressed in URL
Addressed in draft-ietf-suit-information-model-11
Change:
"collector_hpke_config_id" is "collector_config.id" from the task parameters corresponding to "CollectReq.task_id". <del> "enc" is the encapsulated HPKE context, used by the collector to </del> <ins> "enc" is the HPKE encapsulated key, used by the collector to </ins> decrypt the aggregate share. "payload" is an encrypted "AggregateShare".

Discussion:
Here are a few small editorial changes: Refer to TLS's "presentation language", per section 3 of the RFC. The output from the HPKE setup function is an encapsulated key, not an encapsulated context. The term context is defined as "A context is an implementation-specific structure...", whereas is alternately described as "an encapsulated KEM shared secret", an "encapsulated key", or a "KEM encapsulated key". Remove stray whitespace from a hyphenated word.
One non-blocking comment.
Change:
10. Two examples are presented: a Lighting Installation example in lt-ex <del> and a LWM2M example in lwm2m-ex. </del> <ins> and a LwM2M example in lwm2m-ex. </ins> 10.1.

Discussion:
This is a series of commits removing cruft in the examples as discussed in URL Diverging from the discussion outcome, more than a single line was kept of 10.2, as the historical note left in , by analogy, means that we should mention that application's choice of a fixed path as well. Some commits may be added still as I'm going through the list.
I'm merging this in to ensure it interacts well with the example updates (where the resource types were replaced with actual example values); any follow-ups will go to a separate PR.
Change:
3.1. This document clarifies that when a name server generates a referral <del> response over UDP transport, it MUST include all available in-domain glue records in the additional section, or MUST set TC=1.  When a name server generates a referral response over TCP transport, it MUST include all available in-domain glue records. </del> <ins> response, it MUST include all available in-domain glue records in the additional section, or MUST set TC=1 if constrained by message size. At the time of writing, most iterative clients send initial queries over UDP and retry over TCP upon receiving a response with the TC flag set.  UDP responses are generally limited to between 1232 and 4096 bytes, due to values commonly used for the EDNS0 UDP Message Size field RFC6891, FLAGDAY2020.  TCP responses are limited to 65,536 bytes. </ins> 3.2. This document clarifies that when a name server generates a referral response, it SHOULD include all available glue records in the additional section.  If after adding all in-domain glue records, not <del> all sibling glue records fit in a response over UDP transport, the </del> <ins> all sibling glue records fit due to message size constraints, the </ins> name server is NOT REQUIRED to set TC=1. Note that users may experience resolution failures for domains with

Discussion:
and talk more generically about message size constraints regardless of transport. For
As currently written the document only talks about setting TC=1 over UDP. This sort of implies that UDP is the only possible transport where TC flag has meaning. We don't talk about setting TC over TCP because the assumption is that TCP always has enough room for all glue or whatever. But this doesn't account for two possibilities 1) a future transport that is limited in space 2) some kind of ridiculous zone configuration with so many NS and glue records that they won't even fit in a single DNS-over-TCP message. Would it be better to just say "set TC=1 if glue doesn't fit" and not bring UDP or TCP into the requirements language?
I like the idea of that, but I think simultaneous possession and ingestion of cake is also possible -- make the general, transport-agnostic point but also give the UDP/TCP fallback as an example that is known to be common at the time of writing. Joe
I prefer mentioning UDP and TCP and to say clearly never set it for TCP. I wouldn't consider "insanely weird" TCP that requires TC=1
would or wouldn't?
was merged so closing this for now
Change:
same packet as the QUIC CONNECTION_CLOSE frame improves the chances of the frame being received by clients. <ins> If there are open streams that have not been explicitly closed, they are implicitly closed when the connection is closed; see Section 10.2 of QUIC-TRANSPORT. </ins> 5.4. For various reasons, the QUIC transport could indicate to the

Discussion:
Address multiple editorial comments.
NAME said
NAME said
The text currently says: Transport makes the following addition, in : That might be worth reiterating in HTTP/3.
NAME said
Two separate questions. I'm fine generalizing it to HTTP/1.x. The link between the first two sentences is the fact that HTTP/1.x uses human-readable whitespace-delimited fields, but those attributes make parsing inconsistent; subsequent versions of HTTP/2 went a different direction. If you're talking about the second and third, that could easily be a paragraph split; it's a change of idea under the umbrella of major changes of direction from H1 to H2+.
Change:
Clients MUST NOT assume that a positive RateLimit-Remaining field value is a guarantee that further requests will be served. <del> A low RateLimit-Remaining field value is like a yellow traffic-light for either the number of requests issued in the time window or the request throughput: the red light may arrive suddenly (see providing- ratelimit-fields). </del> <ins> When the value of RateLimit-Remaining is low, it indicates that the server may soon throttle the client (see providing-ratelimit-fields). </ins> For example:

Discussion:
This should be specified without resorting to a metaphor that some may find confusing.
I'm ok to removing this line.
Change:
4. <del> QUIC version 2 endpoints SHOULD also support QUIC version 1.  Any QUIC endpoint that supports multiple versions MUST meet the minimum requirements described in QUIC-VN to prevent version downgrade attacks. </del> <ins> QUIC version 2 is not intended to deprecate version 1.  Endpoints that support version 2 might continue support for version 1 to maximize compatibility with clients.  In particular, HTTP clients often use Alt-Svc RFC7838 to discover QUIC support.  As this mechanism does not currently distinguish between QUIC versions, HTTP servers that support multiple versions reduce the probability of incompatibility and the cost associated with QUIC version negotiation or TCP fallback.  For example, an origin advertising support for "h3" in Alt-Svc SHOULD support QUIC version 1 as it was the original QUIC version used by HTTP/3 and therefore some clients will only support that version. Any QUIC endpoint that supports multiple versions MUST meet the minimum requirements described in QUIC-VN to prevent version downgrade attacks. </ins> Note that version 2 meets that document's definition of a compatible <del> version with version 1.  Therefore, v2-capable servers MUST use compatible version negotiation unless they do not support version 1. </del> <ins> version with version 1.  Therefore, servers can use compatible negotiation to switch a connection between the two versions. Endpoints that support both versions SHOULD support compatible version negotiation to avoid a round trip. </ins> 4.1.

Discussion:
The original intent was to recommend compatible VN. But that doesn't make any sense: compatible VN is something that the server initiates between versions that are at least partially supported. The client doesn't really have any control except that it can omit versions from the TP. Incompatible VN cannot happen between mutually supported versions, and the client is in control.
NAME major rewrite that I think addresses your concerns. PTAL
In practice, v2 servers should also support compatible VN, as long as v1 clients are ubiquitous. To do otherwise would result in a performance penalty.
Thanks for the discussion!
Change:
Version Negotiation packet is received.  The client MAY use this value in place of its default for the initial RTT estimate. <del> 5.5. </del> <ins> 5.4. </ins> When packet protection keys are discarded (see Section 4.10 of QUIC- TLS), all packets that were sent with those keys can no longer be

Discussion:
I believe this section was mistakenly on the wrong level. I also added a reference to a later section to the last sentence. Alternatively this sentence could just be removed as this is normatively specified later on.
Change:
The size of the first packet sent by a client will determine whether a server sends a Version Negotiation packet.  Clients that support <del> multiple QUIC versions SHOULD pad the first UDP datagram they send to the largest of the minimum datagram sizes from all versions they support.  This ensures that the server responds if there is a </del> <ins> multiple QUIC versions SHOULD ensure that the first UDP datagram they send is sized to the largest of the minimum datagram sizes from all versions they support, using PADDING frames (frame-padding) as necessary.  This ensures that the server responds if there is a </ins> mutually supported version.  A server might not send a Version Negotiation packet if the datagram it receives is smaller than the minimum size specified in a different version; see initial-size.

Discussion:
Changes to explain Padding == PADDING Frame
Thanks again Gorry.
I have a long comment on a scattered observation that could be very simple to fix: In section 6, it wasn’t clear what were the ways that "padding" could be performed. There could be various ways - simply leave UDP payload unused, fill it with coalesced QUIC packets, add padding and other frames, etc and when the text says this I think it’s unclear to me what is expected - any or all of these, but it doesn't seem to be said. e.g.: /Clients that support multiple QUIC versions SHOULD pad the first UDP datagram they send to the largest of the minimum datagram sizes from all versions they support. / Is the assumption here, more like: /Clients that support multiple QUIC versions SHOULD coalesce QUIC packets or add PADDING frames to pad the first UDP datagram they send to the largest of the minimum datagram sizes from all versions they support. / … rather than some other technique to pad-out the datagram payload? See also: /Clients MUST ensure that UDP datagrams containing Initial packets have UDP payloads of at least 1200 bytes, adding padding to packets in the datagram as necessary. A client that sends padded datagrams allows the server to send more data prior to completing address validation./ and later: /In particular, an endpoint can pad a packet carrying a PATH_CHALLENGE for Path Maximum Transfer Unit (PMTU) discovery / So, I think the topic of padding needs a tiny bit more clarification - it’s almost there, but maybe a sentence that explicitly explains the permitted options in section 14 would be good, which could be cited rather than this scattered mention of “pad-out”
Perhaps these mentions of the word "padding" just need to reference section 19.1. "PADDING Frames" ?
Yes a REF is good: If that is all that is intended, we should say so.
Agreed, I think the right phrasing is PADDING Frames, though I don't think we need to reference 19.1 in every spot we talk about PADDING frames.
So could we grep for Padding and ensure we say /PADDING Frame/? - I guess the REF first time used would be good - if not already there?
How about something like: PR ?
Closing now that we have .

The commas for parentheticals got a little awkward there. Otherwise, this is a good change.I've done a bit of editorializing, and this LGTM. NAME should take a look.
Change:
6. <del> The connection id replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime of a DTLS connection.  Every identifier introduces the risk of linkability, as explained in RFC6973. </del> <ins> The CID replaces the previously used 5-tuple and, as such, introduces an identifier that remains persistent during the lifetime of a DTLS connection.  Every identifier introduces the risk of linkability, as explained in RFC6973. </ins> <del> In addition, endpoints can use the connection ID to attach arbitrary metadata to each record they receive.  This may be used as a mechanism to communicate per-connection information to on-path observers.  There is no straightforward way to address this with connection IDs that contain arbitrary values; implementations concerned about this SHOULD refuse to use connection ids. </del> <ins> In addition, endpoints can use the CID to attach arbitrary metadata to each record they receive.  This may be used as a mechanism to communicate per-connection information to on-path observers.  There is no straightforward way to address this with CIDs that contain arbitrary values; implementations concerned about this SHOULD refuse to use connection ids. </ins> An on-path adversary, who is able to observe the DTLS protocol exchanges between the DTLS client and the DTLS server, is able to link the observed payloads to all subsequent payloads carrying the same connection id pair (for bi-directional communication).  Without <del> multi-homing or mobility, the use of the connection id is not different to the use of the 5-tuple. </del> <ins> multi-homing or mobility, the use of the CID is not different to the use of the 5-tuple. </ins> With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further

Discussion:
It probably makes sense to be a little more consistent.
Makes sense. I will do this after the current wave of pull requests have been reviewed and accepted/rejected.
I addressed this issue in PR
Addressed with submitted draft version -04
I don't think that you need to change the grammar.
Change:
These client-generated CIDs might not conform to the expectations of the routing algorithm and therefore not be routable by the load <del> balancer.  These are called "non-compliant DCIDs": </del> <ins> balancer.  Those that are not routable are "non-compliant DCIDs" and receive similar treatment regardless of why they're non-compliant: </ins> The config rotation bits (config-rotation) may not correspond to an active configuration.  Note: a packet with a DCID that

Discussion:
Here are some suggestions from my first pass, but overall I think the static vs dynamic server ID allocation idea works nicely. 2 Q's: Is the definition of non-compliant different at LB and server in some cases? Might non-routable be a better term than non-compliant?
Yes, they can be different because the perception of the configuration is different. In general, during configuration updates the LB will have a configs that some servers don't. Therefore, a DCID with those CR bits will be compliant at the LB and non-compliant at the server. With static allocation, servers don't do anything with non-compliant DCIDs, so this is irrelevant. With dynamic allocation, it means that the LB will allocate an SID that the server doesn't know anything about, until: 1) the allocation times out 2) the LB has the occasion to forward another packet with that SID to the server when the server has the configuration. I don't feel strongly about this, but it works for me. If you want to file a PR with this change I'd approve it.
In PR I suggested non-routable, though I realize non-conformant may also be an option. The sentence which caused me to suggest non-routable is: URL I'm happy to write a PR if others find non-compliant potentially confusing as well.
I like it. Let's go with it.
Change:
may be using a version of WebTransport extension that is different from the one used by the server. <del> If SETTINGS_ENABLE_WEBTRANSPORT is negotiated, support for the QUIC DATAGRAMs within HTTP/3 MUST be negotiated as described in HTTP3-DATAGRAM; negotiating WebTransport support without negotiating HTTP/3 DATAGRAM support SHALL result in a H3_SETTINGS_ERROR error. </del> 3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by

Discussion:
This PR keeps WebTransport in sync with the latest changes in draft-ietf-masque-h3-datagram.
Change:
8. <del> Security considerations are inherent to any access network.  SATCOM systems introduce standard security mechanisms.  On the specific scenario of NC in SATCOM systems, there are no specific security considerations. </del> <ins> Security considerations are inherent to any access network, and in particular SATCOM systems.  The use of FEC or Network Coding in SATCOM also comes with risks (e.g., a single corrupted redundant packet may propagate to several flows when they are protected togething in an Inter-Flow coding approach, see section sec:use_cases).  However this is not specific to the SATCOM use-case and this document does not further elaborate on it. </ins>

Discussion:
The way it's said may call for comments during SecDir review. I'd rather say: Security considerations are inherent to any access network, and in particular SATCOM systems. The use of FEC or Network Coding in SATCOM also comes with risks (e.g., a single corrupted redundant packet may propagate to several flows when they are protected togething in an Inter-Flow coding approach, see section 3). However this is not specific to the SATCOM use-case and this document does not further elaborate on it.
Thanks for this suggestion. Closed by PR
Change:
deployment with hop-by-hop security and proxies, the server can only verify aliveness of the closest proxy. <ins> 2.5. This section updates the amplification mitigation requirements for servers in RFC7252 to recommend use of the Echo option to mitigate amplification attacks.  The requirements for clients are not updated. Section 11.3 of RFC7252 is updated by adding the following text: A CoAP server SHOULD mitigate potential amplification attacks by responding to unauthenticated clients with 4.01 Unauthorized including an Echo option, as described in echo-app item 3 of [[this document]]. </ins> 3. 3.1.

Discussion:
I think it make sense to make a subsection
This is only mentioned in Abstract and intro. I think it need there needs to be some text in the body as well. The other Update has it's own subsection. "4.2. Updated Token Processing Requirements for Clients"
I added text on server requirements in
updated with one more commit: Shorten amplification-mitigateion-recommendation paragraph, align text The "RECOMMENDED" wording is removed from the description of the mechanism (it was under-explained there, the new section does it right, and there's no need to make readers wonder about updating at this point) Reference updated simplified (we're already talking about server side in the paragraph) Comment about moving text here removed, and replaced with a more precise reference I've toyed with moved text, but it rips the use cases up to the point where we'd have to re-do all the items as subsections for consistency. ... and merging (comments still appreciated, but I need the branches consolidated for futher editing)
(... and that comment should have gone to ... anyway)
Some reformulations in febc426. I think this is ready to close.
Has long been ready, and recently gotten a more explicit cross-reference too.