jiebi/CodeConvo huggingface dataset:
Code change:
LGTM and if Justin wants to tie in the stuff from my comment a bit more that is great
NAME PTAL
seems like it's generally right,LGTM

Related discussion:
text: local answers, "recvonly" for remote answers, or "sendrecv" for either type of answer), choose the media format to send as the most preferred media format from the remote description that is <del> also present in the answer, as described in RFC3264, Sections 6.1 and 7, and start transmitting RTP media once the underlying transport layers have been established.  If an SSRC has not already been chosen for this outgoing RTP stream, choose a random one.  If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as </del> <ins> also locally supported, as discussed in RFC3264, Sections 6.1 and 7, and start transmitting RTP media using that format once the underlying transport layers have been established.  If an SSRC has not already been chosen for this outgoing RTP stream, choose a random one.  If media is already being transmitted, the same SSRC SHOULD be used unless the clockrate of the new codec is different, in which case a new SSRC MUST be chosen, as </ins> specified in RFC7160, Section 3.1. The payload type mapping from the remote description is used to
Code change:
I agree with justin here. my bad for missing that.
The 4th bullet on page 64 is ambiguous at "this m= section". It looks like this bullet should just be merged with the previous bullet.
I'm not sure what the problem is here, but I'm not against merging it. NAME
The bullet point in question is the one that reads If this m= section was present in the previous answer then the state of RTP/RTCP multiplexing MUST match what was previously negotiated.
LGTM

Related discussion:
text: If the RTP/RTCP multiplexing policy is "require", each m= section MUST contain an "a=rtcp-mux" attribute.  If an m= section contains <del> an "a=rtcp-mux-only" attribute then that section MUST also contain an "a=rtcp-mux" attribute. </del> <ins> an "a=rtcp-mux-only" attribute, that section MUST also contain an "a=rtcp-mux" attribute. </ins> <del> If this m= section was present in the previous answer then the state of RTP/RTCP multiplexing MUST match what was previously negotiated. </del> <ins> If an m= section was present in the previous answer, the state of RTP/RTCP multiplexing MUST match what was previously negotiated. </ins> If this session description is of type "pranswer" or "answer", the following additional checks are applied:
Code change:
This is in response to a post NAME made on .
Thanks for the PR! So as an interoperability standard, if the retry service encodes "4000", what does the server do with that? Do we need to add a config parameter for the time_t that serves as time 0?
Timestamps should be absolute, not relative, in which case I'm not sure you need a 0. There's nothing special about midnight 1 January 1970.
Ah, so you're just suggesting declaring a later date to begin the epoch? Makes sense
Why do we need to have a sential time? If it's a precision vs. range issue then shifting the epoch makes sense.
Sorry, I don't know what "sential time" is. What are you proposing?
What I'm proposing is that we not treat any times differently. It's not clear to me why 4000 needed special treatment.
4000 is just an example. The intent of using the epoch was to have common agreement on when tokens expire without any QUIC-LB-specific coordination. The current draft uses 1970 as a timebase, which absolutely makes integers longer than it needs to be. IIUC the PR doesn't have any baseline so it's unclear how the server and retry service are supposed to interpret each other's expiration times. As we're probably speaking past each other: what, precisely, does the integer in this field indicate?
It's the end of the validity period for the token in some convenient timebase.
Alright, we agree on that. So this PR is being a little less precise on synchronization, which is fine, but isn't addressing the fact that we're counting from 1970. Fair enough. Dear QUIC WG, First a moment of unforgivable pedantry. Universal time is unfortunately not the right name for UTC, which is slightly different. It could also mean UT1 or some other variations It's also not clear what the future of computer timekeeping is and I know several places don't synchronize to UTC internally. I think the best way to handle this is to say something like "synchronized" and leave open as to exactly how that is done. I agree with the comments that there are too many options and should be fewer. Other then that I didn't see any problems but I'm probably too sleepy right now to spot them. Sincerely, Watson Ladd Astra mortemque praestare gradatim

Related discussion:
text: packets in response to Initial packets that don't include a valid token. <del> Both server and service must have access to Universal time, though tight synchronization is unnecessary. </del> <ins> Both server and service must have time synchronized with respect to one another to prevent tokens being incorrectly marked as expired, though tight synchronization is unnecessary. </ins> The tokens are protected using AES128-GCM AEAD, as explained in token-protection-with-aead.  All tokens, generated by either the
Code change:
Definitely an edge case, but the LB will spray stateless resets everywhere because the CID is random. If the LB tracks fourtuples, though, it shouldn't be a problem.
Maybe make this part of a thing about stateless LBs.
So, what's the plan ?
NAME raises an interesting point about stateless LBs in .

Related discussion:
text: 6. <del> For protocols where 4-tuple load balancing is sufficient, it is straightforward to deliver ICMP packets from the network to the correct server, by reading the echoed IP and transport-layer headers to obtain the 4-tuple.  When routing is based on connection ID, further measures are required, as most QUIC packets that trigger ICMP responses will only contain a client-generated connection ID that contains no routing information. To solve this problem, load balancers MAY maintain a mapping of Client IP and port to server ID based on recently observed packets. Alternatively, servers MAY implement the technique described in Section 14.4.1 of RFC9000 to increase the likelihood a Source Connection ID is included in ICMP responses to Path Maximum Transmission Unit (PMTU) probes.  Load balancers MAY parse the echoed packet to extract the Source Connection ID, if it contains a QUIC long header, and extract the Server ID as if it were in a Destination CID. </del> <ins> QUIC-LB requires no per-connection state at the load balancer.  The load balancer can extract the server ID from the connection ID of each incoming packet and route that packet accordingly. However, once the routing decision has been made, the load balancer MAY associate the 4-tuple with the decision.  This has two advantages: The load balancer only extracts the server ID once per incoming 4-tuple.  When the CID is encrypted, this substantially reduces computational load. Incoming Stateless Reset packets and ICMP messages are easily routed to the correct origin server. In addition to the increased state requirements, however, load balancers cannot detect the CONNECTION_CLOSE frame to indicate the end of the connection, so they rely on a timeout to delete connection state.  There are numerous considerations around setting such a timeout. In the event a connection ends, freeing an IP and port, and a different connection migrates to that IP and port before the timeout, the load balancer will misroute the different connection's packets to the original server.  A short timeout limits the likelihood of such a misrouting. Furthermore, if a short timeout causes premature deletion of state, the routing is easily recoverable by decoding an incoming Connection ID.  However, a short timeout also reduces the chance that an incoming Stateless Reset is correctly routed. Servers MAY implement the technique described in Section 14.4.1 of RFC9000 in case the load balancer is stateless, to increase the likelihood a Source Connection ID is included in ICMP responses to Path Maximum Transmission Unit (PMTU) probes.  Load balancers MAY parse the echoed packet to extract the Source Connection ID, if it contains a QUIC long header, and extract the Server ID as if it were in a Destination CID. </ins> 7.
Code change:
After thinking it through, various XOR schemes were extremely vulnerable to manipulation, so I went with a brute force approach.
The server now needs to include this field. For the no-shared state service, we just need language that the Retry service needs to encode enough information validate the packet DCID as well and drop if it fails validation. If it does, the server MUST use the packet DCID in the retrysourceconnection_id TP. For the shared state service, the retry source connection ID is going to have to be in the token. We might be able to compress this by xoring some fields; I'll think about it.

Related discussion:
text: verification) or make sure there is common context for the server to verify the address using a service-generated token. <ins> The service must also communicate the source connection ID of the Retry packet to the server so that it can include it in a transport parameter for client verification. </ins> There are two different mechanisms to allow offload of DoS mitigation to a trusted network service.  One requires no shared state; the server need only be configured to trust a retry service, though this
Code change:
After thinking it through, various XOR schemes were extremely vulnerable to manipulation, so I went with a brute force approach.
The server now needs to include this field. For the no-shared state service, we just need language that the Retry service needs to encode enough information validate the packet DCID as well and drop if it fails validation. If it does, the server MUST use the packet DCID in the retrysourceconnection_id TP. For the shared state service, the retry source connection ID is going to have to be in the token. We might be able to compress this by xoring some fields; I'll think about it.

Related discussion:
text: triggering Initial packet.  This is in cleartext to be readable for the server, but authenticated later in the token. <ins> RSCIL: The retry source connection ID length. </ins> Original Destination Connection ID: This also in cleartext and authenticated later. <ins> Retry Source Connection ID: This also in cleartext and authenticated later. </ins> Opaque Data: This data MUST contain encrypted information that allows the retry service to validate the client's IP address, in accordance <del> with the QUIC specification.  It MUST also encode a secure hash of the original destination connection ID field to verify that this field has not been edited. </del> <ins> with the QUIC specification.  It MUST also provide a cryptographically secure means to validate the integrity of the entire token. </ins> Upon receipt of an Initial packet with a token that begins with '0', the retry service MUST validate the token in accordance with the QUIC <del> specification.  It must also verify that the secure hash of the Connect ID is correct.  If incorrect, the token is invalid. </del> <ins> specification. </ins> In active mode, the service MUST issue Retry packets for all Client initial packets that contain no token, or a token that has the first bit set to '1'.  It MUST NOT forward the packet to the server.  The service MUST validate all tokens with the first bit set to '0'.  If successful, the service MUST forward the packet with the token <del> intact.  If unsuccessful, it MUST drop the packet. </del> <ins> intact.  If unsuccessful, it MUST drop the packet.  The Retry Service MAY send an Initial Packet containing a CONNECTION_CLOSE frame with the INVALID_TOKEN error code when dropping the packet. </ins> Note that this scheme has a performance drawback.  When the retry service is in active mode, clients with a token from a NEW_TOKEN
Code change:
After thinking it through, various XOR schemes were extremely vulnerable to manipulation, so I went with a brute force approach.
The server now needs to include this field. For the no-shared state service, we just need language that the Retry service needs to encode enough information validate the packet DCID as well and drop if it fails validation. If it does, the server MUST use the packet DCID in the retrysourceconnection_id TP. For the shared state service, the retry source connection ID is going to have to be in the token. We might be able to compress this by xoring some fields; I'll think about it.

Related discussion:
text: receives an Initial Packet with the first bit to '0', it is a Retry token and the server MUST NOT attempt to validate it.  Instead, it MUST assume the address is validated and MUST extract the Original <del> Destination Connection ID, assuming the format described in nss- service-requirements. </del> <ins> Destination Connection ID and Retry Source Connection ID, assuming the format described in nss-service-requirements. </ins> 6.3.
Code change:
After thinking it through, various XOR schemes were extremely vulnerable to manipulation, so I went with a brute force approach.
The server now needs to include this field. For the no-shared state service, we just need language that the Retry service needs to encode enough information validate the packet DCID as well and drop if it fails validation. If it does, the server MUST use the packet DCID in the retrysourceconnection_id TP. For the shared state service, the retry source connection ID is going to have to be in the token. We might be able to compress this by xoring some fields; I'll think about it.

Related discussion:
text: ODCIL: The original destination connection ID length.  Tokens in NEW_TOKEN frames MUST set this field to zero. <del> Original Destination Connection ID: This is copied from the field in the client Initial packet. </del> <ins> RSCIL: The retry source connection ID length.  Tokens in NEW_TOKEN frames MUST set this field to zero. Original Destination Connection ID: The server or Retry Service copies this from the field in the client Initial packet. Retry Source Connection ID: The server or Retry service copies this from the Source Connection ID of the Retry packet. </ins> Client IP Address: The source IP address from the triggering Initial packet.  The client IP address is 16 octets.  If an IPv4 address, the
Code change:
After thinking it through, various XOR schemes were extremely vulnerable to manipulation, so I went with a brute force approach.
The server now needs to include this field. For the no-shared state service, we just need language that the Retry service needs to encode enough information validate the packet DCID as well and drop if it fails validation. If it does, the server MUST use the packet DCID in the retrysourceconnection_id TP. For the shared state service, the retry source connection ID is going to have to be in the token. We might be able to compress this by xoring some fields; I'll think about it.

Related discussion:
text: retry tokens marked as being a few seconds in the future, due to possible clock synchronization issues. <del> A server MUST NOT send a Retry packet in response to an Initial packet that contains a retry token. </del> <ins> After decrypting the token, the server uses the corresponding fields to populate the original_destination_connection_id transport parameter, with a length equal to ODCIL, and the retry_source_connection_id transport parameter, with length equal to RSCIL. As discussed in QUIC-TRANSPORT, a server MUST NOT send a Retry packet in response to an Initial packet that contains a retry token. </ins> 7.
Code change:
I will probably delete the Stream Cipher algorithm entirely, but consider this an intermediate step.
Merging to enable the next round of edits

Related discussion:
text: 4.4.2. <del> Upon receipt of a QUIC packet that is not of type Initial or 0-RTT, the load balancer extracts as many of the earliest octets from the destination connection ID as necessary to match the nonce length. The server ID immediately follows. </del> <ins> Upon receipt of a QUIC packet, the load balancer extracts as many of the earliest octets from the destination connection ID as necessary to match the nonce length.  The server ID immediately follows. </ins> The load balancer decrypts the nonce and the server ID using the following three pass algorithm:
Code change:
I will probably delete the Stream Cipher algorithm entirely, but consider this an intermediate step.
Merging to enable the next round of edits

Related discussion:
text: encrypted-nonce) Pass 2: The load balancer decrypts the nonce octets using 128-bit <del> AES Electronic Codebook (ECB) mode, much like QUIC header protection, using the server-id intermediate as "nonce" for this </del> <ins> AES ECB mode, using the server-id intermediate as "nonce" for this </ins> pass.  The server-id intermediate octets are zero-padded to 16 octets.  AES-ECB encrypts this padded server-id intermediate using its key to generate a mask which it applies to the encrypted
Code change:
I will probably delete the Stream Cipher algorithm entirely, but consider this an intermediate step.
Merging to enable the next round of edits

Related discussion:
text: nonce = encrypted_nonce ^ AES-ECB(key, padded-server_id_intermediate) Pass 3: The load balancer decrypts the server ID using 128-bit AES <del> Electronic Codebook (ECB) mode, much like QUIC header protection. The nonce octets are zero-padded to 16 octets.  AES-ECB encrypts this nonce using its key to generate a mask which it applies to the intermediate server id.  This provides the dercypted server ID. </del> <ins> ECB mode.  The nonce octets are zero-padded to 16 octets.  AES-ECB encrypts this nonce using its key to generate a mask which it applies to the intermediate server id.  This provides the decrypted server ID. </ins> server_id = server_id_intermediate ^ AES-ECB(key, padded-nonce) <del> This three pass algorithm is a simplified version of the FFX </del> <ins> This three-pass algorithm is a simplified version of the FFX </ins> algorithm.  It has the same connection ID length requirements as the Stream Cipher CID Algorithm, with the additional property that each encrypted nonce value depends on all server ID bits, and each
Code change:
I will probably delete the Stream Cipher algorithm entirely, but consider this an intermediate step.
Merging to enable the next round of edits

Related discussion:
text: When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the server ID octets.  Servers MAY opt to have a longer connection ID <del> beyond the nonce and server ID.  The nonce and additional bits MAY encode additional information, but SHOULD appear essentially random to observers. </del> <ins> beyond the nonce and server ID.  The additional bits MAY encode additional information, but SHOULD appear essentially random to observers. If the decrypted nonce bits increase monotonically, that guarantees that nonces are not reused between connection IDs from the same server. </ins> The server encrypts the server ID using exactly the algorithm as described in triple-stream-cipher-load-balancer-actions, performing
Code change:
by popular demand in .
As discussed at IETF 108. Split from .
Thanks for filing this. I agree that this was the feedback, but I'll take it from the list to be sure.
Removing this seems fine to me.
Yes, do it.
Seems fine.
Do it.
Do it.
Nick Harper concurred on the list
Yes, that works. Minor comment.

Related discussion:
text: MUST be at least 8 octets and no more than 16 octets.  The nonce length and server ID length MUST sum to 19 or fewer octets. <del> 4.3.2. </del> <ins> 4.2.2. </ins> Upon receipt of a QUIC packet, the load balancer extracts as many of the earliest octets from the destination connection ID as necessary
Code change:
by popular demand in .
As discussed at IETF 108. Split from .
Thanks for filing this. I agree that this was the feedback, but I'll take it from the list to be sure.
Removing this seems fine to me.
Yes, do it.
Seems fine.
Do it.
Do it.
Nick Harper concurred on the list
Yes, that works. Minor comment.

Related discussion:
text: The output of the decryption is the server ID that the load balancer uses for routing. <del> 4.3.3. </del> <ins> 4.2.3. </ins> When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the
Code change:
by popular demand in .
As discussed at IETF 108. Split from .
Thanks for filing this. I agree that this was the feedback, but I'll take it from the list to be sure.
Removing this seems fine to me.
Yes, do it.
Seems fine.
Do it.
Do it.
Nick Harper concurred on the list
Yes, that works. Minor comment.

Related discussion:
text: described in stream-cipher-load-balancer-actions, performing the three passes in reverse order. <del> 4.4. </del> <ins> 4.3. </ins> The Block Cipher CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, provides higher cryptographic
Code change:
by popular demand in .
As discussed at IETF 108. Split from .
Thanks for filing this. I agree that this was the feedback, but I'll take it from the list to be sure.
Removing this seems fine to me.
Yes, do it.
Seems fine.
Do it.
Do it.
Nick Harper concurred on the list
Yes, that works. Minor comment.

Related discussion:
text: it also requires connection IDs of at least 17 octets, increasing overhead of client-to-server packets. <del> 4.4.1. </del> <ins> 4.3.1. </ins> The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently
Code change:
by popular demand in .
As discussed at IETF 108. Split from .
Thanks for filing this. I agree that this was the feedback, but I'll take it from the list to be sure.
Removing this seems fine to me.
Yes, do it.
Seems fine.
Do it.
Do it.
Nick Harper concurred on the list
Yes, that works. Minor comment.

Related discussion:
text: The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption. <del> 4.4.2. </del> <ins> 4.3.2. </ins> Upon receipt of a QUIC packet, the load balancer reads the first octet to obtain the config rotation bits.  It then decrypts the
Code change:
by popular demand in .
As discussed at IETF 108. Split from .
Thanks for filing this. I agree that this was the feedback, but I'll take it from the list to be sure.
Removing this seems fine to me.
Yes, do it.
Seems fine.
Do it.
Do it.
Nick Harper concurred on the list
Yes, that works. Minor comment.

Related discussion:
text: in that order.  The load balancer uses the server ID octets for routing. <del> 4.4.3. </del> <ins> 4.3.3. </ins> When generating a routable connection ID, the server MUST choose a connection ID length between 17 and 20 octets.  The server writes its
Code change:
by popular demand in .
As discussed at IETF 108. Split from .
Thanks for filing this. I agree that this was the feedback, but I'll take it from the list to be sure.
Removing this seems fine to me.
Yes, do it.
Seems fine.
Do it.
Do it.
Nick Harper concurred on the list
Yes, that works. Minor comment.

Related discussion:
text: routing bytes.  The Server ID is unique to each server, and the routing bytes are global. <del> For Obfuscated CID Routing, this consists of the Routing Bits, Divisor, and Modulus.  The Modulus is unique to each server, but the others MUST be global. </del> For Stream Cipher CID Routing, this consists of the Server ID, Server ID Length, Key, and Nonce Length.  The Server ID is unique to each server, but the others MUST be global.  The authentication token MUST