jiebi/CodeConvo huggingface dataset:
Change:
if the chosen transport supports using multiple paths. The connection will negotiate the use of multiple paths if the <del> chosen transport supports this.  It will actively bring up paths based on the multipath policy (multipath-policy) selected by the application, as limited by the Interface Instance and Provisioning Domain Instance properties (see prop-interface and prop-pvd). </del> <ins> chosen transport supports this. </ins> The connection will support the use of multiple paths if the <del> remote endpoint requests it.  The connection will not actively initiate the use of any new paths, but will accept paths initiated by the remote endpoint. </del> <ins> remote endpoint requests it. </ins> The policy for using multiple paths is specified using the separate "multipath-policy" property, see multipath-policy below.  To enable

Discussion:
Sorry we just merged the multipath part into the API doc but I think there is still an issue about this part: 'Active: : The connection will negotiate the use of multiple paths if the chosen transport supports this. It will actively bring up paths based on the multipath policy ({{multipath-policy}}) selected by the application, as limited by the Interface Instance and Provisioning Domain Instance properties (see {{prop-interface}} and {{prop-pvd}}). Passive: : The connection will support the use of multiple paths if the remote endpoint requests it. The connection will not actively initiate the use of any new paths, but will accept paths initiated by the remote endpoint.' This mixes two things which should be separated: requesting MP support actively (or just do it if requested by the other end) and opening of new subflows when MP support was negotiated successfully. I thought we wanted to take the later out (opening sub flows) and discuss that separately....?
Just created PR to remove the part about opening new subflows. Do we need to further discuss when/how to open subflows or do we leave this as open for now?
Agree that interim (June 19) to not address opening of subflows in the API
Change:
"OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. <ins> The following terms are used: client: The endpoint initiating the TLS connection. connection: A transport-layer connection between two endpoints. endpoint: Either the client or server of the connection. handshake: An initial negotiation between client and server that establishes the parameters of their transactions. peer: An endpoint.  When discussing a particular endpoint, "peer" refers to the endpoint that is remote to the primary subject of discussion. receiver: An endpoint that is receiving records. sender: An endpoint that is transmitting records. session: An association between a client and a server resulting from a handshake. server: The endpoint which did not initiate the TLS connection. </ins> 1.2. draft-06

Discussion:
PR for suggestion for issue .
Is this helping?
Glossaries are usually a good thing, but pretty much everything in there is either in need of pruning out or is better explained in its relevant section. The HTTP/2 spec just includes a really short glossary of basic terms up top: URL This seems like a better way to do this.
Not sure if this is the best route, but creating a PR for it was quick to do.
I'm in favor of removing the glossary. I don't think there's any need to explain what AES, DSA, etc. is in this document. Maybe it was needed when it first came out but it's not needed now. The only definition I thought might be needed is application layer/application layer protocol, but if you read s1 (right before where these terms will go) the concepts of layering on top of TLS is explained well enough in my mind. I could see adding a definition for "resumption" though.
Define resumption in-line with the text when it is first used, maybe. But I like Dave's change.
I can live with that too. Having it defined will hopefully stop these kind of things: URL
Merged.
Change:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-03 Added ciphersuites and signature schemes (*) Re-ordered fields in UserInitKey to make parsing easier (*) Fixed inconsistencies between Welcome and GroupState (*) Added encryption of the Welcome message (*) </ins> draft-02 Removed ART (*)

Discussion:
I forgot to update the changelog before I published -03. We should add that to the review criteria. This will at least fix it for -04.
Change:
been sent as a single fragment following the algorithm described in Section 4.4.3 and Section 4.4.4 of TLS13, respectively. <del> 5.8. </del> <ins> 5.9. </ins> Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake.  However, a DTLS implementation

Discussion:
NAME
s'OK wi' me. The other thing to consider mentioning is that record shadowing (key compromise at epoch N allowing the attacker to send records that cause records at epoch >N to be dropped) isn't a concern because dropping records in DTLS is trivial.
NAME thoughts?
Change:
NORM: NACK-Oriented Reliable Multicast; <del> PEP: Performance Enhanced Proxy RFC3135 - a typical PEP for </del> <ins> PEP: Performance Enhancing Proxy RFC3135 - a typical PEP for </ins> satellite communications include compression, caching and TCP acceleration;

Discussion:
ACM : Adaptative Coding and Modulation; -- Adaptive. This error repeats. CPE: Customer Premise Equipment; -- Premises. (My premise is that this is unfortunate.) FEC: Forward Erasure Correction;-- FEC is traditionally Error. Redefining industry terms to suit your network coding case won't help. FLUTE: File Delivery over Unidirectional Transport;-- just ref RFC6726. bit of a pointless inclusion imo. PEP: Performance Enhanced Proxy [RFC3135]-- the title of RFC3135 is perfectly clear that it's Enhancing and the word 'Enhanced' does not appear in that document. This is not the sort of thing WGLC is for. PLFRAME - see below. Odd to see mention of PLFRAME but not FECFRAME, which is a more direct translation of the packet data.
I have corrected the accronyms in PR We do not mention FECFRAME because it is an internal format and we focus on what is exchanged between access and physical gateways.
Change:
Normalized Paths: "$[-3]", for example, is a Singular Path, but not a Normalized Path. <ins> 3.6.1. </ins> 4. 4.1.

Discussion:
can only produce a singular result since the slice is equivalent to the index . Agreed?
In the first two examples, the Path and Normalized path are equivalent in what they identify. Not so for the third because the Path produces a plural result and thus cannot be normalized. This should probably be noted?
Change:
MessagContext on the messages received (see msg-ctx for further details). <ins> The following API calls can be used to configure a Preconnection before calling Listen(): </ins> Calling Rendezvous() on a Preconnection with an any-source multicast group address as the Remote Endpoint will join the multicast group, and also indicates that the resulting connection can be used to send

Discussion:
Fix-up multicast
Fixing the sequence of some examples vs. the text describing them, and referring to examples ("The following API calls can be used ...")
Also a great PR! :) Seriously, thanks!
Change:
Typically, a TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or <del> CA) RFC5246 RFC5280.  This organizational separation makes the TLS </del> <ins> CA) RFC8446 RFC5280.  This organizational separation makes the TLS </ins> server operator dependent on the CA for some aspects of its operations, for example:

Discussion:
The suggested OID for the DelegationUsage extension will be 1.3.6.1.4.1.44363.44.
Change:
This document uses the terminology established in the DetNet architecture RFC8655 and the the DetNet Data Plane Framework I- D.ietf-detnet-data-plane-framework.  The reader is assumed to be <del> familiar with these documents and any terminology defined therein. </del> <ins> familiar with these documents, any terminology defined therein and basic MPLS related terminologies in RFC3031. </ins> The following terminology is introduced in this document:

Discussion:
Fixing the comments received during the IESG review.
MPLS document
MPLS: All 01-27 changes updated
Done
Change:
multiplex HTTP requests over a QUIC connection.  This document defines a mechanism for multiplexing non-HTTP data with HTTP/3 in a manner that conforms with the WebTransport protocol requirements and <del> semantics OVERVIEW.  Using the mechanism described here, multiple </del> <ins> semanticsOVERVIEW.  Using the mechanism described here, multiple </ins> WebTransport instances can be multiplexed simultaneously with regular HTTP traffic on the same HTTP/3 connection.

Discussion:
Noticed we had a few oddly long lines, so I hit the rewrap button.
This was Sublime, but many others will attempt to do the same :)
What tool do you use that has a rewrap button?
Change:
using SenML need to look at the overall context of how these formats will be used to decide if the security is adequate.  In particular for sensitive sensor data and actuation use it is important to ensure <del> that proper security mechanisms are used. </del> <ins> that proper security mechanisms are used to provide, e.g., confidentiality, data integrity, and authentication as appropriate for the usage. </ins> The SenML formats defined by this specification do not contain any executable content.  However, future extensions could potentially

Discussion:
The RFC editor will add in the missing comma. Maybe use the usual sequence (confidentiality first). But all this is motherhood and apple pie anyway...
LGTM - thanks
Change:
repair lost packets (such as tail losses). For reliable transfers, including redundancy reduces goodput for <del> large file transfers but the amount of repaired symbols can be adapted, e.g. depending on the congestion window size.  There is a trade-off between the cost in capacity used to transmit source packets and the benefits brought out by transmitting repair symbols (e.g. unlocking the receive buffer if this is limiting).  The coding ratio needs to be carefully designed.  For small files, sending repair symbols when there is no more data to transmit could help to reduce the transfer time.  In general, sending repair symbols could avoid a silent period between the transmission of the last packet in the send buffer and 1) firing the retransmission of lost packets, or 2) the transmission of new packets. </del> <ins> large file transfers but the amount of repair symbols can be adapted, e.g. depending on the congestion window size.  There is a trade-off between the cost in capacity used to transmit source packets and the benefits brought out by transmitting repair symbols (e.g. unlocking the receive buffer if this is limiting).  The coding ratio needs to be carefully designed.  For small files, sending repair symbols when there is no more data to transmit could help to reduce the transfer time.  In general, sending repair symbols could avoid a silent period between the transmission of the last packet in the send buffer and 1) firing the retransmission of lost packets, or 2) the transmission of new packets. </ins> This discussion section is extended in sec:fairness.

Discussion:
Small changes, nothing urging, should be easy to merge if you are ok with it :-)
Change:
"candidate-attribute" field defined for ICE.  For example: The IceCandidate object also contains fields to indicate which m= <del> line it should be associated with.  The m= line can be identified in one of two ways; either by a m= line index, or a MID.  The m= line index is a zero-based index, with index N referring to the N+1th m= line in the SDP sent by the entity which sent the IceCandidate.  The MID uses the "media stream identification" attribute, as defined in RFC5888, Section 4, to identify the m= line.  JSEP implementations creating an ICE Candidate object MUST populate both of these fields, using the MID of the associated RtpTransceiver object (which may be locally generated by the answerer when interacting with a non-JSEP remote endpoint that does not support the MID attribute, as discussed in sec.applying-a-remote-desc below).  Implementations receiving an ICE Candidate object MUST use the MID if present, or the m= line index, if not (the non-JSEP remote endpoint case). </del> <ins> section it should be associated with.  The m= section can be identified in one of two ways; either by a m= section index, or a MID.  The m= section index is a zero-based index, with index N referring to the N+1th m= section in the SDP sent by the entity which sent the IceCandidate.  The MID uses the "media stream identification" attribute, as defined in RFC5888, Section 4, to identify the m= section.  JSEP implementations creating an ICE Candidate object MUST populate both of these fields, using the MID of the associated RtpTransceiver object (which may be locally generated by the answerer when interacting with a non-JSEP remote endpoint that does not support the MID attribute, as discussed in sec.applying-a- remote-desc below).  Implementations receiving an ICE Candidate object MUST use the MID if present, or the m= section index, if not (the non-JSEP remote endpoint case). </ins> 3.5.3.

Discussion:
S 5.2.1 says: Attributes that are common between all m= sections MAY be moved to session-level, if explicitly defined to be valid at session-level. This seems like it would be better as a should
Discussed in DC: Some concerns that things that appear at the session level have, in the past, missed by bad implementations.
Dc - decdie to change to SHOULD NOT and for things that are big, like idientiy, will put MUST
Change:
10. There are significant risks in allowing arbitrary clients to <del> establish a tunnel that permits sending to arbitrary hosts, as that could allow bad actors to send traffic and have it attributed to the IP proxy.  IP proxies SHOULD restrict its use to authenticated users. The HTTP Authorization header HTTP MAY be used to authenticate clients.  More complex authentication schemes are out of scope for this document but can be implemented using extensions. </del> <ins> establish a tunnel that permits sending to arbitrary hosts, regardless of whether tunnels are scoped to specific hosts or not. Bad actors could abuse this capability to send traffic and have it attributed to the IP proxy.  IP proxies SHOULD restrict its use to authenticated users.  Depending on the deployment, possible authentication mechanisms include mutual TLS between clients and proxies, HTTP-based authentication via the HTTP Authorization header HTTP, or even bearer tokens.  Proxies can enforce policies for authenticated users to further constrain client behavior or deal with possible abuse.  For example, proxies can rate limit individual clients that send an excessively large amount of traffic through the proxy.  As another example, proxies can restrict address (prefix) assignment to clients based on certain client attributes such as geographic location. Address assignment can have privacy implications for endpoints.  For example, if a proxy partitions its address space by the number of authenticated clients and then assigns distinct address ranges to each client, target hosts could use this information to determine when IP packets correspond to the same client.  Avoiding such tracking vectors may be important for certain proxy deployments. Proxies SHOULD avoid persistent per-client address (prefix) assignment when possible. </ins> Falsifying IP source addresses in sent traffic has been common for denial of service attacks.  Implementations of this mechanism need to

Discussion:
This adds some additional security considerations, touching on privacy considerations at the same time. Do we want to say anything about IP fragmentation, or at least point to some existing guidance around how to avoid sharp edges there? Please feel free to reframe or modify the text as you see fit!
Change:
Deprecated alias names for this type: application/x-yaml, text/ yaml, text/x-yaml <del> Magic number(s) n/a </del> <ins> Magic number(s) N/A </ins> File extension(s): yaml, yml <del> Macintosh file type code(s): n/a </del> <ins> Macintosh file type code(s): N/A </ins> See Authors' Addresses section.

Discussion:
Fix typical media type template problems Typos
In general, LGTM. About change controller, I was waiting for the feedback from the media type mailing list.
Change:
The receiving clients buffer all packets that belongs to the same frame using the frame beginning and ending marks in the generic RTP frame header extension, and once all packets are available, it passes <del> it to Frame for decryption.  SFrame maintains multiple decryptor </del> <ins> it to SFrame for decryption.  SFrame maintains multiple decryptor </ins> objects, one for each client in the call.  Initially the client might not have the mapping between the incoming streams the user's keys, in this case SFrame tries all unmapped keys until it finds one that

Discussion:
This PR revises the encryption procedures in a few ways: Ciphersuites for AES-GCM are now included The combination of AES-CM and SHA2 is spelled out, including an AAD length prefix to guard against confusion attacks We use the RFC 5116 AEAD interface (in particular, no separate auth tag) ... and as a result the tag truncation is internal to the AES-CM+SHA combination SFrame encryption now includes the encoded header as AAD Depends on
Change:
original request.  New connection attempts that involve transmitting data on the network ought not to be started after another leaf node has already successfully completed, because the connection as a whole <del> has now been established.  An implementation may choose to let certain handshakes and negotiations complete in order to gather metrics to influence future connections.  Keeping additional connections is generally not recommended since those attempts were slower to connect and may exhibit less desirable properties. </del> <ins> has now been established.  An implementation could choose to let certain handshakes and negotiations complete to gather metrics that influence future connections.  Keeping additional connections is generally not recommended, because those attempts were slower to connect and may exhibit less desirable properties. </ins> 4.4.1.

Discussion:
replace DG by CL. Changed one oddity: /as to/ to /about/
"Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite))": I think the criterion is not Datagram transports but "transports without a handshake" or "connectionless protocols" as it is used later in the document.
I wrote, and I suggest we use "connectionless protocols" explicitly mentioning examples of UDP and UDP-Lite when used as a transport without a handshake.
To whoever plans to address this: I checked occurrences of the word "datagram" in the architecture and API drafts, and I found (only) one sentence that needs fixing on similar grounds, I think, in the API draft: in Section 8.1.4 "Timeout for keep alive packets". Surely the guidance regarding this matter in the UDP usage RFC is related to the fact that UDP(-Lite) is connectionless, not that it's datagram based.
Starting to fix this.
This LGTM
Change:
(indicating whether the string is Huffman-coded), followed by the Length encoded as a 7-bit prefix integer, and finally Length bytes of data.  When Huffman encoding is enabled, the Huffman table from <del> Appendix B of RFC7541 is used without modification. </del> <ins> Appendix B of RFC7541 is used without modification and Length indicates the size of the string after encoding. </ins> This document expands the definition of string literals by permitting them to begin other than on a byte boundary.  An "N-bit prefix string <del> literal" begins with the same Huffman flag, followed by the length encoded as an (N-1)-bit prefix integer.  The prefix size, N, can have a value between 2 and 8 inclusive.  The remainder of the string literal is unmodified. </del> <ins> literal" begins mid-byte, with the first (8-N) bits allocated to a previous field.  The string uses one bit for the Huffman flag, followed by the Length encoded as an (N-1)-bit prefix integer.  The prefix size, N, can have a value between 2 and 8 inclusive.  The remainder of the string literal is unmodified. </ins> A string literal without a prefix length noted is an 8-bit prefix string literal and follows the definitions in RFC7541 without

Discussion:
Section 4.1.2: Although this is summary of the definition in HPACK, where this issue is clear I think this document should describe things corretly. HPACK defines string literals to begin on a byte boundary. They begin with a single bit flag, denoted as 'H' in this document (indicating whether the string is Huffman-coded), followed by the Length encoded as a 7-bit prefix integer, and finally Length bytes of data. When Huffman encoding is enabled, the Huffman table from Appendix B of [RFC7541] is used without modification. The length field as described here, provides an uncertainty if it is the data pre huffman (if applied) encoding or post encoding. HPACK is clear that it is the later. Can you please clarify that the length if the length of the encoded string that is encoded using N-bit prefix integer encoding. "An "N-bit prefix string literal" begins with the same Huffman flag, followed by the length encoded as an (N-1)-bit prefix integer." This definition if it is the byte or the prefix field that begins with the huffman flag. I would guess that what is meant is that a 6-bit prefix string literal would have a start byte of "??Hxxxxx" rather than "H??xxxxx".
This would be an "editorial" change.
Yes, the latter is correct. A prefixed string literal does not begin on a byte boundary; the first bit (when it begins) is the Huffman bit, and the remainder is a prefixed integer.
Change:
indexing beyond the end of an array, simply result in fewer nodes being selected. <del> Let's walk through an example in detail.  With the argument </del> <ins> Consider this example.  With the argument </ins> "{"a":[{"b":0},{"b":1},{"c":2}]}", the query "$.a[*].b" selects the following list of nodes: "0", "1" (denoted here by their value).

Discussion:
Fixes URL
In a previous issue, I suggested the idea of adding a processing model description to the specification. So was added. However, in re-reading the current document, I found that the process is repeated (albeit with less detail) in . I think that the language in 3.4 may be sufficient to explain how the path is expected to operate, making the processing model (or at least one of them) somewhat redundant. Can we combine these sections in some way instead of repeating ourselves?
I agree that we could combine these sections and avoid some repetition. I'm inclined to keep the Semantics section and do away with the Processing Model section since I think the term "Processing Model" is a little obscure compared to "Semantics".
Regardless of my question I like the change.