Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS
RFC 8837
Yes
No Objection
Note: This ballot was opened for revision 16 and is now closed.
Alvaro Retana No Objection
(Alissa Cooper; former steering group member) Yes
I would suggest doing a pass through the document to check for uses of the term "browser" and "non-browser" to see if they could or should align with the terms defined in RFC 7742. It's not obvious to me why this document is using a different definition of "browser" than is used in that document.
(Ben Campbell; former steering group member) Yes
I had the same comment as Alissa.
(Mirja Kühlewind; former steering group member) Yes
A very well-written document! Thanks for all the work! One question: the doc says: "This specification [...] does not change any advice or requirements in other IETF RFCs. The contents of this specification are intended to be a simple set of implementation recommendations based on the previous RFCs." This sounds like an information doc for me. However, I'm okay with standards track as this should be consistently applied by WebRTC browsers. Just wondering if this was discussed (because it also reads like this change in scope was applied in a later phase of the live-time of this doc)?
(Spencer Dawkins; former steering group member) Yes
(Alexey Melnikov; former steering group member) No Objection
(Alia Atlas; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
still ok with it
(Kathleen Moriarty; former steering group member) No Objection
I agree with Stephen's comment.
(Stephen Farrell; former steering group member) No Objection
I was a little surprised that there's no additional security considerations due to the fact that JS can set the application priority - isn't that different enough (from earlier uses of DSCP) that a browser might want to be a little suspicious if some JS wants to try send too much stuff as high priority, given that that same JS code might be running on many many browsers all at once for a while after some WebRTC server has been hacked? Or do we conclude that that won't make any real difference or make it easier for such JS malware to cause some kind of DoS somewhere?
(Suresh Krishnan; former steering group member) No Objection
Section 5: The draft claims that "Currently, all WebRTC video is assumed to be interactive" and makes a reference to [I-D.ietf-rtcweb-transports], but the referred draft does not contain any explanation regarding this. Is this some kind of well known fact in WebRTC circles? If so, is it documented somewhere? Section 8: Is this really required to be in the document? The shepherd writeup does explain the rationale for the downrefs.
(Terry Manderson; former steering group member) No Objection