Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS
draft-ietf-tsvwg-rtcweb-qos-18
Yes
(Spencer Dawkins)
No Objection
(Alexey Melnikov)
(Alia Atlas)
(Alvaro Retana)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Terry Manderson)
Note: This ballot was opened for revision 16 and is now closed.
Alissa Cooper Former IESG member
Yes
Yes
(2016-05-17 for -16)
Unknown
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 IESG member
Yes
Yes
(2016-05-18 for -16)
Unknown
I had the same comment as Alissa.
Mirja Kühlewind Former IESG member
Yes
Yes
(2016-05-17 for -16)
Unknown
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 IESG member
Yes
Yes
(for -16)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -16)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -16)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -16)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -16)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -16)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -16)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2016-05-18 for -16)
Unknown
still ok with it
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2016-05-18 for -16)
Unknown
I agree with Stephen's comment.
Stephen Farrell Former IESG member
No Objection
No Objection
(2016-05-18 for -16)
Unknown
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 IESG member
No Objection
No Objection
(2016-05-17 for -16)
Unknown
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 IESG member
No Objection
No Objection
(for -16)
Unknown