RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting
draft-ietf-xrblock-rtcp-xr-summary-stat-11

Note: This ballot was opened for revision 08 and is now closed.

(Gonzalo Camarillo) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Benoit Claise) (was Discuss) No Objection

Comment (2013-03-22 for -10)
Qin, thanks for continuous effort to improve your document, and clear my DISCUSS.
Regards, Benoit

(Ralph Droms) (was Discuss) No Objection

Comment (2013-03-07 for -09)
The text in section 3.1.2 describing the representation of loss rates
and in section 3.2.2 describing the representation of discard rates
now appears to be OK.

I trust the differences between these representations and the 8-bit
representations of similar rates in RFC 3611 will not be problematic
or confusing for implementors.

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2013-02-18 for -08)
The frame impairment block includes the total number of frames
received. I'm not sure if such information is new in XR blocks
or not, but that does suggest a potential attack that I don't
think is noted in 3611 and that might be worth a mention here.

If a bad actor knows that N seconds into a piece of media the
boss says "fire the chief security officer" and the bad actor
could DoS the video stream between "chief" and "security" then
the recipient(s) might take the wrong action. I guess you can
invent a load of amusing variants of this, but this new XR
block could provide the trigger for launching the DoS since it
says how many frames have been received in total. 

It is maybe a little silly as an attack, but could be worth
adding.  I won't object if you choose not to add it. If you do,
and other XR blocks expose similar information then I guess
adding references to those would also be nice.

The secdir review [1] suggests a few nit-fixes too.

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03762.html

(Brian Haberman) No Objection

(Russ Housley) No Objection

(Barry Leiba) (was Discuss) No Objection

Comment (2013-03-07 for -09)
My DISCUSS points are nicely handled in -09; thanks very much for the work.

The "binary point" change is missing in the definition of Burst Discard Rate -- it got into the other three places.  Gonzalo can put in an RFC Editor note asking to fix this, thus:

In Section 3.2.2, please make the following change:

OLD
   Burst Discard Rate: 16 bits

      The fraction of packets discarded during bursts since the
      beginning of reception, expressed as a fixed point number with the
      binary point at the left edge of the field.

NEW
   Burst Discard Rate: 16 bits

      The fraction of packets discarded during bursts since the
      beginning of reception, expressed as a fixed point number with the
      binary point immediately after the left-most bit.

(Pete Resnick) No Objection

Comment (2013-02-20 for -08)
I love it when everyone else gets the DISCUSSes in that I would have before I have a chance. Less typing for me. Definitely support Robert's DISCUSS. Barry and Ralph's DISCUSS looks spot-on.

(Robert Sparks) (was Discuss) No Objection

(Martin Stiemerling) No Objection

Comment (2013-02-19 for -08)
In support of Barry's and Ralph's DISCUSS.

(Sean Turner) No Objection

Comment (2013-02-19 for -08)
I support Barry and Ralph's discuss.