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 defines an RTCP extended report block for reporting the number of RTP payload bytes discarded from a stream after being received, due to packets arriving too early or too late. I believe this document is ready for publication, or nearly so. The Interval Metric (I) flag is described inconsistently with regard to the permissible values. The description of this flag indicates that only I=10 (Interval Duration) or I=11 (Cumulative Duration) are permitted, and that I=01 (Sampled Metric) is specifically prohibited. However, when discussing the meaning of the byte count, the meaning is described for I=11 and I=01 cases, rather than I=11 and I=10. This appears to be a typo, but should be corrected. Also, in the Interval Duration case, the byte count is described as being the number of bytes discarded "since the last RTCP XR Byte Discarded Block was received". In fact, since these blocks may be lost in transit, the sender of this report (the RTP receiver) cannot know which reports were received, and the interval is in fact since the last Byte Discarded block was _sent_. Further, some clarification is probably needed that we're actually talking about the last block with the same 'E' flag. That is, a block arriving with E=0 and I=10 describes bytes discarded due to arriving late since the last block with E=0, even if there was an intervening block with E=1. For the most part, the security considerations section of this document is fairly reasonable. However, one issue I do not see discussed is that senders relying on this information for tuning purposes may be tricked by an attacker into undesirable behavior. This may be one reason to apply appropriate integrity protection, but also suggests that senders take the reported values with a grain of salt. -- Jeffrey T. Hutzelman (N3NHS) Carnegie Mellon University - Pittsburgh, PA