Last Call Review of draft-ietf-xrblock-rtcp-xr-loss-conceal-10

Request Review of draft-ietf-xrblock-rtcp-xr-loss-conceal
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-04-08
Requested 2014-03-20
Authors Alan Clark, Glen Zorn, Claire Bi, Qin Wu
Draft last updated 2014-04-17
Completed reviews Genart Last Call review of -10 by Meral Shirazipour (diff)
Genart Telechat review of -11 by Meral Shirazipour (diff)
Secdir Last Call review of -10 by Steve Hanna (diff)
Opsdir Last Call review of -10 by Al Morton (diff)
Assignment Reviewer Steve Hanna 
State Completed
Review review-ietf-xrblock-rtcp-xr-loss-conceal-10-secdir-lc-hanna-2014-04-17
Reviewed rev. 10 (document currently at 12)
Review result Has Nits
Review completed: 2014-04-17


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 is "Ready with nits".

This document defines two RTCP XR Report Blocks that allow the
reporting of concealment metrics for audio applications of RTP.
In layman's terms, this allows an audio receiver to report back
on how much the audio is being mangled by packet loss.

>From a security perspective, this document is fine. The security
considerations section says that this document introduces no new
security considerations beyond those described in [RFC3611].
I agree.

I do have one nit that I wanted to ask about. At the very end of
section 3.2, the Mean Playout Interrupt Size is defined to be
32 bits long. However, the second paragraph of this definition

      If the measured value exceeds 0xFFFD, the value 0xFFFE MUST be
      reported to indicate an over-range measurement.  If the
      measurement is unavailable, the value 0xFFFF MUST be reported.

Shouldn't those constants be 0xFFFFFFFD, 0xFFFFFFFE, and 0xFFFFFFFF?



P.S. I apologize for sending this review late. However, I believe
that it's still before the IESG telechat on this document so I hope
that it will have some value.