Skip to main content

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

Yes

(Gonzalo Camarillo)

No Objection

(Adrian Farrel)
(Brian Haberman)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
(Wesley Eddy)

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

Gonzalo Camarillo Former IESG member
Yes
Yes (for -08) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2013-03-07 for -09) Unknown
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 IESG member
(was Discuss) No Objection
No Objection (2013-03-22 for -10) Unknown
Qin, thanks for continuous effort to improve your document, and clear my DISCUSS.
Regards, Benoit
Brian Haberman Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (2013-02-19 for -08) Unknown
In support of Barry's and Ralph's DISCUSS.
Pete Resnick Former IESG member
No Objection
No Objection (2013-02-20 for -08) Unknown
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 IESG member
(was Discuss) No Objection
No Objection (2013-03-07 for -09) Unknown
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 IESG member
(was Discuss) No Objection
No Objection (2013-03-07 for -09) Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (2013-02-19 for -08) Unknown
I support Barry and Ralph's discuss.
Stephen Farrell Former IESG member
No Objection
No Objection (2013-02-18 for -08) Unknown
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 IESG member
No Objection
No Objection (for -08) Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection (for -08) Unknown