Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)
RFC 5725

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

(Cullen Jennings) (was Discuss, No Record, Yes) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

Lars Eggert No Objection

(Pasi Eronen) No Objection

(Adrian Farrel) No Objection

(Russ Housley) (was Discuss) No Objection

(Alexey Melnikov) (was Discuss) No Objection

Comment (2009-10-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Section 3 should say that network byte order is used for encoding 16bit values.

(Tim Polk) No Objection

Comment (2009-01-27 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The security considerations are a one sentence pointer to RFC 3611.  While the RFC 3611
considerations do apply, it would be helpful if this document noted any considerations
unique to this report block, as with the security considerations for the Loss RLE report block
in RFC 3611.  Without this information, the reader might infer that the security considerations
are the same as for Loss RLE, which I don't think is true...

It seems that this extension is intended for use in addition to the Loss RLE Report Block.  I also
assume that the Loss RLE and Post Repair Loss RLE report blocks are protected by the same
security mechanisms.  In this case, the only additional information that is revealed is the
overall effectiveness of the loss repair mechanisms.  That is, unlike the Loss RLE report
block, this extension does not facilitate multicast inference of network characteristics (MINC) 
since any useful information has already been revealed.

The open question is whether knowledge of the effectiveness of repair mechanisms on a
particular system is helpful to an attacker.  (I would guess that it could be useful, but I will
leave that up to the RTCP experts.)

(Dan Romascanu) (was Discuss) No Objection

Comment (2009-10-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
1. It is not clear to me what item in the AVT WG charter this document is covering. I see that two new metric blocks are to be defined, one for  high resolution measurements of audio and speech quality and the second for quality of video, but it is not clear where does this document and a number of other of this WG I-Ds fit. 

2. It would be useful to clarify whether the applicability statements defined in RFC 3611 for packet-by-packet reporting blocks fully apply to the new block defined in this document and what are the differences if there are such differences. What is the applicability for network monitoring purposes?

(Robert Sparks) No Objection

Comment (2009-10-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
One thought to explore if it hasn't been already: If an attacker can inject post-repair reports and also induce loss of the RTP, then the processing at the sending endpoint could be convinced that no remedial changes are necessary (due to loss) when, in fact, they should be made. This would only be effective if no other feedback exposed the problem.

(Magnus Westerlund) (was Discuss) No Objection

Comment (2009-01-28)
No email
send info
During the fall we had a discussion about the issue of RTP sequence number wrap around. I did accept the decision to not expand the numberspace. However, I think there still should be a warning about this issue, and the need for senders to take care of this issue. Can you please add a paragraph or so about it?