Last Call Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-10
review-ietf-xrblock-rtcp-xr-burst-gap-discard-10-secdir-lc-lepinski-2013-04-18-00

Request Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard
Requested rev. no specific revision (document currently at 14)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-03-15
Requested 2013-03-07
Other Reviews Genart Last Call review of -10 by Vijay Gurbani (diff)
Genart Telechat review of -13 by Vijay Gurbani (diff)
Review State Completed
Reviewer Matt Lepinski
Review review-ietf-xrblock-rtcp-xr-burst-gap-discard-10-secdir-lc-lepinski-2013-04-18
Posted at http://www.ietf.org/mail-archive/web/secdir/current/msg03914.html
Reviewed rev. 10 (document currently at 14)
Review result Has Nits
Draft last updated 2013-04-18
Review completed: 2013-04-18

Review
review-ietf-xrblock-rtcp-xr-burst-gap-discard-10-secdir-lc-lepinski-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.)