jiebi/CodeConvo huggingface dataset:
Code change:
and imported PSKs are distinct since their identities are different on the wire.  See rollout for more details. <del> Endpoints which import external keys MUST NOT use either the external keys or the derived keys for any other purpose.  Moreover, each external PSK MUST be associated with at most one hash function, as per the rules in Section 4.2.11 from RFC8446.  See security- considerations for more discussion. </del> <ins> Endpoints which import external keys MUST NOT use the keys that are input to the import process for any purpose other than the importer, and MUST NOT use the derived keys for any purpose other than TLS PSKs.  Moreover, each external PSK fed to the importer process MUST be associated with at most one hash function.  This is analogous to the rules in Section 4.2.11 of RFC8446.  See security-considerations for more discussion. </ins> 3.1. <ins> The following terms are used throughout this document: </ins> External PSK (EPSK): A PSK established or provisioned out-of-band, i.e., not from a TLS connection, which is a tuple of (Base Key, External Identity, Hash).

Related discussion:
text: I think it may be useful to call out that the "multiple clients" and "multiple servers" case can occur even when there are only two endpoints that know the key (that is, when they do not have predetermined client/server roles). struct { opaque clientmac; opaque server_mac; } Context; We may not need the whole 16k to hold a MAC address, especially since this is just an example. If an attacker then redirects a ClientHello intended for one node to a different node, the receiver will compute a different context string and the handshake will not complete. Similarly to the above, this could be "a different node (including the node that generated the ClientHello)".
Code change:
represents a security trade-off that may not be appropriate for general environments. <ins> If an item is not marked as recommended it does not necessarily mean that it is flawed; rather, it indicates that either the item has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. </ins> IANA [SHALL add/has added] the following notes for additional information:

Related discussion:
text: NAME PTAL
LGTM - ‘twas just a comment anyway. W I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
Code change:
send a PING or other small ack-eliciting frame occasionally, such as once per round trip, to elicit an ACK from the peer. <del> A receiver MUST NOT send an ack-eliciting frame in all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements. </del> <ins> In cases without ACK frame loss, this algorithm allows for a minimum of 1 RTT of reordering.  In cases with ACK frame loss and reordering, this approach does not guarantee that every acknowledgement is seen by the sender before it is no longer included in the ACK frame. Packets could be received out of order and all subsequent ACK frames containing them could be lost.  In this case, the loss recovery algorithm could cause spurious retransmissions, but the sender will continue making forward progress. </ins> <del> 13.2.6. </del> <ins> 13.2.5. </ins> An endpoint measures the delays intentionally introduced between the time the packet with the largest packet number is received and the

Related discussion:
text: It's no longer normative and it's in a single section. I only moved text so far, and not as far as NAME suggested. I can go farther here or in a follow-up PR.
NAME I would like to merge this. WDYT?
Can we merge this soon. I'm worried about it developing conflicts.
Yep, NAME lost the chance to fix the PR. We are - of course - still open for editorial improvements in the form of new pull requests though.
calls them "exemplary" but 13.2.4 has MUST in it.
For reference, this refers to and in the editor's copy. I'm in favour of striking the exemplary note and saying that while the recovery draft is advisory, this document depends on implementations following something like what is recommended.
The specific MUSTs aren't really about the ACK algorithm per se, but about state endpoints will have to maintain for other reasons that are typically folded into your loss recovery code. If an implementation is unable to do duplicate detection for a packet number range, it MUST fail toward rejecting all packets, not toward accepting potential duplicates. An implementation must track the greatest packet number ever received, for use in recovering future packet numbers. In fact, the first requirement is discussed in 12.3 and could probably be dropped here. The second isn't actually called out (MUST) in 17.1, but could easily be moved there.
I think I'm inclined towards reorganizing the text and putting all the 'exemplary' parts into one section(ie: "Limiting ACK Ranges") and moving the normative text either into "Managing ACK Ranges" or elsewhere in the draft.
I thought I could clean this up fairly quickly, but I think a fair number of paragraphs need to move, including some of NAME suggestions. I'm happy to try to improve this in a few days if no one else has beaten me to it.
Anyone want to help NAME out and take this on?
Sorry about dropping this one. I'm fine with it, and happy to make editorials one later.Thanks Ian. When you lay it out like this, it seems so obvious. I checked that we don't have citations for {{ack-tracking}}, so this works nicely. If you care about the "MAY", then we can fix that in another PR.
Code change:
discard a header once the content has been parsed). To deliver a Message to the application, the framer implementation <del> can either directly deliever data that it has allocated, or deliver a </del> <ins> can either directly deliver data that it has allocated, or deliver a </ins> range of data directly from the underlying transport and <del> simulatenously advance the receive cursor. </del> <ins> simultaneously advance the receive cursor. </ins> Note that "MessageFramer.DeliverAndAdvanceReceiveCursor" allows the framer implementation to earmark bytes as part of a Message even

Related discussion:
text: Just some points about the new text on framers in the API draft: In 10.2 it is specified in which order multiple framers run on incoming and outgoing messages, it is however never specified what the order looks like on Start and Stop events. In 10.6, "MessageFramer.DeliverAndAdvanceReceiveCursor" appears to be missing the "Data" argument that is present in "MessageFramer.Deliver". Also in 10.6, in the second paragraph it says: When it is probably meant to say While the framer implementation is able to notify the Connection that it has finished handling a Start event (by calling MessageFramer.MakeConnectionReady), there is no such way for Stop events.
As notes for the responses to these points: If there are multiple framers, the "lowest" one (the one closest to the transport) would receive start first, and the next would get the start event when the lower one is ready. Similar for stop. Good calls on the missing data argument and the typo re application vs framer. I was thinking to use the failConnection call to complete a stop, potentially with no error?
Code change:
the request (see cose-object). request_piv: contains the value of the 'Partial IV' in the COSE <del> object of the request (see cose-object), with one exception: in case of protection or verification of Observe cancellations, the request_piv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see observe- registration). </del> <ins> object of the request (see cose-object). </ins> options: contains the Class I options (see outer-options) present in the original CoAP message encoded as described in Section 3.1

Related discussion:
text: Solves issue (from review comments by NAME : URL)
In section 5.4 you have the text requestpiv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the requestpiv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request. A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field.
Another case to make sure that works Client - please cancel my observation Server - I don't have an observation for you, but sure I am willing to tell you I canceled it. What request PIV would I use in the AAD?
Yes, the verification of cancellation would fail since the server does not have the initial registration's partial iv saved, if it does not have the observation stored. So OSCORE would fail, which is not right. We have reverted to previous version (request_piv is not exception for cancellations) in c94314321 , but we want to add some security considerations about Observe and cancellations before closing this issue. Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached, but a success message is never going to be cached. Based on this, I don't plan to set an outer Max-Age option. In section 5.4 you have the text requestpiv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the requestpiv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request.
Code change:
the request (see cose-object). request_piv: contains the value of the 'Partial IV' in the COSE <del> object of the request (see cose-object), with one exception: in case of protection or verification of Observe cancellations, the request_piv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see observe- registration). </del> <ins> object of the request (see cose-object). </ins> options: contains the Class I options (see outer-options) present in the original CoAP message encoded as described in Section 3.1

Related discussion:
text: A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field. Section 6.1 - Is a registry needed for the leading byte of compression? Behavior if bits 0, 1, or 2 is set in the flags byte on decode? Section C - given the way that my system is implemented, it would be nice if the outputs included the first full IV to be used for both the sender and the recipient. That would allow for a test that the combination of ids and common ivs is done correctly. In my case I do not have the shared IV available for testing as I immediately or in the id.
Code change:
possible, and that when relative URIs are used, they include the full path (e.g., "/types/123"). <ins> The type URI can also be a non-resolvable URI.  For example, the tag URI scheme RFC4151 can be used to uniquely identify problem types: Non-resolvable URIs ought not be used when there is some future possibility that it might become desireable to do so.  For example, if the URI above were used in an API and later a tool was adopted that resolves type URIs to discover information about the error, taking advantage of that capability would require switching to a resolvable URI, thereby creating a new identity for the problem type and thus introducing a breaking change. </ins> 3.1.2. The "status" member is a JSON number indicating the HTTP status code

Related discussion:
text: NAME done; see change. P.S. GitHub lets you make suggestions using the little +/- icon in the inline comment UX :)
Pulling this conversation out of : It's clear that there's demand for error codes scoped to the API, without creating documentation pages for each code and linking to them in the field. There are many ways that implementers could do this, from linking to non-existent URLs to URNs to tags URIs, etc. It would be useful if the specification included examples of this, and made a clear recommendation for this case.
We (well, mostly NAME have made some good progress on the other issues raised out of but we haven't looked at this one yet. As strawman to get this moving, how about: we register a URN namespace id, and we recommend that non-dereferenceable URIs should be URNs using that, namespaced with an appropriate domain and raw type id, for example: . Would that work? It would give us a clear solution to recommend, which is explicit but easy to read, with minimal extra complexity or overhead for implementers (imo). I don't have examples, but I suspect there are other standards elsewhere that would appreciate having a problem id namespace for URNs as well. I don't love using a domain for namespacing a non-locator, but I think some namespacing is preferable, and I'm not sure what other namespaces would be suitable. Alternatives very welcome :smile:
We penciled in the URI prefix for registered types as "URL" in , but that was not finalised. I think registering one or more problems as exemplars is a good path forward for this and other issues (e.g., as discussed in ). We need to be very careful to set a good example in them, which means we need good candidates; I'm thinking 'JSON Validation Error' and 'XML Validation Error' might be appropriate (perhaps along with corresponding wellformedness errors). If we choose a urn, I suspect there will be considerable pressure to use or something similar, as per .
my understanding of the "urn:ietf:params" namespace is that it is meant to be used for parameters managed/defined by IETF specs. i think the original's suggestion intent was to have a "safe prefix" for a namespace which then would be "unmanaged" with some conventions around that, such as using domains names.
Code change:
possible, and that when relative URIs are used, they include the full path (e.g., "/types/123"). <ins> The type URI can also be a non-resolvable URI.  For example, the tag URI scheme RFC4151 can be used to uniquely identify problem types: Non-resolvable URIs ought not be used when there is some future possibility that it might become desireable to do so.  For example, if the URI above were used in an API and later a tool was adopted that resolves type URIs to discover information about the error, taking advantage of that capability would require switching to a resolvable URI, thereby creating a new identity for the problem type and thus introducing a breaking change. </ins> 3.1.2. The "status" member is a JSON number indicating the HTTP status code

Related discussion:
text: i think the idea of giving examples (and even a suggested namespace along with conventions for using it) is a good one. that way we can clearly support both scenarios: if you're planning on making documentation available, use a resolvable URI but keep in mind that this best should be managed in a way so that it works for a good number of years. if you're planning on just identifying problem types, use a non-resolvable URI, and here's a recipe for doing it.
:+1: exactly I think is relevant in that it would be helpful to everybody if we can follow our own recommendations in our own problem id registry, but it's otherwise independent.
the difficulty may be that IETF has an institutional approach for managing parameters (urn:ietf:params:http-problems mentioned by NAME above), whereas most orgs minting problem types probably won't have one and won't create one. which may lead to us to saying three things about what kind of URI to use: check out common problem types registered under urn:ietf:params:http-problems and consider reusing one if it fits. use URIs when creating dereferencable problem type identifiers. when using non-dereferencable problem type identifiers be clear about that by using non-dereferencable URIs, and here's an URN-based recipe how to do that.
Ah, I see, ok. Yes, that makes sense, and given that the 3 part recommendation seems reasonable to me.
to be used for parameters managed/defined by IETF specs. No, it's for parameter name spaces managed by IETF documents -- which this would be. We could also give an example that uses a URI.
that's what i wanted to say. so these URIs/examples would just cover the common problem types that would be managed by the spec. which then would be for those other types that people/orgs are minting and where they say these are not resolvable, right? i think for those terry proposed a URN namespace instead of tag URIs, but either way it simply would help to state the use case ("your own types, not intended to be resolvable") and provide a recipe ("here's one way to do it").
Code change:
possible, and that when relative URIs are used, they include the full path (e.g., "/types/123"). <ins> The type URI can also be a non-resolvable URI.  For example, the tag URI scheme RFC4151 can be used to uniquely identify problem types: Non-resolvable URIs ought not be used when there is some future possibility that it might become desireable to do so.  For example, if the URI above were used in an API and later a tool was adopted that resolves type URIs to discover information about the error, taking advantage of that capability would require switching to a resolvable URI, thereby creating a new identity for the problem type and thus introducing a breaking change. </ins> 3.1.2. The "status" member is a JSON number indicating the HTTP status code

Related discussion:
text: the main point seems to be: the spec should mention both "common types" which may even get a registry, and "private types" which probably are using a different namespace, and we could suggest one pattern for doing that.
Code change:
1. <del> QUIC is a new multiplexed and secure transport protocol atop UDP, specified in QUIC-TRANSPORT.  This document describes congestion control and loss recovery for QUIC.  Mechanisms described in this document follow the spirit of existing TCP congestion control and loss recovery mechanisms, described in RFCs, various Internet-drafts, or academic papers, and also those prevalent in TCP implementations. </del> <ins> QUIC is a secure general-purpose transport protocol, described in QUIC-TRANSPORT).  This document describes loss detection and congestion control mechanisms for QUIC. </ins> 2.

Related discussion:
text: In the Recovery genart review, Vijay Gurbani wrote:
Based on the proposed PR, I'm marking this as editorial.
In the Recovery genart review, Vijay Gurbani wrote:
Based on the proposed PR, I'm marking this as editorial.
Code change:
example, if reliable delivery was requested for a Message handed over before calling Close, the Closed Event will signify that this Message has indeed been delivered.  This action does not affect any other <del> Connection that is entangled with this one in a Connection Group. </del> <ins> Connection in the same Connection Group. </ins> The Closed Event informs the application that the Remote Endpoint has closed the Connection.  There is no guarantee that a remote Close will indeed be signaled. Abort terminates a Connection without delivering any remaining <del> Messages.  This action does not affect any other Connection that is entangled with this one in a Connection Group. </del> <ins> Messages.  This action does not affect any other Connection that in the same Connection Group. </ins> CloseGroup gracefully terminates a Connection and any other <del> Connections that are entangled with this one in a Connection Group. For example, all of the Connections in a group might be streams of a single session for a multistreaming protocol; closing the entire group will close the underlying session.  See also groups.  As with Close, any Messages remaining to be processed on a Connection will be handled prior to closing. AbortGroup terminates a Connection and any other Connections that are entangled with this one in a Connection Group without delivering any remaining Messages. </del> <ins> Connections in the same Connection Group.  For example, all of the Connections in a group might be streams of a single session for a multistreaming protocol; closing the entire group will close the underlying session.  See also groups.  As with Close, any Messages remaining to be processed on a Connection will be handled prior to closing. AbortGroup terminates a Connection and any other Connections in the same Connection Group without delivering any remaining Messages. </ins> A ConnectionError informs the application that: 1) data could not be delivered to the peer after a timeout, or 2) the Connection has been

Related discussion:
text: I can try to fix this.
Sounds good - we should add that explanation upfront in the definitions then also?
[Yes, I think so.] EDIT: no, now I don't think so anymore. (see )
I have addressed this in PR . Note that the text interchangeably talked about both Connections and Connection Properties as being "entangled". I have now written this such that the term "entanglement" applies to Connection Properties only, whereas Connections in a group are, well, members of the same Connection Group.
Looks good to me.
Code change:
ACK-FREQUENCY frames have a type of 0xXX, and contain the following fields: <del> An optional variable-length integer representing the maximum number of ack-eliciting packets after which the receiver sends an acknowledgement. </del> <ins> A variable-length integer representing the maximum number of ack- eliciting packets after which the receiver sends an acknowledgement.  A value of 1 will result in an acknowledgement being sent for every ack-eliciting packet received.  A value of 0 is invalid. A variable-length integer representing an update to the peer's "max_ack_delay" transport parameter (Section 18.2 in QUIC- TRANSPORT).  The value of this field is in microseconds.  Any value smaller than the min_ack_delay advertised by this endpoint is invalid. </ins> <del> An optional variable-length integer representing the maximum amount of time, in microseconds, after which the receiver sends an acknowledgement.  The value of the Time Tolerance field is scaled by multiplying the encoded value by 2 to the power of the value of the "ack_delay_exponent" transport parameter set by the sender of the ACK-FREQUENCY frame (see Section XX in QUIC-TRANSPORT). Scaling in this fashion allows for a larger range of values with a shorter encoding at the cost of lower resolution. </del> <ins> Receipt of invalid values in an ACK-FREQUENCY frame MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> ACK-FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission.

Related discussion:
text: This PR changes a few things: Introduces a TP for negotiating extension use Changes to Makes the fields required Specifies invalid values
I'm merging this, let's address issues in later PRs.
I think it'll be easier to make both parameters required. Not doing so saves 1 to 2 bytes, which is really not much in a frame I expect will be sent a few times a connection. Also, I think 0 should be an invalid value for both params, and 1 should be invalid for the number of packets, though I can see someone arguing that point.
addresses these issues, with the exception that 1 is allowed for packet tolerance. I think that's actually useful for some startup schemes, so we shouldn't disallow it.