RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting
RFC 7004
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
(Gonzalo Camarillo; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Barry Leiba; former steering group member) (was Discuss) No Objection
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.
(Benoît Claise; former steering group member) (was Discuss) No Objection
Qin, thanks for continuous effort to improve your document, and clear my DISCUSS. Regards, Benoit
(Brian Haberman; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
In support of Barry's and Ralph's DISCUSS.
(Pete Resnick; former steering group member) No Objection
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.
(Ralph Droms; former steering group member) (was Discuss) No Objection
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.
(Robert Sparks; former steering group member) (was Discuss) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
I support Barry and Ralph's discuss.
(Stephen Farrell; former steering group member) No Objection
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
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection