RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting
draft-ietf-xrblock-rtcp-xr-burst-gap-loss-12

I agree with Pete's DISCUSS.

Thanks for addressing my DISCUSS, and answering my COMMENT.

Still waiting for a Gen-ART review on this document. I have done an overview review of the document myself.

if peet's discuss is cleared I have no other objections.

Did the performance metrics directorate review wrt  RFC 6390 happen in the meantime?

Thanks for addressing the DISCUSS comments.

We had a conversation in email about the contact info in 6.3. RFC 3611 did not itself provide specific contact information for the registrations it made, nor have some other documents (5093, 6679). Other documents have provided contact info, usually using an author, even though it is a standards track document. I suggest that contact information should *not* be used when IETF consensus documents are making the registration. Perhaps 3611 needs to be clarified. Though I'm not balloting DISCUSS, I would appreciate a few minutes to chat about this during the telechat.

Couple of minor things, and one less minor:

In Section 1.1., "this draft" should be "this document" (hopefully, it won't be a draft soon!)

In Section 5.1., Is there a reason that "u" is the only letter left out of "brst-gap-loss"?

In Section 7., it seems worth noting that the gaps indicated with this XR block could be used to detect the timing of other events on the path between the sender and receiver.  For example, a competing multimedia stream might cause a loss burst for the duration of the stream, allowing the receiver of the XR block to know when the competing stream was active.  This is not a significant threat, however, because the only information leaked is the timing of the loss, not the cause.

- 2.1, "specific time-window" could maybe do with a reference
to RFC 6921?

- 3.2, sum of burst durations has a max of <5 hours, which I
guess is ok unless the "period of the report" (where's that
defined?) is very long. Is that ok?

- 3.2, Do you need to say fields are unsigned values? All
those 0xF.... might be a problem otherwise. (Maybe that's a
general xrblock thing though.)

The way requirements and validation requirements are set out in this document is hard to follow.   I suggest the following changes:

Section 3:

OLD:
   Metrics in this block report on Burst/Gap Loss in the stream arriving
   at the RTP system.  The measurement of these metrics are made at the
   receiving end of the RTP stream.  Instances of this Metrics Block
   refer by Synchronization source (SSRC) to the separate auxiliary
   Measurement Information block [RFC6776] which describes measurement
   periods in use(see RFC6776 section 4.2).  This Metrics Block relies
   on the measurement period in the Measurement Information block
   indicating the span of the report and MUST be sent in the same
   compound RTCP packet as the measurement information block.  If the
   measurement period is not received in the same compound RTCP packet
   as this Metrics Block, this Metrics Block MUST be discarded.
NEW:
   Metrics in this block report on Burst/Gap Loss in the stream arriving
   at the RTP system.  The measurement of these metrics are made at the
   receiving end of the RTP stream.  Instances of this Metrics Block
   refer by Synchronization source (SSRC) to the separate auxiliary
   Measurement Information block [RFC6776] which describes measurement
   periods in use(see RFC6776 section 4.2).

   This Metrics Block relies on the measurement period in the
   Measurement Information block indicating the span of the report.
   Senders MUST send this block in the same compound RTCP packet
   as the measurement information block.  Receivers MUST verify that the
   measurement period is received in the same compound RTCP packet
   as this Metrics Block. If not, this Metrics Block MUST be discarded.

In section 3.2, the text is needlessly repetitive, and also doesn't say what must be discarded; I suspect that it should be changed to something like this:

OLD:
      In this document, Burst/Gap Loss Metrics can only be measured over
      definite intervals, and cannot be sampled.  Accordingly, the value
      I=01, indicating a sampled value, MUST NOT be sent, and MUST be
      discarded when received.  In addition, the value I=00 is reserved
      and also MUST NOT be sent, and MUST be discarded when received.
NEW:
      In this document, Burst/Gap Loss Metrics can only be measured over
      definite intervals, and cannot be sampled. Also, the value I=00 is
      reserved for future use. Senders MUST NOT use
      the values I=00 or I=01. If a block is received with I=00 or
      I=01, the receiver MUST discard the block.

In section 3.3, there's a very awkward parenthetical note which refers back to the first paragraph of section 3.   This is the text that prompted my DISCUSS; on review I see that rather than actually adding requirements to the sender and receiver, it's merely reiterating them.   The easy fix is to just take it out:

OLD:
   The metrics described here are intended to be used as described in
   this section, in conjunction with information from the Measurement
   Information block [RFC6776] (which MUST be present in the same RTCP
   packet as the Burst/Gap Loss block (see section 3,1st paragraph) )
   and also with the metric "cumulative number of packets lost" provided
   in standard RTCP [RFC3550].
NEW:
   The metrics described here are intended to be used as described in
   this section, in conjunction with information from the Measurement
   Information block [RFC6776] and also with the metric "cumulative
   number of packets lost" provided in standard RTCP [RFC3550].

However, of course the authors had some reason for putting this note into section 3.3; if removing it entirely feels uncomfortable, how about something like this?

OLD:
   The metrics described here are intended to be used as described in
   this section, in conjunction with information from the Measurement
   Information block [RFC6776] (which MUST be present in the same RTCP
   packet as the Burst/Gap Loss block (see section 3,1st paragraph) )
   and also with the metric "cumulative number of packets lost" provided
   in standard RTCP [RFC3550].
NEW:
   The metrics described here are intended to be used as described in
   this section, in conjunction with information from the Measurement
   Information block [RFC6776], which, as mentioned previously, must
   be present, and also with the metric "cumulative number of packets
   lost" provided in standard RTCP [RFC3550].

I prefer the former edit, but something like the latter edit would also satisfy me.   I've removed my DISCUSS on this because now that I understand the context better, I don't think this _has_ to be fixed.   However, I would appreciate it if the authors would consider fixing it; I think it would improve the readability of the document.