Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-qoe-07.txt

On 20 May 2013, at 03:26, Qin Wu wrote:
> Hi, Colin:
> Thank for your valuable review, please see my reply inline below.
> 
> Regards!
> -Qin
> 
> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org] 
> Sent: Thursday, May 16, 2013 8:58 PM
> To: Qin Wu
> Cc: 'xrblock'; 'xrblock-chairs'
> Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-qoe-07.txt
> 
> Qin,
> 
> While I think this is in good shape, I do still have some comments on this version:
> 
> The ABNF in Section 4.1 defines mediatype and mosreference rules. It's not clear that these are needed: can't the media types and resolution be inferred from the payload type? If they are needed, I think their purpose needs to be clearer, and the draft needs to better explain how they interact with SDP O/A, especially in terms of failure modes. 
> 
> [Qin]: I agree mediatype can be inferred from payload type. Ad for mosrefereence, for audio application, I agree  whether it is narrowband or wideband, this can also be inferred from payload type since payload type will indicate whether it is narrowband or wideband.
> For video, it seems payload type doesn't distinguish standard definition video codec and high definition video codec.

If you can't tell what video QoE metric to use from the payload format and it's parameters, then you might need to keep the parameter. I was assuming that the information needed was available.

> Anyway I am okay to remove mediatype and mosreference.
> The question is shall we need to remove media type in the registry when we decide remove media type from SDP format?

I don't understand your question. Can you clarify?

> The ABNF defines video and multimedia mediatypes, but this draft only defines audio metric report blocks. 
> 
> [Qin]:That's not true. The single stream per segment will be used for video and multimedia media types. Multimedia media type means it can be either audio media type or video media type or audiovisual media type, e.g., P.1201.
> 
> The ABNF and the table of registrations in the IANA considerations include P1201_01, P1201_02, P1202_01, and P1202_02 algorithms, which only work for multimedia or video, but this draft only defines audio metric report blocks.
> 
> [Qin]: See above.
> 
> The policies for the new registry of calculation algorithms in Section 5.4 state that the information require should include "how values of the metric are reported in the one 16-bit fields or 13-bit fields", but the registration template and initial assignments do not do so. 
> 
> [Qin]:I am not sure how this sentence " how values of the metric are reported in the one 16-bit fields or 13-bit fields " affects registration template and initial assignment since this sentence really means how we format "MOS value" in 16 bits or 13 bits. The details of definition of "MOS value" field
> Has been specified in the section 3.2.1 for 16-bit "MOS value" and in the section 3.2.2 for 13-bit "MoS value". What am I missing?

If you need to specify something different about how the metric values are reported for each metric then the IANA registration template needs to specify what information is needed. If not, then you should remove that sentence from Section 5.4, since it implies that additional information is needed. 

Colin

> Regards,
> Colin
> 
> 
> 
> On 14 May 2013, at 03:20, Qin Wu wrote:
>> We have a minor update to QoE draft which incorporates the similar changes that are applied to burst gap related drafts.
>> Also we add a new appendix to apply RFC6390 template.
>> One comment was raised in the Last IETF meeting is about suggestion on soliciting review from SDP Directorate review for SDP part.
>> We think the current version is ready to go for such review and WGLC.
>> 
>> Regards!
>> -Qin
>> -----Original Message-----
>> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
>> Sent: Tuesday, May 14, 2013 10:11 AM
>> To: i-d-announce@ietf.org
>> Cc: xrblock@ietf.org
>> Subject: I-D Action: draft-ietf-xrblock-rtcp-xr-qoe-07.txt
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Metric Blocks for use with RTCP's Extended Report Framework Working Group of the IETF.
>> 
>> 	Title           : RTP Control Protocol (RTCP) Extended Report (XR) Blocks for QoE Metric Reporting
>> 	Author(s)       : Alan Clark
>>                         Qin Wu
>>                         Roland Schott
>>                         Glen Zorn
>> 	Filename        : draft-ietf-xrblock-rtcp-xr-qoe-07.txt
>> 	Pages           : 22
>> 	Date            : 2013-05-13
>> 
>> Abstract:
>>  This document defines an RTP Control Protocol (RTCP) Extended Report
>>  (XR) Block including two new segment types and associated SDP
>>  parameters that allow the reporting of QoE metrics for use in a range
>>  of RTP applications.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-qoe
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-qoe-07
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-qoe-07
>> 
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> _______________________________________________
>> xrblock mailing list
>> xrblock@ietf.org
>> https://www.ietf.org/mailman/listinfo/xrblock
> 
> 
> 
> -- 
> Colin Perkins
> http://csperkins.org/
> 
> 
> 

-- 
Colin Perkins
http://csperkins.org/