Skip to main content

Last Call Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-10

Request Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard
Requested revision No specific revision (document currently at 14)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-03-15
Requested 2013-03-07
Authors Alan Clark , Rachel Huang , Qin Wu
I-D last updated 2013-04-18
Completed reviews Genart Last Call review of -10 by Vijay K. Gurbani (diff)
Genart Telechat review of -13 by Vijay K. Gurbani (diff)
Secdir Last Call review of -10 by Matt Lepinski (diff)
Assignment Reviewer Matt Lepinski
State Completed
Review review-ietf-xrblock-rtcp-xr-burst-gap-discard-10-secdir-lc-lepinski-2013-04-18
Reviewed revision 10 (document currently at 14)
Result Has nits
Completed 2013-04-18
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.

Summary: In my opinion this document is acceptable. I have no concerns with
this document.

This document describes a new RTCP block for use in the RTCP eXtended Reporting
(XR) framework. The block specified in this protocol is a companion to the
block specified in

draft-ietf-xrblock-rtcp-xr-discard. Where I-D.xrblock-rtcp-xr-discard allows a
receiver to report the number of packets discarded without being used (played
out), this current draft allows a receiver to provide additional data regarding
the pattern of discarded packets. That is, how many of the discarded packets
arrived during intervals of high discard rate (i.e., intervals of poor quality
due to many discards).

The document authors claim that this draft introduces no new security
considerations beyond those described in RFC 3611 (RTCP eXtended Reports). I
agree with this assessment.

I did have one minor question about Section 3.2. I admit that I am not an RTCP
expert, but I was confused by the description of the Threshold value. The
document says that the Threshold is calculated in the same way Gmin is
calculated in 3611. However, in 3611 it appears that Gmin is a value configured
by the receiver (Recommended to be 16, but can be set to any non-zero value the
receiver desires.) Am I correct in assuming that Threshold is also a configured
value sent by the receiver?

Finally, do you expect implementations to use both the VoIP Metrics block and
the Burst/Gap Discard block together (for the same RTP session)? If so, is it
important that the Threshold in the Burst/Gap Discard block be set to the same
value as the Gmin value in the VoIP Metrics block? (If there are any problems
that would arise if the two parameters were set to different values, those
should be mentioned. If there are no anticipated issues with setting the values
independently, then that's fine there is no need to say anything more than is
currently in the document.)