RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications
draft-ietf-xrblock-rtcp-xr-loss-conceal-12
Yes
(Alissa Cooper)
No Objection
(Alia Atlas)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Martin Stiemerling)
(Richard Barnes)
(Spencer Dawkins)
(Ted Lemon)
Note: This ballot was opened for revision 11 and is now closed.
Alissa Cooper Former IESG member
Yes
Yes
(for -11)
Unknown
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
(2014-04-10 for -11)
Unknown
Thanks. The RFC Editor Note addresses my concerns
Alia Atlas Former IESG member
No Objection
No Objection
(for -11)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2014-04-08 for -11)
Unknown
Adrian's right, and the block in Section 4 gets it correct -- only Section 3 is wrong (in two places).
Brian Haberman Former IESG member
No Objection
No Objection
(2014-04-07 for -11)
Unknown
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 IESG member
No Objection
No Objection
(for -11)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -11)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -11)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -11)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2014-04-09 for -11)
Unknown
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 IESG member
No Objection
No Objection
(for -11)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -11)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-04-08 for -11)
Unknown
- 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 IESG member
No Objection
No Objection
(for -11)
Unknown