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; former steering group member) Yes

Yes ( for -11)
No email
send info

(Adrian Farrel; former steering group member) (was Discuss) No Objection

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

(Alia Atlas; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection (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).

(Brian Haberman; former steering group member) No Objection

No Objection (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.

(Jari Arkko; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection (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.

(Richard Barnes; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection (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.)

(Ted Lemon; former steering group member) No Objection

No Objection ( for -11)
No email
send info