RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report
draft-ietf-avtcore-feedback-supression-rtp-17

I just have a few questions on this draft:

1. The Protocol Overview section states : "Intermediaries in the network that receive a RTCP TPLR SHOULD NOT send their own additional Third-Party Loss Report messages for the same packet sequence numbers."  Why is this not a MUST?  Is it simply to handle intermediate devices that don't support this function?  If there is another scenario where a device may send a TPLR that overlaps, it would be good to spell that out.

2. There are two places (Sections 4.1 & 4.2) where the length field in the feedback message is set to "2+1*N".  Should I interpret that to mean the value is really just N+2?  Or is there something I am missing?

The document writeup says, "There are not yet any reported implementations." Are you really saying that for a protocol that appears to have serious congestion control effects, nobody has written a line of code yet? Has there been any testing of this at all? Are there any planned implementations (perhaps by more than one independent implementer)? If not, perhaps this should be published as Experimental first.

Had the same question Stephen had.

Just checking: there's no way that a 3rd party loss report
could cause a flood of re-transmitted data (that hadn't
actually been lost) to be (re-)sent to a target is there? If
so, that might constitute a new DoS vector. Its not clearly
the case that that can't happen. If it could, then 
that'd be another reason to authenticate these messages.

nits/typos:

- s/to pose/pose/
- s/message,which/message, which/
- maybe s/the distribution source will not/if the
  distribution source will not/ in 6.1? (and some
  missing spaces there too)o
- I like "badly screwed up" as a descriptive phrase!

moved from DISCUSS to COMMENT after emails from authors:

(1)

"screwed up" in Section 6.5 is not very technical; please say what is really wrong (loss, corruption, reordering, etc.)


(2)

Section 1 lists a number of *BUGS* in implementations as the motivations for this.  It starts by saying that a use case for this is people not implementing RFC 4585 dithering correctly, then says that another use case is that there are other poor designs causing implosions of FIRs.

It seems silly to write this new RFC adding a new mechanism rather than just applying pressure to fix those implementations; it would be useful to discuss why that isn't the right answer, since receivers have to implement reactions to this new report anyways, they should be fixing their bugs.  I think this is an especially relevant question given the lack of implementation noted in the writeup and Pete's ballot.