Subject: [rtcweb] Warren Kumari's No Objection on draft-ietf-rtcweb-overview-18: (with COMMENT)

From: Warren Kumari <[email-masked]>
Date: Tue, 25 Apr 2017 08:11:32 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-rtcweb-overview-18: No Objection

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

Thank you -- I like these sort of overview documents for complex things
like WebRTC - they provide a newcomer to the technology a good place to
start, and help describe some of the reasons why things look the way they
do.

[ Edit: So, after more thought (and some discussion) I think that it
would be useful for the document to at least note the fact that
technologies like this mean that some of the existing operational
practices may need to change. For example, many enterprises perform QoS
based upon the fact that certain types of devices live in certain subnets
(e.g many phones get placed in a specific VLAN using LLDP or CDP). With
more real time content coming from browsers, these matching practices
break, and so operators may not be able to QoS mark / prioritize traffic
accordingly. Perhaps something like: "One of the implications of a
solution like WebRTC is that more real-time traffic will be sourced from
computers (and not dedicated devices like telephones or 
videoconferencing devices). This may have implications for operators
performing QoS marking and prioritization" ? This isn't really specific
to webrtc, but rather to a more general set of solutions like softphones
and the like, but is accelerated by WebRTC. ] 

I do have a few comments on the document itself - there are all minor /
bikeshedding and can be ignored if you choose:
1: "Development of The Universal Solution has proved hard, however, for
all the usual reasons."
 -- this is cute, but leaves people wondering what "all the usual reasons
are". Perhaps just "Development of The Universal Solution has, however, 
proved hard." (or just cut after the "however in the original").

2: I'm not sure why you have "Protocol" in the terminology section. It
doesn't seem like it is useful for the document, and this document
doesn't seem like the right place to (re) define it.

3: Acknowledgements: 
Funny spacing in "Olle E.     Johansson"