jiebi/CodeConvo huggingface dataset:
Change:
DNS resolution privileges to URIs that are not recognized by the client as trusted DNS API servers. <ins> 6.4. In order to maximize interoperability, DNS API clients and DNS API servers MUST support the "application/dns-udpwireformat" media type. Other media types MAY be used as defined by HTTP Content Negotiation (RFC7231 Section 3.4). </ins> 7. 7.1.

Discussion:
By my unofficial informal tally, there was a strong agreement on application/dns-udpwireformat being mandatory, and both GET and POST mandatory for servers.
I made some very minor edits NAME merge if you're ok with them
The fact that an HTTP server can provide a response in the format of its choice was not well understood by DNS people. This motivates the MTI format for servers.
On 2018-03-25, NAME sent the following to the list: At the meeting in London last week, we asked the room for opinions on two topics: Should we have a content-type that is Mandatory to Implement? Several participants spoke in favor of making the default format (currently called "application/dns-udpwireformat") mandatory, at least for servers. Among the GET and POST modes of operation, which, if any, should be mandatory to implement? Among the participants, there was consensus in favor of making both GET and POST mandatory to implement for servers. If you would like to voice a dissenting opinion on either point, please reply on this list. Otherwise, the chairs will regard these decisions as the group's consensus.
See PR
I think most of this can be handled by the MTI PR. But I will just make a tiny clarification indicating that the server is really able to return whatever it needs to.
as discussed on list.. 1) Make one mandatory-to-implement 2) Make both mandatory-to-implement 3) Talk about why there is no mandatory-to-implemen
At the face-to-face meeting, I thought the sense of the room was servers MUST implement both GET and POST, clients can implement either or both. This needs to be confirmed on the list.
See PR
My personal take of consensus is that, having heard no opposition to the position of NAME summary above, to go with that.
Change:
If the offer supports bundle, all m= sections to be bundled must use the same ICE credentials and candidates; all m= sections not being bundled must use unique ICE credentials and candidates.  Each m= <del> section MUST include the following: </del> <ins> section MUST contain the following attributes (which are of attribute types other than IDENTICAL and TRANSPORT): </ins> If and only if present in the offer, an "a=mid" line, as specified in RFC5888, Section 9.1.  The "mid" value MUST match that

Discussion:
NAME NAME Is this approximately right?
Looks close enough to me - lets land this then tune with future PRs
LG with nits
Change:
endpoint's RTT samples, and rttvar is the endpoint's estimated variance in the RTT samples. <del> smoothed_rtt uses path latency after adjusting RTT samples for peer- reported host delays (host-delay).  A peer limits any delay in </del> <ins> The calculation of smoothed_rtt uses path latency after adjusting RTT samples for host delays (host-delay).  For packets sent in the ApplicationData packet number space, a peer limits any delay in </ins> sending an acknowledgement for an ack-eliciting packet to no greater <del> than the advertised max_ack_delay transport parameter.  Consequently, when a peer reports an Ack Delay that is greater than its max_ack_delay, the delay is attributed to reasons out of the peer's control, such as scheduler latency at the peer or loss of previous ACK frames.  Any delays beyond the peer's max_ack_delay are therefore considered effectively part of path delay and incorporated into the smoothed_rtt estimate. </del> <ins> than the value it advertised in the max_ack_delay transport parameter.  Consequently, when a peer reports an Ack Delay that is greater than its max_ack_delay, the delay is attributed to reasons out of the peer's control, such as scheduler latency at the peer or loss of previous ACK frames.  Any delays beyond the peer's max_ack_delay are therefore considered effectively part of path delay and incorporated into the smoothed_rtt estimate. </ins> When adjusting an RTT sample using peer-reported acknowledgement delays, an endpoint: <ins> MUST ignore the Ack Delay field of the ACK frame for packets sent in the Initial and Handshake packet number space. </ins> MUST use the lesser of the value reported in Ack Delay field of the ACK frame and the peer's max_ack_delay transport parameter (host-delay).

Discussion:
This should have been part of .
NAME I applied your suggestions. I think this PR should be marked as editorial.
The new "MUST" threw me, but it's not really new, is it?
That one was introduced in already.
Seems reasonable to me. Throughout here, should we be using "peer" or "receiver"? (The suggestions I make here are not issues with this change, but I'm sure that NAME or NAME will find them a home.)Thanks for fixing this.
Change:
13.3.1. <del> On receiving a QUIC packet with an ECT or CE codepoint, an endpoint that can access the ECN codepoints from the enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE count, and includes these counts in subsequent ACK frames (see processing-and-ack and frame-ack). </del> <ins> On receiving a QUIC packet with an ECT or CE codepoint, an ECN- enabled endpoint that can access the ECN codepoints from the enclosing IP packet increases the corresponding ECT(0), ECT(1), or CE count, and includes these counts in subsequent ACK frames (see processing-and-ack and frame-ack).  Note that this requires being able to read the ECN codepoints from the enclosing IP packet, which is not possible on all platforms. </ins> A packet detected by a receiver as a duplicate does not affect the receiver's local ECN codepoint counts; see (security-ecn) for

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:
14.3. <ins> In order to ensure that MLS provides meaningful authentication it is important that each member is able to authenticate some identity information for each other member.  Identity information is encoded in Credentials, so this property is assured by ensuring that members use compatible credential types. The types of credential that may be used in a group is restricted to what all members of the group support, as specified by the "capabilities" field of each LeafNode in the RatchetTree.  An application can introduce new credential types by choosing an unallocated identifier from the registry in mls-credential-types and indicating support for the credential type in published LeafNodes, whether in Update proposals to existing groups or KeyPackages that are added to new groups.  Once all members in a group indicate support for the credential type, members can start using LeafNodes with the new credential.  Application may enforce that certain credential types always remain supported by adding a "required_capabilities" extension to the group's GroupContext, which would prevent any member from being added to the group that doesn't support them. In future extensions to MLS, it may be useful to allow a member to present more than one credential.  For example, such credentials might present different attributes attested by different authorities. To be consistent with the general principle stated at the beginning of this section, such an extension would need to ensure that each member can authenticate some identity for each other member.  For each pair of members (Alice, Bob), Alice would need to present at least one credential of a type that Bob supports.  ## Extensions </ins> This protocol includes a mechanism for negotiating extension parameters similar to the one in TLS RFC8446.  In TLS, extension negotiation is one-to-one: The client offers extensions in its

Discussion:
This PR adds a way for the members of a group to indicate the credential types they support, and how to negotiate which credential types may be used in a group.
I discussed this offline with NAME and we arrived at: We might need multiple credentials later (as I suspect) If we do that (say in an extension), we will need to update this text We should capture the general theory that covers both single- and multiple-credential cases The proposed additions here just abstract the principle of universal compatibility (which we need in a single-credential world) to one of "at least something" compatibility (which is more compatible with a multi-credential world).> The types of credential that may be used in a group is restricted to what all I think this is too restrictive if we adopt PR . I think it is between the client and its AS if all the clients need to support every credential type used in the group. If you agree with the concept, I am happy to propose slight changes.I think this makes sense.
Change:
4.1.3.5.2. If the server accepts an Observe registration, a Partial IV MUST be <del> included in all notifications (both successful and error).  To protect against replay, the client SHALL maintain a Notification Number for each Observation it registers.  The Notification Number is a non-negative integer containing the largest Partial IV of the received notifications for the associated Observe registration. Further details of replay protection of notifications are specified in replay-notifications. </del> <ins> included in all notifications (both successful and error), except for the first one where Partial IV MAY be omitted.  To protect against replay, the client SHALL maintain a Notification Number for each Observation it registers.  The Notification Number is a non-negative integer containing the largest Partial IV of the received notifications for the associated Observe registration.  Further details of replay protection of notifications are specified in replay-notifications. </ins> For notifications, the Inner Observe value MUST be empty (see Section 3.2 of RFC7252).  The Outer Observe in a notification is

Discussion:
Solves issue (from review comments by NAME : URL)
According to Jim, the change of always including a Partial IV for notifications (both successful or errors) complicates the code too much, although it simplifies the spec, so he proposes to revert that change. 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. 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.
Change:
If the ClientHello is not encrypted, SNI can be derived from the client's Initial packet by calculating the Initial secret to decrypt <del> the packet payload and parsing the QUIC CRYPTO Frame containing the TLS ClientHello. </del> <ins> the packet payload and parsing the QUIC CRYPTO frame(s) containing the TLS ClientHello. </ins> As both the derivation of the Initial secret and the structure of the Initial packet itself are version-specific, the first step is always

Discussion:
I think there are still a few potentially misleading statements left in the text. I'll send out a PR.
The mentions . This makes the assumption that INITIAL packets carry a single CRYPTO frame. That assumption might not always hold in modern browsers, so the text should clarify that any middlebox that wishes to extract the SNI MUST perform reconstruction of the crypto stream from one or more CRYPTO frames in one or more INITIAL packets. The current assumption might lead middlebox vendors to write deploy software that doesn't work if there are multiple CRYPTO frames. The section correctly states but that comes late in the section and doesn't detail what middlebox vendors should do about it. That section also contains another incorrect assumption: . There are other frame types that are legal in INITIAL packets and may be sent by browsers.
I think this is pretty similar to , though that one is a bit more broad. Thanks for noticing the statement about Initials only containing CRYPTO and PADDING, I missed that.
The text already says the following now: Not sure when exactly this got added but I assume this is sufficient to address this issue? NAME NAME ?
I don't think the new text fully addresses this issue. In the new text, this statement is incorrect: What about PING frames for example? Additionally, the client's first flight won't contain extension frames because the client has no way of knowing whether the server supports them so this statement is somewhat misleading: What are middleboxes supposed to do if they see an unknown frame type, we should provide guidance there. I think we should just tell middlebox implementors to refer to that section of RFC 9000 and expect to parse all frame types, and fail parsing if they see a frame type they don't recognize. And while we're at it, we should also mention that CRYPTO frames might be out of order.
I would expect ping frame in the initial... so that sentence might still be fine. I think there could actually be extension frame in the first flight, e.g. if information was cached about the support of the extension. In any case, can you maybe propose text NAME ?
Extension caching doesn't work for initials because the server can still reject 0-RTT at this point. How about this text:
Change:
An ECHConfigs structure containing one or more ECHConfig structures, in decreasing order of preference, to be used by the <del> client in subsequent connection attempts. </del> <ins> client in subsequent connection attempts.  These are known as the server's "retry configurations". </ins> This document also defines the "ech_required" alert, which the client MUST send when it offered an "encrypted_client_hello" extension that

Discussion:
The reference to "retry keys" comes from when the field was called retrykeys and the type ESNIKeys. We've since renamed them to retryconfig and ECHConfig, so the prose should match.
Change:
encryption operation.  The length will generally be larger than TLSPlaintext.length, but by an amount that varies with the AEAD cipher.  Since the ciphers might incorporate padding, the amount of <del> overhead could vary with different TLSPlaintext.length values.  Each AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. </del> <ins> overhead could vary with different TLSPlaintext.length values. </ins> Symbolically, <del> [[OPEN ISSUE: Reduce these values? https://github.com/tlswg/tls13- spec/issues/55]] </del> In order to decrypt and verify, the cipher takes as input the key, nonce, the "additional_data", and the AEADEncrypted value.  The output is either the plaintext or an error indicating that the

Discussion:
As discussed on list.
Minor suggestions: 1) Explicitly specify the expectation of a "record_overflow" alert after the two "MUST NOT"s. 2) Also drop the issue "OPEN ISSUE" note that's on line 1087-1088. 3) Amend the changelog to mention this. 4) Add a sentence noting the overhead cap has changed to the "Note: In versions of TLS prior to 1.3" paragraph, or elsewhere.
As NAME suggests, I've updated the PR. I have not added the Note. I don't like those. The change log is enough.
Why was the changelog amended as for draft-09? The draft-08 hasn't been published yet. Is it in the progress of being released? (not shown on DataTracker and releases haven't been tagged on GitHub since draft-05)
Pilot error. Please feel free to submit a PR. , Dave Garrett EMAIL wrote:
This is currently 2^{14} + 2048 (in TLSCiphertexT) and then 2^{14} + 1024 later. This is introduced by leaving room for compression. Should we just reduce this entirely across the board. Certainly we don't need to leave room for compression.
Proposal at interim: 256 octets total.
Change:
successful earlier registration. Lifetime (optional).  Lifetime of the registration in seconds. <del> Range of 60-4294967295.  If no lifetime is included, the </del> <ins> Range of 1-4294967295.  If no lifetime is included, the </ins> previous last lifetime set on a previous update or the original registration (falling back to 90000) SHOULD be used.

Discussion:
Not setting to 0 as this would require further explanation on what it means, and also leaves the 0 value usable as a sentinel in implementations for "no lt given" (although the same, with -1, could be achieved by reducing the range at the top end). Closes: URL
Feedback from LwM2M: Their testing takes long with the arbitrary limit of 60s. We found no technical reasons to keep it there, and it should probably be abolished in favor of the natural lower limit of 1 second.
Change:
Additionally, each code of the format "0x1f * N + 0x21" for integer values of N (that is, "0x21", "0x40", ..., through <del> "0x&#8237;3FFFFFFFFFFFFFFE&#8236;") MUST NOT be assigned by IANA. </del> <ins> "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. </ins> 11.  References

Discussion:
This was fun, it turns out there were actually 3 pair of instances where the were added. I wonder if this was super meta level protest against the endianess-swap from back in the day...
Draft 19 has rendering issue for the reserved frame type in section 10.4
Change:
information.  If certificate validation fails, User Equipment MUST NOT make any calls to the API server. <ins> The User Equipment can store the last response it received from the Captive Portal API as a cached view of its state within the Captive Network.  This state can be used to determine whether its Captive Portal Session is near expiry.  For example, the User Equipment might compare a timestamp indicating when the session expires to the current time.  Storing state in this way can reduce the need for communication with the Captive Portal API.  However, it could lead to the state becoming stale if the User Equipment's view of the relevant conditions (byte quota, for example) is not consistent with the Captive Portal API's. </ins> 2.2. The Provisioning Service is primarily responsible for providing a

Discussion:
In section 4.2, we describe a condition where the session is about to expire. The UE detects this by consulting some form of storage. Yet, we never mentioned that it was proper to store any state. This commit adds a small section outlining that the UE can store state, with a brief discussion about the tradeoffs in doing so.
Roman writes, it retrieved from the API so that it could consult the time remaining (seconds-remainingin the API document). I can update section 2.1 to indicate that the UE could store informationfrom the API's response in order to trigger workflows related to imminent expiry of its access.Storing the state isn't required, but it could make the user experience better if supported.
Change:
Definition: <del> Note: We do not explicitly log the encryption_level or packet_number_space: the header.packet_type specifies this by inference (assuming correct implementation) </del> <ins> Note: The encryption_level and packet_number_space are not logged explicitly: the header.packet_type specifies this by inference (assuming correct implementation) </ins> Note: for more details on "datagram_id", see transport-datagramssent. It is only needed when keeping track of packet coalescing.

Discussion:
Work towards resolving , for the QUIC events document.
This is great. There are 2-3 instances in the h3 document as well that could use similar re-wording. I'll post a PR for that
Change:
7.2.1. DATA frames (type=0x0) convey arbitrary, variable-length sequences of <del> bytes associated with HTTP request or response payload data. </del> <ins> bytes associated with HTTP request or response content. </ins> DATA frames MUST be associated with an HTTP request or response.  If a DATA frame is received on a control stream, the recipient MUST

Discussion:
… avoiding confusion with individual frame payloads (editorial). This is related to the Semantics issue URL
NAME has created URL on http-core Semantics draft, which describes how the term "payload" is overloaded when considered with the H2 and H3 docs. Roy's has a proposal to change that term in Semantics, which impacts the HTTP/3 draft. But he was kind enought to submit PR URL, which demonstrates the impact of that change. This issue is mainly for visibility and tracking purposes.
With or without NAME suggestion. I need to do the same for h2, so it is good to see URL suggestion
Change:
The encrypted message payload is defined in the MLS protocol document MLSPROTO, in order to get federation between different systems, the <del> identity key and user init key retrieval MUST be defined as well. The identity key can always be included in the user init key </del> <ins> identity key and client init key retrieval MUST be defined as well. The identity key can always be included in the client init key </ins> response. <del> The delivery service will return one or more user init key bundles, </del> <ins> The delivery service will return one or more client init key bundles, </ins> one for each member. OPEN QUESTION: What if different clients have different cipher

Discussion:
Addressed SV's comments Remove the client fanout concept (because of TreeKEM's handshake ordering requirements) Rename UserInitKeys to ClientInitKeys Minor editorial edits
drop client fanout specify why (policy enforcement, metadata protection) incorporated comments from SV check if it is necessary to define server-to-server message formats only one domain is responsible for a group
I'm very interested in the details of this, but was unable to attend the interim meeting. Does this mean that we are explicitly ruling out client fanout entirely? What metadata are we trying to protect here? You could in theory protect all the metadata with client fanout over Tor for example. Does domain here mean domain name? Why is that relevant? (I'd expect MLS to be independent of DNS) The kind of federated delivery service I'm hoping to be able to use with MLS is logically an append only list of messages published by each member. Where each member can read any other members queue and pull messages they don't have into their own queue (they push their own messages to their own queue only). This allows for diverse P2P topologies, and bandwidth efficient routing. This would be compatible with both and .
TreeKEM has the requirement of total ordering of handshake messages which doesn't work with client fanout. Therefore we drop the idea of client fanout until we have a better proposal on how to solve this. is more conceptual, it doesn't have to be an actual domain name.
Addressed in .