jiebi/CodeConvo huggingface dataset:
Code change:
RFC8859 groups SDP attributes into different categories.  To avoid unnecessary duplication when bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled "m=" sections, <del> repeating the guidance from RFC8843.  This includes "m=" sections for which bundling has been negotiated and is still desired, as well as "m=" sections marked as bundle-only. </del> <ins> repeating the guidance from I-D.ietf-mmusic-rfc8843-bis.  This includes "m=" sections for which bundling has been negotiated and is still desired, as well as "m=" sections marked as bundle-only. </ins> The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each "m=" section:

Related discussion:
text: and
To resolve WGLC comments: URL it was agreed to incorporate a reference to this text in 8843bis: URL That text ended up in s7.6.
When draft-8843bis is given an RFC number, this draft should reference the new RFC. Hi, Eventhough I would not like to make more changes than necessary, I am fine with "3PCC Considerations". However, your suggested text is very difficult to understand in some places, so let me give it a try. (The first paragraph is generic, the second SIP specific, and the third BUNDLE specific.) 3PCC Considerations In some 3PCC scenarios a new session will be established between an endpoint that is currently part of an ongoing session and an endpoint that is currently not part of an ongoing session. The endpoint that is part of a session will generate a subsequent offer that will be forwarded to the other endpoint by a 3PCC controller. The endpoint that is not part of a session will process the offer as an initial offer. The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in the associated 200 OK response. If the UAS is a part of an ongoing session, it will include a subsequent offer in the 200 OK response. The offer will be received by a 3PCC controller (UAC) and then forwarded to another User Agent (UA). If the UA is not part of an ongoing session, it will process the offer as an initial offer. When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed using different rules than subsequent BUNDLE offers, and it cannot be assumed that a UA is able to correctly process a subsequent offer as an initial offer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid initial offer, following the procedures in (Section 7.2), before it forwards the offer to a UA.
Code change:
RFC8859 groups SDP attributes into different categories.  To avoid unnecessary duplication when bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled "m=" sections, <del> repeating the guidance from RFC8843.  This includes "m=" sections for which bundling has been negotiated and is still desired, as well as "m=" sections marked as bundle-only. </del> <ins> repeating the guidance from I-D.ietf-mmusic-rfc8843-bis.  This includes "m=" sections for which bundling has been negotiated and is still desired, as well as "m=" sections marked as bundle-only. </ins> The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each "m=" section:

Related discussion:
text: In the rewritten offer the 3PCC controller will set the port value to zero (and include an SDP 'bundle-only' attribute) for each "m=" section within the BUNDLE group, excluding the offerer-tagged "m=" section. __ From: Roman Shpount Sent: Tuesday, November 2, 2021 6:33 PM To: Christer Holmberg Cc: Justin Uberti ; Justin Uberti ; RTCWeb IETF Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-URL How about we replace the SIP Considerations with: 3PCC Considerations In some 3PCC scenarios, an offer generated during an ongoing session, i.e., a subsequent offer, will be used by a 3PCC controller to establish a new session and forwarded as an initial offer to another endpoint that is currently not part of a session. For example, the Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in the associated 200 OK response. If UAS is a part of an ongoing session, it will include a subsequent offer in the 200 OK response. The offer will be received by a 3PCC controller (UAC) and then forwarded to another User Agent (UA) as an initial offer. When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed using different rules than subsequent BUNDLE offers. It cannot be assumed that a subsequent offer is a valid initial offer and that the endpoint that expects an initial offer will properly process such a subsequent offer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid initial offer before it is used to establish a new session. To make the subsequent offer a valid initial offer, 3PCC will need to modify all the non-tagged m= lines to include the bundle-only attribute and set the m= line port to zero.
Code change:
RFC8859 groups SDP attributes into different categories.  To avoid unnecessary duplication when bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled "m=" sections, <del> repeating the guidance from RFC8843.  This includes "m=" sections for which bundling has been negotiated and is still desired, as well as "m=" sections marked as bundle-only. </del> <ins> repeating the guidance from I-D.ietf-mmusic-rfc8843-bis.  This includes "m=" sections for which bundling has been negotiated and is still desired, as well as "m=" sections marked as bundle-only. </ins> The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each "m=" section:

Related discussion:
text: _ Roman Shpount Christer Holmberg > wrote: Hi, What about something like this: OLD: “The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP Offer in the associated 200 OK response. This is typically used for 3rd Party Call Control (3PCC) scenarios. >From a BUNDLE perspective, such SDP Offer SHOULD be generated using the procedures defined in Section 7.2.” NEW: “The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in the associated 200 OK response. This is typically used for 3rd Party Call Control (3PCC) scenarios. In some 3PCC scenarios the UAS will be part of an ongoing session, and will therefore include a subsequent offer in the 200 OK responses. The offer will be received by a 3PCC controller (UAC) and then forwarded as an initial offer to another User Agent (UA) that is currently not part of a session. When the BUNDLE mechanism is used, as an initial BUNDLE offer look different than a subsequent BUNDLE offer, it cannot be assumed that a UA that expects an initial offer will be able to properly process a subsequent offer.
Code change:
RFC8859 groups SDP attributes into different categories.  To avoid unnecessary duplication when bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled "m=" sections, <del> repeating the guidance from RFC8843.  This includes "m=" sections for which bundling has been negotiated and is still desired, as well as "m=" sections marked as bundle-only. </del> <ins> repeating the guidance from I-D.ietf-mmusic-rfc8843-bis.  This includes "m=" sections for which bundling has been negotiated and is still desired, as well as "m=" sections marked as bundle-only. </ins> The following attributes, which are of a category other than IDENTICAL or TRANSPORT, MUST be included in each "m=" section:

Related discussion:
text: Therefore, the 3PCC controller needs to act as a Back-To-Back User Agent (B2BUA), and when it receives the subsequent offer it needs to rewrite it into an initial offer before it is forwarded to such UA.” Regards, Christer From: Roman Shpount > Sent: tiistai 2. marraskuuta 2021 10.41 To: Justin Uberti > Cc: Christer Holmberg >; Justin Uberti >; RTCWeb IETF > Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-URL The PROBLEM is that we have two endpoints, where one sends a subsequent offer, and the other one expects an initial offer. What do you normally do when you have that kind of problem? You use an SBC/B2BUA. In this case that SBC/B2BUA would be the 3PCC controller. So, my suggestion would be to remove the SHOULD text from 8843bis, and simply add a note somewhere (in 8843bis and/or 8829bis) which describes the issue and says that the 3GPP controller needs to modify the offer accordingly. Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP anyway then maybe adding a=bundle-only isn't the end of the world. I am not opposed to this idea. 3PCC typically knows that the subsequent offer is going to be used as initial, and should be able to rewrite the offer to make it valid. We can change SIP Considerations section in 8843bis (URL), remove the SHOULD, and specify that 3PCC controller should fix the offer. We can then reference this note from 8829bis or restate the same guidance. Roman Shpount
Not seeing any objections for a month then once -02 is submitted we will progress this towards our AD. spt
Code change:
use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost Multi-Path (ECMP) routing, is applied on a per flow-basis (and not per-packet) and as such that all packets belonging to the same QUIC <del> connection get uniform treatment.  Using ECMP to distribute packets from a single flow across multiple network paths or any other non- uniform treatment of packets belong to the same connection could result in variations in order, delivery rate, and drop rate.  As feedback about loss or delay of each packet is used as input to the congestion controller, these variations could adversely affect performance. Depending on the loss recovery mechanism implemented, QUIC may be more tolerant of packet re-ordering than traditional TCP traffic (see packetnumber).  However, it cannot be known by the network which exact recovery mechanism is used and therefore reordering tolerance should be considered as unknown. </del> <ins> connection get uniform treatment. Using ECMP to distribute packets from a single flow across multiple network paths or any other non-uniform treatment of packets belong to the same connection could result in variations in order, delivery rate, and drop rate.  As feedback about loss or delay of each packet is used as input to the congestion controller, these variations could adversely affect performance.  Depending on the loss recovery mechanism implemented, QUIC may be more tolerant of packet re- ordering than traditional TCP traffic (see packetnumber).  However, the recovery mechanism used by a flow cannot be known by the network and therefore reordering tolerance should be considered as unknown. </ins> 4.9.

Related discussion:
text: It could be worth noting two general further things about DSCPs : (a) "When multiplexing multiple flows over a QUIC connection, the DSCP value selected should be the one associated with the highest priority requested for all multiplexed flows." (b) "If a packet enters a network segment that does not support the DSCP value, this could result in the connection not receiving the network treatment it expects. The DSCP value in this packet could also be remarked as the packet travels along the network path."
A sample PR: "More aspects of setting DSCPs"
Code change:
they SHOULD follow the guidance in BCP38 to help prevent denial of service attacks. <del> 8. </del> <ins> 9. </ins> <del> 8.1. </del> <ins> 9.1. </ins> This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at

Related discussion:
text: Aligning CONNECT-IP with the changes in HTTP datagrams and CONNECT-UDP.
NAME when do you plan to merge the other PRs?
NAME I plan on merging the other PRs as soon as we have WG consensus, which (assuming no objections) should happen at the end of the month (see ) Hi folks, During today's interim call, there was strong support to proceed with the output of the Design Team. This email begins a call to confirm that consensus. As a reminder, this consists of the following changes to draft-ietf-masque-h3-datagram and draft-ietf-masque-connect-udp: URL URL Please review these changes and send your comments to the list. This consensus call will conclude on February 28. Thanks, Chris and Eric
Code change:
Operational Considerations for Streaming Media <del> draft-ietf-mops-streaming-opcons-00 </del> <ins> draft-ietf-mops-streaming-opcons-01 </ins> Abstract

Related discussion:
text: This is based on the post-IETF 107 MOPS meeting where we talked about this. I chased some more references.
We should try to improve this reference - it's a long page, additions are at the top, so we have to either scroll for a long time or search for the date to get the relevant part of the page. Maybe reach out to ATT to get fragment tags that work?
Code change:
A 1-bit field representing a boolean truth value.  This field is set to "true" by an endpoint that does not wish to receive an <del> immediate acknowledgement when the peer observes reordering (reordering).  0 represents 'false' and 1 represents 'true'. </del> <ins> immediate acknowledgement when the peer receives a packet out of order (out-of-order). 0 represents 'false' and 1 represents 'true'. </ins> A 1-bit field representing a boolean truth value.  This field is set to "true" by an endpoint that does not wish to receive an immediate acknowledgement when the peer receives CE-marked packets <del> (reordering).  0 represents 'false' and 1 represents 'true'. </del> <ins> (out-of-order).  0 represents 'false' and 1 represents 'true'. </ins> ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission if an ACK_FREQUENCY frame with a larger

Related discussion:
text: NAME tell me if this is sufficient, or if you wanted more references to RFC9000.
Thanks, I'm open to other suggestions if you have them, but nothing else stuck out at me. I'm reluctant to repeat the full definition of out of order in this document, given it's well defined in RFC9000.
When reviewing the draft I got caught on this part: As specified in Section 13.2.1 of [QUIC-TRANSPORT], endpoints are expected to send an acknowledgement immediately on receiving a reordered ack-eliciting packet. This extension modifies this behavior. There is an issue here in how this draft uses "reordering". Section 13.2.1 of RFC 9000 does say that ACKs should be sent immediately if: "In order to assist loss detection at the sender, an endpoint SHOULD generate and send an ACK frame without delay when it receives an ack-eliciting packet either: when the received packet has a packet number less than another ack-eliciting packet that has been received, orwhen the packet has a packet number larger than the highest-numbered ack-eliciting packet that has been received and there are missing packets between that packet and this packet." Although the first bullet clearly is reordering, the second could be caused by three different mechanisms: Reordering of packets, loss of packets, or sender intentional gap (as discussed in ) Thus, I think this section needs to be clear if actually means both of the above bullets for when to send ACK or only one of them?
Thanks Magnus, the intent was to follow the RFC9000 definition, so I'll write a PR to clarify that was the intent.
A couple of minor edits, but lgtmOk, I think this is truly the bare minimal to resolve my issue. There exist a clearer chain back towards Section 13.2.1 in RFC9000 and I guess that is sufficient.
Code change:
fewer than 2^40 tokens are generated with a single key, the risk of collisions is lower than 0.001%. <del> 11.8. When using Dynamic SID allocation, the load balancer's SID table can be as large as 2^56 entries, which is prohibitively large.  To constrain the size of this table, servers are encouraged to accept as few SIDs as possible, so that the remainder do not enter the load balancer's table. </del> 12. There are no IANA requirements.

Related discussion:
text: and .
In light of , NAME concerns about the framework, and NAME declining interest in implementing, I think it's time to simply eliminate this from the document.
Thanks for all the hard work, but sorry to be the cause of it.
Fixed by
How does a dynamic framework survive an HA handover? It would seem to lose all the SID allocations and break all connections.
Code change:
available and unused connection IDs.  While each endpoint independently chooses how many connection IDs to issue, endpoints SHOULD provide and maintain at least eight connection IDs.  The <del> endpoint SHOULD do this by always supplying a new connection ID when a connection ID is retired by its peer or when the endpoint receives a packet with a previously unused connection ID.  Endpoints that initiate migration and require non-zero-length connection IDs SHOULD provide their peers with new connection IDs before migration, or risk the peer closing the connection. </del> <ins> endpoint SHOULD do this by supplying a new connection ID when a connection ID is retired by its peer or when the endpoint receives a packet with a previously unused connection ID.  However, it MAY limit the frequency or the total number of connection IDs issued for each connection to avoid the risk of running out of connection IDs (see reset-token). An endpoint that initiates migration and requires non-zero-length connection IDs SHOULD ensure that the pool of connection IDs available to its peer allows the peer to use a new connection ID on migration, as the peer will close the connection if the pool is exhausted. </ins> 5.1.2.

Related discussion:
text: NAME I think we should have a separate discussion around a sensible default. Part of the idea here was to make sure that we were very unlikely to run out, even around lost/retransmitted packets on different paths. Choosing a very low number brings with it other potential issues which probably should hold up this change?
NAME yes, I realised this relates to maxconnectionids.
I'm going with editorial then.
While I can see why you'd limit the frequency of issuing new connection IDs, I don't think you should limit the number of total connection IDs per connection.Unfortunately, this is a design change, and a new one. From an abundance of caution, we'll need an issue for this, and chair assessment of consensus.I'm not convinced this is a design change -- there was previously a SHOULD, and this adds additional text (including a MAY) around when you might choose to violate the SHOULD. However, no mandatory behavior is added, changed, or removed.A few nits, but this looks good to me. That said, this issue will need consensus.
Code change:
newer encryption level are available. An endpoint cannot discard keys for a given encryption level unless <del> it has both received and acknowledged all CRYPTO frames for that encryption level and when all CRYPTO frames for that encryption level have been acknowledged by its peer.  However, this does not guarantee that no further packets will need to be received or sent at that </del> <ins> it has received all the cryptographic handshake messages from its peer at that encryption level and its peer has done the same. Different methods for determining this are provided for Initial keys (discard-initial) and Handshake keys (discard-handshake).  These methods do not prevent packets from being received or sent at that </ins> encryption level because a peer might not have received all the <del> acknowledgments necessary to reach the same state. </del> <ins> acknowledgments necessary. </ins> Though an endpoint might retain older keys, new data MUST be sent at the highest currently-available encryption level.  Only ACK frames

Related discussion:
text: The three points are wordy enough it might be worth making this a bulleted list, however. Thoughts?
NAME said:
With NAME fixes, this is good.
Code change:
Issuer-Client unlinkability.  This is similar to Origin-Client unlinkability in that a Client in an issuance context is indistinguishable from any other Client that might use the same <del> issuance context.  The set of Clients that share the same redemption context is referred to as a redemption anonymity set. </del> <ins> issuance context.  The set of Clients that share the same issuance context is referred to as an issuance anonymity set. </ins> Attester-Origin unlinkability.  This is similar to Origin-Client and Issuer-Client unlinkability.  It means that given two attestation contexts, the Attester cannot determine if both contexts correspond to the same Origin or two different Origins. The set of Clients that share the same attestation context is <del> referred to as an anonymity set. </del> <ins> referred to as an attestation anonymity set. </ins> By ensuring that different contexts cannot be linked in this way, only the Client is able to correlate information that might be used

Related discussion:
text: I think that this definition is incorrect. The latest sentence is from the definition of Origin-Client unlinkability:
good catch. Copy-pasta error.
Code change:
open a connection, which begins the exchange described in handshake; <del> enable 0-RTT; and </del> <ins> enable 0-RTT when available; and </ins> be informed when 0-RTT has been accepted or rejected by a server.

Related discussion:
text: In , we say that one of the required operations on a connection is "enable 0-RTT". NAME : The current text implies that implementations are required to support 0-RTT, which is not the case. It would be more correct to say that applications must be able to prevent early data from being offered on a connection, even if the implementation supports it.
Alternately, the server section prefaces certain bullets with "If Early Data is supported, ...." That formulation might be used here as well. Also, this section uses "0-RTT" in the client piece but "Early Data" in the server piece. Should be consistent.
Code change:
attempted against.  An empty redemption is returned when the limit has been hit: <ins> 5.4. A consequence of limiting the number of participants (Attesters or Issuers) in Privacy Pass deployments for meaningful privacy is that it forces concentrated centralization amongst those participants. CENTRALIZATION discusses several ways in which this might be mitigated.  For example, a multi-stakeholder governance model could be established to determine what participants are fit to operate as participants in a Privacy Pass deployment.  This is precisely the model used to control the Web's trust model. Alternatively, Privacy Pass deployments might mitigate this problem through implementation.  For example, rather than centralize the role of attestation in one or few entities, attestation could be a distributed function performed by a quorum of many parties, provided that neither Issuers nor Origins learn which attester implementations were chosen.  As a result, clients could have more opportunities to switch between attestation participants. </ins> 6. We present a number of security considerations that prevent malicious

Related discussion:
text: cc NAME
There should be documentation that addresses the risks of the centralization in the current Privacy Pass architecture with potential solutions. This was raised in the previous WG meeting: URL This documentation should either be incorporated into the architecture document as a section when discussing the shape of the ecosystem, and/or security considerations. There is also the option of declaring a separate document for addressing this.
A draft has been put forward for this by Mark McFadden: URL, and will be discussed at IETF 110. Will leave this open for now, until this draft (or some form of it) is accepted.