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

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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:
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.

[Ballot comment]
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.

[Ballot discuss]
Hi Qin,

Me again ;-)
During the last IETF, we work together (with Dan Romascanu) on using the RFC6390 template in
http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-summary-stat-11#appendix-A
You should apply the same rule with this draft.

[Ballot comment]
RTCP XR views a call as being divided into bursts, which are periods
  during which the loss rate is high enough to cause noticeable call
  quality degradation (generally over 5 percent loss rate), and gaps,
  which are periods during which lost packets are infrequent and hence
  call quality is generally acceptable.

I always heard of max 1 percent of packet loss to avoid audible errors

[Ballot comment]
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.

[Ballot comment]

- 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.)

[Ballot discuss]
Section 3.3:

  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) and also with the metric
  "cumulative number of packets lost" provided in standard RTCP
  [RFC3550].

There are a lot of validation requirements in this document that are embedded in the description of the data format; the above is an example of this.  It would be better to have a section 3.4 that describes what senders SHOULD/MUST do and describes how receivers validate that it was done.  I picked out the above example because we have a MUST that doesn't say what to do if it's violated, and that appears in parentheses.  I don't think RFC2119 forbids this, but it seems like a stylistic faux pas that the authors ought to correct, even if they disagree with the proposal to move the requirements text into a new section on validation.

[Ballot comment]
Given the possibility of overflow of various values, particularly the sum of squares of burst durations, I was surprised to see that there was no guidance about the frequency at which burst and gap report loss blocks should be sent; presumably if they are sent before the sum of squares reaches the maximum value that can be stored in that field, it would be preferable.

[Ballot discuss]
Section 3:

                                            This Metrics Block relies
  on the measurement period in the Measurement Information block
  indicating the span of the report and SHOULD 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.
 
If the Metrics Block MUST be discarded if it is not sent in the same RTCP packet as the measurement information block, why is it only that it SHOULD be sent in the same packet? Shouldn't that first one be a MUST? If not, why MUST the block be discarded? And if it is SHOULD, under what circumstances might the block not be included in the same packets? The SHOULD also disagrees with the parenthetical in the first paragraph of 3.3. Something needs fixing here.

3.2:

      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 used.  In addition,
      the value I=00 is reserved and also MUST NOT be used.  The block
      MUST be discarded if the value I=01 or I=00 is received.

When you say MUST NOT be used, do you mean MUST NOT be sent? If so, why are you even defining 01 in the first place? If it cannot be sent, shouldn't 01 be simply "reserved" the same as 00? Why is this not just a single bit indicating "Interval" or "Cumulative"? I am also left to wonder why the block MUST be discarded: If 01 *is* meaningful, can't I log or otherwise save the value in that block reasonably? I don't understand.

      The 'C' flag is used to indicate whether the loss/discard report
      is combined with the burst gap loss report in the same compound
      RTCP packet.  The value MUST be set to '1' if the loss/discard
      report and the burst gap loss report are combined.  Otherwise, the
      value MUST be set to '0'.  If the burst gap discard is not sent
      with the burst gap loss, then the receiver MUST discard the burst
      gap loss with 'C' flag set to 1.  If the 'C' flag is set to 0,
      then receiver MUST NOT discard the burst gap loss Metrics Block
      when the burst gap discard is not received.

The first two "MUST be set" should really be "is set"; the MUSTs are superfluous. But that's not the real problem here: The fourth sentence of this paragraph ("If the burst gap discard...") is  very confusing. Do you mean that the receiver can determine whether the combined report has been sent without looking at this flag, and you are requiring the receiver to determine whether the flag and the truth of the matter disagree with eachother and discard the packet if so? That sounds like it's ripe for error, and then makes me not understand the purpose of the C flag in the first place. The last sentence of the paragraph is even more confusing: There are one to many nots in that sentence, and I don't understand how you can require a receiver NOT to discard a packet that it wants to discard. This paragraph needs quite a bit of editing. I don't understand it.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-xrblock-rtcp-xr-burst-gap-loss-08.txt.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA understands that, upon approval of this document, there are two actions which IANA needs to complete.

First, in the RTCP XR Block Type subregistry of the RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry located at:

http://www.iana.org/assignments/rtcp-xr-block-types

a new block type will be registered as follows:

BT: [ TBD-at-Registration ]
Name: Burst/Gap Loss Metrics Block
Reference: [ RFC-to-be ]

Second, in the RTP Control Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters Registry located at:

http://www.iana.org/assignments/rtcp-xr-sdp-parameters

a new parameter will be registered as follows:

Parameter: brst-gap-loss
Reference: [ RFC-to-be ]

IANA understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss metric Reporting) to Proposed Standard


The IESG has received a request from the Metric Blocks for use with
RTCP's Extended Report Framework WG (xrblock) to consider the following
document:
- 'RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap
  Loss metric Reporting'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-03-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines an RTP Control Protocol (RTCP) Extended Report
  (XR) Block that allows the reporting of Burst and Gap Loss metrics
  for use in a range of RTP applications.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-burst-gap-loss/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-burst-gap-loss/ballot/


No IPR declarations have been submitted directly on this I-D.

UPDATED:
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Proposed Standard - similar to all the other XRBLOCK documents. Header says ' Intended status: Standards Track '


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document defines an RTP Control Protocol (RTCP) Extended Report
(XR) Block that allows the reporting of Burst and Gap Loss metrics
for use in a range of RTP applications.

Working Group Summary

The WG path of this document was reasonably short and efficient.
Several technical comments were made during the reviews and all were
resolved with consensus.

Document Quality

At least one vendor has implemented this draft. It is expected that with
the approval of this document the number of implementations will increase.

Personnel

Dan Romascanu is the Document Shepherd. Gonzalo Camarillo
is the Responsible Area Director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


I have performed a detailed review of the document and I consider it
ready.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.


This I-D deals with reporting of the proportion of packets lost by the
network and specifically during loss bursts. The metrics carried by this
block are consistent with the definitions in RFC 3550 and RFC 3611.
Although several PM-DIR members participate in the WG, a formal RFC 6390
review could be useful.
The SDP Review was performed by Adam Roach.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been submitted directly on draft-ietf-xrblock-rtcp-xr-burst-gap-loss-08.txt or its predecessors.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The number of active participants in the Working Group is not very high (around ten). Among the active participants there seems to be solid consensus in support of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No critical issues. There is one reference to a document that has a issued more recent versions since the publication of the I-D, and one warning about [RFC6709] being unused. It is actually used by the brackets were forgotten. I hope that the RFC Editor can easily fix these.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

I would recommend for another reviewer from the performance metrics directorate to do an RFC 6390 review of the I-D.
The SDP Review was performed by Adam Roach.


(13) Have all references within this document been identified as
either normative or informative?

Yes


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

N/A

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

N/A

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The document requires from IANA allocations of values in existing registries which are clearly defined.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.


N/A

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Proposed Standard - similar to all the other XRBLOCK documents. Header says ' Intended status: Standards Track '


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document defines an RTP Control Protocol (RTCP) Extended Report
(XR) Block that allows the reporting of Burst and Gap Loss metrics
for use in a range of RTP applications.

Working Group Summary

The WG path of this document was reasonably short and efficient.
Several technical comments were made during the reviews and all were
resolved with consensus.

Document Quality

At least one vendor has implemented this draft. It is expected that with
the approval of this document the number of implementations will increase.

Personnel

Dan Romascanu is the Document Shepherd. Gonzalo Camarillo
is the Responsible Area Director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


I have performed a detailed review of the document and I consider it
ready.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.


This I-D deals with reporting of the proportion of packets lost by the
network and specifically during loss bursts. The metrics carried by this
block are consistent with the definitions in RFC 3550 and RFC 3611.
Although several PM-DIR members participate in the WG, a formal RFC 6390
review could be useful.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been submitted directly on draft-ietf-xrblock-rtcp-xr-burst-gap-loss-08.txt or its predecessors.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The number of active participants in the Working Group is not very high (around ten). Among the active participants there seems to be solid consensus in support of this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No critical issues. There is one reference to a document that has a issued more recent versions since the publication of the I-D, and one warning about [RFC6709] being unused. It is actually used by the brackets were forgotten. I hope that the RFC Editor can easily fix these.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

I would recommend for another reviewer from the performance metrics directorate to do an RFC 6390 review of the I-D.


(13) Have all references within this document been identified as
either normative or informative?

Yes


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

N/A

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

N/A

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The document requires from IANA allocations of values in existing registries which are clearly defined.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.


N/A