RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-09

I have no objection to this document, and just one non-blocking comment:
I find the reference to "receiver" and "sender" (in the descriptions of the reserved bits in Sections 3 and 4, and in Section 5, especially 5.2) to be confusing.  The problem is that the media receiver is sending the report, and the media sender is receiving it, and the sense can easily get tangled.

I suggest always using "media sender" and "media receiver", rather than just "sender" and "receiver", and explicitly saying that the media receiver generates these reports and that the media sender consumes them.  Then stick with "generate" and "consume" to avoid confusion with "send" and "sender", and so on.

Does that make sense?

Thanks for addressing my comment

Section 2: "...and indicate requirement levels for compliant implementations." What does that mean? 2119 defines the terms specifically to be used only when necessary for interoperability. To use them to indicate compliance requirements is to do something different than 2119 defines. Why was this added to the boilerplate?

Section 3: I agree with Spencer that the two "SHALL"s in the first paragraph need to be removed.

   rsvd (3 bits): These reserved bits SHOULD be set to zero by receivers
   and MUST be ignored by senders.

Shouldn't both statements be MUST? Is there a reason that a receiver would ever set it to other than 0?

   The 'E' bit MUST be set to '1' if the chunks represent packets discarded
   due to too early arrival and MUST be set to '0' otherwise.

These are definitions, not requirements. Nobody would choose to do differently. Instead: "When the 'E' bit is set to '1', it indicates that the chunks represent packets discarded due to early arrive. Otherwise, the 'E' bit is set to '0'."

The same sorts of things appear in section 4, and should be corrected there too.

Section 6: "The parameter 'discard-rle' MUST be used". Instead say, "The parameter 'discard-rle' is used".

Thank you for resolving my Discuss and addressing my comments.

I don't agree with the assertion in section 7 -
sometimes more precision is in fact enough to cause a
security issue, so the statement is just wrong. Was
security really considered?

The secdir review [1] also raises an interesting
question, about which we've planned to chat in
Berlin.

[1] http://www.ietf.org/mail-archive/web/secdir/current/msg04048.html