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
(Benoît Claise) (was Discuss) No Objection
Comment (2013-03-22 for -10)
No email
send info
send info
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)
No email
send info
send info
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)
No email
send info
send info
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)
No email
send info
send info
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)
No email
send info
send info
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)
No email
send info
send info
In support of Barry's and Ralph's DISCUSS.
(Sean Turner) No Objection
Comment (2013-02-19 for -08)
No email
send info
send info
I support Barry and Ralph's discuss.