RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications
RFC 7294
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
(Alissa Cooper; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
Thanks. The RFC Editor Note addresses my concerns
(Alia Atlas; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
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
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
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
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
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
- 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