jiebi/CodeConvo huggingface dataset:
Change:
may change over time (Q/V bands, Ka band, etc.).  Depending on the use-case (e.g. very high frequency bands, mobile users) or depending on the deployment use-cases (e.g. performance of the network between <del> each individual block), the relevance of adding coding is different. </del> <ins> each individual block), the relevance of adding coding techniques is different. </ins> 3.5.

Discussion:
A first sentence says quasi-error-free is usually guarranteed thanks to redundancy, while the following sentence tends to say the opposite. Not very clear.The intro fails to clarify the targets. Among them there is "coding to recover from packet losses" (to avoid confusion with bit-error corrections), but also "coding to improve the usage of radio resource". You should also clarify better what is meant by coding: it's not a content coding (e.g., to compress a video flow) but rather a computation of linear combination of packets. Say since the begining you'll rely on RFC8406 whenever possible. Parts of the text currently in section 3 (1st paragraph) deserve to be moved here.Typo: s/to cope from/to cope with/
We have updated the introduction structure and changed the usage of coding in the whole document. We hope this is better. cf PR and PR
this is cherrypicking, not discussing link/channel FEC (Error) or ACK. the heading should really be 'of network coding schemes'. "to cover cases where where"? At the physical layer, FEC mechanisms can be exploited.-- Erasure or Error? "Based on public information, coding does not seem to be widely used at higher layers." it isn't, and that section can be reduced to just that sentence.
Vincent in item X1, 1st sentence, it suggests QUIC is a video streaming application. Change it.Fig. 2 raises a general question: it refers to upper applications that are by nature on the end-hosts. Everything is imaginable here and this is not specific to a SATCOM system. Why don't you limit yourself to the communication layers + middleware? I'm a bit confused.When you say: "Based on public information, coding does not seem to be widely used at higher layers." I guess you limit yourself to the "packetization UDP/IP + middleware" but do not consider upper applications. It's also confusing.
We think that these comments have been assessed with PR
"In this context, this document aims at identifying opportunities for further usage of coding in these systems." again, network coding. this pretending that link and channel FEC don't exist and that "coding", i.e. network coding, is somehow new is irksome.
Closed by PR
Change:
"extensions": The new GroupContext extensions (possibly updated by a GroupContextExtensions proposal) <del> Create an UpdatePath that encrypts the path secrets for the nodes along the sender's filtered direct path to the new ratchet tree, using the provisional GroupContext as context. Any new member (from an Add proposal) MUST be excluded from the resolution during the computation of the UpdatePath. </del> <ins> Encrypt the path secrets resulting from the tree update to the group as described in synchronizing-views-of-the-tree, using the provisional group context as the context for HPKE encryption. </ins> <del> Assign this UpdatePath to the "path" field in the Commit. </del> <ins> Create an UpdatePath containing the sender's new leaf node and the new public keys and encrypted path secrets along the sender's filtered direct path.  Assign this UpdatePath to the "path" field in the Commit. </ins> If not populating the "path" field: Set the "path" field in the Commit to the null optional.  Define "commit_secret" as the all-

Discussion:
Conflicts with (in derivation of ) This is intended just to move around the required steps and give them clearer labels. Please keep an eye out for things that might have accidentally been added or dropped.
Interim 2022-06-02: NAME to review, then clear to merge
Currently, we only have explicit algorithm steps for validating an UpdatePath. We should have a similar level of concreteness for the process of creating an UpdatePath.
Change:
gnuTLS for example treats PSK identities as usernames. PSK identities MAY have a domain name suffix for roaming and <del> federation. </del> <ins> federation.  In applications and settings where the domain name suffix is privacy sensitive, this practice is NOT RECOMMENDED. </ins> Deployments should take care that the length of the PSK identity is sufficient to avoid collisions.

Discussion:
cc NAME NAME
In section 4 there is a statement that switching the roles of servers which use PSKs will lead to weakening of security properties. As this is a common scenario today in situations where you are doing server-to-server communication, it would be useful to discuss just how and how much this weakening occurs. This was a complete surprise to me and I don't know if it was supposed to be one. Are there mitigations that can be made? In section 7, The first sentence does not read, also It seems a bit difficult to have a MUST in there when most of the items below are SHOULDs. That seems to be a dissonance. Section 7.1.1 - The idea of having domain name suffixes on PSKs seems to me to be a bad idea as this would seem to lower privacy levels. Section 7.1.2 - There seem to me to be three different places where collisions will occur. The importer function could get a collision, there could be collisions with pre-TLS 1.2 external identifiers and there could be collision with resumption keys. There has been a huge discussion about this in the EMU group and I don't find the text here to be sensible in term of whether this is or is not a problem. Section 7.1.2 - One of the things that I kept meaning to get to and just haven't done so yet, is dealing with the question of can the TLS Key binders in the handshake to distinguish between multiple keys that happen to have the same identity. Perhaps you should look to see if this does work and if it is safe.
Change:
bandwidth requirements at peering or ingest points can be reduced to as low as a per-feed requirement instead of a per-user requirement. <del> 2.3. </del> <ins> 2.4. </ins> When demand for content is relatively predictable, and especially when that content is relatively static, caching content close to

Discussion:
This definitely needs more work!
NAME and NAME - I have three notes in the section I've added. I'll hit this again later in the week, but if you can express opinions about any of them, that would be very helpful.
NAME In the call we discussed this and we feel like we don't need to say anything about this in addition to what we already said in Section titled "Bitrate Detection Challenges". So, maybe we can drop and close this?
I actually like NAME suggestions - let me spend a couple of hours on this, and then you two can either merge it or reject it.
NAME and NAME see what you think. I'm also ok with closing as wontfix, but wanted to give it a try.
NAME and NAME any thoughts on this PR? I tried to reflect Jake's high-level comments, which were even more helpful and actionable than usual ...
This reads much better than the initial version, thanks.
Pulling the TBD out of the draft text and capturing it here instead. Suggestion from mic at IETF 106 (Mark Nottingham) in response to call for help on capturing the mismatch between supply and demand of bandwidth with regard to video: Dive into the different constraints coming from different parts of the network or distribution channels. (regarding questions about how to describe the disconnect between demand vs. capacity, while keeping good archival value.) "These are big numbers, but the internet has grown over time, and CDN capacities have grown over time. Is it last mile? Probably not--Is it middle mile? Maybe that's more interesting. It it CPU? Is it network cards? Is it the economics of your peering relationships? Unpicking those bits might help a bit. URL
For many, poor Wifi is the culprit. For many others, the ISP aggregation links are the culprit during the prime times (since most such links are oversubscribed/oversold). For some, the CDN issues create problems and for rare cases, the origin drowns and everybody gets upset. For certain environments like student dorms, campus networks, libraries, airport cafes, it is just lack of bandwidth for the power users.
Thanks, this version reads much better to me. I have no objections.
Change:
"token_type" is a 2-octet integer, which matches the type in the challenge. <del> "token_key_id" is the least significant byte of the "key_id" in network byte order (in other words, the last 8 bits of "key_id"). </del> <ins> "truncated_token_key_id" is the least significant byte of the "token_key_id" in network byte order (in other words, the last 8 bits of "token_key_id"). </ins> "blinded_msg" is the Ne-octet blinded message defined above, computed as "SerializeElement(blinded_element)".  Ne is as defined

Discussion:
cc NAME NAME
Let's use different names to make this distinction clear.
This helps, thanks!
Change:
Path validation does not validate that a peer can send in the return direction.  Acknowledgments cannot be used for return path validation <del> as they contain insufficient entropy and might be spoofed.  Endpoints independently determine reachability on each direction of a path, and therefore return reachability can only be established by the peer. </del> <ins> because they contain insufficient entropy and might be spoofed. Endpoints independently determine reachability on each direction of a path, and therefore return reachability can only be established by the peer. </ins> Path validation can be used at any time by either endpoint.  For instance, an endpoint might check that a peer is still in possession

Discussion:
Error? / A stateless reset is not appropriate for signaling error conditions./ I understand, but this sentence seems odd to me, is it possible to say /error conditions when there is connection state/ or something like that? Is it worth a cross ref to section 11 to be clear what a “normal” error is? Section 9 NiTs in wording: /Acknowledgments cannot be used for path validation as they contain insufficient entropy/ Acknowledgments cannot be used for path validation because they contain insufficient entropy/ /as endpoints independently determine reachability on each direction of a path./the endpoints independently determine reachability on each direction of a path./ Is it slightly easier to read: / One or more frames are assembled into packets./ / One or more frames are assembled into a QUIC packet./ In section 3.3. It says: /The receiver of a stream sends MAXSTREAMDATA (Section 19.10) and STOP_SENDING frames (Section 19.5)./ Is this a para where ACK frames should also be mentioned? It seemed odd to me that ACKs are not mentioned at some pointy around here.
I think that the intent is to be more general than just "this is not for connection errors". How about: I don't think that we want to talk about acknowledgements at the level of the stream section. They don't affect stream states and this is specifically about what stream-related frames can be sent.
Change:
The presence of the SSRC in the EKTPlaintext ensures that an attacker cannot substitute an EKTCiphertext from one SRTP stream into another <del> SRTP stream. An attacker who tampers with the bits in FullEKTField can prevent the intended receiver of that packet from being able to decrypt it.  This is a minor denial of service vulnerability.  Similarly the attacker could take an old FullEKTField from the same session and attach it to the packet.  The FullEKTField would correctly decode and pass integrity checks.  However, the key extracted from the FullEKTField , when used to decrypt the SRTP payload, would be wrong and the SRTP integrity check would fail.  Note that the FullEKTField only changes the decryption key and does not change the encryption key.  None of these are considered significant attacks as any attacker that can modify the packets in transit can cause the integrity check to fail. </del> <ins> SRTP stream.  This mitigates the impact of the cut-and-paste attacks that arise due to the lack of a cryptographic binding between the EKT tag and the rest of the SRTP packet.  SRTP tags can only be cut-and- pasted within the stream of packets sent by a given RTP endpoint; an attacker cannot "cross the streams" and use an EKT tag from one SSRC to reset the key for another SSRC.  The epoch field in the FullEKTField also prevents an attacker from rolling back to a previous key. </ins> An attacker could send packets containing a FullEKTField, in an attempt to consume additional CPU resources of the receiving system

Discussion:
This PR addresses IESG review comments from Ben Kaduk, Alexey Melnikov, and Eric Rescorla (while he was still SEC AD).
LGTM
Change:
is finished for the report share. The helper's response to the leader is an HTTP status code 200 OK <del> whose body is the AggregateInitializeResp and media type is "message/ dap-aggregate-initialize-resp". </del> <ins> whose body is the AggregateInitializeResp and media type is "application/dap-aggregate-initialize-resp". </ins> Upon receipt of a helper's AggregateInitializeResp message, the leader checks that the sequence of PrepareStep messages corresponds

Discussion:
In IANA all media types seem to be of "application" type instead of "message" type, this PR is to align the mismatch in the protocol description and adapt to the media types specified in IANA.
Nice catch!
Change:
about the TCP stream they are injecting into, they can simply enumerate all ~70000 possible windows; this is particularly useful for interrupting encrypted/obfuscated protocols such as SSH or Tor <del> Gilad.  RST Packet Injection relies on a stateful network, making it useless against UDP connections.  RST Packet Injection is among the most popular censorship techniques used today given its versatile nature and effectiveness against all types of TCP traffic.  Recent research shows that a TCP RST packet injection attack can even work in the case of an off-path attacker Cao-2016. </del> <ins> Gilad.  Some censorship evasion systems work by trying to confuse the censor into tracking incorrect information, rendering their RST Packet Injection useless Khattak-2013, Wang-2017, Li-2017, Bock-2019, Wang-2020. RST Packet Injection relies on a stateful network, making it useless against UDP connections.  RST Packet Injection is among the most popular censorship techniques used today given its versatile nature and effectiveness against all types of TCP traffic.  Recent research shows that a TCP RST packet injection attack can even work in the case of an off-path attacker Cao-2016. </ins> Empirical Examples: RST Packet Injection, as mentioned above, is most often paired with identification techniques that require splitting,

Discussion:
Hi team - Here's a pull request with some additional text and information to add to the RFC. Please let me know if there are things I should change or add or remove or fix - totally open to feedback! My changes are the following: Added text towards additional forms of TLS censorship (and citations for them): ESNI censorship, server certificate censorship, omitted SNI censorship Added text about residual censorship Added text about censorship in depth Added text about additional keyword blocking dynamics, there's been some recent research on this Added text about protocol filtering (such as Iran's protocol filter) Added some additional citations for various forms of censorship I'd be happy to break this up into multiple PRs if that's easier as well.
Kevin, if you can rebase your commits on top of the latest version, I'm happy to merge this PR. Thank you for your work on it!
Hi NAME - Just wanted to give this a bump as I close this tab. Let me know if there's any other work that should be added!
Change:
stream.  If a stream that is critical for an application is closed, the application can generate error messages on the application layer to inform the other end and/or the higher layer, which can eventually <del> reset the QUIC connection. </del> <ins> terminate the QUIC connection. </ins> Mapping of application data to streams is application-specific and described for HTTP/3 in QUIC-HTTP.  There are a few general

Discussion:
Reset is a directional stream semantic, not a connection one.
Actually the idea here was not necessarily talk about the semantics of how a connection is closed. So maybe using something else like "abort" would avoid any confusion here...?
Oh, I see. Yeah maybe abort is better. For me reading this "reset" made me think of TCP connection and or QUIC stream semantics, which is probably not the intention.
Change:
ACK-FREQUENCY frames have a type of 0xXX, and contain the following fields: <ins> A variable-length integer representing the sequence number assigned to the ACK-FREQUENCY frame by the sender, see multiple- frames. </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

Discussion:
merging.
We currently use PNs for ordering, but that runs afoul of requirements at the receiver specified in .
Change:
asynchronous interface using sockets generally uses a try-and-fail model.  If the application wants to read, but data has not yet been received from the peer, the call to read will fail.  The application <del> then waits and can try again later. In contrast to sockets, all interaction using the Transport Services API is expected to be asynchronous, and use an event-driven model (see events).  For example, an application first completes a call to receive new data from the connection.  When delivered data becomes available, this data is delivered to the application using asynchronous events that contain the data.  Error handling is also asynchronous; a failure to send results in an asynchronous send error as an event. </del> <ins> then waits and can try again later.  In contrast to sockets, all interaction using the Transport Services API is expected to be asynchronous and use an event-driven model (see events).  For example, an application first issues a call to receive new data from the connection.  When delivered data becomes available, this data is delivered to the application using asynchronous events that contain the data.  Error handling is also asynchronous; a failure to send data results in an asynchronous error event. </ins> The Transport Services API also delivers events regarding the lifetime of a connection and changes in the available network links,

Discussion:
Be clear that the API is asynchronous (not the whole arch); and reword the read example to also be asynchronous.
In section 2.1 "its call to read will not complete immediately" is easy to misread. The call to read does in fact return immediately. Any read data is returned asynchronously. Please rework this sentence.
Change:
For more information about time scales, see RFC1305, Section 3 of ISO8601, and the appropriate ITU documents ITU-R-TF.460-6. <del> 3. </del> <ins> 2. </ins> This section discusses desirable qualities of formats for the timestamp extension suffix and defines such a format that extends RFC3339 for use in Internet protocols. <del> 3.1. </del> <ins> 2.1. </ins> The format should allow implementations to specify additional important information in addition to the bare timestamp.  This is

Discussion:
The current draft does not say what it actually means when a timezone name is added to a timestamp. Is the combination of the timezone name and the timezone offset an assertion that the offset was correct for the named timezone at the time? What if that assertion is not true? What about future times? Does the timezone name take precedence over the offset given (i.e., the timestamp changes its meaning with political decisions) or does the offset win?
(From the SEDATE meeting: "encode the intention"?)
(From the SEDATE meeting: "don't encode the timezone if that is not the overriding information".) One use case is documenting the time zone name, though.
We now have a clarified scope ( as published in -02). This makes the underlying issue out of scope -- the RFC 3339 semantics prevail. Discuss.
essentially is the continuation of this issue with a revised question. The resolution of the question in this PR remains in place.
As a description of one path forward, this is good - and it's sufficient for the proposal that I made. Good threading of the potential needle here.
Change:
Case 2: The old path is alive but not preferred. This case is shown in fig-old-path-not-preferred whereby the sender <del> replies with a "path_delete" message (2) on the old path.  This </del> <ins> replies with a "path_drop" message (2) on the old path.  This </ins> triggers the receiver to send a "path_challenge" (3) on the new path. The sender will reply with a "path_response" (4) on the new path, thus providing confirmation for the path migration.

Discussion:
Signed-off-by: Thomas Fossati
A better name could be or -- one doesn't "delete" a path.
I agree. I prefer path_drop
Change:
specific usage for each media type is outlined in Sections 4 and 5. <ins> If this m= section is for media with configurable durations of media per packet, e.g., audio, an "a=maxptime" line, as described in sec-create-offer. If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </ins> For each supported RTP header extension that is present in the offer, an "a=extmap" line, as specified in RFC5285, Section 5. The list of header extensions that SHOULD/MUST be supported is

Discussion:
It's a transport attribute, so it should come at the end, like other transport attribs
just checking ... this is just a style thing right? the code would accept SDP with these in any order ?
Of course. This is just how we order things in Section 5.
For createoffer, createanswer ordering of attribs
So SDP has no requirement on the ordering of the a= lines. I don't see how a parser, even a JSEP one can expect to get the a= lines in any specific order. I fear that even a "it is recommended to generate them in this order" will be misinterpreted. I think this is one of SDPs warts that you will have to live with.
Right, there isn't any need to mandate an order, I just think that in the text for generating an offer, the places that talk about adding a=rtpmap should be adjacent. This should be a fairly trivial editorial change.