jiebi/CodeConvo huggingface dataset:
Change:
or more ACK Blocks.  ACK Blocks are ranges of acknowledged packets. If the frame type is 0x03, ACK frames also contain the sum of QUIC packets with associated ECN marks received on the connection up until <del> this point. </del> <ins> this point.  QUIC implementations MUST properly handle both types and, if they have enabled ECN for packets they send, they SHOULD use the information in the ECN section to manage their congestion state. </ins> QUIC acknowledgements are irrevocable.  Once acknowledged, a packet remains acknowledged, even if it does not appear in a future ACK

Discussion:
Implementations are free to enable sending or not. 2, Implementations MAY read the ECN code points if they can and send ECN ACKs. Implementations MUST accept the 0x03 ACK type and if they are sending ECN SHOULD use the ECN section. I recognize that some people want to have stronger language here, based on this discussion I think this is where we are. I'll defer to the chairs to judge whether more is needed here and can change the PR as required.
I took the discussion to be "MAY" but obviously this is easily changed if the chairs judge consensus otherwise.
Change:
Message Properties can be set and queried using the Message Context: <del> To get or set Message Properties, the optional scope parameter is left empty.  To get or set meta-data for a Framer, the application has to pass a reference to this Framer as the scope parameter. </del> <ins> These Message Properties may be generic properties or Protocol Specific Properties. </ins> For MessageContexts returned by send Events (see send-events) and receive Events (see receive-events), the application can query

Discussion:
The other option is to tell people to prepend the name of the framer to the property name.
Is the "scope" used for message contexts (9.1.1) ever anything but a framer? If not, could this section just say framer?
We believe that it is the same; if so, "scope" should probably indeed be named "framer". Tommy, could you please check?
I find this a little strange: given that we do have optional parameters, what's the benefit of first introducing the "add" and "get" calls as if the "framer" parameter didn't exist, and then later changing that? It would seem more consistent to me to introduce it where you had the scope parameter before, called "framer", and use a forward reference to say that framers will be explained later.
Change:
derivation and signing.  The client's identity key is intended to be stable throughout the lifetime of the group; there is no mechanism to change it.  Init keys are intended to be used a very limited number <del> of times, potentially once. (see init-key-reuse). </del> <ins> of times, potentially once. (see init-key-reuse).  UserInitKeys also contain an identifier chosen by the client, which the client MUST assure uniquely identifies a given UserInitKey object among the set of UserInitKeys created by this client. </ins> The init_keys array MUST have the same length as the cipher_suites array, and each entry in the init_keys array MUST be a public key for

Discussion:
This PR addresses two outstanding issues with Welcome messages: Welcome messages were not encrypted for the new member, so that the information in them (in particular, init secrets) were not appropriately protected. The protocol overview had not been updated to include the Welcome-based add flow.
This was resolved in , but recording it in this issue for posterity. A Welcome message carries the value for the group, and so it needs to be encrypted for the new joiner. The struct proposed in the revised draft wraps the information in the Welcome in an ECIES ciphertext, and adds enough information to enable the joiner to identify the private key it needs to decrypt the Welcome message.
Change:
of zero or more segments each of which contains one or more selectors. <del> 1.3.1. </del> <ins> 1.4.1. </ins> The

Discussion:
The text will be adjusted in a future PR.
This github bug is slowing me down a bit:
Huh! I'm not seeing that.
I'm only seeing it every second time I try to pull the repo state (issues, PRs) into emacs, which seems to use a graphql API. Annoying. This used to work well...
Thanks!
Change:
As above, mitigation of this threat is beyond the scope of this proposal. <del> 7. </del> <ins> 8. </ins> This document requires no actions from IANA. <del> 8. </del> <ins> 9. </ins> The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP

Discussion:
Added new section on latency, as requested by NAME PTAL - will plan to merge at EOD if there are no outstanding comments.
Include experimental results, if we have them
LGTM
Change:
current maximum datagram size, referred to as PMTU probes.  All QUIC packets that are not sent in a PMTU probe SHOULD be sized to fit within the maximum datagram size to avoid the datagram being <del> fragmented or dropped BCP145. </del> <ins> fragmented or dropped RFC8085. </ins> If a QUIC endpoint determines that the PMTU between any pair of local and remote IP addresses cannot support the smallest allowed maximum

Discussion:
Individual commits break this down, but this is all fairly prosaic stuff..
Thanks for clarifying and for fixing the one awkward case.
Change:
CID is received that has the source address of the enclosing UDP datagram different from the one previously associated with that CID value, the receiver SHOULD perform a return routability check as <del> described in path-validation. </del> <ins> described in path-validation, unless an application layer specific address validation mechanism can be triggered instead. </ins> 6.

Discussion:
Signed-off-by: Thomas Fossati
cc NAME
Works for me.
When discussing that in RFC9146, my consideration was, that a "similar mechanism" maybe used also on the next layer. With that, I would consider
Just to mention, for me the idea of UDP is: Do, what could be done, but be also open, to delegate functions to the next layer, if it could be done there maybe more efficient. Therefore RRC with DTLS is great as one option, but other options in upper layers should not be discredited.
Change:
distributed pre-shared keys (PSKs).  Implementations should be aware of security concerns around using these tokens across multiple addresses or paths when racing.  In the case of TLS, any given ticket <del> or PSK should only be used on one leaf node.  If implementations have multiple tickets available from a previous connection, each leaf node attempt must use a different ticket.  In effect, each leaf node will send the same early application data, yet encoded (encrypted) differently on the wire. </del> <ins> or PSK should only be used on one leaf node, since servers will likely reject duplicate tickets in order to prevent replays (see section-8.1 RFC8446).  If implementations have multiple tickets available from a previous connection, each leaf node attempt can use a different ticket.  In effect, each leaf node will send the same early application data, yet encoded (encrypted) differently on the wire. </ins> 6.

Discussion:
I would further recommend to move this section into 4 somewhere as this section is more about connection establishment than sending messages
LGTM
Change:
types of values, from numbers to text strings and arbitrary binary data values.  In order to facilitate processing of binary data values, this document specifies a pair of new SenML fields for <del> indicating the Content-Format of those binary data values, i.e., their Internet media type including parameters as well as any Content-Coding applied. </del> <ins> indicating the content format of those binary data values, i.e., their Internet media type including parameters as well as any content codings applied. </ins> 1.

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:
transport connection.  Endpoints can be Local Endpoints or Remote Endpoints, and respectively represent an identity that the application uses for the source or destination of a connection. <del> An Endpoint can be specified at various levels of abstraction, and an Endpoint at a higher level of abstraction (such as a hostname) can be resolved to more concrete identities (such as IP addresses). </del> <ins> An Endpoint can be specified at various levels of abstraction.  An Endpoint at a higher level of abstraction (such as a hostname) can be resolved to more concrete identities (such as IP addresses). An endpoint may also represent a multicast group, in which case it selects a multicast transport for communication. </ins> Remote Endpoint: The Remote Endpoint represents the application's identifier for a peer that can participate in a transport

Discussion:
This is the only place multicast considerations might fit in -arch. We don't discuss anycast at all, and I think it's largely orthogonal to transport (indeed, people seem to be running stateful/connection-oriented transports to anycast endpoints just fine in the Internet, even though it "doesn't work" :) )
Consider an explicit discussion of multicast/anycast considerations in this document.
Change:
TCP connections between two hosts map directly to Connection objects. <del> Calling "Initiate" on a TCP Connection causes it to reserve a local port, and send a SYN to the Remote Endpoint. </del> <ins> CONNECT.TCP.  Calling "Initiate" on a TCP Connection causes it to reserve a local port, and send a SYN to the Remote Endpoint. </ins> <del> Early idempotent data is sent on a TCP Connection in the SYN, as TCP Fast Open data. </del> <ins> CONNECT.TCP with parameter "user message".  Early idempotent data is sent on a TCP Connection in the SYN, as TCP Fast Open data. </ins> A TCP Connection is ready once the three-way handshake is complete. <del> TCP can throw various errors during connection setup. Specifically, it is important to handle a RST being sent by the peer during the handshake. </del> <ins> Failure of CONNECT.TCP.  TCP can throw various errors during connection setup.  Specifically, it is important to handle a RST being sent by the peer during the handshake. </ins> Once established, TCP throws errors whenever the connection is <del> disconnected, such as due to receive a RST from the peer; or </del> <ins> disconnected, such as due to receiving a RST from the peer; or </ins> hitting a TCP retransmission timeout. <del> Calling "Listen" for TCP binds a local port and prepares it to receive inbound SYN packets from peers. </del> <ins> LISTEN.TCP.  Calling "Listen" for TCP binds a local port and prepares it to receive inbound SYN packets from peers. </ins> TCP Listeners will deliver new connections once they have replied to an inbound SYN with a SYN-ACK.

Discussion:
(SCTP mapping) This uses a new approach for such text for TCP, UDP and SCTP. Also: updates appendix D of interface.
We've updated Implementation mapping details for most protocols with , but we didn't tackle SCTP yet.
I'm fine with this being assigned to me. However, it's more than just writing the SCTP text. Here's the relevant part of what I wrote in PR : I don't suggest to delete much of the text that's there but definitely amend it with the RFC reference at least for what's covered in RFC 8303. There's a very direct line from this type of text in RFC 8303 to the original specs, so I do believe that should be helpful. That's (obviously) post-Montreal though!
NAME please send a PR along these lines.
Change:
continuation of the previous line.  In addition, some blank lines have been added to improve readability but are not valid in SDP. <del> More examples of SDP for WebRTC call flows can be found in I- D.nandakumar-rtcweb-sdp. </del> <ins> More examples of SDP for WebRTC call flows, including examples with IPv6 addresses, can be found in I-D.nandakumar-rtcweb-sdp. </ins> 7.1.

Discussion:
Section 7 does not acknowledge IPv6. The IAB statement on IPv6 has a recommendation that all protocol specifications have IPv6 examples in them. Since we have a separate example document, and Suhas has indicated that he will be including some IPv6 examples in it, I think you can get away in this document by amending the final paragraph of section 7 as: "More examples of SDP for WebRTC call flows, including examples of IPv6 addresses, can be found in [I-D.ietf-rtcweb-sdp]." I make no promise that other IESG members will find this sufficient, but I'm personally okay with it.
Change:
RR RRset Recursive mode <ins> Recursive query </ins> Recursive resolver Referrals Registrant

Discussion:
…erative resolution
Agree with your fix to the definition.
During the lead-up to RFC 7719, Tony Finch asked for four terms to be defined: Recursive query Non-recursive query Iterative query Iterative resolution The were not in RFC 7719 but could be in the -bis.
Updated the document in URL
I don't think iterative query is a synonym. I think an iterative query is a non-recursive query that happens to be a query in a series of recursive queries but that is itself not a recursive query. No? That seems more consistent with the iterative resolution definition that follows.
Change:
7.3.1.4. <del> Next, the agent constructs a pair whose local candidate is equal to the transport address (as seen by the agent) on which the STUN request was received, and a remote candidate equal to the source transport address where the request came from (which may be the peer reflexive remote candidate that was just learned).  The local candidate will either be a host candidate (for cases where the request was not received through a relay) or a relayed candidate (for cases where it is received through a relay).  The local candidate can never be a server reflexive candidate.  Since both candidates are known to the agent, it can obtain their priorities and compute the candidate pair priority.  This pair is then looked up in the check list.  There can be one of several outcomes: </del> <ins> Next, the agent constructs a pair whose local candidate has the transport address (as seen by the agent) on which the STUN request was received, and a remote candidate equal to the source transport address where the request came from (which may be the peer reflexive remote candidate that was just learned).  The local candidate will either be a host candidate (for cases where the request was not received through a relay) or a relayed candidate (for cases where it is received through a relay).  The local candidate can never be a server reflexive candidate.  Since both candidates are known to the agent, it can obtain their priorities and compute the candidate pair priority.  This pair is then looked up in the check list.  There can be one of several outcomes: </ins> If the pair is already on the check list:

Discussion:
Fix spelling: Replace “fulfil” with “fulfill” Fix grammar: “agent sets the state…is set to Completed“ with “agent sets the state…to Completed” Make consistent with recent changes: Replace “candidate is equal to the transport address” with “candidate has the transport address” Replace “multimedia session” with “data session” Replace “media data stream” with “RTP/RTCP data stream” or just “data stream” Replace “media data” with “data”
Change:
The Idempotency-Key HTTP Header Field <del> draft-ietf-httpapi-idempotency-key-header-01 </del> <ins> draft-ietf-httpapi-idempotency-key-header-latest </ins> Abstract

Discussion:
This: Gets the editors' draft generated by the template using GitHub actions (was never set up) Fixes up some document metadata Updates the IANA considerations section to fit current practice
looks like this one didn't work as expected, NAME URL
Fixed.
Change:
This property represents the maximum Message size that an application can send. <del> 7.1.9.4. </del> <ins> 7.1.10.4. </ins> recvMsgMaxLen

Discussion:
… and move the group limit connection property to the right place (it was misplaced). Note that section 8.2.7 ("Priority in TAPS") already clarifies that a Connection Priority choice doesn't guarantee a certain outcome; this just adds another sentence in the paragraph describing the Connection property to make it clearer (less easy to miss).
Looks ready to merge to me.
Change:
requests and responses can be transferred in a block-wise fashion as defined in I-D.ietf-core-block. <del> Empty messages (Code 0.00) are ignored by the recipient (see also </del> <ins> Empty messages (Code 0.00) MUST be ignored by the recipient (see also </ins> sec-ping). 3.3.

Discussion:
Consistent language for empty messages. Edits to Signaling section - including replacing Default Value in tables with Base Value for clarity.
Change:
19.18. The PATH_RESPONSE frame (type=0x1b) is sent in response to a <del> PATH_CHALLENGE frame.  Its format is identical to the PATH_CHALLENGE frame (frame-path-challenge). </del> <ins> PATH_CHALLENGE frame.  Its format, shown in fig-path-response is identical to the PATH_CHALLENGE frame (frame-path-challenge). </ins> If the content of a PATH_RESPONSE frame does not match the content of a PATH_CHALLENGE frame previously sent by the endpoint, the endpoint

Discussion:
This is not an editorial decision, this is a request for feedback on whether this form of presentation makes more sense. So far we have mixed feedback.
Did you consider TLS presentation language? It would be nice to not have n+1 formats.
NAME TLS presentation language implies length prefixes in a lot of places. Plus we already ripped out TLS presentation language for definition of the transport parameters. Bringing it back for definition of packet layouts would be... a bit weird.
As long as it was considered and found to be unsuitable, that's fine with me.
I definitely like this general structure better. As far as the question of whether we should import the TLS language, you would need some extensions, but I suspect that you could get pretty far with the following three: uintX == unsigned integer of size X uintv == varint opaque x[URL] == opaque vector without a header (TLS uses <> to mean that it has a header) and opaque x[y..] means "to end of the container and minimum size y] I believe we've already done uintv for MLS and NAME has been thinking about a generalized an a "TLS spec language"
Orthogonal to this PR, but perhaps we should align the "Maximum Data" and "Data Limit" terms which reference the same limit in different frames? Originally posted by NAME in URL
SGTM. Maximum Data(or Max Data) seems like the preferable option to me.
NAME The link to NAME post seems to be broken.
Odd, that was automatically generated by GitHub. That comment was on a review of .
But...! But...! Muh ASCII art! More seriously, this is probably a net improvement for readability. There's value in conforming to existing paradigms where possible, but we'd already had to define custom extensions to the notation from RFC2360 and from RFC7540, so this is probably no worse. What are your thoughts on applying this to QPACK as well? I'm really not a fan of the trailing comma in the lists, but that's neither here nor there.I really like this format.
Change:
2.1. <del> Origins send a token challenge to Clients in an "WWW-Authenticate" </del> <ins> Origins send a token challenge to clients in an "WWW-Authenticate" </ins> header with the "PrivateToken" scheme.  This challenge includes a TokenChallenge message, along with information about what keys to use when requesting a token from the issuer.

Discussion:
NAME please have a look!
From Ted Hardie in Vienna.
We should also clarify more explicitly how the client uses the origin name field for validating the context it is in.
Leaning towards allowing the being able to be a list of hostnames, with comma separation.
+1 to csv. We think this keeps the client impl's simple while allowing for the added flexibility of origin sets.
Might also have to say something about ignoring whitespace vs and then maybe just whitespace is the separator?
While I can understand the appeal, I'm not yet convinced we should do this until we have a use case and have thought through the possible privacy impacts.
perfect!
Change:
Compatible Encoding prefix "xn--" as defined in RFC5890 are properly encoded.  Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization objects.  If an authorization object <del> conveys authorization for the base domain of a newOrder DNS type identifier with a wildcard prefix, then the optional authorizations "wildcard" field MUST be present with a value of true. </del> <ins> conveys authorization for the base domain of a newOrder DNS identifier containing a wildcard domain name, then the optional authorizations "wildcard" field MUST be present with a value of true. </ins> identifier-validation-challenges describes a set of challenges for domain name validation.

Discussion:
badState should be orderNotReady Use "wildcard domain name" consistently instead of "wildcard prefix"
Thanks NAME :ballotboxwith_check:
Change:
request is signed with the private key corresponding to the "key" field of the request before updating the registration. <ins> For example, to update the contact information in the above registration, the client could send the following request: </ins> Servers SHOULD NOT respond to GET requests for registration resources as these requests are not authenticated.  If a client wishes to query the server for information about its account (e.g., to examine the

Discussion:
vs. The spec doesn't seem to be consistent. And why does it have to be completed with HTTP? I honestly don't understand that.
LE's seems to give a choice. I'd really prefer that. This would make it possible to not even listen on port 80 for things like APIs, e.g. GitHub does that on .
As discussed on the list and in the document, the HTTP challenge needs to be HTTP-only in order to avoid the default-vhost issues. Thanks for catching the stray HTTPS text. I will remove it.
Do you have a link to the discussion?
See URL Is that example just bogus or what's the for? There are only two challenges, so it can't be an index there.
Good point. Left over from when we had three challenges in the example.
Contact information may have been misspelled during registration. Contact information such as phone numbers may also change. https://acme-URL exposes only the endpoint and that endpoint doesn't accept updates, because it has to respond with 409 Conflict for already existing keys. There should be a way to update that information. See also URL
thanks NAME yes updating the contact email for registered LE account is a must have feature otherwise an LE notifications/renew notices may end up going to invalid email addresses.
Right now, the spec says that you can update anything in the registration with a : Note that the request goes to the registration URL, not the new-registration URL. I'll add an example to the document to clarify.