jiebi/CodeConvo huggingface dataset:
Change:
Tweaks for Supported Groups. We still need to figure out what to do with curves smaller than 256.

Discussion:
Despite the following behavior being misguided, experience has shown that some customers use the IANA registry as a checklist against which to measure an implementation's completeness, and some <del> implementers blindly implement supported group.  Therefore, IANA [SHALL add/has added] the following warning to the registry: </del> <ins> implementers blindly implement supported group.  Therefore, IANA has added the following warning to the registry: </ins> IANA [SHALL update/has updated] the reference for this registry to <del> also refer to this document. </del> <ins> refer to this document instead of RFC8447. </ins> The value 0 (0x0000) has been marked as reserved.
Change:
Update exporter
NAME minor nit, but this is what I remember being discussed in Philly.
I was recently surprised to learn that the uses . This is a problem for us - we have an internal use of an exporter that we cannot release a specification for at this time. This means that our only option is to "squat" on the value instead of registering it. Since we're already making changes to these repositories and we now have a Recommended column, I propose that we instead use . Note that Expert Review is exactly the same as Specification Required, with the exception that it doesn't require a specification. We could also add a requirement that entries with have a specification.

Discussion:
7. <del> In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS Exporter Labels Registry as follows: </del> <ins> This document updates the registration procedure for the TLS Exporter registry and updates the Recommended column allocation.  IANA SHALL update the TLS Exporter Labels Registry as follows: </ins> <del> Update the registration procedure to include: </del> <ins> Change the registration procedure from Specification Required to Expert Review and update it to include: </ins> Add a reference to this document under the reference heading.

Update note on the recommended column with text in rec-note. <ins> update the note on the role of the expert reviewer as follows. </ins> 8. In order to refect the changes in the Recommended column allocation,
Change:
ID-nits turned up that the 2119 language section was missing. I added it as a new section, but could also see it being in the existing section 2.
I think I prefer it in section 2.4, with the rest of terminology.

Discussion:
2.4. <ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </ins> The following terms are used across the documents specifying the WebRTC suite, in the specific meanings given here.  Not all terms are used in this document.  Other terms are used in their commonly used
Change:
Benoit submitted a DISCUSS related to management. It was discussed and adding the following text as the penultimate paragraph in s1 ought will resolve it: Operators should note that deployment of WebRTC will result in a change in the nature of signaling for real time media on the network, and may result in a shift in the kinds of devices used to create and consume such media. In the case of signaling, WebRTC session setup will typically occur over TLS-secured web technologies (such as WebSockets [RFC6455]) using application-specific protocols. Operational techniques that involve inserting network elements to interpret SDP -- either through endpoint cooperation [RFC3361] or through the transparent insertion of of SIP Application Level Gateways (ALGs) -- will not work with such signaling. In the case of networks using cooperative endpoints, the approaches defined in [RFC8155] may serve as a suitable replacement for [RFC3361]. The increase in browser-based communications may also lead to a shift away from dedicated real-time-communications hardware, such as SIP desk phones. This will diminish the efficacy of operational techniques that place dedicated real-time devices on their own network segment, address range, or VLAN for purposes such as applying traffic filtering and QoS. The markings described in [URL] may be appropriate replacements for such techniques.

Discussion:
concentrates on specifying the protocols and subprotocols that are needed to specify the interactions over the network. <ins> Operators should note that deployment of WebRTC will result in a change in the nature of signaling for real time media on the network, and may result in a shift in the kinds of devices used to create and consume such media.  In the case of signaling, WebRTC session setup will typically occur over TLS-secured web technologies using application-specific protocols.  Operational techniques that involve inserting network elements to interpret SDP -- either through endpoint cooperation RFC3361 or through the transparent insertion of SIP Application Level Gateways (ALGs) -- will not work with such signaling.  In the case of networks using cooperative endpoints, the approaches defined in RFC8155 may serve as a suitable replacement for RFC3361.  The increase in browser-based communications may also lead to a shift away from dedicated real-time-communications hardware, such as SIP desk phones.  This will diminish the efficacy of operational techniques that place dedicated real-time devices on their own network segment, address range, or VLAN for purposes such as applying traffic filtering and QoS.  Applying the markings described in I-D.ietf-tsvwg-rtcweb-qos may be appropriate replacements for such techniques. </ins> This memo uses the term "WebRTC" (note the case used) to refer to the overall effort consisting of both IETF and W3C efforts.
Change:
Ben noted is his comments: 2.3, last paragraph: The paragraph is a single, convoluted sentence that is hard to parse. (It's also a comma splice). Please consider breaking into multiple simpler sentences.
This text is gross, but the changes are fine.

Discussion:
other party is willing to accept communication at the base level of that specification, you can communicate successfully. <del> The alternative - that of having no mandatory to implement - does not </del> <ins> The alternative, that is having no mandatory to implement, does not </ins> mean that you cannot communicate, it merely means that in order to be part of the communications partnership, you have to implement the <del> standard "and then some" - that "and then some" usually being called a profile of some sort; in the version most antithetical to the </del> <ins> standard "and then some".  The "and then some" is usually called a profile of some sort; in the version most antithetical to the </ins> Internet ethos, that "and then some" consists of having to use a specific vendor's product only.
Change:
Please double check this, but it did say "functions for ... function such as" so I changed the second function to application.
Ben had the following comment: 3, first paragraph: This is also convoluted and hard to parse.

Discussion:
3. <del> The model of real-time support for browser-based applications does not assume that the browser will contain all the functions that need to be performed in order to have a function such as a telephone or a video conferencing unit; the vision is that the browser will have the functions that are needed for a Web application, working in conjunction with its backend servers, to implement these functions. </del> <ins> For browser-based applications, the model for real-time support does not assume that the browser will contain all the functions needed for an application such as a telephone or a video conference.  The vision is that the browser will have the functions needed for a Web application, working in conjunction with its backend servers, to implement these functions. </ins> This means that two vital interfaces need specification: The protocols that browsers use to talk to each other, without any
Change:
Spencer had the following comment: This is a nit, but in this text, Other efforts, for instance the W3C WEBRTC, Web Applications and Device API working groups, focus on making standardized APIs and interfaces available, within or alongside the HTML5 effort, it would be nice to have the names here match what's on the W3C website. So, "Web Real-Time Communication", "Web Application Security", and "Device and Sensors", unless I'm guessing at the mapping wrong. It's also easy to read that text with "Web Applications and Device API" as a single working group, so using a comma after "Web Application Security" would be helpful.
LGTM with editorial

Discussion:
protocol suite is intended to enable all the applications that are described as required scenarios in the use cases document RFC7478. <del> Other efforts, for instance the W3C WEBRTC, Web Applications and Device API working groups, focus on making standardized APIs and interfaces available, within or alongside the HTML5 effort, for those functions; this memo concentrates on specifying the protocols and subprotocols that are needed to specify the interactions that happen across the network. </del> <ins> Other efforts, for instance the W3C Web Real-Time Communications, Web Applications Security, and Device and Sensor working groups, focus on making standardized APIs and interfaces available, within or alongside the HTML5 effort, for those functions.  This memo concentrates on specifying the protocols and subprotocols that are needed to specify the interactions over the network. </ins> This memo uses the term "WebRTC" (note the case used) to refer to the overall effort consisting of both IETF and W3C efforts.
Change:
Mirja had the following comment: section 3: "Data transport: TCP, UDP and the means to securely set up connections between entities, as well as the functions for deciding when to send data: Congestion management, bandwidth estimation and so on." This seems to implicitly assume that only TCP or something encapsulated over UDP can be used. Even though that might be true, I assume this was not intentionally, maybe: NEW "Data transport: such as TCP or UDP and the means to securely set up connections between entities, as well as the functions for deciding when to send data: Congestion management, bandwidth estimation and so on."

Discussion:
The functionality groups that are needed in the browser can be specified, more or less from the bottom up, as: <del> Data transport: TCP, UDP and the means to securely set up </del> <ins> Data transport: such as TCP, UDP and the means to securely set up </ins> connections between entities, as well as the functions for deciding when to send data: Congestion management, bandwidth estimation and so on.
Change:
Mirja had the following comment/nit: massage the signals": not sure if "massage" is actually a meaningful word here…

Discussion:
("low path") goes directly between the browsers, so it has to be conformant to the specifications of the WebRTC protocol suite; the signaling path ("high path") goes via servers that can modify, <del> translate or massage the signals as needed. </del> <ins> translate or manipulate the signals as needed. </ins> If the two Web servers are operated by different entities, the inter- server signaling mechanism needs to be agreed upon, either by
Change:
Jingle and XMPP already had references by BOSH didn't so I added it.
Kathleen had the following comment: I had to look up jingle and BOSH, you may want to consider adding references to the XMPP specifications.

Discussion:
servers implement Extensible Messaging and Presence Protocol (XMPP), XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g.  XMPP over WebSockets <del> or BOSH) or a proprietary signaling mechanism used between the application running in the browser and the web server. </del> <ins> or BOSH XEP-0124 or a proprietary signaling mechanism used between the application running in the browser and the web server. </ins> The choice of protocols for client-server and inter-server signalling, and definition of the translation between them, is
Change:
Ben provided the following comment: s7, list item 1: The citiation to [3264] seems misplaced. It describes the offer/answer model, not SIP in general. I suggest moving the citation to after the word "semantics”.

Discussion:
The following principles apply: The WebRTC media negotiations will be capable of representing the <del> same SDP offer/answer semantics that are used in SIP RFC3264, in </del> <ins> same SDP offer/answer semantics RFC3264 that are used in SIP, in </ins> such a way that it is possible to build a signaling gateway between SIP and the WebRTC media negotiation.
Change:
LGMT
ekr provided the following comment for s3: I would say HTTP(S) in this diagram.

Discussion:
intervening servers, and the APIs that are offered for a Javascript application to take advantage of the browser's functionality. <del> Note that HTTP and WebSockets are also offered to the Javascript </del> <ins> Note that HTTPS and WebSockets are also offered to the Javascript </ins> application through browser APIs. As for all protocol and API specifications, there is no restriction
Change:
ekr had the following comment: You should probably list DTLS, SCTP, and SDP in this section. It's not like we haven't decided we need them.
LGTM with nits

Discussion:
Data transport: such as TCP, UDP and the means to securely set up connections between entities, as well as the functions for <del> deciding when to send data: Congestion management, bandwidth </del> <ins> deciding when to send data: congestion management, bandwidth </ins> estimation and so on. <del> Data framing: RTP, SCTP and other data formats that serve as containers, and their functions for data confidentiality and </del> <ins> Data framing: RTP, SCTP, DTLS, and other data formats that serve as containers, and their functions for data confidentiality and </ins> integrity. Data formats: Codec specifications, format specifications and

formats, a way to describe them, a session description, is needed. Connection management: Setting up connections, agreeing on data <del> formats, changing data formats during the duration of a call; SIP and Jingle/XMPP belong in this category. </del> <ins> formats, changing data formats during the duration of a call; SDP, SIP, and Jingle/XMPP belong in this category. </ins> Presentation and control: What needs to happen in order to ensure that interactions behave in a non-surprising manner.  This can
Change:
o Added a SHOULD NOT about using deprecated temporary IPv6 addresses. o Updated draft-ietf-dart-dscp-rtp reference to RFC 7657
Some systems keep old IPv6 addresses around even when changing to new for privacy. How should we avoid trying the ones that don't make sense to try?
As documented here: URL and here: URL it appears that the implementers claim everything is working as designed on systems which accumulate several temporary deprecated IPv6 addresses. My assumption here is that using deprecated temp addresses as ICE candidates (additionally to the non deprecated temporary address) is not going to increase the likeliness of establishing a connection. So adding these additional ICE candidates only causes extra over head. Therefore adding a warning/clarification statement for implementers to avoid deprecated temporary IPv6 addresses (in case there is usable non-deprecated temporary IPv6 address available) seem appropriate.
Adding warning in -12: "If some of the temporary IPv6 addresses, but not all, are marked deprecated, the client SHOULD discard the deprecated addresses."
Sounds good to me.
Addressed in (version -12)

Discussion:
Transports for WebRTC <del> draft-ietf-rtcweb-transports-11 </del> <ins> draft-ietf-rtcweb-transports-12 </ins> Abstract

exposing addresses to the application or using them in ICE.  This is consistent with the default policy described in RFC6724. <ins> If some of the temporary IPv6 addresses, but not all, are marked deprecated, the client SHOULD discard the deprecated addresses. </ins> 3.4. The primary mechanism to deal with middle boxes is ICE, which is an

All packets on one TCP connection, no matter what it carries, MUST use a single DSCP code point. <del> More advice on the use of DSCP code points with RTP is given in I- D.ietf-dart-dscp-rtp. </del> <ins> More advice on the use of DSCP code points with RTP is given in RFC7657. </ins> There exist a number of schemes for achieving quality of service that do not depend solely on DSCP code points.  Some of these schemes
Change:
Fixes URL
From Cullen Jennings, RTCWEB mailing list Feb 3 2016: I think we need to make the ALPN a bit more explicit. We agreed to include the ALPN header so that a proxy knows it might receive video packet rates tunnelled across it. However the text on this is not 100% clear. Right now it says If it does so, it MUST support the "ALPN" header as specified in [RFC7639], But some people have posted out including this header is optional in 7639 so there might be some ubiquity here about what is meant. I think we should change the word “support” to “include” to make it clear this needs to be sent to the proxy so that it would read specified in [RFC7639], I believe that correctly reflects what we intended on this. There is no requirement for the proxy to understand or do anything with this header. Old proxies will just ignore it and cary on as if it was not there.
Fixed in version -10.
Seems "support" never got changed to "include", so reopening issue.

Discussion:
(300 Try Alternate) MUST be supported. The WebRTC implementation MAY support accessing the Internet through <del> an HTTP proxy.  If it does so, it MUST support the "ALPN" header as </del> <ins> an HTTP proxy.  If it does so, it MUST include the "ALPN" header as </ins> specified in RFC7639, and proxy authentication as described in Section 4.3.6 of RFC7231 and RFC7235 MUST also be supported.
Change:
LGTM with comment above.
I think we should just refer people to 5763, S 6.7.1: Interactive Connectivity Establishment (ICE), as specified in [RFC5245], provides a methodology of allowing participants in multimedia sessions to verify mutual connectivity. When ICE is being used, the ICE connectivity checks are performed before the DTLS handshake begins. Note that if aggressive nomination mode is used, multiple candidate pairs may be marked valid before ICE finally converges on a single candidate pair. Implementations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association. Thus, there will be only one DTLS handshake even if there are multiple valid candidate pairs. Note that this may mean adjusting the endpoint IP addresses if the selected candidate pair shifts, just as if the DTLS packets were an ordinary media stream. Specifically, I think we should say: Note: DTLS-SRTP as defined in defines how DTLS interacts with ICE in Section 6.7.1. As indicated therein, implementations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association. Thus, there will be only one DTLS handshake even if there are multiple valid candidate pairs.
Rephrased according to Justin's suggestion.

Discussion:
Transports for WebRTC <del> draft-ietf-rtcweb-transports-08 </del> <ins> draft-ietf-rtcweb-transports-09 </ins> Abstract

The setup protocol for WebRTC data channels described in I-D.ietf- rtcweb-data-protocol MUST be supported. <ins> Note: DTLS-SRTP as defined in RFC5764 section 6.7.1 defines the interaction between DTLS and ICE ( RFC5245).  The effect of this specification is that all ICE candidate pairs associated with a single component are part of the same DTLS association.  Thus, there will only be one DTLS handshake even if there are multiple valid candidate pairs. </ins> WebRTC implementations MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS-SRTP specification RFC5764, section 5.1.2.  All application layer protocol payloads over
Change:
Notes that there's no way to mark a stream as non-interactive.
From discussion with DSCP folks:
after
Discussion people: Cc: EMAIL; EMAIL; EMAIL; EMAIL; Black, David
I chose to integrate this minus the G.1010 reference, since I did not know how to get that reference in using XML2RFC markup, and the reference to 4594 already covers it.
Fixed in (version -14)

Discussion:
Transports for WebRTC <del> draft-ietf-rtcweb-transports-13 </del> <ins> draft-ietf-rtcweb-transports-14 </ins> Abstract

specification does not describe prioritization between the RTP streams that come from a single "media source". <ins> All media flows in WebRTC are assumed to be interactive, as defined in RFC4594; there is no browser API support for indicating whether media is interactive or non-interactive. </ins> A "data flow" is the outgoing data on a single WebRTC data channel. The priority associated with a media flow or data flow is classified
Change:
NAME please review
From Magnus Westerlund in IETF LC: Section 3.5: WebRTC implementations MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS-SRTP specification [RFC5764], section 5.1.2. All application layer protocol payloads over this DTLS connection are SCTP packets. This text should reference also the update to RFC5764: URL That document is publication requested so even as normative reference it will hopefully have minimal impact on the publication progress of this document.
Looking at -mux-fixes, I think this is worth including. Adding.

Discussion:
WebRTC implementations MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS-SRTP specification <del> RFC5764, section 5.1.2.  All application layer protocol payloads over this DTLS connection are SCTP packets. </del> <ins> RFC5764, section 5.1.2, with clarifications in I-D.ietf-avtcore- rfc5764-mux-fixes.  All application layer protocol payloads over this DTLS connection are SCTP packets. </ins> Protocol identification MUST be supplied as part of the DTLS handshake, as specified in I-D.ietf-rtcweb-alpn.
Change:
Also do reformatting (xxe equivalent of tidy).
From Ben Campbell's IESG comments:

Discussion:
STUN - Session Traversal Utilities for NAT, <del> ICE - Interactive Connectivity Establishment, RFC5245 </del> <ins> ICE - Interactive Connectivity Establishment, </ins> TLS - Trasnsport Layer Security,

media type (audio, video or data) into its own 5-tuple (bundling by media type). <del> Sending data over multiple 5-tuples is not supported. </del> <ins> Sending data channel data over multiple 5-tuples is not supported. </ins> A receiving implementation MUST be able to receive media and data in all these configurations.
Change:
This is the companion to w3c/webrtc-pc A move to JS realms and so forth removes the need for a "protocol" in this document. Instead, I've tried to focus here on what information needs to pass between the browser and the IdP, rather than be prescriptive. I didn't reindent anything, so it's a mess. I also didn't move Section 5.6 up a level, as I am sorely tempted to do. Hopefully these changes are easy enough to review as they are.

Discussion:
can fail to generate an assertion and instead indicate a URL where login should proceed. <del> A calling site is then able to load the provided URL in an IFRAME in order to trigger the required user interactions.  Once any user interactions are complete, the IFRAME MUST send a WebMessaging to the calling site indicating that login has completed.  Any message is sufficient for this purpose, the "source" parameter identifies the originating IFRAME. </del> <ins> The application can then load the provided URL to enable the user to enter credentials.  The communication between the application and the IdP is described in webrtc-api. </ins> 5.7.