Ready with Nits

Reviewer: Nancy Cam-Winget
I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document describes how streaming applications may use network and 
transport protocol and presents some challenges or issues as either or both
the use cases and protocols continue to evolve.  The goal of the authors is
to provide a snapshot overview of the requirements and challenges current
streaming applications on the network protocols to serve as a reference
for future design and protocol proposals.

I have reviewed the document from the perspective of security requirements/
considerations. Section 7 focuses on this topic and scopes the description to
how media is encrypted at the transport layer only and asserts that it does not
validate the encryption goals.  With that in mind, the subsections do provide
a cursory view of how encryption is applied.  As it is not a security considerations
section (or security focused document) it lacks depth in the security and privacy
requirements or challenges.  For instance, no mention to the use of specific
cipher suites nor requiring strong authentication and
key management mechanisms when using the encryption.

I have a couple of nits that can help clarify intent and descriptions in the 
document:
-	Section 3.2: I believe the last paragraph is trying to point out that there
bottlenecks can exist at both different nodes/hops in the network, endpoint
and service but I believe there are also bottlenecks that can exist or be addressed
by proper configuration at the different levels of the OSI stack 
(e.g. Wifi/cellular/ethernet link layer, TCP/UDP to application layer).  But the 
reference to a “link” can benefit from including better qualification.

-	Section 4.1: better quantification of the number of users it can serve is needed
as better guidance (vs. “…do not need to scale to more than a few users at a time”)
As I can see live media events (like conference calls?) where there could be up to
a hundred users (whether recommended or not!) attempting to hold a collaborative
conversation (e.g. live video, audio and other resources like whiteboarding)

-	Section 5.4 2nd paragraph pg. 20 speaks to potential privacy (and security)
violations as ad fraud.  As a non-expert in the full live-streaming workflow with ads
but a security expert, a better description of the current workflow or mention that the
misreporting is out of scope (?) is needed.  If the intent is to provide guidance for future
design and protocol improvements, at least a reference to how current solutions work
and fail is required.

-	Section 5.5.3 – have the authors considered how QoS signaling at the link layer 
like 802.11e and 802.11u help or affect performance?  

Editorial nits:
-	Section 3.4 pg 10 last paragraph.  The 2nd sentence “For example, with the
emergence of ultra-low-latency streaming…..” is an awkward sentence.  I suggest 
To break it into two sentences.
-	Secion 5.5.3: typo “detection” is misspelled