Subject: [xrblock] FW: Ted Lemon's No Objection on draft-ietf-xrblock-rtcp-xr-qoe-15: (with COMMENT)

From: Qin Wu <[email-masked]>
Date: Tue, 18 Feb 2014 10:31:51 +0000

Hi, all:
May I ask people to take a look at the changes we made in v-(014) and v-(015).
The diff is
http://tools.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-qoe-14.txt
http://tools.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-qoe-15.txt
These proposed changes address two ADs DISCUSSes during IESG review.
Change 1: Make metric name represented using RFC6390 template more specific.
Change 2: Forbidden using sampled value based on Ted's suggestion.
Change 3:  Clarify how to deal with the error due to extension direction
   incompatible with the stream direction.
Some typo in v-(015) was caught by Ted and mentioned below. 

Additional comments from Pete hasn't been addressed and agreed by authors of draft.
One comment is about the contacts for IETF
standards track registered item.
I like to propose the following change
OLD TEXT:
"
5.3.  The SDP calgextmap Attribute

   This section contains the information required by [RFC4566] for an
   SDP attribute.
   o  contact name, email address: ietf
"
NEW TEXT:
"
5.3.  The SDP calgextmap Attribute

   This section contains the information required by [RFC4566] for an
   SDP attribute.
   o  contact name, email address: RAI Area Directors
      <[email-masked]>
"

The second comment is about numeric format representation for MoS Score value.
Pete thinks "MoS score multiply by 10" is used to support float-point value representation.
since we have numeric format representation for MoS Score value,
Numeric format supports float-point value representation, therefore we don't need
MoS score multiply by 10.
Alan will provide input to address the second comment.
We will issue an update when authors reach agreement on how to address Pete's two comments.

Regards!
-Qin
-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Friday, February 14, 2014 12:44 AM
To: The IESG
Cc: [email-masked]; [email-masked]
Subject: Ted Lemon's No Objection on draft-ietf-xrblock-rtcp-xr-qoe-15: (with COMMENT)

Ted Lemon has entered the following ballot position for
draft-ietf-xrblock-rtcp-xr-qoe-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-qoe/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.