[rtcweb] Mirja Kühlewind's No Objection on draft-ietf-rtcweb-overview-18: (with COMMENT)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind 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:
----------------------------------------------------------------------

One high level comments on normative language:
While I think this document is very useful to explain the relationship
between the other webrtc documents and serves a a good starting point for
an implementor, I'm not sure if the use of normative language is actually
helpful. Most of the language is used to say that a webrtc endpoint MUST
implement a certain other document. However, I believe this is inherently
necessary to achieve interoperability. So I don't see a need to specify
this normatively.

In regard to the shepherd write-up, I just want to note that using
normative language does not automatically make the document Standards
Track; there are many informational docs that use normative language. As
such, I don't want raise a big discussion on status now, but this
document sounds more informational to me (giving pointers to other
document). However, I don't object to publication on Standards Track.

minor comments:
1) I would not need all the text on the history of Internet communication
in this doc (especially all text on page 3 in the intro as well as
section 2.3 and the second to last paragraph in 3)... however, I guess it
doesn't hurt

2) Agree with Warren that 'Protocol' probably doesn't need to be
(re)defined in this doc

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

nit:
-"massage the signals": not sure if "massage" is actually a meaningful
word here…