jiebi/CodeConvo huggingface dataset:
If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to "application" and the <proto> and "fmt" fields MUST be set to exactly <del> match the fields in the offer. </del> <ins> match the fields in the offer.  Note that if media m= sections are bundled into a data m= section, then certain TRANSPORT and IDENTICAL attributes may appear in the data m= section even if they would otherwise only be appropriate for a media m= section (e.g., "a=rtcp- mux"). </ins> Within the data m= section, an "a=mid" line MUST be generated and included as described above, along with an "a=sctp-port" line
excluded by subsequent calls to createOffer and createAnswer, in which case the corresponding media formats in the associated m= section will be excluded.  The codec preferences cannot add media <del> formats that would otherwise not be present.  This includes codecs that were not negotiated in a previous offer/answer exchange that included the transceiver. </del> <ins> formats that would otherwise not be present. </ins> The codec preferences of an RtpTransceiver can also determine the order of codecs in subsequent calls to createOffer and createAnswer,
For each offered m= section, if any of the following conditions are true, the corresponding m= section in the answer MUST be marked as rejected by setting the port in the m= line to zero, as indicated in <del> RFC3264, Section 6., and further processing for this m= section can be skipped: </del> <ins> RFC3264, Section 6, and further processing for this m= section can be skipped: </ins> The associated RtpTransceiver has been stopped. <del> No supported codec is present in the offer. </del> <ins> None of the offered media formats are supported and, if applicable, allowed by codec preferences. </ins> The bundle policy is "max-bundle", and this is not the first m= section or in the same bundle group as the first m= section.
for the corresponding m= line in the offer. If codec preferences have been set for the associated transceiver, <del> media formats MUST be generated in the corresponding order, and MUST exclude any codecs not present in the codec preferences or not present in the offer.  Note that non-JSEP endpoints are not subject to this restriction, and might add media formats in the answer that are not present in the offer, as specified in RFC3264, Section 6.1.  Therefore, JSEP implementations MUST be prepared to receive such answers. Unless excluded by the above restrictions, the media formats MUST include the mandatory audio/video codecs as specified in RFC7874, Section 3, and RFC7742, Section 5. </del> <ins> media formats MUST be generated in the corresponding order, regardless of what was offered, and MUST exclude any codecs not present in the codec preferences. Otherwise, the media formats on the m= line MUST be generated in the same order as those offered in the current remote description, excluding any currently unsupported formats.  Any currently available media formats that are not present in the current remote description MUST be added after all existing formats. In either case, the media formats in the answer MUST include at least one format that is present in the offer, but MAY include formats that are locally supported but not present in the offer, as mentioned in RFC3264, Section 6.1.  If no common format exists, the m= section is rejected as described above. </ins> The m= line MUST be followed immediately by a "c=" line, as specified in RFC4566, Section 5.7.  Again, as no candidates are available yet,
must instead match what was supplied in the offer, as described above. <del> Unless codec preferences have been set for the associated transceiver, the media formats on the m= line MUST be generated in the same order as in the current local description. </del> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the m= section is restarting, in which case new ICE credentials must be created as specified in RFC5245, Section 9.2.1.1.  If the
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
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:
If present, "a=msid" attributes MUST be parsed as specified in I- D.ietf-mmusic-msid, Section 3.2, and their values stored, ignoring <del> any "appdata" field. </del> <ins> any "appdata" field.  If no "a=msid" attributes are present, a random msid-id value is generated for a "default" MediaStream for the session, if not already present, and this value is stored. </ins> Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.
The setConfiguration method allows the global configuration of the PeerConnection, which was initially set by constructor parameters, to <del> be changed during the session.  The effects of this method call </del> <ins> be changed during the session.  The effects of calling this method </ins> depend on when it is invoked, and they will differ, depending on which specific parameters are changed: <del> This call may result in a change to the state of the ICE agent. </del> <ins> Calling this method may result in a change to the state of the ICE agent. </ins> 4.1.17.
4.2.2. The stopped property indicates whether the transceiver has been <del> stopped, either by a call to stopTransceiver or by applying an answer that rejects the associated "m=" section.  In either of these cases, it is set to "true" and otherwise will be set to "false". </del> <ins> stopped, either by a call to stop or by applying an answer that rejects the associated "m=" section.  In either of these cases, it is set to "true" and otherwise will be set to "false". </ins> A stopped RtpTransceiver does not send any outgoing RTP or RTCP or process any incoming RTP or RTCP.  It cannot be restarted.
The currentDirection property indicates the last negotiated direction for the transceiver's associated "m=" section.  More specifically, it <del> indicates the directional attribute RFC3264 of the associated "m=" </del> <ins> indicates the direction attribute RFC3264 of the associated "m=" </ins> section in the last applied answer (including provisional answers), with "send" and "recv" directions reversed if it was a remote answer. <del> For example, if the directional attribute for the associated "m=" </del> <ins> For example, if the direction attribute for the associated "m=" </ins> section in a remote answer is "recvonly", currentDirection is set to "sendonly".
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
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.
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
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
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.
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
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.
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:
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
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
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
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
map to the same server.  It could then apply analytical techniques to try to obtain the server encoding. <del> The Stream and Block Cipher CID algorithms provide robust entropy to making any sort of linkage.  The Obfuscated CID obscures the mapping and prevents trivial brute-force attacks to determine the routing parameters, but does not provide robust protection against sophisticated attacks. </del> <ins> The Stream and Block Cipher CID algorithms provide robust protection against any sort of linkage.  The Plaintext CID algorithm makes no attempt to protect this encoding. </ins> Were this analysis to obtain the server encoding, then on-path observers might apply this analysis to correlating different client
To avoid this, the configuration agent SHOULD issue QUIC-LB configurations to mutually distrustful servers that have different <del> keys (for the block cipher or stream cipher algorithms) or routing masks and divisors (for the obfuscated algorithm).  The load balancers can distinguish these configurations by external IP address, or by assigning different values to the config rotation bits (config-rotation).  Note that either solution has a privay impact; see multiple-configs. </del> <ins> keys for encryption algorithms.  The load balancers can distinguish these configurations by external IP address, or by assigning different values to the config rotation bits (config-rotation).  Note that either solution has a privacy impact; see multiple-configs. </ins> These techniques are not necessary for the plaintext algorithm, as it does not attempt to conceal the server ID.
6.3.2.1. This sub-tree defines the L2VPN service type, according to the <del> several signalling options to exchange membership information between </del> <ins> several signaling options to exchange membership information between </ins> PEs of an L2VPN.  The following signaling options are supported: <del> Refers to the BGP control plane as described in RFC4761 and RFC6624. Refers to the BGP control plane as described in RFC7432 and RFC7209. </del> <ins> The service is a Multipoint VPLSs that use a BGP control plane as described in RFC4761 and RFC6624.  For this L2VPN service, the model allows configuring the Route Distinguisher, the Route Targets, the PWE encapsulation type and the MTU configurations to allow MTU mismatch. The service is a Multipoint VPLSs that use also a BGP control plane but also includes the additional features and related parameters RFC7432 and RFC7209.  The model allows the configuration of the EVPN service interface type, the local and remote VPWS Service Instance (VSI) RFC8214, the EVPN policies for handling MAC addresses and the Ethernet Segment Identifier (ESI) information. </ins> <del> Refers to LDP-signaled pseudowires RFC6074. </del> <ins> A Multipoint VPLSs that use a mesh of LDP-signaled Pseudowires RFC6074.  The model allows configuring the T-LDP PWE type, MTU mismatch and the list of AC and PW bindings. </ins> <del> Refers to L2TP-signaled pseudowires RFC6074. </del> <ins> The L2 VPN uses L2TP-signaled Pseudowires as described in RFC6074. The model allows configuring TBC. </ins> 6.3.2.2.
explanation for the overall connection rate drop is that hairpinning failed in some cases. <del> One potential mitigation, as discussed in privacy, is to not conceal candidates created from RFC4941 IPv6 addresses.  This permits connectivity even in large internal networks or where mDNS is disabled.  Future versions of this document will include experimental data regarding this option. </del> 5.2. As noted in description, ICE agents using the mDNS technique are
This document uses the Augmented BNF defined in RFC5234 and updated by RFC7405. <del> 1.2. The OpenAPI Specification Media Types convey OpenAPI Specification (OAS) files as defined in oas for version 3.0.0 and above. Those files can be serialized in JSON or yaml.  Since there are multiple OpenAPI Specification Specifications versions, those media- types support the "version" parameter. The following examples conveys the desire of a client to receive an OpenAPI Specification resource preferably in the following order: openapi 3.1 in yaml openapi 3.0 in yaml any openapi version in json </del> 2. <del> Security requirements for both media type and media type suffix registrations are discussed in Section 4.6 of MEDIATYPE. </del> <ins> This section describes the information required to register the above media types. </ins> <del> 3. </del> <ins> 2.1. </ins> <del> This specification defines the following new Internet media types MEDIATYPE. 3.1. </del> <ins> The following information serves as the registration form for the "application/yaml" media type. </ins> Type name: application
Change controller: n/a <del> 3.2. </del> <ins> 2.2. The OpenAPI Specification Media Types convey OpenAPI document (OAS) files as defined in oas for version 3.0.0 and above. Those files can be serialized in JSON or yaml.  Since there are multiple OpenAPI Specification versions, those media-types support the "version" parameter. The following examples conveys the desire of a client to receive an OpenAPI Specification resource preferably in the following order: openapi 3.1 in yaml openapi 3.0 in yaml any openapi version in json 2.2.1. The following information serves as the registration form for the "application/openapi+json" media type. </ins> Type name: application