Subject: [xrblock] New Version Notification for draft-huang-xrblock-rtcp-xr-decodability-02.txt and comments reply

From: "Rachel Huang(yihong)" <[email-masked]>
Date: Thu, 16 Feb 2012 09:36:26 +0000

Hi all,

We have submitted a new version of draft-huang-xrblock-rtcp-xr-decodablity. This new version fixed some language related errors and the wrong boilerplate. Now it's available at:
http://www.ietf.org/internet-drafts/draft-huang-xrblock-rtcp-xr-decodability-02.txt 
Comments are welcomed.

I'm sorry for very late reply for the comments given by Glen. The grammar and spelling errors have been addressed in the new version. Some technical comments are replied below:

Section 3, paragraph 2 says:

   Note that this metric report block is not only applicable to MPEG-2
   transport streams[RFC2250],but also applicable to any other Transport
   Streams that adopt other audio and video codec.

Are there any examples of such things?

[Rachel]Of course. For example, MPEG-4 over TS.

The report block contains data about some, but not all, of the indicators listed in sections 5.2.1-5.2.3 of ETSI TR 101 290; it might be helpful if the rationale for the omission of some indicators was discussed, perhaps in the introduction.

[Rachel] The parameters defined in ETSI TR 101 290 are categorized according to severity and are listed as Priorities 1, 2 and 3. Priority 1 is defined as those "necessary for de-codability", Priority 2 is "recommended for continuous or periodic monitoring", and priority 3 is defined as "application dependent monitoring". The parameters in priority 3 are specific to DVB SI while in IPTV they are not required. So we adopted 8 most important and most universal metrics from priorities 1 and 2. Also some errors never or seldom happening during the content transmission are also omitted, such as PAT_error, PMT_error, PID_error, CAT_error.

I imagine that this document would be used by people who are at least familiar with ETSI TR 101 290, so I suggest that the mapping between the report block fields and the corresponding error indicators in the ETSI spec might be made clearer.  Maybe use the same names?

[Rachel] I think they have different meanings. The name defined in ETSI TR 101 290 is an error name, while the name in the report block defines the count of the specific error. It's better to have different name. 

Best Regards!
Rachel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, February 14, 2012 7:10 PM
To: [email-masked]
Cc: [email-masked]; Rachel Huang(yihong); [email-masked]; Qin Wu
Subject: New Version Notification for draft-huang-xrblock-rtcp-xr-decodability-02.txt

A new version of I-D, draft-huang-xrblock-rtcp-xr-decodability-02.txt has been successfully submitted by Glen Zorn and posted to the IETF repository.

Filename:	 draft-huang-xrblock-rtcp-xr-decodability
Revision:	 02
Title:		 RTCP XR Report Block for TS Decodability Statistics Metric Reporting
Creation date:	 2012-02-14
WG ID:		 Individual Submission
Number of pages: 8

Abstract:
   Transport Stream is a standard container format used in the
   transmission and storage of multimedia data.  This document defines
   an RTCP XR Report Block that allows the reporting of decodability
   statistics metrics related to transmissions in Transport Stream
   format.

The IETF Secretariat

---

From: Glen Zorn <[email-masked]>
Date: Fri, 17 Feb 2012 14:17:51 +0700

> [Rachel]Of course. For example, MPEG-4 over TS.

Perhaps adding this would be good.

> [Rachel] The parameters defined in ETSI TR 101 290 are categorized according to severity and are listed as Priorities 1, 2 and 3. Priority 1 is defined as those "necessary for de-codability", Prior…

This would be good to mention, I think, maybe in the introduction.

> [Rachel] I think they have different meanings. The name defined in ETSI TR 101 290 is an error name, while the name in the report block defines the count of the specific error. It's better to have…

Sorry, I guess that I didn't communicate well.  I wasn't suggesting that
exactly the same name be used, just something similar enough to be
easily findable (like Sync_byte_error_cnt, for example).

...

---

From: "Rachel Huang(yihong)" <[email-masked]>
Date: Fri, 17 Feb 2012 08:34:41 +0000

Hi Glen,

Okay. The next version will address them all. 

Best Regards!
Rachel

-----Original Message-----
From: Glen Zorn [mailto:[email-masked]] 
Sent: Friday, February 17, 2012 3:18 PM
To: Rachel Huang(yihong)
Cc: [email-masked]
Subject: Re: [xrblock] New Version Notification for draft-huang-xrblock-rtcp-xr-decodability-02.txt and comments reply

...