[rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-overview-18: (with COMMENT)

[Spencer Dawkins <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-rtcweb-overview-18: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I've been waiting for this one, for a while. Thanks for finishing it. I'm
a Yes, with comments.

I agree with EKR that there's a lot of general philosophy in this draft.
I wouldn't ask that you pull all of it, but perhaps it could be trimmed
down a bit.

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.

The term of art "floor control" is likely to be new to many readers in
the future. Since it appears in a list of non-niche examples, maybe you
don't need it at all?

I'm not sure whether "let a thousand flowers bloom" is a reference to the
Hundred Flowers campaign in 1956, but (1) that ended very badly for the
bloomers, and (2) I could easily imagine the phrase tripping DPI
filtering for a specific part of the Internet community. Maybe there's a
better phrase?

I'm not sure how tutorial you want section 4 to be, but I'd at least
mention appropriate retransmission and in-order delivery, in addition to
congestion control, since you get that with SCTP on the data channel.

4.  Data transport

   Data transport refers to the sending and receiving of data over the
   network interfaces, the choice of network-layer addresses at each
end
   of the communication, and the interaction with any intermediate
   entities that handle the data, but do not modify it (such as TURN
   relays).

   It includes necessary functions for congestion control: When not to
   send data.
   
Or maybe you can just chop that sentence, because the next paragraph
points to https://tools.ietf.org/html/draft-ietf-rtcweb-transports-06,
anyway?

I found the reference to MMUSIC WG in

   3.  When a new codec is specified, and the SDP for the new codec is
       specified in the MMUSIC WG, no other standardization should be
       required for it to be possible to use that in the web browsers.

to be odd. MMUSIC may be around forever, but this work might be
refactored at some point in the future. Is the point that 

   3.  When SDP for a new codec is specified, 
       no other standardization should be
       required for it to be used in the web browsers.
       
Or is there another way to say this?

I'm also wondering if the statement is true for any WebRTC endpoint, not
just browsers.

In this text,

   WebRTC endpoints MUST implement the functions described in that
   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.
   
I would have thought these were related to the transport layer. No?