jiebi/CodeConvo huggingface dataset:
Change:
over arbitrary lower layer protocols.  The security considerations in this document (RFC XXXX) also apply. <ins> N/A RFC XXXX MLS-based messaging applications N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A IETF MLS Working Group mls@ietf.org [3] COMMON N/A IETF MLS Working Group IESG No </ins> 18.  References 18.1.  URIs

Discussion:
Early review from IANA indicated that we had not completed the . This PR adds the missing fields.
Change:
In most cases, this field will be equal to the value of the Version field in the long header that carries this data. <del> The contents of the "Other Versions" field depends on whether it is </del> <ins> The contents of the Other Versions field depends on whether it is </ins> sent by the client or by the server. <del> When sent by a client, the "Other Versions" field lists all the </del> <ins> When sent by a client, the Other Versions field lists all the </ins> versions that this first flight is compatible with, ordered by <del> descending preference.  Note that the version in the "Chosen Version" field MUST be included in this list to allow the client to communicate the chosen version's preference.  Note that this </del> <ins> descending preference.  Note that the version in the Chosen Version field MUST be included in this list to allow the client to communicate the chosen version's preference.  Note that this </ins> preference is only advisory, servers MAY choose to use their own preference instead. <del> When sent by a server, the "Other Versions" field lists all the </del> <ins> When sent by a server, the Other Versions field lists all the </ins> Fully-Deployed Versions of this server deployment, see server- <del> fleet.  Note that the version in the "Chosen Version" field is not </del> <ins> fleet.  Note that the version in the Chosen Version field is not </ins> necessarily included in this list, because the server operator could be in the process of removing support for this version.  For the same reason, this field MAY be empty. Clients and servers MAY both include versions following the pattern <del> "0x?a?a?a?a" in their "Other Versions" list.  Those versions are reserved to exercise version negotiation (see the Versions section of QUIC), and will never be selected when choosing a version to use. </del> <ins> 0x?a?a?a?a in their Other Versions list.  Those versions are reserved to exercise version negotiation (see the Versions section of QUIC), and will never be selected when choosing a version to use. </ins> 6.

Discussion:
In , NAME points out that the backticks don't render nicely in the TXT version, so let's remove them
Change:
Security decisions, especially pertaining to trust, are not static. Once configured, parameters may also be supplied during connection establishment.  These are best handled as client-provided callbacks. <del> Security handshake callbacks that may be invoked during connection establishment include: </del> <ins> Callbacks block the progress of the connection establishment, which distinguishes them from other Events in the transport system.  How callbacks and events are implemented is specific to each implementation.  Security handshake callbacks that may be invoked during connection establishment include: </ins> Trust verification callback: Invoked when a Remote Endpoint's trust must be validated before the handshake protocol can

Discussion:
Closes issue
We have a “ Terminology and Notation” section, but we don’t define these terms: Clone: Calling Clone on a Connection yields a group of Connections: the parent Connection on which Clone was called, and a resulting cloned Connection. Entangled connection: if we do we need this term, we should define and explain what is different. Callback: can we have a one line definition that explains the different with respect to an event that an application can also asynchronously receive.
I can take care of the first two; regarding callbacks, I think there should also be at least one sentence somewhere explaining the need (why are Events not good enough for security?). I remember that this was clearly said, and I remember understanding it :) but by now, I have forgotten, and I can't find the rationale written anywhere.
As I looked at this now, I felt that such definitions would seem a bit out of place in the "Terminology and Notation" section; rather, if we need to define it globally, the concepts of Cloning and Entanglement should be defined where we also define what our Connections are, what Transport Properties are, etc. - and this is in -arch. Thoughts?
This isn't need for entangled with the way used in PR
I'm adding the arch label so people notice :-)
The one action remaining is defining "callback" within the scope of section 4.3.
Looks like this will be addressed.
Change:
Magic number(s) N/A <del> File extension(s): yaml, yml </del> <ins> File extension(s): "yaml" (preferred), "yml".  See int-yaml- filename-extension. </ins> Macintosh file type code(s): N/A

Discussion:
looks good to me (with one minor editorial note i left as a comment).
Would it be valuable to express a preference for over for file extensions? I'm assuming 3 character extensions are legacy from DOS file systems that had a 3 character limit. I reviewed the YAML 1.2 spec and there is no mention of using as a file extensions, so this might be a good opportunity to steer the community away from having two extensions.
Pls let's annihilate the DOS zombie!
NAME let's summon NAME and the YAML folks on that. IMHO: agree on expressing a preference disagree on removing references to .yml, since it's used in the wild. My2¢, R.
Discussed with YAML folks. Ok for indicating a preference without normative implications.
Change:
Round-trip time of QUIC flows can be inferred by observation once per flow, during the handshake, as in passive TCP measurement; this requires parsing of the QUIC packet header and recognition of the <del> handshake, as illustrated in handshake. </del> <ins> handshake, as illustrated in handshake.  It can also be inferred during the flow's lifetime, if the endpoints use the spin bit facility described below and in QUIC-SPIN. </ins> In the common case, the delay between the Initial packet containing the TLS Client Hello and the Handshake packet containing the TLS

Discussion:
Review the text of the -manageability draft to ensure that changes to headers in the latest version of -transport are correctly tracked.
on review CIDs are mostly okay but there are other header changes to track.
Change:
The following examples are valid values for the "ct" and "bct" fields (explanation/comments in parentheses): <del> "60" (CoAP Content-Format for "application/cbor") </del> <ins> "60" (CoAP Content-Format number for "application/cbor") </ins> <del> "0" (CoAP Content-Format for "text/plain" with parameter </del> <ins> "0" (CoAP Content-Format number for "text/plain" with parameter </ins> "charset=utf-8") "application/json" (JSON Content-Type - equivalent to "50" CoAP <del> Content-Format identifier) </del> <ins> Content-Format number) </ins> "application/json@deflate" (JSON Content-Type with "deflate" as <del> Content-Coding - equivalent to "11050" CoAP Content-Format identifier) </del> <ins> content coding - equivalent to "11050" CoAP Content-Format number) "application/json@deflate@aes128gcm" (JSON Content-Type with "deflate" followed by "aes128gcm" as content codings) </ins> "text/csv" (Comma-Separated Values (CSV) RFC4180 Content-Type) "text/csv;header=present@gzip" (CSV with header row, using "gzip" <del> as Content-Coding) </del> <ins> as content coding) </ins> 6.

Discussion:
Address Ben Kaduk's DISCUSS by allowing multiple content codings. Use the opportunity to also address Christer Holmberg's comment that Ben offered some sympathy to -- but staying with the (now lower case) term "content format".
On 2020-08-19, at 04:29, Jim Schaad wrote: (Archived-At: ) Right, this would be what you easily get if you do a “naïve” resolution of “bct" base fields. (However, Section 4 says that you only copy them to records with “vd” fields.) I think that it would be good to do the same thing with “naïve” resolution, i.e., ignore “ct” if there is no “vd”. But I don’t have a strong opinion. Section 3 says: When a SenML Record contains a Data Value field ("vd"), the Record MAY also include a Content-Format indication field. In logic, it simply doesn’t say anything about records without “vd”. In English, it does seem to imply that the MAY does not apply to them. (But then it doesn’t say what is supposed to happen.)
I believe this is now covered by the text in Section 4. For the most part it looks good. However, I am not sure that I understand what the correct behavior for {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","vs":"7.1","ct":"0"} {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":7.1,"ct":"0"} Should the ct be ignored if the value is not "vd"? If it is present but does not make sense what should happen? Jim
Change:
13.2. <del> ICE agents SHOULD use the default Ta value, 50 ms, but MAY use another value based on the characteristics of the associated media. ICE agents MUST NOT use a Ta value smaller than 5 ms. If an ICE agent wants to use another Ta value than the default value, the agent MUST indicate the proposed value to its peer during the ICE exchange.  Both agents MUST use the higher value of the proposed values.  If an agent does not propose a value, the default value is used for that agent when comparing which value is higher. NOTE: sec-concheckbw shows examples of required bandwidth, using different Ta values. </del> <ins> In cases where ICE is used to establish some kind of session that is not real time, and has no fixed rate associated with it that is known to work on the network in which ICE is deployed, Ta and RTO revert to more conservative values.  Ta SHOULD be configurable, SHOULD have a default of 500 ms, and MUST NOT be configurable to be less than 500 ms. </ins> <del> 13.3. </del> <ins> If other Ta value than the default is used, the agent MUST indicate the value it prefers to use in the ICE exchange.  Both agents MUST use the higher out of the two proposed values. </ins> <del> During the ICE gathering phase, ICE agents SHOULD calculate the RTO value using the following formula: </del> <ins> In addition, the retransmission timer for the STUN transactions, RTO, SHOULD be configurable and during the gathering phase, SHOULD have a default of: </ins> <del> For connectivity checks, ICE agents SHOULD calculate the RTO value using the following formula: </del> <ins> where the number of pairs refers to the number of pairs of candidates with STUN or TURN servers. </ins> <del> ICE agents MAY calculate the RTO value using other mechanisms than those described above.  ICE agents MUST NOT use a RTO value smaller than 500 ms. </del> <ins> For connectivity checks, RTO SHOULD be configurable and SHOULD have a default of: </ins> 14.

Discussion:
Trying to avoid conflicts with txt files by creating a new pull request for the tie-breaker and role changes.
Change:
all streams other than the first will be marked as bundle-only. This policy aims to minimize candidate gathering and maximize multiplexing, at the cost of less compatibility with legacy <del> endpoints.  When acting as answerer, the implementation will reject any m= section that is not in a bundle group. </del> <ins> endpoints.  When acting as answerer, if there if no bundle group in the offer, the implementation will reject all but the first m= section. </ins> As it provides the best tradeoff between performance and compatibility with legacy endpoints, the default bundle policy MUST

Discussion:
If a non-bundle offer is received, and "max-bundle" is used, the first m= section should be accepted and all others rejected. This will ensure the same result whether or not the "max-bundle" endpoint is the offerer or answerer (ignoring some unlikely corner cases), and will prevent a lone media description from being rejected if the remote offer didn't contain a bundle group simply because it wasn't necessary. Also added equivalent rules for the "balanced" bundle policy.
This LGTM
This isn't exactly what I had in mind for 'balanced', but this might not be an issue in practice. If the answerer needs to handle multiple m= lines that are unbundled, it can set max-compat.
lgtm
Change:
countermeasures, QUIC server implementations should assume that attackers can cause them to generate arbitrary UDP payloads to arbitrary destinations.  QUIC servers SHOULD NOT be deployed in <del> networks that also have inadequately secured UDP endpoints. </del> <ins> networks that do not deploy ingress filtering BCP38 and also have inadequately secured UDP endpoints. </ins> Although it is not generally possible to ensure that clients are not co-located with vulnerable endpoints, this version of QUIC does not

Discussion:
This is already something we recommend separately, but this is a SHOULD and the extra is useful.
Roman Danyliw said:
It might not be entirely realistic, in that the person deploying a server might not be aware of unsecure endpoints around them, but it's better to have the caution present than say nothing.
I think that it is moderately realistic for most deployments. There aren't so many UDP-based protocols out there in common usage. Besides, conducting an audit, if you did not already know, would be healthy. From another angle, a reason to include this is that if you have a firewall, deploy a QUIC server behind that firewall, and don't know what else is behind that firewall, then us writing this text makes it clear where fault lies if something bad happens.
This is not an editorial issue. I think that it is an excellent question, and definitely the sort of question I would expect the IESG to press on. FWIW, I think that this response would be totally unreasonable if this were TCP instead of UDP, which implies that there is a degree of subjectivity involved in the decision. The working group position suggests no action, but I want to confirm that NAME is satisfied with that response. As this was only a comment, not DISCUSS, I'm going to assume that this is OK unless I'm told otherwise.
Would it help to more tightly scope the definition of "networks"? One absurd reading is that QUIC should not be deployed on Internet facing networks because there is not a 0% chance of some unsecured UDP listening host somewhere.
I think we might be able to say "networks without ingress filtering [BCP38]". Servers are only vulnerable to these attacks if they (or their network) permit source address spoofing.
WfMq
I think the addition of BCP 38 makes it much more pointed and realistic. Overall, this is an important cautionary note. We decided that instead of trying to fix this in the protocol, it made sense to force those deploying QUIC to consider the implications of the environment in which they are doing it.
NAME could you comment on the proposed resolution?
Thanks for the refined text. The reference to ingress filtering makes it clearer. Consider this COMMENT resolved.
Change:
are tracked and can be audited.  Within the usual Working Group process it is expected that Internet-Drafts will receive regular review.  Finally, process checkpoints like Working Group Last Call <del> (WGLC; Section 7.4 of RFC2418) provides additional safeguards against </del> <ins> (WGLC; Section 7.4 of RFC2418) provide additional safeguards against </ins> abuse. Working Groups are advised against allowing editors this degree of

Discussion:
Please pay special attention to b872e53 and e74ba45 when reviewing this.
LGTM with some proposed simplifying text.
Change:
Each RRset in the chain is composed of a sequence of wire format DNS resource records.  The format of the resource record is described in <del> RFC1035, Section 3.2.1.  The resource records SHOULD be presented in the canonical form and ordering as described in RFC4034. </del> <ins> RFC1035, Section 3.2.1. </ins> <del> RRs within the RRset MAY be ordered canonically, by treating the RDATA portion of each RR as a left-justified unsigned octet sequence in which the absence of an octet sorts before a zero octet. Each RRset in the sequence is followed by its associated RRsig record.  The RRsig record is in DNS wire format as described in RFC4034, Section 3.1.  The signature portion of the RDATA, as described in the same section, is the following: </del> <ins> Each RRset in the sequence is followed by its associated RRsig record set.  The RRsig record wire format is described in RFC4034, Section 3.1.  The signature portion of the RDATA, as described in the same section, is the following: </ins> where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signer's Name field in canonical form and the signature field

Discussion:
Draft 05. Tried to address all the outstanding comments during the WGLC. Draft cutoff for IETF100 is Monday evening - hopefully we can submit a new version.
Change:
Content-encryption key (CEK), a term defined in RFC 2630 RFC2630. <del> Hybrid Public Key Encryption (HPKE), defined in I-D.irtf-cfrg- hpke. </del> <ins> Hybrid Public Key Encryption (HPKE), defined in RFC9180. The main use case of this document is to encrypt firmware.  However, SUIT manifests may require other payloads than firmware images to experience confidentiality protection using encryption.  While the term firmware is used throughout the document, plaintext other than firmware images may get encrypted using the described mechanism. Hence, the terms firmware (image) and plaintext are used interchangably. </ins> 3.

Discussion:
Based on discussions with Russ, I have updated the text in Section 7 about CEK Verification. Text about the parameters used for encryption were missing.
Change:
JSONPath expressions are applied to a JSON value, the <del> .  Within the JSONPath expression, the abstract name "$" is used to refer to the </del> <ins> . A JSONPath expression consists of an identifier followed by a series of zero or more segments each of which contains one or more selectors. 1.3.1. The "$" refers to the of the argument, i.e., to the argument as a whole.  Every JSONPath expression begins with the root node identifier. The "@" refers to the </ins> <del> of the argument, i.e., to the argument as a whole. </del> <ins> in the context of the evaluation of a filter expression (described later). </ins> <del> JSONPath expressions use the </del> <ins> 1.3.2. Segments can use the </ins> , for example:

Discussion:
This is a stab at addressing one NAME review comments in PR .
NAME If you don't think this PR is going in the right direction, please close it and we'll circle back to the matter later.
The term "current node" is traditionally used with iterating over children of structured nodes in filter selectors. Now it also appears in 3.3 Semantics chapter in a different context: To avoid confusion of readers, we might use a different term there. A good alternative would be "context node", which is also used by XPath in a similar context.
Perhaps a simple solution would be to avoid the use of the term in 3.3 as this term doesn't appear to be used elsewhere.
Please see the simplification in URL
Change:
consensus MUST NOT be reopened unless new information is presented. For long-running work items, new contributors often raise issues that <del> have already been resolved.  Chairs need to assess whether the arguments offered represent new information or not.  This can require some discussion to determine accurately.  Resolved issues MUST remain closed unless there is consensus to reopen an issue. </del> <ins> have already been resolved.  Moreover, there could be temptation to reopen contentious issues resolved with rough consensus.  Determining whether arguments presented in favor of reopening an issue represents new information might require some discussion in the Working Group. Chairs are empowered to exercise discretion in determining whether to reopen issues.  For more difficult matters, the chairs MAY insist that the Working Group reach consensus on whether an issue should be reopened.  Note however that any product of this process still needs to have the support of rough consensus in the Working Group, which could justify reopening issues. </ins> 4.2. <del> Pull requests are the GitHub feature that allow users to request changes to a repository.  A user does not need to have write access to a repository to create a pull request.  A user can create a "fork", or copy, of any public repository.  The user has write access to their own fork, allowing them to make local changes.  A pull request asks the owner of a repository to merge a specific set of changes from a fork (or any branch) into their copy. </del> <ins> A pull request is a GitHub feature that allows a user to request a change to a repository.  A user does not need to have write access to a repository to create a pull request.  A user can create a "fork", or copy, of any public repository.  The user has write access to their own fork, allowing them to make local changes.  A pull request asks the owner of a repository to merge a specific set of changes from a fork (or any branch) into their copy. </ins> Editors SHOULD make pull requests for all substantial changes rather than committing directly to the "master" branch of the repository.

Discussion:
Please pay special attention to b872e53 and e74ba45 when reviewing this.
LGTM with some proposed simplifying text.
Change:
MAX_STREAMS frames (frame-max-streams).  Separate limits apply to unidirectional and bidirectional streams. <ins> If a max_streams transport parameter or MAX_STREAMS frame is received with a value greater than 2^60, this would allow a maximum stream ID that cannot be expressed as a variable-length integer (see integer- encoding).  If either is received, the connection MUST be closed immediately with a connection error of type STREAM_LIMIT_ERROR (see immediate-close). </ins> Endpoints MUST NOT exceed the limit set by their peer.  An endpoint that receives a STREAM frame with a stream ID exceeding the limit it has sent MUST treat this as a stream error of type STREAM_LIMIT_ERROR

Discussion:
This LGTM, but it will need chair approval eventually.
This is also applies to the transport parameters, doesn’t it?
Good point, I think it does.
I now mention the transport parameters and incorporated a version of Martin's suggested text. PTAL.
2^60 is too large as well, as 2^62 cannot be expressed as a variable-length integer, either.
I believe 2^60 means stream IDs of that type with Stream IDs less than 2^62 can be opened, but those equal and greater cannot. ie: MAX_STREAMS of 1 means a single stream can be opened, and that stream will have an ID less than 1 * 2^2 = 4.
NAME I see. You're right -- thanks.
Currently, stream IDs are as high as 2^62-1. The MAXSTREAMS frame specifies a limit as a varint that has a max value of 2^62-1 that translates to a Stream ID of 4 * maxstreams + initialstreamidfortype. This is larger than the max expressible stream ID, so we should specify what happens in this case. I'm suggesting that we allow all streams to be opened and MUST NOT close the connection in PR
Good idea.
I don't have a strong opinion, but this seems like a bug at the peer. I would be inclined to specify that an endpoint MUST NOT advertise max streams that are too large, and close the connection (with PROTOCOL_VIOLATION) if a value is received that is too large.
I'd also lean towards closing the connection (probably with a TRANSPORTPARAMETERERROR, not a PROTOCOL_VIOLATION though). Interestingly, we have the following definition for packet numbers but no such thing for stream IDs, although this is implied by the way we encode them.
I'm happy to close the connection as well, as long as the behavior is well-defined.
On PR , NAME noted that this logic should apply to the equivalent transport param as well.
Wordsmithing, but content is fine.