RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications
draft-ietf-xrblock-rtcp-xr-loss-conceal-12

Note: This ballot was opened for revision 11 and is now closed.

Alissa Cooper Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Richard Barnes) No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2014-04-10 for -11)
No email
send info
Thanks. The RFC Editor Note addresses my concerns

(Stephen Farrell) No Objection

Comment (2014-04-08 for -11)
No email
send info
- section 2.2 confused me a bit, you said these new
values are in seconds, but then present the binary
fraction encoding. Is that latter really needed for
this one? (Just checking, I assume it is used in some
field.)

(Brian Haberman) No Objection

Comment (2014-04-07 for -11)
No email
send info
I support Adrian's DISCUSS point.  I followed the chain of related RFCs back to 3550 as far as the definition of an RTP Extension Header goes.  Section 5.3.1 of 3550 says the following:

   The header extension contains a 16-bit length field that
   counts the number of 32-bit words in the extension, excluding the
   four-octet extension header (therefore zero is a valid length).

So, 6 appears to be the correct length for the report structure in 3.1.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2014-04-08 for -11)
No email
send info
Adrian's right, and the block in Section 4 gets it correct -- only Section 3 is wrong (in two places).

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

(Pete Resnick) No Objection

Comment (2014-04-09 for -11)
No email
send info
Just editorial stuff:

In 3.2 and 4.2, you say things like:

      If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE
      MUST be reported to indicate an over-range measurement.  If the
      measurement is unavailable, the value 0xFFFFFFFF MUST be reported.

You should instead use the style that appears in draft-ietf-xrblock-rtcp-xr-qoe:

      Two values are reserved: A value of 0xFFFE indicates out of range
      and a value of 0xFFFF indicates that the measurement is
      unavailable.

If you wanted to clarify even more, you could say:

      Two values are reserved: A value of 0xFFFFFFFE indicates out of
      range (that is, a measured value exceeding 0xFFFFFFFD) and a value
      of 0xFFFFFFFF indicates that the measurement is unavailable.

The MUSTs are unnecessary. These are definitions, not protocol requirements.

4.2: I would strike the words "For clarification". While reading this, it declarified things for me for a moment. :-)

5.1: No need to redefine DIGIT. Just put a reference to RFC 5234 in section 2.

(Martin Stiemerling) No Objection