Subject: [rtcweb] AD evaluation: draft-ietf-rtcweb-overview-17

From: Alissa Cooper <[email-masked]>
Date: Wed, 22 Feb 2017 16:14:55 -0500

I have reviewed this document in preparation for IETF last call. While the document content appears mostly ready, I don't think it makes sense to send this document out for IETF LC while the security documents are expired. For community review and IESG evaluation I think those doing the reviewing need at a minimum to feel like the normative dependencies in this document are in roughly the shape they will be in when those dependency documents get published. So at a minimum I think revisions of the security documents need to be published before IETF LC for this document makes sense.

Otherwise I have one substantive comment below and some nits to be resolved together with Sean’s PRs.

Substantive comment:

= Section 9 =

"Certain parts of the system SHOULD conform to certain properties, for
   instance:

   o  Echo cancellation should be good enough to achieve the suppression
      of acoustical feedback loops below a perceptually noticeable
      level.

   o  Privacy concerns MUST be satisfied; for instance, if remote
      control of camera is offered, the APIs should be available to let
      the local participant figure out who's controlling the camera, and
      possibly decide to revoke the permission for camera usage.

   o  Automatic gain control, if present, should normalize a speaking
      voice into a reasonable dB range."

I think there are some problematic uses of normative language here. Saying systems SHOULD conform to "certain properties" but not listing what all of those properties are and not defining them precisely seems problematic since implementers aren't being given clear directives. Likewise, the second bullet's MUST is quite vague and again just gives examples of how to comply rather than specifying precisely how. It's also confusing to use normative SHOULD in the heading but non-normative "should" in the bullets.

My suggestion would be to not use normative language in this part at all, since these aren't really hard requirements anyway. E.g., 

"Ideally certain parts of the system would conform to certain properties, for
   instance:

   o  Echo cancellation needs to be good enough to achieve the suppression
      of acoustical feedback loops below a perceptually noticeable
      level. 
   
   o  Privacy concerns need to be satisfied; for instance, if remote
      control of camera is offered, the APIs should be available to let
      the local participant figure out who's controlling the camera, and
      possibly decide to revoke the permission for camera usage.

   o  Automatic gain control, if present, needs to normalize a speaking
      voice into a reasonable dB range."

If you really want to use normative language here, I would suggest that the "shoulds" in the bullets become SHOULDs and the middle bullet provide precise guidance about what is required.

Nits to be resolved together with Sean's PRs:

= Section 2.2 =

Would be good to cite the protocol spec in the bulleted list at the top.

s/Javascript API defined above/Javascript API cited above/

= Section 2.4 =

A citation for Jingle should be included.

I don't really understand why this text is included or what it means:

"NOTE: Where common definitions exist for these terms, those
   definitions should be used to the greatest extent possible."

= Section 7 =

It would be good to include citations for Bundle, RTCP-mux and Trickle ICE.