Hello, 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. -- One minor comment first: It is said that "Differences in playout time exceeding configured limits (e.g. more than ten seconds) could be an indication of such inconsistent information." But it could as well be caused by a misbehaving receiver (e.g. with an intermittent connection) who should better be removed from the destination set altogether. So I wouldn't speak of "inconsistent information", but rather "out of bound information" since this situation is "consistent" with the real situation. Then, using "configured limits" is necessary, sure, but not sufficient. What if an attacker periodically reports values that are just below this configured limit? They should be accepted whereas they will negatively impact the session. And you cannot reduce indefinitely the configured limits. A third comment. The document only mentions devices (in the example) that report erroneous information. The problem is broader than that. The attacker may also be on the route between a legitimate destination to the source, and be able to alter the report message. Or the attacker may be able to forge a packet with erroneous information, masquerading as a legitimate receiver. So it would be great to broaden the problem statement with that in mind. And then it quickly leads to the idea of message integrity verification (to combat packet modification) and source authentication (to combat masquerading). You should say something on it. Of course, the same comments apply for the messages sent on the other direction, from source to destinations. A reference to SRTP is missing. Please add. Finally, since everything depends on precise time synchronization, it should be highlighted that having a secure time synchronization service is absolutely required. Otherwise this is another potential means to attack the session. Cheers, Vincent