RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting
draft-ietf-xrblock-rtcp-xr-qoe-17

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

(Gonzalo Camarillo) Yes

(Spencer Dawkins) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

(Benoît Claise) (was Discuss) No Objection

Comment (2014-02-13 for -15)
No email
send info
Thanks for addressing my DISCUSS point.

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2014-02-06 for -13)
No email
send info
Be nice to expand MOS in the abstract.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2014-02-05 for -13)
No email
send info
Pete has my comments covered.

(Ted Lemon) (was Discuss) No Objection

Comment (2014-02-13 for -15)
No email
send info
After the most recent update to 4.2, the text is still slightly broken:

  understand the extension SHOULD NOT include it from the SDP answer

I believe that this should be "SHOULD NOT include it in the SDP answer" instead.   The same error repeats in the next paragraph.

---

Former DISCUSS, which has been addressed:

In section 4.2, third paragraph (not counting bullet items above it):

   Segment extensions, with their directions, MAY be signaled for an
   "inactive" stream.  It is an error to use an extension direction
   incompatible with the stream direction (e.g., a "sendonly" attribute
   for a "recvonly" stream).

How is this error handled?   You an address this DISCUSS point by adding text that says how, or pointing out why it isn't a problem.

Comments that have been addressed:

Page 6, first paragraph:
   measurement techniques allows much large scale measurements to

This is obviously a typo; could be much larger scale measurements or much large scale measurement.   Might want to disambiguate before the copyedit happens to avoid misunderstandings.

      In this document, MOS Metrics MAY be reported for intervals or
      for the duration of the media stream (cumulative) however it
      is not recommended that sampled values are used.

Section 3.2, just above the Reserved heading:
      In this document, MOS Metrics MAY be reported for intervals or
      for the duration of the media stream (cumulative) however it
      is not recommended that sampled values are used.

It might be better to forbid sampled values if they aren't useful, so that implementations don't have to handle them.   Just a suggestion—you know better than I.   No need to explain if you disagree.

(Pete Resnick) (was Discuss) No Objection

Comment (2014-02-26 for -16)
No email
send info
Thanks for addressing my DISCUSSion points.

One last comment, which Gonzalo could simply change in an RFC Editor note if you decide to do so; you don't need to do a new draft:

In section 3:

   This block reports the media quality in the form of a 1-5 MOS range

That's not really precise. Probably better to say:

   This block reports the media quality in the form of a MOS range
   (e.g., 1-5, 0-10, or 0-100, as specified by the calculation
   algorithm)

(Martin Stiemerling) No Objection

(Sean Turner) No Objection