jiebi/CodeConvo huggingface dataset:
Change:
functions together.  In this case, there is no need for a protocol between the two. <del> It is also worth pointing out that the choice of model is generally up to the Relying Party.  The same device may need to create Evidence for different Relying Parties and/or different use cases.  For instance, it would use one model to provide Evidence to a network infrastructure device to gain access to the network, and the other model to provide Evidence to a server holding confidential data to gain access to that data.  As such, both models may simultaneously be in use by the same device. </del> <ins> It is also worth pointing out that the choice of model depends on the use case, and that different Relying Parties may use different topological patterns. The same device may need to create Evidence for different Relying Parties and/or different use cases.  For instance, it would use one model to provide Evidence to a network infrastructure device to gain access to the network, and the other model to provide Evidence to a server holding confidential data to gain access to that data.  As such, both models may simultaneously be in use by the same device. </ins> combination shows another example of a combination where Relying Party 1 uses the passport model, whereas Relying Party 2 uses an

Discussion:
We say: I'm not sure it "is up to the RP"_. Maybe better saying it "depends on the RP application" (or similar) because it's typically not a choice of the RP but of the use case / protocol flow in which the RP operates...
+1
Proposal: "Individual applications, use cases or protocol flows interacting with the same Attester can use different models."
Change:
deprecated and MUST be ignored for all purposes. The length (in bytes) of the following TLSPlaintext.fragment.  The <del> length MUST NOT exceed 2^14. </del> <ins> length MUST NOT exceed 2^14.  An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert. </ins> The data being transmitted.  This value transparent and treated as an independent block to be dealt with by the higher-level protocol

Discussion:
Before record protection is established, if an endpoint receives a TLSPlaintext structure whose "length" field is too large (>2^14), should it send a "record_overflow" alert?
Change:
The term 'byte string' is used for sequences of bytes, while the term 'text string' is used for sequences of characters. <ins> The tables for algorithms contain the following columns: Additional columns may be present in the table depending on the algorithms. </ins> 1.4. At the time that RFC8152 was initially published, the CBOR Data

Discussion:
Add in response for IANA review on all documents SecDir review by Nancy on -algs GenArt review on -struct
Change:
Section 5.14.  For the m= line itself, the following rules MUST be followed: <del> The port value is set to the port of the default ICE candidate for this m= section, but given that no candidates are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </del> <ins> If the m= section is marked as bundle-only, then the port value MUST be set to 0.  Otherwise, the port value is set to the port of the default ICE candidate for this m= section, but given that no candidates are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in I-D.ietf-ice-trickle, Section 5.1. </ins> To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8.

Discussion:
BLOCKER: The first bullet on page 37 says that port 9 "MUST be used," which contradicts the behavior required of BUNDLE-only sections (for which port 0 MUST be used). Clarify.
Yes - we need to indicate that bundle-only sections use 0 instead of 9.
Change:
The addIceCandidate method provides a remote candidate to the ICE Agent, which, if parsed successfully, will be added to the current and/or pending remote description according to the rules defined for <del> Trickle ICE.  Connectivity checks will be sent to the new candidate. </del> <ins> Trickle ICE.  If the MID, m-line index, or candidate string provided in the ICE candidate is invalid, an error is generated.  Connectivity checks will be sent to the new candidate. </ins> This method can also be used to provide an end-of-candidates indication (as defined in I-D.ietf-ice-trickle) to the ICE Agent for

Discussion:
Fixes URL
fixed the typos - LGTM
The spec is clear on that the MID has precedence over m= line index when coordinating candidates with m= lines. But it is not clear on what would happen if the MID has a value can't be matched to an m= line (while potentially the m= line index is valid).
I suspect that should result in some sort of invalid value error.
Right, I think we should return an error from addIceCandidate in this case. If you wanted a different result, you should have used the correct mid :-)
I agree to the above, just want it clarified.
Change:
A sender MAY implement alternate mechanisms to update its congestion window after idle periods, such as those proposed for TCP in RFC7661. <del> 7.8. When keys for a packet number space are discarded, any in-flight packets sent with those keys are removed from the count of bytes in flight.  Loss recovery state is also discarded, so no loss events will occur for any in-flight packets from that space (see discard- initial).  Note that it is expected that keys are discarded after those packets would be declared lost, but Initial secrets are destroyed earlier. When 0-RTT is rejected, all in-flight 0-RTT packets are removed from the count of bytes in flight.  Loss recovery state is also discarded, so no loss events will occur for any in-flight 0-RTT packets. If a server accepts 0-RTT, but does not buffer 0-RTT packets that arrive before Initial packets, early 0-RTT packets will be declared lost, but that is expected to be infrequent. </del> 7.9. 7.9.1.

Discussion:
Ignore the loss of Handshake, 0-RTT, and 1-RTT packets if the peer doesn't have the keys to process them. Also unifies the text on discarding keys and no longer implies that 0-RTT has it's own packet number space. Replaces
merging this one as well to get this in -18.
A few comments, editorial.
Change:
privacy handling, and key derivation need to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher). <del> This document defines how to use EAP-TLS with TLS 1.3 (or higher) and does not change how EAP-TLS is used with older versions of TLS.  It does however provide additional guidance on authorization and resumption for EAP-TLS in general (regardless of the underlying TLS version used).  While this document updates EAP-TLS RFC5216, it remains backwards compatible with it and existing implementations of EAP-TLS.  This document only describes differences compared to RFC5216.  All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2. </del> <ins> This document defines how to use EAP-TLS with TLS 1.3 and does not change how EAP-TLS is used with older versions of TLS.  It does however provide additional guidance on authorization and resumption for EAP-TLS in general (regardless of the underlying TLS version used).  While this document updates EAP-TLS RFC5216, it remains backwards compatible with it and existing implementations of EAP-TLS. This document only describes differences compared to RFC5216.  All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2.  Since EAP-TLS couples the TLS handshake state machine with the EAP state machine it is possible that new versions of TLS will cause incompatibilities that introduce failures or security issues if they are not carefully imtegrated into the EAP-TLS protocol.  Therefore, implementations MUST limit the maximum TLS version they use to 1.3, unless later versions are explicitly enabled by the administrator. </ins> In addition to the improved security and privacy offered by TLS 1.3, there are other significant benefits of using EAP-TLS with TLS 1.3.

Discussion:
Explain that the next version of TLS may not be compatible with this document. Remove "or higher" in several sections. This addresses issue
NAME does this commit address Issue ?
As an implementor, I'm not sure what it means to "automatically support" or "not automatically support" something. It's not clear to me what I do with that recommendation. I think it's best to make an explicit statement that That statement gives clear direction on exactly what to do. i.e. there are APIs to "limit the maximum TLS version". So I know what that phrase means. There are no APIs to "not automatically support" something. So I don't know what that phrase means, or what I should do in order to satisfy its' requirements. The rest of the changes are fine.
Thanks, I updated the text.
From Alan's review: Suggestion: remove all "or higher" text. Add in text which says that by default, EAP-TLS 1.3 implementations MUST limit the maximum TLS version to 1.3, unless later versions are explicitly enabled by the administrator.
It would help implementors to understand why this restriction is there. i.e. instead of just saying "use TLS 1.3", it would be good to note something like:
Change:
for a bi-directional Internet access can be found in SAT2017. Some functional blocks aggregate the traffic of multiple users. <del> Coding schemes could be applied on both single and aggregated </del> <ins> Coding techniques could be applied on both single and aggregated </ins> traffic. 3. <del> This section details use-cases where coding schemes could improve the overall performance of a SATCOM system (e.g. considering a more </del> <ins> This section details use-cases where coding techniques could improve the overall performance of a SATCOM system (e.g. considering a more </ins> efficient usage of the satellite resource, delivery delay, delivery ratio).

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:
Abstract <del> WebTransport OVERVIEW is a protocol framework that enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport.  This document describes a WebTransport protocol that uses HTTP semantics to provide support for unidirectional streams, bidirectional streams, and datagrams. This protocol can be used with any HTTP version, however this document focuses on TCP-based HTTP versions, specifically providing examples of these capabilities when multiplexed within the same HTTP/2 RFC7540 connection. </del> <ins> WebTransport defines a set of low-level communications features designed for client-server interactions that are initiated by Web clients.  This document describes a protocol that can provide many of the capabilities of WebTransport over HTTP/2.  This protocol enables the use of WebTransport when a UDP-based protocol is not available. </ins> Note to Readers

Discussion:
There is a long and proud legacy of drafts that carry introductions concentrating on the motivations for the last design change rather than the true reasons for the protocol. This is my attempt to bring things back on the level. I didn't stop there though. I think that we should make this about HTTP/2 because we don't currently have an extended CONNECT defined for HTTP/1.1. This walks back some of the "generic HTTP" language. More changes might be needed later in the document for that to be complete, but I wanted to keep this fix localized. I did cut stuff that I think the document should still contain. I just don't think that these need to be in the introduction. That is: you can multiplex multiple sessions other protocols might take stuff from this session and transmit them in different, better ways
Change:
Secure RTP (SRTP) is a profile for RTP that provides confidentiality, message authentication, and replay protection for RTP data packets <del> and RTP control protocol (RTCP) packets RFC3711.  SRTP can use different handshake protocols, such as DTLS in DTLS-SRTP RFC5764 or ZRTP RFC6189. </del> <ins> and RTP control protocol (RTCP) packets RFC3711.  SRTP provides a record layer only, and requires a separate handshake protocol to provide key agreement and identity management. </ins> <del> 3.2.2. </del> <ins> The commonly used handshake protocol for SRTP is DTLS, in the form of DTLS-SRTP RFC5764.  This is an extension to DTLS that negotiates the use of SRTP as the record layer, and describes how to export keys for use with SRTP. </ins> <del> ZRTP RFC6189 is an alternative key agreement protocol for SRTP.  It uses standard SRTP to protect RTP data packets and RTCP packets, but provides alternative key agreement and identity management protocols. Key agreement is performed using a Diffie-Hellman key exchange that runs on the media path.  This generates a shared secret that is then used to generate the master key and salt for SRTP. </del> <ins> ZRTP RFC6189 is an alternative key agreement and identity management protocols for SRTP.  ZRTP Key agreement is performed using a Diffie- Hellman key exchange that runs on the media path.  This generates a shared secret that is then used to generate the master key and salt for SRTP. </ins> 3.3.

Discussion:
This revises the description of SRTP and the relation between SRTP, DTLS, and ZRTP.
If we keep that headline, we need one for DTLS-SRTP too. Yes, that was intentional. SRTP is just the record protocol. The key management is usually done by DTLS or occasionally by ZRTP.
Comment from Ekr's review of -10: Pre-Connection Interfaces […] Also, I'm not sure you want to omit tcpcrypt here, in that it does have a way to do external authentication by exporting a session ID. Also ZRTP allows for some sort of fingerprint-based auth. tcpcrypt (and I believe ZRTP) both have session caches.
ZRTP uses , compared by the users, as an external authentication mechanism (similar process to the Safety Numbers in Signal, I believe). ZRTP does maintain a session cache.
In other words, ZRTP supports interfaces to Authentication Delegation and Session Cache Management, and DTLS-SRTP does not?
Thanks for the reply. I'm okay with merging these changes as they are, or you can add that one reference for ZRTP to have both.
Change:
The DNS name of the client-facing server, i.e., the entity trusted to update the ECH configuration.  This is used to correct <del> misconfigured clients, as described in handle-server-response. </del> <ins> misconfigured clients, as described in rejected-ech. </ins> Clients MUST ignore any "ECHConfig" structure whose public_name is not parsable as a dot-separated sequence of LDH labels, as defined

Discussion:
Handling server response discusses how to dispatch between accept/reject, but the retry flow is specifically the reject bit.
Change:
and SRTCP traffic. Either the FullEKTField or ShortEKTField is appended at the tail end <del> of all SRTP packets. </del> <ins> of all SRTP packets.  The decision on which to send is specified in timing. </ins> 2.2.1.

Discussion:
There is slight mention of i frames but they get called "intra coded video frames"
Either the FullEKTField or ShortEKTField is appended at the tail end of all SRTP packets.
Pointing to the section looks good This is ok. I reviewed the timing section briefly, but didn't see mention of I-frame or key frame packets. That's another good time to provide the full EKT field.
Change:
number of routers (6LR) that the packet goes through from the 6LBR (Node A) to the RUL (Node G). <del> The 6LBR will insert an RPI, encapsulated in a IPv6-in-IPv6 header. The IPv6-in-IPv6 header is addressed to the 6LR parent of the RUL (6LR_n).  The 6LR parent of the RUL removes the header and sends the packet to the RUL. </del> <ins> The 6LBR will encapsulate the packet in an IPv6-in-IPv6 header, and prepend an RPI.  The IPv6-in-IPv6 header is addressed to the 6LR parent of the RUL (6LR_n).  The 6LR parent of the RUL removes the header and sends the packet to the RUL. </ins> The Storing-root2notrpl summarizes what headers are needed for this use case.

Discussion:
This covers the text from the beginning up to Section 7.2.1. These were reviewed with Pascal on March 26th. I will continue my review from Section 7.2.2 forward. More trivial editorial suggestions to follow, as well.
Many thanks for these fixs.
Change:
messages send a modified value. These are not default values for the option, as defined in <del> Section 5.4.4 in RFC7252.  A default value would mean that an empty Capabilities and Settings message would result in the option being set to its default value. </del> <ins> Section 5.4.4 in RFC7252.  Default values apply on a per-message basis and thus reset when the value is not present in a given Capabilities and Settings message. </ins> Capabilities and Settings messages are indicated by the 7.01 code (CSM).

Discussion:
(1) s/between 0 and 12/& inclusive/ (2) maybe revisit the language about default values vs. origin values for CSM options:
Change:
attempting compatible version negotiation.  If both versions support authenticating Retry packets, the compatibility defition needs to define how to authenticate the Retry in the negotiated version <del> handshake even though the Retry itself was sent using the original version. </del> <ins> handshake even though the Retry itself was sent using the client's chosen version. </ins> 7.2.

Discussion:
Original version was defined as the version a client attempts prior to a VN packet. If there is a VN packet, I think that it is still possible to do a compatible upgrade from the version in the client's second attempt. In that case, "original version" isn't the right term to use when talking about compatible upgrades.
We can sidestep this particular issue by removing the "unless..." clause. That clause isn't helping because the client's chosen version MUST already be present in the compatible versions list. However, this issue raises a good point: it's possible for incompatible VN to happen and then be followed by compatible VN. We should clarify that this is allowed, and clearly define what the "original version" is in that scenario.
Consider the case where the client and server both support v1 and v2 and prefer v2. In the current draft, if the client puts v1 in the long header and the server responds with v2, that's called "compatible version negotiation". OTOH, if the client puts v2 in the long header and the server responds with v2, that's called, well, I'm not quite sure what. I guess not negotiation? I think a better way to think about this is that the client is sending an Initial that is compatible with both versions and so both of these cases are compatible version negotiation.
In the scenario where the client starts with v2 and the server responds with v2, I think of that as just "creating a v2 connection" without compatible version negotiation involved. Let's discuss this with the WG at IETF 113.
Change:
perform an excessive number of key derivations.  For example, a malicious group member could send a message with "generation = 0xffffffff" at the beginning of a new epoch, forcing recipients to <del> perform billions of key derivations. </del> <ins> perform billions of key derivations unless they apply limits of the type discussed above. </ins> 15.

Discussion:
Comment by NAME I personally don't like the underscored words in the html rendering of the document It "blank" the new American spelling of "blanc" ? I find "summarizes" a strange word here. It is not the hash contains a summary one can read. [SECG] has no IETF equivalent? Should it? proposaland -> proposal and I would say "after removing member C" (avoid ambiguity about "every third") I read this wrong the first way, the "," vanishes due to the unscores. Maybe: This section defines tree hashes, the next section defines parent hashes. Or alternatively, leave onlthe the first sentence in 8.8, then put the remainder and next section in two subsections (so 8.8.1 and 8.8.2) Maybe: For example, a malicious group member could otherwise send Maybe: to public keys whose private key was previously compromised. This reads a little odd as "new groups" would have no history and thus no previous compromise.
Filed I think it's important to emphasize the terms being defined, and this seems more readable than a definition list. Note that a hash function is often called a "message digest", in the same sense as the "Weekly github digest" that goes to the mailing list. I think referring to SECG is still pretty state-of-the-art. But apparently RFC 8446 moved on from that, so I updated to use that representation.