jiebi/CodeConvo huggingface dataset:
Change:
Any profile in the offer matching one of the following MUST be accepted: <del> "RTP/AVP" </del> <ins> "RTP/AVP" (Defined in RFC4566, Section 8.2.2) </ins> <del> "RTP/AVPF" </del> <ins> "RTP/AVPF" (Defined in RFC4585, Section 9) </ins> <del> "RTP/SAVP" </del> <ins> "RTP/SAVP" (Defined in RFC3711, Section 12) </ins> <del> "RTP/SAVPF" </del> <ins> "RTP/SAVPF" (Defined in RFC5124, Section 6) </ins> <del> "UDP/TLS/RTP/AVP" </del> <ins> "TCP/DTLS/RTP/SAVP" (Defined in RFC7850, Section 3.4) </ins> <del> "UDP/TLS/RTP/AVPF" </del> <ins> "TCP/DTLS/RTP/SAVPF" (Defined in RFC7850, Section 3.5) </ins> <del> "UDP/TLS/RTP/SAVP" </del> <ins> "UDP/TLS/RTP/SAVP" (Defined in RFC5764, Section 9) </ins> <del> "UDP/TLS/RTP/SAVPF" "TCP/TLS/RTP/SAVP" "TCP/TLS/RTP/SAVPF" </del> <ins> "UDP/TLS/RTP/SAVPF" (Defined in RFC5764, Section 9) </ins> The profile in any "m=" line in any generated answer MUST exactly match the profile provided in the offer.

Discussion:
The only draft or RFC that uses "UDP/TLS/RTP/AVP" is one typo in URL I just reported an RFC Errata on that. I think the argument here is anyone who was advertising TLS in the label, also put the S in the SAVP so we don't need to worry about any of the cases where we have TLS. The case with TCP it is a bit different. You can take RTP (not SRTP) and send it as unencrypted RTP over a normal TLS (not DTLS-SRTP) tunnel so for that case the label is TCP/TLS/RTP/AVPF. However, this is RTP over 4571 framing so treating it as SRTP is going to not work. Because of this, I think we need to remove all the options from this list that are RTP (not SRTP) framed over 4571. That means remove from the list "TCP/RTP/AVP", "TCP/RTP/AVPF" , "TCP/TLS/RTP/AVP" , "TCP/TLS/RTP/AVPF". For "TCP/RTP/SAVP" and "TCP/RTP/SAVPF", this is SRTP with 4571 framing over TCP ( See URL ). Since this is not DTLS-SRTP, it seems we should also remove theses two labels as well. So what I am proposing is we move the list to be just "RTP/AVP" "RTP/AVPF" "RTP/SAVP" "RTP/SAVPF" "TCP/DTLS/RTP/SAVP" "TCP/DTLS/RTP/SAVPF" "UDP/TLS/RTP/SAVP" "UDP/TLS/RTP/SAVPF" Backing up to first principals on this, the problem we are tying to solve is an offer that is offering RTP or DTLS-SRTP. It is going to have RTP/AVP[F] and a fingerprint so it seems as long as we have that on the list it is good. Of some one, RTP/SAVP is defined in URL(and the RTP/SAVFP version in URL) while the UDP/TLS/RTP/SAVP[F] is in URL )
I added the refs for where these are defined. If that look OK, I think this is ready to merge.

table is at URL
So when I take that table and do grep AVP grep -v MBMS I get RTP/AVP RTP/AVPF RTP/SAVP RTP/SAVPF TCP/DTLS/RTP/SAVP TCP/DTLS/RTP/SAVPF TCP/RTP/AVP TCP/RTP/AVPF TCP/RTP/SAVP TCP/RTP/SAVPF TCP/TLS/RTP/AVP TCP/TLS/RTP/AVPF UDP/TLS/RTP/SAVP UDP/TLS/RTP/SAVPF The diff from what we have now is < TCP/DTLS/RTP/SAVP < TCP/DTLS/RTP/SAVPF < TCP/RTP/AVP < TCP/RTP/AVPF < TCP/RTP/SAVP < TCP/RTP/SAVPF < TCP/TLS/RTP/AVP < TCP/TLS/RTP/AVPF
NAME be sure to check the references for the profiles.
Change:
server MUST reject the request as unauthorized. Except for the directory resource, all ACME resources are addressed <del> with URLs provided to the client by the server.  In such cases, the client MUST set the "url" field to the exact string provided by the server (rather than performing any re-encoding on the URL). </del> <ins> with URLs provided to the client by the server.  For these resources, the client MUST set the "url" field to the exact string provided by the server (rather than performing any re-encoding on the URL).  The server SHOULD perform the corresponding string equality check, configuring each resource with the URL string provided to clients and having the resource check that requests have the same string in their "url" fields. </ins> 5.3.1.

Discussion:
As discussed at IETF 96, ACME server processing of the "url" field should perform an exact string equality test between the URL string provided to the client and the string provided by the client in its "url" parameter. Effectively, this turns "url" values into opaque service labels, which just happen to have the side effect of being able to direct an HTTP request.
Change:
each time a new TLS connection is established, both the client and the server (or the server only when using mtls) have to validate the other party's identity.  Such a verification can be achieved via <del> methods described in I-D.ietf-uta-6125bis), but these are not enough to establish the identity of the client instance in many cases. </del> <ins> methods described in I-D.ietf-uta-rfc6125bis, but these are not enough to establish the identity of the client instance in many cases. </ins> To counter this, GNAP defines a set of key binding methods in binding-keys that allow authentication and proof of possession by the

Discussion:
Built To edit notification comments on pull requests, go to your .
[I-D.ietf-uta-6125bis] " BROKEN REFERENCE ".
Change:
match the fields in the offer. Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", <del> "a=ice-options", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an "a=fmtp:webrtc- datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1. </del> <ins> "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included as mentioned above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1. </ins> If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as

Discussion:
This contains the ice-options changes as well - will take another look once that PR is merged.
looks like a straightforward change - lgtm
LGTM
JSEP defines this attribute on media level, while 5245 says it is a session level attribute. I understand that there is development ongoing here (e.g. 5245bis), but given that canTrickleIceCandidates is an API on the PeerConnection it makes more sense IMO to have ice-options:trickle on the session level than media line level. If we want this on media line line level, canTrickleIceCandidates should be a (readonly) Transceiver attribute. To that seems messy though, what would happen if Bundle is negotiated but one media line can do trickle but the other not? While the relation between the application of an Answer and canTrickleIceCandidates is spelled out, the same thing should be done for application of an Offer.
Decision on 1): simplest thing here is to move ice-options to session level, right after "An "a=msid-semantic:WMS" line MUST be added..." 2) yes, this should be put into handling a remote description, not handling an answer.
I can take this.
JSEP requires sending q=msid-semantics:WMS: If I read URL correctly, that is no longer defined, so that requirement should probably go. I'm happy to provide a PR that removes the requirement, the example usage and updates the reference, but I assume that updating the reference involves more work than just this, so I'll refrain from doing so unless I hear it would still be useful.
I think we can just remove this line, and scrub it from the examples. More work is probably needed to fix up the refs regarding a=msid, but I think this part should be easy to handle.
Change:
A frame was received on a stream where it is not permitted. <del> A Stream ID, Push ID, or Placeholder ID greater than the current maximum for that identifier was referenced. </del> <ins> A Stream ID, Push ID, or Placeholder ID was used incorrectly, such as exceeding a limit, reducing a limit, or being reused. </ins> <del> A Push ID was referenced in two different stream headers. </del> <ins> N/A </ins> A unidirectional stream header contained an unknown stream type.

Discussion:
Implements suggestions from
Updated to replace HTTPLIMITEXCEEDED and HTTPPUSHIDERROR with the single error HTTPID_ERROR.
There are presently a few cases where the Push ID can be used incorrectly. The table shows current error codes, proposes replacing the HTTPDUPLICATEPUSH with an HTTPPUSHIDERROR code, and replaces use of HTTPMALFORMED frame. Note, on I suggested a slightly different solution to replace HTTPMALFORMED FRAME, but I think this is a better path.
To me it seems that having an error code for specific part of push (i.e. ID of push-related information being incorrect) a bit too detailed. I think it sticks out, because we do not have things like "IDERROR, STREAMIDERROR. Also, using PUSHIDERROR in some cases while using MALFORMEDFRAME in others seems confusing. I think we might want to consider doing either of the two: Use PUSHIDERROR (or a generic error code for push) for all the push-related errors. This makes sense if we consider push as an optional feature of HTTP/3 Introduce IDERROR that captures all the limit and ID errors.
Thanks NAME The proposal is a bit of a compromise, so I agree with some of the points that you make. I like your idea of replacing HTTPLIMITEXCEEDED with HTTPIDERROR. I think it solves the issue in the most general way and doesn't change the protocol mechanics. What follows is the response I made first, before coming to that agreement :) Right. The difference here is that H3 frames only reference the stream and placeholder ID spaces, they don't control them. So, if the peer references an ID that doesn't exist then respond with HTTPLIMITEXCEEDED. Multiple references to the same ID is a little different, its ok to reuse placeholder ID (as long as the above condition holds, and you create a semantically valid PRIORITY frame). The transport spec discusses reuse of stream IDs at that layer; in H3 we only use stream ID for PRIORITY and GOAWAY - this has similar restrictions. However, server push is a little different because it's ID space is managed by the MAXPUSHID frame. The three errors that use HTTPPUSHIDERROR are unique to push.

However, if we modified HTTPLIMITEXCEEDED to cover exceeding limits and incorrect ID usage (call it HTTPID_ERROR) I think that would work.
I updated the PR with the above, so that we can see what it looks like.
I'm not totally sold on this, but I'm having trouble articulating what it is that doesn't flow for me. I suspect that means I don't actually disagree, I just need some time to wrap my head around it.
We merged so I'm closing this as completed.
Change:
the identity is configured by human users).  On the other hand, RFC7925 advises implementations against assuming any structured format for PSK identities and recommends byte-by-byte comparison for <del> any operation.  When PSK identites are configured manually it is </del> <ins> any operation.  When PSK identities are configured manually it is </ins> important to be aware that due to encoding issues visually identical strings may, in fact, differ.

Discussion:
cc NAME NAME
In section 4 there is a statement that switching the roles of servers which use PSKs will lead to weakening of security properties. As this is a common scenario today in situations where you are doing server-to-server communication, it would be useful to discuss just how and how much this weakening occurs. This was a complete surprise to me and I don't know if it was supposed to be one. Are there mitigations that can be made? In section 7, The first sentence does not read, also It seems a bit difficult to have a MUST in there when most of the items below are SHOULDs. That seems to be a dissonance. Section 7.1.1 - The idea of having domain name suffixes on PSKs seems to me to be a bad idea as this would seem to lower privacy levels. Section 7.1.2 - There seem to me to be three different places where collisions will occur. The importer function could get a collision, there could be collisions with pre-TLS 1.2 external identifiers and there could be collision with resumption keys. There has been a huge discussion about this in the EMU group and I don't find the text here to be sensible in term of whether this is or is not a problem. Section 7.1.2 - One of the things that I kept meaning to get to and just haven't done so yet, is dealing with the question of can the TLS Key binders in the handshake to distinguish between multiple keys that happen to have the same identity. Perhaps you should look to see if this does work and if it is safe.
Change:
Elements after this point are dependent on the specific message type. <ins> COSE messages are also built using the concept of using layers to separate different types of cryptographic concepts.  As an example of how this works consider the COSE_Encrypt message (EnvelopedData). This message type is broken into two layers: the content layer and the recipient layer.  In the content layer, the plain text is encrypted and information about the encrypted message are placed.  In the recipient layer, the content encryption key (CEK) is encrypted and information about how it is encrypted for each recipient is placed.  A single layer version of the encryption message COSE_Encrypt0 (EnvelopedData0) is provided for cases where the CEK is pre-shared. </ins> Identification of which type of message has been presented is done by the following method:

Discussion:
Some more edits in response to the review. Does not include one item that was proposed for clarification
Change:
endpoints and a resource lookup MUST return a list of links to resources. <del> The value of the lt attribute of the registration represents the time interval form the lookup moment till the end of life of the registration. </del> The lookup type is selected by a URI endpoint, which is indicated by a Resource Type as per lookup-types below:

Discussion:
We've had conflicting concepts (show remaining vs show registered), and they problematic w/rt caching and useless to some kinds of consumers, respectively. Given that there is no clear case for existing consumers that could fully work from those attributes in lookup, they're removed; when a use case does come up, it can still register a lookup parameter. Closes: URL
should lt value in lookup give time from specification moment to end or from lookup moment to end
added text in this sense in section 7
That's hard to keep consistent with caching. What use cases do we have for exposing a lifetime in the endpoint lookup at all?
returning the lt value as specified at registration time does not really help and can be omitted at lookup. Returning the remaining registration time till end of registration "could" be useful to a commissioning device that is unaware of the earlier registration time because it was not involved.
Given that caching of down-counting values is problematic, and the 'Returning the remaining [...] time [...] "could" be useful' does not sound too convinced, I'd suggest just not returning it by default and leaving it up to extensions to say what exactly they need. NAME is that something you'd be happy with?
Change:
necessary ensure that in high speed networks the sequence number space does not wrap whilst packets are in flight. <del> The LSP used to forward the DetNet packet may be of any type (MPLS- LDP, MPLS-TE, MPLS-TP RFC5921, or MPLS-SR I-D.ietf-spring-segment- routing-mpls).  The LSP (F-Label) label and/or the S-Label may be used to indicate the queue processing as well as the forwarding parameters.  Note that the possible use of Penultimate Hop Popping (PHP) means that the S-Label may be the only label received at the terminating DetNet service. </del> <ins> The LSP used to forward the DetNet packet is not restricted regarding any method used for establishing that LSP (for example, MPLS-LDP, MPLS-TE, MPLS-TP RFC5921, MPLS-SR RFC8660, etc.).  The LSP (F-Label) label and/or the S-Label may be used to indicate the queue processing as well as the forwarding parameters.  Note that the possible use of Penultimate Hop Popping (PHP) means that the S-Label may be the only label received at the terminating DetNet service. </ins> 4.2.

Discussion:
Fixing the comments received during the IESG review.
MPLS document
MPLS: All 01-27 changes updated
Done
Change:
Abstract <del> While WebRTC has been very successful in a wide range of scenarios, </del> <ins> While WebRTC has been very sucessful in a wide range of scenarios, </ins> its adoption in the broadcasting/streaming industry is lagging behind.  Currently there is no standard protocol (like SIP or RTSP) <del> designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it. These protocols are much older than webrtc and lack by default some important security and resilience features provided by webrtc with minimal delay. The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node, introducing delay and degrading media quality.  This transcoding step is always present in traditional streaming to support e.g.  ABR, and comes at no cost.  However webrtc implements client-side ABR, also called Network-Aware Encoding by e.g.  Huavision, by means of simulcast and SVC codecs, which otherwise alleviate the need for server-side transcoding.  Content protection and Privacy Enhancement can be achieved with End-to-End Encryption, which preclude any server-side media processing. </del> <ins> designed for ingesting media into a streaming service using WebRTC and so content providers still rely heavily on protocols like RTMP for it. These protocols are much older than WebRTC and by default lack some important security and resilience features provided by WebRTC with minimal overhead and additional latency. The media codecs used for ingestion in older protocols tend to be limited and not negotiated.  WebRTC includes support for negotiation of codecs, potentially alleviating transcoding on the ingest node (wich can introduce delay and degrade media quality).  Server side transcoding that has traditionally been done to present multiple renditions in Adaptive Bit Rate Streaming (ABR) implementations can be replaced with simulcasting and SVC codecs that are well supported by WebRTC clients.  In addition, WebRTC clients can adjust client- side encoding parameters based on RTCP feedback to maximize encoding quality. Encryption is mandatory in WebRTC, therefore secure end-to-end transport of media is implicit. </ins> This document proposes a simple HTTP based protocol that will allow <del> WebRTC endpoints to ingest content into streaming services and/or CDNs to fill this gap and facilitate deployment. </del> <ins> WebRTC based ingest of content into streaming servics and/or CDNs. </ins> 1.

Discussion:
I'd like to propose removing the mention of a specific company/brand in the abstract as well as some clarification around the language used to describe the protocol and why it is important/different from "other protocols".
Change:
an input.  The values of the parameters L, and T MUST be defined by each EKTCipher. <del> 2.4. </del> <ins> 2.5. </ins> If a source has its EKTKey changed by the key management, it MUST also change its SRTP master key, which will cause it to send out a

Discussion:
,
Changes look good , except for few typos .
Nothing to add beyond Suhas' comments.
Section 4 Each EKT cipher specifies a value T that is the maximum number of times a given key can be used. An endpoint MUST NOT send more than T Full EKT Field using the same EKTKey. In addition, the EKTKey MUST NOT be used beyond the lifetime provided by the TTL described in Section 3.2.
ektttl: The maximum amount of time, in seconds, that this ektkeyvalue can be used. The ektkey_value in this message MUST NOT be used for encrypting or decrypting information after the TTL expires.
These functions have the property that D(K, E(K, P)) = ( P concatenated with optional padding) for all values of K and P. Each cipher also has a limit T on the number of times that it can be used with any fixed key value. The EKTKey MUST NOT be used more that T times.
Change:
application requirements and network conditions, without requiring changes to the applications.  This flexibility enables faster deployment of new features and protocols.  It can also support <del> applications by offering racing and fallback mechanisms, which otherwise need to be implemented in each application separately. </del> <ins> applications by offering racing mechanisms (attempting multiple IP addresses, protocols, or network paths in parallel), which otherwise need to be implemented in each application separately (see racing). </ins> This document was developed in parallel with the specification of the Transport Services API I-D.ietf-taps-interface and Implementation

Discussion:
Describe what you mean by racing earlier in the document - the use in the Introduction is bare.
As NAME said.
Change:
An endpoint resets the spin value for a network path to zero when changing the connection ID being used on that network path. <del> With this mechanism, the server reflects the spin value received, while the client 'spins' it after one RTT.  On-path observers can measure the time between two spin bit toggle events to estimate the end-to-end RTT of a connection. </del> 18. The extension_data field of the quic_transport_parameters extension

Discussion:
while the client 'spins' it after one RTT. On-path observers can measure the time between two spin bit toggle events to estimate the end-to-end RTT of a connection. It would be clearer to the reader if the explanation of operation proceeded the detail.
This is fine, but I find that description to be less than ideal. I won't try to suggest an improvement though. It isn't so bad.
Change:
perspective there is no practical difference based on the origin of flow mapping related information (management plane or control plane). <ins> The following summarizes the set of information that is needed to configure DetNet MPLS over TSN: DetNet MPLS related configuration information according to the DetNet role of the DetNet MPLS node, as per I-D.ietf-detnet-mpls. TSN related configuration information according to the TSN role of the DetNet MPLS node, as per IEEE8021Q, IEEE8021CB and IEEEP8021CBdb. Mapping between DetNet MPLS flow(s) (label information: A-labels, S-labels and F-labels as defined in I-D.ietf-detnet-mpls) and TSN Stream(s) (as stream identification information defined in IEEEP8021CBdb).  Note, that managed objects for TSN Stream identification can be found in IEEEP8021CBcv. This information MUST be provisioned per DetNet flow. </ins> TSN-aware MPLS DetNet nodes are member of both the DetNet domain and the TSN sub-network.  Within the TSN sub-network the TSN-aware MPLS (DetNet) node has a TSN-aware Talker/Listener role, so TSN specific

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
a packet.  Restarting this timer when sending a packet ensures that connections are not closed after new activity is initiated. <ins> To avoid excessively small idle timeout periods, endpoints MUST increase the idle timeout period to be at least three times the current Probe Timeout (PTO). </ins> 10.2.1. An endpoint that sends packets close to the effective timeout risks

Discussion:
The text as written implied that the actual timeout period was calculated using: This is silly, as 3PTO is usually smaller than the other two values, and connections would time out too fast. Splitting the text regarding the 3PTO backstop makes this clearer.
Wasn't the intended meaning
I can only speak about my intent, but I did not intend to always add 3PTO to the timeout. The text was clearly more confused than I thought.
I actually wasn't sure what you meant before, but this is what I assumed.