RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric
draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-02

-- Section 7.3 --

In the discussion of draft-ietf-xrblock-rtcp-xr-synchronization, Pete brought up the question of using an individual as the contact point for working group stuff.  I suggest that this document should use the same resolution as that one, specifying the RAI ADs <rai-ads@tools.ietf.org>.

I put myself in the shoes of the operator looking at the different extended reports, and I'm trying to understand how to correlate the number of discarded bytes with  number of discarded packets from the different extended reports.

From the document, there could be 3 different extended reports reporting the number of discarded packets:

   o  Reporting the number of discarded packets in a measurement
      interval, i.e., during either the last reporting interval or since
      the beginning of the session, as indicated by a flag in the
      suggested XR report [RFC7002].  If an endpoint needs to report
      packet discard due to other reasons than early- and late-arrival
      (for example, discard due to duplication, redundancy, etc.)  then
      it should consider using the Discarded Packets Report Block
      [RFC7002].

   o  Reporting gaps and bursts of discarded packets during a
      measurement interval, i.e., the last reporting interval or the
      duration of the session [RFC7003].

   o  Reporting run-length encoding of discarded packet during a
      measurement interval, i.e., between a set of sequence numbers
      [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics].


First of all, it would be nice to mention that the measurement intervals from the different extended reports are synchronized.
Talking to Dan Romacanu (btw thanks Dan), I understand that the number of bytes can be correlated to the number of packet in bullet 1 (RFC 7002) and/or in the bullet 3 ([I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics]), depending on the flag value expressing whether we speak about delta or running counters.
A few sentences (or a new section) about this would be an extremely useful addition from an operational point of view.

Note: it was confusing to me that  [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics] refers to http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06, a very old version of the draft ... which still contains the bytes extended report. Mentioning RFC 7097 obviously solves that one. Thanks again Dan for gently highlighting the obvious to me :-)

Thanks for a well-written document. 

As pointed out by Vijay in his Gen-ART review, in Section 6,

   In some situations, returning very
   detailed error information (e.g., over-range measurement or
   measurement unavailable) using this report block can provide an
   attacker with insight into the security processing.  Implementers
   should consider the guidance in [I-D.ietf-avt-srtp-not-mandatory] for
   using appropriate security mechanisms, i.e., where security is a
   concern, the implementation should apply encryption and
   authentication to the report block. 

the text does not really describe what security issue is being an issue here. I also read draft-ietf-avt-srtp-not-mandatory, but it did not talk about this specific issue. In the e-mail discussion a brief mention of the rational was given. I think it would be useful to add some text here. But this is an editorial issue, not a blocking-level comment.