Abstract <del> This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy.  These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process. </del>  <del> This document obsoletes RFC 8447 and updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. </del>  1. This document instructs IANA to make changes to a number of the IANA registries related to Transport Layer Security (TLS) and Datagram <del> Transport Layer Security (DTLS). Most of the instructions included herein and previously included in RFC8447, which this document obsoletes, were motivated by the development of TLS 1.3 RFC8446.  The changes ranged from simple, e.g., adding notes, to complex, e.g., changing a registry's registration policy.  Instead of listing the changes and their rationale here in the introduction, each section provides rationale for the proposed change(s).  The instructions in this document revise the values of "Recommended" column, applies the new value to the registries, and adds this column as noted in orphaned-registries. There are also instructions to update references, including replacing references to RFC8446 with I-D.ietf-tls-rfc8446bis and RFC8447 with I-D.ietf-tls-rfc8447bis. This document proposes no changes to the registration policies for TLS Alerts I-D.ietf-tls-rfc8446bis, TLS ContentType I-D.ietf-tls- rfc8446bis, TLS HandshakeType I-D.ietf-tls-rfc8446bis, and TLS Certificate Status Types RFC6961 registries; the existing policies (Standards Action for the first three; IETF Review for the last), are appropriate for these one-byte code points because of their scarcity. </del>  2. 3. <del> For consistency amongst TLS registries, IANA has prepended "TLS" to the following registries: Application-Layer Protocol Negotiation (ALPN) Protocol IDs RFC7301, ExtensionType Values, Heartbeat Message Types RFC6520, and Heartbeat Modes RFC6520. IANA [SHALL update/has updated] the reference for these four registries to also refer to this document.  The remainder of this document will use the registry names with the "TLS" prefix. 4. Many of the TLS-related IANA registries had the registration procedure "IETF Consensus", which was changed to "IETF Review" by RFC8126.  To align with the new terminology, IANA has updated the following registries to "IETF Review": TLS Authorization Data Formats TLS Supplemental Data Formats (SupplementalDataType) This is not a universal change, as some registries originally defined with "IETF Consensus" are undergoing other changes either as a result of this document or RFC8422. IANA [SHALL update/has updated] the reference for these two registries to also refer to this document. 5. </del> The instructions in this document update the Recommended column, originally added in RFC8447 to add a third value, "D", indicating that a value is "Discouraged".  The permitted values are: might have consensus to leave an items marked as "N" on the basis of it having limited applicability or usage constraints. <del> D: Indicates that the item is discouraged and SHOULD NOT or MUST NOT be used.  This marking could be used to identify mechanisms that might result in problems if they are used, such as a weak cryptographic algorithm or a mechanism that might cause interoperability problems in deployment. </del>  <del> Setting the Recommended item to "Y" or "D" or changing a item whose current value is "Y" or "D" requires Standards Action RFC8126.  Not all items defined in Standards Track RFCs need to be marked as Recommended.  Changing the Recommended status of an item in a Standards Track RFC requires Standards Action RFC8126. </del>  <del> 6. </del>  <del> The nomenclature for the registry entries in the TLS ExtensionType Values registry correspond to the presentation language field name except for entry 35.  To ensure that the values in the registry are consistently identified in the registry, IANA: </del>  <del> has renamed entry 35 to "session_ticket (renamed from "SessionTicket TLS")" RFC5077. [SHALL replace] the references to RFC8447 with a reference to this document in the "Reference" column for entry 35. 7. </del>  In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS ExtensionType Values registry as follows: <del> Change the registry policy to: </del>  Add a reference to this document under the reference heading. Update the "Recommended" column with the changes as listed below. <del> This table has been generated by keeping existing "Y" and "N" entries except for "truncated_hmac" (4), "connection_id (deprecated)" (53), "reserved" (40) and "Reserved" (46) as "D".  A reference to this document SHALL be added to these entries. Update the following note on the recommended column 8. Experience has shown that the IETF Consensus registry policy for TLS Cipher Suites was too strict.  Based on WG consensus, the decision was taken to change the TLS Cipher Suites registry's registration policy to Specification Required while reserving a small part of the code space for Experimental and Private Use RFC8126.  Therefore, IANA has updated the TLS Cipher Suites registry's policy as follows: See expert-pool for additional information about the designated expert pool. The TLS Cipher Suites registry has grown significantly and will continue to do so.  To better guide those not intimately involved in TLS, IANA [SHALL update/has updated] the TLS Cipher Suites registry as follows: Added a "Recommended" column to the TLS Cipher Suites registry. The cipher suites that follow in the two tables are marked as "Y". All other cipher suites are marked as "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. The cipher suites that follow are Standards Track server- authenticated (and optionally client-authenticated) cipher suites that are currently available in TLS 1.2. RFC EDITOR: The previous paragraph is for document reviewers and is not meant for the registry. The cipher suites that follow are Standards Track ephemeral pre- shared key cipher suites that are available in TLS 1.2. RFC EDITOR: The previous paragraph is for document reviewers and is not meant for the registry. The TLS 1.3 cipher suites specified by I-D.ietf-tls-rfc8446bis are not listed here; that document provides for their "Recommended" status. 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 implementers blindly implement cipher suites.  Therefore, IANA has added the following warning to the registry: IANA has added the following note to ensure that those that focus on IANA registries are aware that TLS 1.3 I-D.ietf-tls-rfc8446bis uses the same registry but defines ciphers differently: IANA [SHALL add/has added] the following notes to document the rules for populating the "Recommended" column: IANA [SHALL add/has added] the following notes for additional information: IANA [SHALL update/has updated] the reference for this registry to refer to this document instead of RFC8447. 9. Similar to cipher suites, supported groups have proliferated over time, and some use the registry to measure implementations. Therefore, IANA [SHALL add/has added] a "Recommended" column with a "Y" for secp256r1, secp384r1, x25519, and x448, while all others are "N".  These "Y" groups are taken from Standards Track RFCs; RFC8422 elevates secp256r1 and secp384r1 to Standards Track.  Not all groups from RFC8422, which is Standards Track, are marked as "Y"; these groups apply to TLS 1.3 I-D.ietf-tls-rfc8446bis and previous versions of TLS.  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. IANA [SHALL add/has added] the following notes: 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 implementers blindly implement supported group.  Therefore, IANA has added the following warning to the registry: </del>  <del> IANA [SHALL update/has updated] the reference for this registry to refer to this document instead of RFC8447. </del>  <del> The value 0 (0x0000) has been marked as reserved. 10. Experience has shown that the IETF Consensus registry policy for TLS ClientCertificateType Identifiers is too strict.  Based on WG consensus, the decision was taken to change the registration policy to Specification Required while reserving some of the code space for Standards Track usage and a small part of the code space for Private Use RFC8126.  Therefore, IANA has updated the TLS ClientCertificateType Identifiers registry's policy as follows: See expert-pool for additional information about the designated expert pool. </del>  <del> IANA [SHALL add/has added] the following notes: </del>  <del> 11. </del>  <del> To align with TLS implementations and to align the naming nomenclature with other Handshake message types, IANA: </del>  <del> has renamed entry 4 in the TLS HandshakeType registry to "new_session_ticket (renamed from NewSessionTicket)" RFC5077. </del>  <del> [SHALL replace/has replaced] a reference to RFC8447 with a reference to this document in the "Reference" column for entry 4 in the TLS HandshakeType registry. </del>  <del> 12. </del>  <del> To aid those reviewers who start with the IANA registry, IANA [SHALL add/has added]: </del>  <del> The following note to the TLS Exporter Labels registry: </del>  <del> A "Recommended" column to the TLS Exporter Labels registry.  The table that follows has been generated by marking Standards Track RFCs as "Y" and all others as "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N, Y->D, or D->Y|N transitions. </del>  <del> To provide additional information for the designated experts, IANA [SHALL add/has added] the following notes: </del>  <del> IANA [SHALL update/has updated] the reference for this registry to refer to refer to this document instead of RFC8447. </del>  <del> 13. </del>  <del> IANA has added the following entry to the TLS Alerts registry; the entry was omitted from the IANA instructions in RFC7301: </del>  <del> 14. </del>  <del> Experience has shown that the IETF Consensus registry policy for TLS Certificate Types is too strict.  Based on WG consensus, the decision was taken to change registration policy to Specification Required while reserving a small part of the code space for Private Use RFC8126.  Therefore, IANA has changed the TLS Certificate Types registry as follows: </del>  <del> Changed the registry policy to: </del>  <del> Added a "Recommended" column to the registry.  X.509 and Raw Public Key are "Y".  All others are "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N, Y->D, and D->Y|N transitions. </del>  <del> See expert-pool for additional information about the designated expert pool. </del>  <del> IANA [SHALL add/has added] the following note: </del>  <del> IANA [SHALL update/has updated] the reference for this registry to refer this document instead of RFC8447. </del>  <del> 15. </del>  <del> To make it clear that (D)TLS 1.3 has orphaned certain registries (i.e., they are only applicable to version of (D)TLS protocol versions prior to 1.3), IANA: </del>  <del> has added the following to the TLS Compression Method Identifiers registry RFC3749: </del>  <del> has added the following to the TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries RFC5246: </del>  <del> [SHALL update/has updated] the "Reference" field in the TLS Compression Method Identifiers, TLS HashAlgorithm and TLS SignatureAlgorithm registries to refer to this document instead of RFC8447. </del>  <del> has updated the TLS HashAlgorithm registry to list values 7 and 9-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-6 and 9-223 as "Reserved". </del>  <del> has added the following to the TLS ClientCertificateType Identifiers registry RFC5246: </del>  <del> Despite the fact that the TLS HashAlgorithm and SignatureAlgorithm registries are orphaned, it is still important to warn implementers of pre-TLS1.3 implementations about the dangers of blindly implementing cryptographic algorithms.  Therefore, IANA has added the following warning to the TLS HashAlgorithm and SignatureAlgorithm registries: </del>  Though TLS 1.0 and TLS 1.1 were deprecated RFC8996, TLS 1.2 will be <del> in use for some time.  IANA [SHALL update/has updated] the TLS HashAlgorithm, TLS SignatureAlgorithm, and TLS ClientCertificateTypes registries to add a "Recommended" column as follows: TLS HashAlgorithm registry: TLS SignatureAlgorithm registry: TLS ClientCertificateTypes registry: In the TLS HashAlgorithm, TLS SignatureAlgorithm, and TLS ClientCertificateTypes registries, all unassigned and reserved values have a "Recommended" that is blank. </del>  <del> 16. </del>  <del> IANA has added the following warning and note to the TLS SignatureScheme registry: </del>  <del> IANA [SHALL update/has updated] added the following notes to the TLS PskKeyExchangeMode registry: </del>  <del> 17. </del>  <del> Specification Required RFC8126 registry requests are registered after a three-week review period on the tls-reg-review@ietf.org [1] mailing list, on the advice of one or more designated experts.  However, to allow for the allocation of values prior to publication, the designated experts may approve registration once they are satisfied that such a specification will be published. </del>  <del> Registration requests sent to the mailing list for review SHOULD use an appropriate subject (e.g., "Request to register value in TLS bar registry"). </del>  <del> Within the review period, the designated experts will either approve or deny the registration request, communicating this decision to the review list and IANA.  Denials SHOULD include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org [2] mailing list) for resolution. </del>  <del> Criteria that SHOULD be applied by the designated experts includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or useful only for a single application, and whether the registration description is clear. </del>  <del> IANA MUST only accept registry updates from the designated experts and SHOULD direct all requests for registration to the review mailing list. </del>  <del> It is suggested that multiple designated experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly informed review of registration decisions.  In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert SHOULD defer to the judgment of the other Experts. </del>  <del> 18. </del>  The change to Specification Required from IETF Review lowers the amount of review provided by the WG for cipher suites and supported taken as an endorsement of the cipher suite, extension, supported group, etc. <del> 19. </del>  This document is entirely about changes to TLS-related IANA registries. <del> 20.  References 20.1.  URIs [1] mailto:tls-reg-review@ietf.org [2] mailto:iesg@ietf.org </del>

Updated introduction and recommended column section. Deleted some irrelevant sections.
Changed from obsolete to update.
Obsoleting RFC 8447 means duplicating a lot of text and making changes to it which makes the document have awkward wording and makes the changes difficult to follow. I think it would be clearer if it were an update and just listed the changes. see Extension Types PR
At IETF 115, there was general agreement that this document could be an update as opposed to an obsolete to make it easier on IANA.
These are nits.

Abstract  <ins> This document updates the changes to TLS and DTLS IANA registries made in RFC 8447.  It adds a new value "D" for discouraged to the recommended column of the selected TLS registries. </ins>  <ins> This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447. </ins> 1. This document instructs IANA to make changes to a number of the IANA registries related to Transport Layer Security (TLS) and Datagram  <ins> Transport Layer Security (DTLS).  These changes update the changes made in RFC8447. This specification updates the "Recommended" column in TLS registries to define a third value "D" for items that are discouraged. </ins> 2. 3.  The instructions in this document update the Recommended column, originally added in RFC8447 to add a third value, "D", indicating that a value is "Discouraged".  The permitted values are: might have consensus to leave an items marked as "N" on the basis of it having limited applicability or usage constraints.  <ins> D: Indicates that the item is discouraged.  This marking could be used to identify mechanisms that might result in problems if they are used, such as a weak cryptographic algorithm or a mechanism that might cause interoperability problems in deployment. Implementers SHOULD consult the linked references associated with the item to determine the conditions under which it SHOULD NOT or MUST NOT be used. </ins>  <ins> Setting a value to "Y" or "D" in the "Recommended" column requires IETF Standards Action RFC8126.  Any state transition to or from a "Y" or "D" value requires IESG Apporval.  Not all items defined in Standards Track RFCs need to be set to "Y" or "D".  Any item not otherwise specified is set to "N".  The column is blank for values that are unassigned or reserved unless specifically set. </ins>  <ins> 3.1. </ins>  <ins> Existing registries have a note on the meaning of the recommended column.  For the registries discussed in the subsequent sections this note is updated with a sentence describing the 'D' vaue as follows: </ins>  <ins> 4. </ins> In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS ExtensionType Values registry as follows:  <ins> Change the registration procedure to: </ins> Add a reference to this document under the reference heading. Update the "Recommended" column with the changes as listed below.  <ins> Entries keep their existing "Y" and "N" entries except for the entries in following table.  A reference to this document SHALL be added to these entries. </ins>  <ins> Update note on the recommended column with text in rec-note. </ins>  <ins> 5. </ins>  <ins> In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS ExtensionType Values registry as follows: </ins>  <ins> Change the registration procedure to: </ins>  <ins> Add a reference to this document under the reference heading. </ins>  <ins> Update the "Recommended" column with the changes as listed below. Entries keep their existing "Y" and "N" entries except for the entries in following table.  A reference to this document SHALL be added to these entries. </ins>  <ins> Update note on the recommended column with text in rec-note. </ins>  <ins> 6. </ins>  <ins> In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS Supported Groups registry as follows: </ins>  <ins> Update the registration policy to include: Add a reference to this document under the reference heading. Entries keep their existing Recommended column "Y" and "N" entries. </ins>  <ins> Update note on the recommended column with text in rec-note. </ins>  <ins> 7. </ins>  <ins> In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS Exporter Labels Registry as follows: </ins>  <ins> Update the registration procedure to include: </ins>  <ins> Add a reference to this document under the reference heading. </ins>  <ins> Entries keep their existing Recommended column "Y" and "N" entries </ins>  <ins> Update note on the recommended column with text in rec-note. </ins>  <ins> 8. </ins>  <ins> In order to refect the changes in the Recommended column allocation, IANA SHALL update the the TLS Certificate Types registry as follows: </ins>  <ins> Change the registration procedure to: </ins>  <ins> Add a reference to this document under the reference heading. </ins>  <ins> Entries keep their existing Recommended column "Y" and "N" entries. </ins>  <ins> Update note on the recommended column with text in rec-note. </ins>  <ins> 9. </ins>  <ins> Though TLS 1.0 and TLS 1.1 were deprecated RFC8996, TLS 1.2 will be in use for some time.  In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS HashAlgorithm Registry registry as follows: Update the registration procedure to include: Add a reference to this document under the reference heading. </ins>  <ins> Update the TLS HashAlgorithm registry to add a "Recommended" column as follows: Add note on the recommended column with text in rec-note. 10. </ins>  <ins> Though TLS 1.0 and TLS 1.1 were deprecated RFC8996, TLS 1.2 will be in use for some time.  In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS SignatureAlgorithm registry registry as follows: </ins>  <ins> Update the registration procedure to include: </ins>  <ins> Add a reference to this document under the reference heading. Update the TLS SignatureAlgorithm registry to add a "Recommended" column as follows: Add note on the recommended column with text in rec-note. </ins>  <ins> 11. </ins> Though TLS 1.0 and TLS 1.1 were deprecated RFC8996, TLS 1.2 will be  <ins> in use for some time.  In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS ClientCertificateTypes registry as follows: </ins>  <ins> Update the registration procedure to include: </ins>  <ins> Add a reference to this document under the reference heading. </ins>  <ins> Update the TLS ClientCertificateTypes registry to add a "Recommended" column as follows: </ins>  <ins> Add note on the recommended column with text in rec-note. </ins>  <ins> 12. </ins>  <ins> In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS PskKeyExchangeMode registry as follows: </ins>  <ins> Update the registration procedure to include: </ins>  <ins> Add a reference to this document under the reference heading. </ins>  <ins> Entries keep their existing recommended column "Y" and "N" entries. </ins>  <ins> Update note on the recommended column with text in rec-note. </ins>  <ins> 13. </ins> The change to Specification Required from IETF Review lowers the amount of review provided by the WG for cipher suites and supported taken as an endorsement of the cipher suite, extension, supported group, etc.  <ins> 14. </ins> This document is entirely about changes to TLS-related IANA registries.


7. <del> In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS Exporter Labels Registry as follows: </del>  <del> Update the registration procedure to include: </del>  Add a reference to this document under the reference heading. Update note on the recommended column with text in rec-note.  8. In order to refect the changes in the Recommended column allocation,

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.

7.  <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>  <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,


2.4.  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

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.

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


special hardware and custom-built software, often at very high prices or at low quality, placing great demands on the infrastructure. <del> As the available bandwidth has increased, and as processors an other </del>  hardware has become ever faster, the barriers to participation have decreased, and it has become possible to deliver a satisfactory experience on commonly available computing hardware. pointers to other documents that form part of the WebRTC suite. By reading this document and the documents it refers to, it should be <del> possible to have all information needed to implement an WebRTC </del>  compatible implementation. 2.2. endpoints in the form of messages.  Two endpoints can have multiple data channels between them. <del> An implementation of the Interactive Connectivty Establishment </del>  (ICE) I-D.ietf-ice-rfc5245bis protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166). more than hundreds of milliseconds).  Real-time media can be used to support interactive communication. <del> The protocol implementation involved in the SDP offer/answer exchange, as defined in RFC3264 section 3. </del>  Communication that happens in order to establish, manage and control media paths and data paths. running in the browser. A commonly imagined model of deployment is the one depicted below.  On this drawing, the critical part to note is that the media path ("low path") goes directly between the browsers, so it has to be If the two Web servers are operated by different entities, the inter- server signaling mechanism needs to be agreed upon, either by standardization or by other means of agreement.  Existing protocols <del> (for example SIP RFC3261 or XMPP RFC6120) could be used between servers, while either a standards-based or proprietary protocol could be used between the browser and the web server. </del>  For example, if both operators' servers implement SIP, SIP could be used for communication between servers, along with either a standardized signaling mechanism (e.g.  SIP over WebSockets) or a proprietary signaling mechanism used between the application running in the browser and the web server.  Similarly, if both operators' <del> servers implement XMPP, XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g. XMPP over WebSockets or BOSH) or a proprietary signaling mechanism used between the application running in the browser and the web server. </del>  The choice of protocols for client-server and inter-server signalling, and definition of the translation between them, is WebRTC browsers MUST implement I-D.ietf-rtcweb-jsep. WebRTC endpoints MUST implement the functions described in that <del> document that relate to the network layer (for example Bundle I- D.ietf-mmusic-sdp-bundle-negotiation, RTCP-mux RFC5761 and Trickle ICE I-D.ietf-ice-trickle), but do not need to support the API functionality described there. </del>  8.

This deals with some of Meral's GEN-ART comments.
I can see putting it back, but we should be consistent there were two e.g. and two for examples. My matchy-matchy tendencies getting to me.
:-) I can flip it in the other direction. Sometimes I show off my English skills, othertimes I want to write simple English. Trapped by my own filters .... the review ended up in my gen-art inbox, which I stopped reading years ago when I left the gen-art team....
No worries. I would go with whatever the RFC editor is going to end up doing, but to be honest I don’t know which they’d prefer. spt

special hardware and custom-built software, often at very high prices or at low quality, placing great demands on the infrastructure.  <ins> As the available bandwidth has increased, and as processors and other </ins> hardware has become ever faster, the barriers to participation have decreased, and it has become possible to deliver a satisfactory experience on commonly available computing hardware. pointers to other documents that form part of the WebRTC suite. By reading this document and the documents it refers to, it should be  <ins> possible to have all information needed to implement a WebRTC </ins> compatible implementation. 2.2. endpoints in the form of messages.  Two endpoints can have multiple data channels between them.  <ins> An implementation of the Interactive Connectivity Establishment </ins> (ICE) I-D.ietf-ice-rfc5245bis protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166). more than hundreds of milliseconds).  Real-time media can be used to support interactive communication.  <ins> The protocol implementation involved in the Session Description Protocol (SDP) offer/answer exchange, as defined in RFC3264 section 3. </ins> Communication that happens in order to establish, manage and control media paths and data paths. running in the browser. A commonly imagined model of deployment is the one depicted below. <ins> In the figure below JS is Javascript. </ins> On this drawing, the critical part to note is that the media path ("low path") goes directly between the browsers, so it has to be If the two Web servers are operated by different entities, the inter- server signaling mechanism needs to be agreed upon, either by standardization or by other means of agreement.  Existing protocols  <ins> (e.g.  SIP RFC3261 or XMPP RFC6120) could be used between servers, while either a standards-based or proprietary protocol could be used between the browser and the web server. </ins> For example, if both operators' servers implement SIP, SIP could be used for communication between servers, along with either a standardized signaling mechanism (e.g.  SIP over WebSockets) or a proprietary signaling mechanism used between the application running in the browser and the web server.  Similarly, if both operators'  <ins> 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 or BOSH) 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 WebRTC browsers MUST implement I-D.ietf-rtcweb-jsep. WebRTC endpoints MUST implement the functions described in that  <ins> document that relate to the network layer (e.g.  Bundle I-D.ietf- mmusic-sdp-bundle-negotiation, RTCP-mux RFC5761 and Trickle ICE I- D.ietf-ice-trickle), but do not need to support the API functionality described there. </ins> 8.


concentrates on specifying the protocols and subprotocols that are needed to specify the interactions over the network.  This memo uses the term "WebRTC" (note the case used) to refer to the overall effort consisting of both IETF and W3C efforts.

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.

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.


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>  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>  Internet ethos, that "and then some" consists of having to use a specific vendor's product only.

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.

other party is willing to accept communication at the base level of that specification, you can communicate successfully.  <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  <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.


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>  This means that two vital interfaces need specification: The protocols that browsers use to talk to each other, without any

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.

3.  <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


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>  This memo uses the term "WebRTC" (note the case used) to refer to the overall effort consisting of both IETF and W3C efforts.

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

protocol suite is intended to enable all the applications that are described as required scenarios in the use cases document RFC7478.  <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.


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>  connections between entities, as well as the functions for deciding when to send data: Congestion management, bandwidth estimation and so on.

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."

The functionality groups that are needed in the browser can be specified, more or less from the bottom up, as:  <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.


("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>  If the two Web servers are operated by different entities, the inter- server signaling mechanism needs to be agreed upon, either by

Mirja had the following comment/nit: massage the signals": not sure if "massage" is actually a meaningful word here…

("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,  <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


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>  The choice of protocols for client-server and inter-server signalling, and definition of the translation between them, is

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.

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  <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


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>  such a way that it is possible to build a signaling gateway between SIP and the WebRTC media negotiation.

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”.

The following principles apply: The WebRTC media negotiations will be capable of representing the  <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.


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>  application through browser APIs. As for all protocol and API specifications, there is no restriction

LGMT
ekr provided the following comment for s3: I would say HTTP(S) in this diagram.

intervening servers, and the APIs that are offered for a Javascript application to take advantage of the browser's functionality.  <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


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>  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>  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>  Presentation and control: What needs to happen in order to ensure that interactions behave in a non-surprising manner.  This can

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

Data transport: such as TCP, UDP and the means to securely set up connections between entities, as well as the functions for  <ins> deciding when to send data: congestion management, bandwidth </ins> estimation and so on.  <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  <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


invoked.  Both subject to constraints of the implementation, of course. <del> For the purpose of this document, we define the following terminology to talk about WebRTC things: </del>  <del> A WebRTC browser (also called a WebRTC User Agent or WebRTC UA) is something that conforms to both the protocol specification and the Javascript API cited above. </del>  <del> A WebRTC non-browser is something that conforms to the protocol specification, but does not claim to implement the Javascript API. This can also be called a "WebRTC device" or "WebRTC native application". </del>  <del> A WebRTC endpoint is either a WebRTC browser or a WebRTC non- browser.  It conforms to the protocol specification. </del>  <del> A WebRTC-compatible endpoint is an endpoint that is able to successfully communicate with a WebRTC endpoint, but may fail to meet some requirements of a WebRTC endpoint.  This may limit where in the network such an endpoint can be attached, or may limit the security guarantees that it offers to others.  It is not constrained by this specification; when it is mentioned at all, it is to note the implications on WebRTC-compatible endpoints of the requirements placed on WebRTC endpoints. </del>  <del> A WebRTC gateway is a WebRTC-compatible endpoint that mediates media traffic to non-WebRTC entities. </del>  All WebRTC browsers are WebRTC endpoints, so any requirement on a WebRTC endpoint also applies to a WebRTC browser. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. <del> 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 meaning. The list is in alphabetical order. Undefined term.  See "SDP Agent" and "ICE Agent". Application Programming Interface - a specification of a set of calls and events, usually tied to a programming language or an abstract formal specification such as WebIDL, with its defined semantics. Used synonymously with "Interactive User Agent" as defined in the HTML specification W3C.WD-html5-20110525.  See also "WebRTC User Agent". An abstraction that allows data to be sent between WebRTC endpoints in the form of messages.  Two endpoints can have multiple data channels between them. An implementation of the Interactive Connectivity Establishment (ICE) I-D.ietf-ice-rfc5245bis protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166). Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another party, and the reaction can be observed by the first party, with the total time required for the action/reaction/observation is on the order of no more than hundreds of milliseconds. Audio and video content.  Not to be confused with "transmission media" such as wires. The path that media data follows from one WebRTC endpoint to another. A specification of a set of data units, their representation, and rules for their transmission, with their defined semantics.  A protocol is usually thought of as going between systems. Media where generation of content and display of content are intended to occur closely together in time (on the order of no more than hundreds of milliseconds).  Real-time media can be used to support interactive communication. The protocol implementation involved in the Session Description Protocol (SDP) offer/answer exchange, as defined in RFC3264 section 3. Communication that happens in order to establish, manage and control media paths and data paths. The communication channels used between entities participating in signaling to transfer signaling.  There may be more entities in the signaling path than in the media path. </del> 3. For browser-based applications, the model for real-time support does

ekr had the following comment: S 2.4. Why do you have two terminology sections? I would merge them.
Most of my comments are consequential.

invoked.  Both subject to constraints of the implementation, of course.  <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 meaning. </ins>  <ins> Undefined term.  See "SDP Agent" and "ICE Agent". </ins>  <ins> A specification of a set of calls and events, usually tied to a programming language or an abstract formal specification such as WebIDL, with its defined semantics. </ins>  <ins> Used synonymously with "Interactive User Agent" as defined in the HTML specification W3C.WD-html5-20110525.  See also "WebRTC User Agent". </ins>  <ins> An abstraction that allows data to be sent between WebRTC endpoints in the form of messages.  Two endpoints can have multiple data channels between them. </ins>  <ins> An implementation of the Interactive Connectivity Establishment (ICE) I-D.ietf-ice-rfc5245bis protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166). Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another party, and the reaction can be observed by the first party, with the total time required for the action/reaction/observation is on the order of no more than hundreds of milliseconds. Audio and video content.  Not to be confused with "transmission media" such as wires. The path that media data follows from one WebRTC endpoint to another. A specification of a set of data units, their representation, and rules for their transmission, with their defined semantics.  A protocol is usually thought of as going between systems. Media where generation of content and display of content are intended to occur closely together in time (on the order of no more than hundreds of milliseconds).  Real-time media can be used to support interactive communication. The protocol implementation involved in the Session Description Protocol (SDP) offer/answer exchange, as defined in RFC3264 section 3. Communication that happens in order to establish, manage and control media paths and data paths. The communication channels used between entities participating in signaling to transfer signaling.  There may be more entities in the signaling path than in the media path. (also called a WebRTC User Agent or WebRTC UA) Something that conforms to both the protocol specification and the Javascript API cited above. Something that conforms to the protocol specification, but does not claim to implement the Javascript API.  This can also be called a "WebRTC device" or "WebRTC native application". Either a WebRTC browser or a WebRTC non-browser.  It conforms to the protocol specification. An endpoint that is able to successfully communicate with a WebRTC endpoint, but may fail to meet some requirements of a WebRTC endpoint.  This may limit where in the network such an endpoint can be attached, or may limit the security guarantees that it offers to others.  It is not constrained by this specification; when it is mentioned at all, it is to note the implications on WebRTC-compatible endpoints of the requirements placed on WebRTC endpoints. A WebRTC-compatible endpoint that mediates media traffic to non- WebRTC entities. </ins> All WebRTC browsers are WebRTC endpoints, so any requirement on a WebRTC endpoint also applies to a WebRTC browser. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.  3. For browser-based applications, the model for real-time support does


Overview: Real Time Protocols for Browser-based Applications <del> draft-ietf-rtcweb-overview-16 </del>  Abstract participants. This document is intended to serve as the roadmap to the WebRTC <del> specifications.  It defines terms used by other pieces of specification, lists references to other specifications that don't need further elaboration in the WebRTC context, and gives pointers to other documents that form part of the WebRTC suite. </del>  By reading this document and the documents it refers to, it should be possible to have all information needed to implement an WebRTC 2.2. <del> The total WebRTC effort consists of two pieces: </del>  A protocol specification, done in the IETF <del> A Javascript API specification, done in the W3C </del>  Together, these two specifications aim to provide an environment <del> where Javascript embedded in any page, viewed in any compatible browser, when suitably authorized by its user, is able to set up communication using audio, video and auxiliary data, where the browser environment does not constrain the types of application in which this functionality can be used. </del>  The protocol specification does not assume that all implementations implement this API; it is not intended to be necessary for HTML specification W3C.WD-html5-20110525.  See also "WebRTC User Agent".  An implementation of the Interactive Connectivty Establishment <del> (ICE) RFC5245 protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle). </del>  Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another exchange, as defined in RFC3264 section 3. Communication that happens in order to establish, manage and <del> control media paths. </del>  The communication channels used between entities participating in signaling to transfer signaling.  There may be more entities in conjunction with its backend servers, to implement these functions. This means that two vital interfaces need specification: The <del> protocols that browsers talk to each other, without any intervening servers, and the APIs that are offered for a Javascript application to take advantage of the browser's functionality. </del>  <del> Note that HTTP and Websockets are also offered to the Javascript </del>  application through browser APIs. As for all protocol and API specifications, there is no restriction For example, if both operators' servers implement SIP, SIP could be used for communication between servers, along with either a <del> standardized signaling mechanism (e.g.  SIP over Websockets) or a </del>  proprietary signaling mechanism used between the application running in the browser and the web server.  Similarly, if both operators' servers implement XMPP, XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g. <del> XMPP over Websockets or BOSH) or a proprietary signaling mechanism </del>  used between the application running in the browser and the web server. <del> The choice of protocols, and definition of the translation between them, is outside the scope of the WebRTC protocol suite described in the document. </del>  The functionality groups that are needed in the browser can be specified, more or less from the bottom up, as: deciding when to send data: Congestion management, bandwidth estimation and so on. <del> Data framing: RTP and other data formats that serve as containers, and their functions for data confidentiality and integrity. </del>  Data formats: Codec specifications, format specifications and functionality specifications for the data passed between systems.

From Magnus, on mailing list, with response: Actually both the IETF effort and the W3C effort consists of lots of moving parts. Would "A Javascript API, defined by a set of specifications [cite]" scan better?
"This means that two vital interfaces need specification: The protocols that browsers talk to each other, without any intervening servers, and the APIs that are offered for a Javascript application to take advantage of the browser's functionality." I would add a "use to" between "browsers" and "talk"
You write "Websockets" in many places. The w3c spec seems to prefer "WebSockets"
"The choice of protocols, and definition of the translation between them, is outside the scope of the WebRTC protocol suite described in the document." I would like to add "inter-server signaling" before "protocols" to be very clear here.
"Data framing: RTP and other data formats that serve as containers, and their functions for data confidentiality and integrity." Should SCTP be mentioned here for clarity?
All suggestions taken except the "inter-server signalling" one - the choice of protocols for client-server signalling is also out of scope for this document, so I added "client-server and inter-server" instead.
"ICE Agent: An implementation of the Interactive Connectivty Establishment (ICE) [RFC5245] protocol. An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle)." Just a not to verify that this is right: RFC 5245 defines "Agent" the same way as this document specifies "SDP agent" and refers to RFC 3264 for a definition of Agent. The term "Ice Agent" appear later in the terminology section though not as a separate definition but as an explanation of controlling and controlled agent... Nit picking here. ;-)
"Signaling: Communication that happens in order to establish, manage and control media paths." Signaling is also used for data channels
Data channels lack a term here. You have defined media and media path
Re Agent: RFC 5245 section 2 says "In a typical ICE deployment, we have two endpoints (known as AGENTS in RFC 3264 terminology) that want to communicate. They are able to communicate indirectly via some signaling protocol (such as SIP), by which they can perform an offer/answer exchange of SDP [RFC3264] messages." RFC 5245bis says "In a typical ICE deployment, we have two endpoints (known as ICE AGENTS) that want to communicate. They are able to communicate indirectly via some signaling protocol (such as SIP), by which they can exchange ICE candidates." The binding to SDP has apparently been loosened in 5245bis. I think we should move the reference to 5245bis - we already have normative dependencies on that from dualstack-fairness and bundle, so it's not a new blocker.
Added data channel and moved pointers to 5245bis.
" The total WebRTC effort consists of two pieces:" I would say "two major pieces" or "parts" since we have a lot of documents and components, so just saying two pieces seems an underestimation.
" Together, these two specifications aim to provide an environment where Javascript embedded in any page, viewed in any compatible browser, when suitably authorized by its user, is able to set up communication using audio, video and auxiliary data, where the browser environment does not constrain the types of application in which this functionality can be used." This is a very complex sentence. Can this be simplified?
I tried restructuring it.
"It defines terms used by other pieces of specification," Doesn't feel right to me, but I could be reading in Swenglish here. "other specifications" or "other pieces of specifications"
"other pieces of specification" should probably read "other parts of the WebRTC protocol suite". The intent was to capture that terms of art like "WebRTC browser" and "WebRTC endpoint" are defined here and used elsewhere.
Changed to "other parts of the WebRTC protocol specifications".
"This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web"." Later in the document you mention non-browsers such as gateways. Do you want to include them in the abstract? ..."to make sure all the parts"... I feel that "that" is missing between "sure" and "all"
Not really - the focus here is that it has to be usable on the Web. There's time enough to mention non-browsers later in the document. My English sense says that the sentence works both with and without "that" - I'll defer to native speakers of US-English for this one.
Closing as "no change needed" (editor's judgment).

Overview: Real Time Protocols for Browser-based Applications  <ins> draft-ietf-rtcweb-overview-17 </ins> Abstract participants. This document is intended to serve as the roadmap to the WebRTC  <ins> specifications.  It defines terms used by other parts of the WebRTC protocol specifications, lists references to other specifications that don't need further elaboration in the WebRTC context, and gives pointers to other documents that form part of the WebRTC suite. </ins> By reading this document and the documents it refers to, it should be possible to have all information needed to implement an WebRTC 2.2.  <ins> The total WebRTC effort consists of two major parts, each consisting of multiple documents: </ins> A protocol specification, done in the IETF  <ins> A Javascript API specification, defined in a series of W3C documents </ins> Together, these two specifications aim to provide an environment  <ins> where Javascript embedded in any page, when suitably authorized by its user, is able to set up communication using audio, video and auxiliary data, as long as the browser supports this specification. The browser environment does not constrain the types of application in which this functionality can be used. </ins> The protocol specification does not assume that all implementations implement this API; it is not intended to be necessary for HTML specification W3C.WD-html5-20110525.  See also "WebRTC User Agent". <ins> An abstraction that allows data to be sent between WebRTC endpoints in the form of messages.  Two endpoints can have multiple data channels between them. </ins> An implementation of the Interactive Connectivty Establishment  <ins> (ICE) I-D.ietf-ice-rfc5245bis protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle). </ins> Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another exchange, as defined in RFC3264 section 3. Communication that happens in order to establish, manage and  <ins> control media paths and data paths. </ins> The communication channels used between entities participating in signaling to transfer signaling.  There may be more entities in conjunction with its backend servers, to implement these functions. This means that two vital interfaces need specification: The  <ins> protocols that browsers use to talk to each other, without any intervening servers, and the APIs that are offered for a Javascript application to take advantage of the browser's functionality. </ins>  <ins> Note that HTTP and WebSockets are also offered to the Javascript </ins> application through browser APIs. As for all protocol and API specifications, there is no restriction For example, if both operators' servers implement SIP, SIP could be used for communication between servers, along with either a  <ins> standardized signaling mechanism (e.g.  SIP over WebSockets) or a </ins> proprietary signaling mechanism used between the application running in the browser and the web server.  Similarly, if both operators' servers implement XMPP, XMPP could be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g.  <ins> XMPP over WebSockets or BOSH) or a proprietary signaling mechanism </ins> 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 outside the scope of the WebRTC protocol suite described in the document. </ins> The functionality groups that are needed in the browser can be specified, more or less from the bottom up, as: deciding when to send data: Congestion management, bandwidth estimation and so on.  <ins> Data framing: RTP, SCTP and other data formats that serve as containers, and their functions for data confidentiality and integrity. </ins> Data formats: Codec specifications, format specifications and functionality specifications for the data passed between systems.


Transports for WebRTC <del> draft-ietf-rtcweb-transports-10 </del>  Abstract overview, which also defines terminology used in this document, including the terms "WebRTC device" and "WebRTC browser".  This document focuses on the data transport protocols that are used by conforming implementations, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT 4. The WebRTC prioritization model is that the application tells the <del> WebRTC implementation about the priority of media and data flows through an API. </del>  <del> The priority associated with a media or data flow is classified as "normal", "below normal", "high" or "very high".  There are only four </del>  priority levels at the API. The priority settings affect two pieces of behavior: Packet send based on the stream a packet belongs to. When an WebRTC implementation has packets to send on multiple streams <del> (with each media stream and each data channel considered as one "stream" for this purpose) that are congestion-controlled under the same congestion controller, the WebRTC implementation SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given approximately twice the transmission capacity (measured in payload bytes) of the level below. Thus, when congestion occurs, a "very high" priority flow will have the ability to send 8 times as much data as a "below normal" flow if </del>  both have data to send.  This prioritization is independent of the media type.  The details of which packet to send first are implementation defined. <del> For example: If there is a very high priority audio flow sending 100 byte packets, and a normal priority video flow sending 1000 byte packets, and outgoing capacity exists for sending >5000 payload bytes, it would be appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes (one packet) of video as the result of a single pass of sending decisions. </del>  <del> Conversely, if the audio flow is marked normal priority and the video flow is marked very high priority, the scheduler may decide to send 2 </del>  video packets (2000 bytes) and 5 audio packets (500 bytes) when outgoing capacity exists for sending > 2500 payload bytes. <del> If there are two very high priority audio flows, each will be able to send 4000 bytes in the same period where a normal priority video flow is able to send 1000 bytes. </del>  Two example implementation strategies are:

Updated terminology.
On reading the document, I find that the term "media flow" is used where draft-ietf-avtext-rtp-grouping-taxonomy suggests "source stream". Still open what to use instead of "data flow". "Data stream"?
After reconsidering, I added a definition for "flow" instead. Let's see how that scans.
rtcweb-transport: "normal", "below normal", "high" or "very high". tsvwg-rtcweb-qos: “very low”, “low”, “medium”, “high”. WEBRTC-PC: enum RTCPriorityType { "very-low", "low", "medium", "high" }; The majority should win.

Transports for WebRTC  <ins> draft-ietf-rtcweb-transports-11 </ins> Abstract overview, which also defines terminology used in this document, including the terms "WebRTC device" and "WebRTC browser". <ins> Terminology for RTP sources is taken fromRFC7656 . </ins> This document focuses on the data transport protocols that are used by conforming implementations, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT 4. The WebRTC prioritization model is that the application tells the  <ins> WebRTC implementation about the priority of media and data that is controlled from the API. In this context, a "flow" is used for the units that are given a specific priority through the WebRTC API. For media, a "media flow", which can be an "audio flow" or a "video flow", is what RFC7656 calls a "media source", which results in a "source RTP stream" and one or more "redundancy RTP streams".  This specification does not describe prioritization between the RTP streams that come from a single "media source". A "data flow" is the outgoing data on a single WebRTC data channel. </ins>  <ins> The priority associated with a media flow or data flow is classified as "very-low", "low", "medium or "high".  There are only four </ins> priority levels at the API. The priority settings affect two pieces of behavior: Packet send based on the stream a packet belongs to. When an WebRTC implementation has packets to send on multiple streams  <ins> that are congestion-controlled under the same congestion controller, the WebRTC implementation SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given approximately twice the transmission capacity (measured in payload bytes) of the level below. Thus, when congestion occurs, a "high" priority flow will have the ability to send 8 times as much data as a "very-low" priority flow if </ins> both have data to send.  This prioritization is independent of the media type.  The details of which packet to send first are implementation defined.  <ins> For example: If there is a high priority audio flow sending 100 byte packets, and a low priority video flow sending 1000 byte packets, and outgoing capacity exists for sending >5000 payload bytes, it would be appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes (one packet) of video as the result of a single pass of sending decisions. </ins>  <ins> Conversely, if the audio flow is marked low priority and the video flow is marked high priority, the scheduler may decide to send 2 </ins> video packets (2000 bytes) and 5 audio packets (500 bytes) when outgoing capacity exists for sending > 2500 payload bytes.  <ins> If there are two high priority audio flows, each will be able to send 4000 bytes in the same period where a low priority video flow is able to send 1000 bytes. </ins> Two example implementation strategies are:


Transports for WebRTC <del> draft-ietf-rtcweb-transports-11 </del>  Abstract exposing addresses to the application or using them in ICE.  This is consistent with the default policy described in RFC6724.  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>  There exist a number of schemes for achieving quality of service that do not depend solely on DSCP code points.  Some of these schemes

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)

Transports for WebRTC  <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.  <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


(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>  specified in RFC7639, and proxy authentication as described in Section 4.3.6 of RFC7231 and RFC7235 MUST also be supported.

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.

(300 Try Alternate) MUST be supported. The WebRTC implementation MAY support accessing the Internet through  <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.


Transports for WebRTC <del> draft-ietf-rtcweb-transports-12 </del>  Abstract based on the stream a packet belongs to. When an WebRTC implementation has packets to send on multiple streams <del> that are congestion-controlled under the same congestion controller, the WebRTC implementation SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given </del>  approximately twice the transmission capacity (measured in payload bytes) of the level below. 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 RFC7657. </del>  There exist a number of schemes for achieving quality of service that do not depend solely on DSCP code points.  Some of these schemes

From Michael Welzl, rtcweb mailing list, March 2016: Hi, On 26 February, I sent an email to rtcweb in which I made some suggestions to this document. I see that these have not been incorporated, and my email has also never been answered (except that I-D.ietf-dart-dscp-rtp was replaced by RFC 7657, but that may not have been due to my email). I can understand that: probably my prior email just drowned in the WebRTC Audio Codec related thread. However I do think that these comments would be good to address, so I'm copying in the email again below. Cheers, Michael Hi, Overall, I like this document a lot - it makes for a very good read! but I think it would make sense for section 4.1 to explicitly point to draft-ietf-rmcat-coupled-cc (the next version of which is going to explain how weights much be set to adhere to the priority levels that are described in this section; it's easy, we just didn't have this text in there yet). To be concrete, I suggest the following two changes: When an WebRTC implementation has packets to send on multiple streams that are congestion-controlled under the same congestion controller, the WebRTC implementation SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given approximately twice the transmission capacity (measured in payload bytes) of the level below. should be: When a WebRTC implementation has packets to send on multiple streams that are congestion-controlled under the same congestion controller or multiple coupled congestion controllers (e.g. using the mechanism in [draft-ietf-rmcat-coupled-cc]), the WebRTC implementation SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given approximately twice the transmission capacity (measured in payload bytes) of the level below. (note a fixed nit in there: the second word is "a" instead of "an") and, perhaps even more importantly, a small change in section 4.2: More advice on the use of DSCP code points with RTP is given in [I-D.ietf-dart-dscp-rtp]. should be: More advice on the use of DSCP code points with RTP as well as coupled congestion control is given in [I-D.ietf-dart-dscp-rtp]. and in fact I-D.ietf-dart-dscp-rtp should now be RFC 7657. Cheers, Michael
NAME - what's your recommendation on this?
NAME I regard the mention of coupled CC as mostly "pointless but harmless". The initial decision to mention a single controller was to mention only the most restricted case; if the chairs think extending this to coupled CC is OK, I don't have any strong reason to push back against it. The extensive use of "common (coupled)" in RFC 7657 is (in my opinion) a mistake; these two are not the same thing, and I can't see that RFC 7657 is really clear about the difference.
individual contributor opinion only here as I the chairs would mostly be trying to figure out list consensus and that mostly seemed fine with current text ... I'm hesitant to introduce in the "coupled" term and ref to draft as it is not clear where all of RMCAT is going yet and it seems like we could have text that was broad enough to include draft-ietf-rmcat-coupled-cc with being explicitly tied to just that. So i'd probbably lean towards something like More advice on the use of DSCP code points with RTP as well as congestion control is given in [I-D.ietf-dart-dscp-rtp]. instead of More advice on the use of DSCP code points with RTP as well as coupled congestion control is given in [I-D.ietf-dart-dscp-rtp]. only difference is the removal of the word "coupled" at end of first line
I used "congestion control regime" tin section 4.1 - this seems to be wide enough to include both a single congestion controller and multiple coupled congestion controllers. In section 4.2, I changed it to be "More advice on the use of DSCP code points with RTP and on the relationship between DSCP and congestion control is given in RFC 7657". This seems to achieve the point that you have to read RFC 7657 and references to get the right advice.

Transports for WebRTC  <ins> draft-ietf-rtcweb-transports-13 </ins> Abstract based on the stream a packet belongs to. When an WebRTC implementation has packets to send on multiple streams  <ins> that are congestion-controlled under the same congestion control regime, the WebRTC implementation SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given </ins> approximately twice the transmission capacity (measured in payload bytes) of the level below. All packets on one TCP connection, no matter what it carries, MUST use a single DSCP code point.  <ins> More advice on the use of DSCP code points with RTP and on the relationship between DSCP and congestion control 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


Transports for WebRTC <del> draft-ietf-rtcweb-transports-08 </del>  Abstract The setup protocol for WebRTC data channels described in I-D.ietf- rtcweb-data-protocol MUST be supported.  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

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.

Transports for WebRTC  <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


Transports for WebRTC <del> draft-ietf-rtcweb-transports-13 </del>  Abstract specification does not describe prioritization between the RTP streams that come from a single "media source".  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

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)

Transports for WebRTC  <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


of packets with certain DSCP markings.  The detection of these conditions is implementation dependent.  All packets carrying data from the SCTP association supporting the data channels MUST use a single DSCP code point.  The code point used SHOULD be that recommended by I-D.ietf-tsvwg-rtcweb-qos for the A sending implementation MUST be able to support the following configurations: <del> multiplex all media and data on a single 5-tuple (fully bundled) </del>  <del> send each media stream on its own 5-tuple and data on its own </del>  5-tuple (fully unbundled) It MAY choose to support other configurations, such as bundling each

Note that this differs from what was said at the IETF meeting - after considering, I didn't see a reason to recommend ICE restart. The text does not contain MUST or SHOULD. This is implementation advice.
FWIW ... This looks good to me
Per Martin, need to be explicit that switching to DSCP 0 needs doing for the media type as a whole, because the DSCP codepoints in a transport are chosen for compatibility on classes (AF4x for instance).
From Magnus Westerlund in IETF LC: Section 4.2: The implementation MAY turn off use of DSCP markings if it detects symptoms of unexpected behaviour like priority inversion or blocking of packets with certain DSCP markings. The detection of these conditions is implementation dependent. As raised on the TSVWG and RTCWEB mailing list recently in regards to draft-ietf-tsvwg-rtcweb-qos there have been a recent study (URL) showing that non zero DSCP values resulted in consistent failures in 10-13% of the tested paths. So I think it worth considering if this text needs to be sharpen, and possibly actually point to a solution that needs to be specified?
Resolution in WG in Berlin: "We will treat DSCP-induced path failure parallel with other types of path failure, and resolve it by using an ICE restart". Note: There is a problem with multiple DSCP codepoints on a single transport, where one might be blocked and another might get through. In this case, the ICE probes (using one DSCP code point) may succeed while others fail. This is complex, and should be warned about - likely mode of solution is ICE restart with DSCP markings turned off, but detection requires watching the multiple DSCP-codepoint-using channels for differential failures. See minutes for details.
From Martin Thomson: URL - I know what you mean, of course. Presumably if DSCP 0 passes, but probes with DSCP N fails, only traffic that was intended to be sent with DSCP N would be sent with DSCP 0. If DSCP M succeeds, then you could continue to use that; your text implies otherwise. You might like to point out that switching DSCP marking mid-flow can have negative effects on things like congestion controllers and loss recovery.

of packets with certain DSCP markings.  The detection of these conditions is implementation dependent. <ins> A particularly hard problem is when one media transport uses multiple DSCP code points, where one may be blocked and another may be allowed.  This is allowed even within a single media flow for video in I-D.ietf-tsvwg-rtcweb-qos.  Implementations need to diagnose this scenario; one possible implementation is to send initial ICE probes with DSCP 0, and send ICE probes on all the DSCP code points that are intended to be used once a candidate pair has been selected.  If one or more of the DSCP-marked probes fail, the sender will switch the media type to using DSCP 0.  This can be carried out simultaneously with the initial media traffic; on failure, the initial data may need to be resent.  This switch will of course invalidate any congestion information gathered up to that point. Failures can also start happening during the lifetime of the call; this case is expected to be rarer, and can be handled by the normal mechanisms for transport failure, which may involve an ICE restart. Note that when a DSCP code point causes non-delivery, one has to switch the whole media flow to DSCP 0, since all traffic for a single media flow needs to be on the same queue for congestion control purposes.  Other flows on the same transport, using different DSCP code points, don't need to change. </ins> All packets carrying data from the SCTP association supporting the data channels MUST use a single DSCP code point.  The code point used SHOULD be that recommended by I-D.ietf-tsvwg-rtcweb-qos for the A sending implementation MUST be able to support the following configurations:  <ins> Multiplex all media and data on a single 5-tuple (fully bundled) </ins>  <ins> Send each media stream on its own 5-tuple and data on its own </ins> 5-tuple (fully unbundled) It MAY choose to support other configurations, such as bundling each


addresses.  This is a change from the rules specified by RFC3484. For applications that select a single address, this is usually done by the IPV6_PREFER_SRC_TMP preference flag specified in RFC5014. <del> However, this rule is not completely obvious in the ICE scope.  This is therefore clarified as follows: When a client gathers all IPv6 addresses on a host, and both temporary addresses and permanent addresses of the same scope are present, the client SHOULD discard the permanent addresses before exposing addresses to the application or using them in ICE.  This is consistent with the default policy described in RFC6724. </del>  If some of the temporary IPv6 addresses, but not all, are marked <del> deprecated, the client SHOULD discard the deprecated addresses. </del>  3.4.

NAME please review
From Magnus Westerlund in Last Call: . Section 3.3: When a client gathers all IPv6 addresses on a host, and both temporary addresses and permanent addresses of the same scope are present, the client SHOULD discard the permanent addresses before exposing addresses to the application or using them in ICE. This is consistent with the default policy described in [RFC6724]. If some of the temporary IPv6 addresses, but not all, are marked deprecated, the client SHOULD discard the deprecated addresses. I haven't noticed this before, but if you have both permanent and temporary addresses, can all the temporary be marked deprecated? If that can occur, does this specification need to say something in this case which should be used, a deprecated temporary or a permanent one?
Adding "non-deprecated" in front of "temporary" - that seems reasonable. NAME OK with you?
From Spencer Dawkins in IESG review:
From Suresh Krishnan in IESG review: In Section 3.3. Usage of temporary IPv6 addresses, the draft states " The IPv6 default address selection specification [RFC6724] specifies that temporary addresses [RFC4941] are to be preferred over permanent addresses." While this is technically true, this is only the seventh rule in an ordered list of eight rules. e.g. A valid permanent address would be preferred over a deprecated temporary address based on Rule 3. If a host had only a valid permanent address and a deprecated temporary address, the mechanism specified in the draft would result in no addresses being made available, whereas the permanent address would have been an acceptable choice using RFC6724. So, it is not entirely clear to me what the draft is trying to accomplish. It says " However, this rule is not completely obvious in the ICE scope. This is therefore clarified as follows:" What rule is this talking about when it says "this rule"? Similarly, it also says "When a client gathers all IPv6 addresses on a host..." but it is not clear what "client" the draft is referring to. I think if you can clarify what you want to achieve with the address selection we can work together on some replacement text.

addresses.  This is a change from the rules specified by RFC3484. For applications that select a single address, this is usually done by the IPV6_PREFER_SRC_TMP preference flag specified in RFC5014.  <ins> However, this rule, which iis intended to ensure that privacy- enhanced addresses are used in preference to static addresses, doesn't have the right effect in ICE, where all addresses are gathered and therefore revealed to the application.  Therefore, the following rule is applied instead: When a client gathers all IPv6 addresses on a host, and both non- deprecated temporary addresses and permanent addresses of the same scope are present, the client SHOULD discard the permanent addresses before 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  <ins> deprecated, the client SHOULD discard the deprecated addresses.  In an ICE restart, deprecated addresses that are currently in use MAY be retained. </ins> 3.4.


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>  Protocol identification MUST be supplied as part of the DTLS handshake, as specified in I-D.ietf-rtcweb-alpn.

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.

WebRTC implementations MUST support multiplexing of DTLS and RTP over the same port pair, as described in the DTLS-SRTP specification  <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.


STUN - Session Traversal Utilities for NAT, <del> ICE - Interactive Connectivity Establishment, RFC5245 </del>  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>  A receiving implementation MUST be able to receive media and data in all these configurations.

Also do reformatting (xxe equivalent of tidy).
From Ben Campbell's IESG comments:

STUN - Session Traversal Utilities for NAT,  <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).  <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.


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>  5.7.

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.

can fail to generate an assertion and instead indicate a URL where login should proceed.  <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.