jiebi/CodeConvo huggingface dataset:
Code change:
Upon transmission or receipt of a fatal alert message, both parties immediately close the connection.  Whenever an implementation encounters a condition which is defined as a fatal alert, it MUST <del> send the appropriate alert prior to closing the connection. </del> <ins> send the appropriate alert prior to closing the connection.  All alerts defined in this section below, as well as all unknown alerts are universally considered fatal as of TLS 1.3 (see alert-protocol). </ins> The following error alerts are defined: <del> An inappropriate message was received.  This alert is always fatal and should never be observed in communication between proper implementations. </del> <ins> An inappropriate message was received.  This alert should never be observed in communication between proper implementations. </ins> This alert is returned if a record is received which cannot be deprotected.  Because AEAD algorithms combine decryption and verification, this alert is used for all deprotection failures. <del> This alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network). </del> <ins> This alert should never be observed in communication between proper implementations, except when messages were corrupted in the network. </ins> A TLSCiphertext record was received that had a length more than 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record <del> with more than 2^14 bytes.  This alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network). </del> <ins> with more than 2^14 bytes.  This alert should never be observed in communication between proper implementations, except when messages were corrupted in the network. </ins> Reception of a "handshake_failure" alert message indicates that the sender was unable to negotiate an acceptable set of security <del> parameters given the options available.  This alert is always fatal. </del> <ins> parameters given the options available. </ins> A certificate was corrupt, contained signatures that did not verify correctly, etc.

Related discussion:
text: As all error alerts are now considered fatal (PR ), we no longer need "This alert is always fatal" explicitly stated everywhere in that section.
Code change:
but is not limited to, spoofing DNS responses, blocking DNS requests, and tracking.  HTTP authentication and proxy friendliness are expected to make this protocol function in some environments where <del> DNS directly on TLS (RFC7858) would not. </del> <ins> unsecured DNS (DNS) or DNS directly on TLS (RFC7858) would not. </ins> A secondary use case is web applications that want to access DNS information.  Standardizing an HTTPS mechanism allows this to be done

Related discussion:
text: I think that we should specify behaviour for truncated responses with the TC bit more clearly. Right now the text is a little vague. There seem to be three options: mandate the generation of an HTTP error mandate the forwarding of the truncated response explicitly allow either forbid the use of truncated responses and recommend fallback to TCP if the DNS API server is just making DNS requests to another server I think that the draft current vacilates in the direction of 3, but I tend to like 1 or 4. Choosing 4 wouldn't be consistent with the dnsop DNS-over-HTTP draft using DOH though.
is the right answer, so the text should just be stronger about it. If DOH requires or , that means that the DNS server code will need to be heavily reworked to capture these from going out, which seems pointless. DOH clients can act like normal stubs: either they do or don't know about truncation and TC.
I agree - I don't think doh needs to behave differently here than any other datagram based client - i.e. its not a transport error. NAME can you do a pr to clarify?
Will do.
Code change:
9.1.6. <del> Integer This property specifies how long to wait before aborting a Connection during establishment, or before deciding that a Connection has failed after establishment.  It is given in seconds. </del> <ins> This property specifies how long to wait before deciding that a Connection has failed after establishment. </ins> 9.1.7.

Related discussion:
text: Notable changes: added control over using multipath (which was a late addition to minset) added a timeout for conn. establishment, separate from the other conn. abort timeout (see ) renamed InitiateWithIdempotentSend into InitiateWithSend, and adjusted the text to recommend declaring idempotence. This addresses the minset function that goes back to TCP's send-with-SYN.
Status: NAME said "LGTM modulo tiny nits" and I think these nits are now addressed. NAME requests something more than just a boolean to enable/disable usage of multiple paths. It seems to me that this needs more discussion, but it also doesn't seem like a show-stopper for the boolean to begin with; I think we can discuss this more after landing this PR. NAME hasn't reacted (or am I missing this), but this has an ok from NAME and NAME In conclusion: I think this is good to go. I'll wait until tomorrow; unless someone speaks up by then, I'll merge this PR.
If you make it a boolean it cannot be used as a selection property, so I do not think that is a good choice. Or how should it be interpreted for the selection?
NAME what do you mean, that it should be a (binary - yes/no) Preference instead? I thought this would be more limiting but I'm fine with this as well.
NAME I meant that it should be a Preference as pointed out in the original comment by NAME I do not understand what a boolean means during selection (is it a requirement or a preference?) I also do not understand what it means in the middle of a connection. You mean you should try and use a single or several subflows for scheduling data, assuming you already have a multipath connection? I guess this is possible, but then the description needs to be more clear that this is what it means. In the appendix about minset your have "Disable MPTCP: "Parallel Use of Multiple Paths" Property." I assume this refers to the Protocol Selection phase? It does not make sense to disable or enable MPTCP in the middle of a connection I think. I guess part of how to specify the property depends on how to interpret this part from the intro to the Managing Connections section: "The application can set and query Connection Properties on a per-Connection basis.
Code change:
9.1.6. <del> Integer This property specifies how long to wait before aborting a Connection during establishment, or before deciding that a Connection has failed after establishment.  It is given in seconds. </del> <ins> This property specifies how long to wait before deciding that a Connection has failed after establishment. </ins> 9.1.7.

Related discussion:
text: Connection Properties that are not read-only can be set during pre-establishment (see {{selection-props}}), as well as on connections directly using the SetProperty action" I interpreted this as properties set during pre-establishment are selection properties, but maybe this is not the intention as they may need to be expressed differently? If they are not intended as selection properties, we are missing a selection property for multipath I guess.
NAME Ok. That's what I meant, yes - but I agree that's not covered by the description, it really is a selection preference only as it's written now. OK (though you CAN do it with the "real" API, by closing subflows, but this goes beyond the spec'd protocol, and I'm also not sure it's a good idea, especially when limited to only enabling / disabling it altogether). I would have understood this as in your first interpretation: "properties set during pre-establishment are selection properties".
NAME Closing a subflow is not the same as disabling MPTCP to me. You will still be using MPTCP, only with a single subflow. And you can certainly not open a subflow unless MPTCP is already enabled. But seems we now have a common understanding.
NAME ack, we've converged. I just pushed a commit that turns the "Parallel Use of Multiple Paths" property into a Selection property.
these are a few minor changes to apply, and properties to add (e.g. "disable MPTCP")
this is done, yes?
No. But I'm planning to do a PR to address this issue this week.
Note that this also requires closing , which I re-opened with a concrete proposal to address something from minset.
LGTM modulo tiny nitsSorry, missed this until just now. Looks fine with me, I just have a small question and my 2 cents to the multipath discussion (which we can have at a later point).
Code change:
3.8. <del> In order to reduce round trips and the number of messages or to </del> <ins> In order to reduce round trips and the number of messages, or to </ins> simplify processing, external security applications may be integrated into EDHOC by transporting authorization related data in the messages. <del> EDHOC allows opaque external authorization data (EAD) to be sent in each of the four EDHOC messages (EAD_1, EAD_2, EAD_3, EAD_4). </del> <ins> EDHOC allows processing of external authorization data (EAD) to be defined in a separate specification, and sent in dedicated fields of the four EDHOC messages (EAD_1, EAD_2, EAD_3, EAD_4).  EAD is opaque data to EDHOC. </ins> <del> External authorization data is a CBOR sequence (see CBOR) consisting of one or more (ead_label, ead_value) pairs as defined below: </del> <ins> Each EAD field is a CBOR sequence (see CBOR) consisting of one or more EAD items (ead_label, ead_value) as defined below: </ins> A security application using external authorization data need to <del> register an ead_label, specify the ead_value format for each message (see iana-ead), and describe processing and security considerations. </del> <ins> register a positive ead_label and the associated ead_value format for each EAD item it uses (see iana-ead), and describe processing and security considerations.  Each application registers their own EAD items and defines associated operations.  The application may define multiple uses of certain EAD items, e.g., the same EAD item may be used in different EDHOC messages with the same application. An EAD item can be either critical or non-critical, determined by the sign of the ead_label in the transported EAD item included in the EDHOC message.  Using the registered positive value indicates that the EAD item is non-critical.  The corresponding negative value indicates that the EAD item is critical. ead_label = 0 MUST NOT be used. If an endpoint receives a critical EAD item it does not recognize or a critical EAD item that contains information that it cannot process, the EDHOC protocol MUST be discontinued.  A non-critical EAD item can be ignored. The specification registring a new EAD label needs to describe under what conditions the EAD item is critical or non-critical. </ins> The EAD fields of EDHOC must not be used for generic application <del> data.  Examples of the use of EAD is provided in ead-appendix. </del> <ins> data.  Examples of the use of EAD are provided in ead-appendix. </ins> 3.9.

Related discussion:
text: If is is big it might make more sense to define new method(s) based on the noise IK pattern.
Could we have a design team meeting or an interim to discuss this issue?
In the use case that the Initiator gets the Responders static public key beforehand The Responder would in this case have a static DH key. The Initiator could use Static DH or a singature.
Perhaps a breakout meeting during/just before IETF 114?
Closing this since NAME agreed that the introduction of critical/non-critical EAD (PR , included in -15) in combination with an example using third party encrypted EAD (as in ace-ake-authz) resolves the issue.
Code change:
Abstract This document provides an overview of operational networking issues <del> that pertain to quality of experience in delivery of video and other </del> <ins> that pertain to quality of experience in streaming of video and other </ins> high-bitrate media over the internet. 1.

Related discussion:
text: Ali, this PR looks nice. Two meta-issues (which we can talk about whenever). I changed my references in the draft to a more complete format (using ins: can result in odd formatting in the References section). We don't have to do that for all the references in -04, but that would be a good thing to do in an editorial pass. I see that you're making some terminology changes (from "delivery" to "streaming", stuff like that). I agree with the changes you made in this PR, but we may want to make sure that they are made globally, for consistency.
I was not sure about the reference format, normally I just use the casual format: Authors, "Title," Journal/Conference, Date. I saw the missing author names and realized "ins" would do the trick. By no means, I am tied to that format - don't know even know what "ins" stands for here :)
From URL : "as in the author list, ins is an abbreviation for "initials/surname";" I tend to think an editorial pass on references would be better as a separate commit, where they need cleaning. Anything that somehow made it in and breaks the "make" needs fixing, but others maybe later?
I suggest a definition along these lines: Streaming is transmission of a continuous content from a server to a client and its simultaneous consumption by the client. ("simultaneous" is the key here) This has two implications: 1) Server transmission rate (loosely or tightly) matches to client consumption rate. That is, no buffer overrun or underrun is desirable/acceptable. 2) Client consumption rate is also limited by real-time constraints as opposed to just bandwidth availability. That is, client cannot fetch the content not available yet.
+1, this sgtm. But this probably implies a refactor of the intro section and the abstract, to better focus on the relevant use case.
I can take a crack at this.
Ali has text for this, will create a PR for the issue.
Code change:
the inclusion of uppercase field names, or <del> the inclusion of invalid characters in field names or values </del> <ins> the inclusion of invalid characters in field names or values. </ins> A request or response that includes a payload body can include a Content-Length header field.  A request or response is also malformed

Related discussion:
text: if we want to do that. There was a hole in the error code space, so I filled it with this. I haven't pulled Push out to its own error; it doesn't seem like it belongs with this one.
We might want to add a mention of this in A.4 where we talk about PROTOCOL_ERROR
(I couldn't find anything on this, but I'm prepared to be corrected. Also, it's late, so if this is closed, I'm totally OK with that.) We're just in the process of doing full validation of pseudo-header fields (I know, seems late, what are you gonna do about that). And we realized that there is no error code for indicating this sort of error. That is, if pseudo-fields are out of order, or a request contains , or there are uppercase characters. contains lots of MUSTs, but it seems to rely entirely on the definition of "malformed" which leads to H3GENERALPROTOCOL_ERROR. This is fine, but not especially helpful in isolating problems. Could we define an error code for this specific case?
H2 just says malformed is treated as PROTOCOL_ERROR. So H3 is providing parity. There might be an argument for more fidelity but I'm not convinced it would help much. It could require more contortions in the text - do you have different error for different types of malformed?
Internally, we use a different error code. Of course, all internal error codes map to the same code for sending in RESETSTREAM/CONNECTIONCLOSE.
I'm inclined not to do much, if anything, here. They all trace back to "malformed," as you note, which leads to GENERALPROTOCOLERROR. The instances in which we use GPE are: Malformed HTTP messages Push whose request headers change across multiple promises As a substitute for more specific codes I wouldn't be opposed to splitting the first two off into a new / two new codes, because that would be consistent with our principle of indicating the general area where the failure occurred. I would push back on having separate error codes for specific ways the message could be malformed, because that's pretty expansive rabbit hole.
OK, I'm satisfied with that response. I think that we'll just have to signal extra information in the text field. Happy to close this.
Code change:
the inclusion of uppercase field names, or <del> the inclusion of invalid characters in field names or values </del> <ins> the inclusion of invalid characters in field names or values. </ins> A request or response that includes a payload body can include a Content-Length header field.  A request or response is also malformed

Related discussion:
text: NAME do you think an error code for "malformed message" would be useful, if we don't go into the various types of malformed?
That might be useful, yes.
This is a design change, albeit a marginal one.
NAME let's merge the associated PR but keep this issue open and marked as "call-issued"
Keeping open, as requested.
Closing this now that the IESG review of draft 33 has concluded.
In fairness, I question whether the IESG review of the HTTP drafts has concluded. But as this is not an IESG comment, I'm content to close it. People have had time to object.
Yes I agree Mike. This was due to me being over eager with the close button. The issue may not have strictly been raised in the period that the IESG were directed to review the doc, and they have yet to ballot on draft 33. But either way there was no push back from the WG on this change since draft 33 was published.
Code change:
Various academic works have analyzed MLS and the different security guarantees it aims to provide.  The security of large parts of the <del> protocol has been analyzed by [BBN19] (draft 7), [ACDT21] (draft 11) and [AJM20] (draft 12). </del> <ins> protocol has been analyzed by BBN19 (draft 7), ACDT21 (draft 11) and AJM20 (draft 12). </ins> Individual components of various drafts of the MLS protocol have been analyzed in isolation and with differing adversarial models, for <del> example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20] and [ACJM20] </del> <ins> example, BBR18, ACDT19, ACCKKMPPWY19, AJM20, ACJM20, and AHKM21 </ins> analyze the ratcheting tree as the sub-protocol of MLS that <del> facilitates key agreement, while [BCK21] analyzes the key derivation paths in the ratchet tree and key schedule.  Finally, [CHK21] analyzes the authentication and cross-group healing guarantees provided by MLS. </del> <ins> facilitates key agreement, while BCK21 analyzes the key derivation paths in the ratchet tree and key schedule.  Finally, CHK21 analyzes the authentication and cross-group healing guarantees provided by MLS. </ins> 8. <del> ACCKKMPPWY19: https://eprint.iacr.org/2019/1489 ACDT19: https://eprint.iacr.org/2019/1189 ACDT21: https://eprint.iacr.org/2021/1083 ACJM20: https://eprint.iacr.org/2020/752 AHKM21: https://eprint.iacr.org/2021/1456 AJM20: https://eprint.iacr.org/2020/1327 BBN19: https://hal.laas.fr/INRIA/hal-02425229 BBR18: https://hal.inria.fr/hal-02425247 BCK21: https://eprint.iacr.org/2021/137 CHK21: https://www.usenix.org/system/files/sec21-cremers.pdf 9. </del> This document makes no requests of IANA.

Related discussion:
text: The references at the end of the Security Considerations weren't in kramdown format. Fixed.
Code change:
A PATH_RESPONSE frame received on any network path validates the path on which the PATH_CHALLENGE was sent. <del> If the PATH_CHALLENGE frame that resulted in successful path validation was sent in a datagram that was not expanded to at least 1200 bytes, the endpoint can regard the address as valid.  The endpoint is then able to send more than three times the amount of </del> <ins> If an endpoint sends a PATH_CHALLENGE frame in a datagram that is not expanded to at least 1200 bytes, and if the response to it validates the peer address, the path is validated but not the path MTU.  As a result, the endpoint can now send more than three times the amount of </ins> data that has been received.  However, the endpoint MUST initiate another path validation with an expanded datagram to verify that the <del> path supports required MTU. </del> <ins> path supports the required MTU. </ins> Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be

Related discussion:
text: This was definitely odd. Let's take another tilt at making it comprehensible.
Erik Kline said:
Yep, when it's called out, it's distinctly odd. Hopefully it's an easy fix, but writing is hardd.
Code change:
(e.g.  I-D.ietf-httpbis-priority. A Transport Services system gives no guarantees about how its <del> expression of relative priorities will be realized; for example, if a transport stack that only provides a single in-order reliable stream is selected, prioritization information can only be ignored. However, the Transport Services system will seek to ensure that performance of relatively-prioritized connections and messages is not worse with respect to those connections and messages than an equivalent configuration in which all prioritization properties are left at their defaults. </del> <ins> expression of relative priorities will be realized.  However, the Transport Services system will seek to ensure that performance of relatively-prioritized connections and messages is not worse with respect to those connections and messages than an equivalent configuration in which all prioritization properties are left at their defaults. </ins> The Transport Services interface does order Connection Priority over the Priority Message Property.  In the absense of other externalities

Related discussion:
text: Section 7.2.6. says " for example, if a transport stack that only provides a single in-order reliable stream is selected, prioritization information can only be ignored." I don't think this is entirely true as you can still decide in which order you schedule independent messages on one stream.
I don't get this. The sentence says "in-order". Scheduling them from buffer A into buffer B in accordance with priorities won't help when everything leaves buffer B in a fixed sequence.
How about a less complex sentence: ..."for example, if the transport system selects a stack that only provides a single in-order reliable stream, the prioritization information is ignored."
message on the taps "layer" are independent. so the order an application calls send on these message doesn't have to be the same order the messages are send on an "in-order stream"
Oh, now I see what you mean. Hmmm... looking at the text, it seems that we could just delete this sentence and the problem is solved?
I think what was intended with the example was to show that the set priorities may not have any effect. Perhaps we should instead just add "and the set priorities may not have any effect" if we want to be explicit? Removing it also works though.
I think just add that!
I'm for removing it (I think I wrote this sentence btw :-) ). Giving this example just throws off someone who thinks about this case like Mirja did here - even if we say "may not apply", the reader may (correctly) think "but why, in this case they CAN well apply!". So I don't find that helpful. For context, the full current statement is: and I believe that we say everything we need to say if we just change this into:
I like simple examples, this one wasn't great so this is OK.