Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-summary-stat-03

Hi, Colin:
Thank for your comments, please see my reply inline below.

Regards!
-Qin
----- Original Message ----- 
From: "Colin Perkins" <csp@csperkins.org>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Cc: <xrblock@ietf.org>
Sent: Wednesday, December 12, 2012 5:48 AM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-summary-stat-03

On 29 Nov 2012, at 13:55, Romascanu, Dan (Dan) wrote:
> This is a Working Group Last Call for http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-summary-stat-03.txt.  
> 
> Please read and review this document, and send your comments, questions and concerns to the WG list before December 13, 2012. If you have no comments and you believe that the document is ready for submission to the IESG as a Standards Track document please send a short message as well to help us in determining the level of review and consensus. 

Section 3.2.2 of the draft cites draft-ietf-xrblock-rtcp-xr-discard and suggests that the gap discard rate is based on the value of DT=3 packets, but there was some discussion at IETF 85 about removing DT=3, since it’s redundant with the sum of DT=1 and DT=2. Was that discussion resolved?

[Qin]: I remembered you proposed in the meeting to remove DT=3, instead using the sum of DT=1 and DT=2 to calculate the total number of packet discard. But I am a little doubt after the meeting since the merit of keeping DT=3 is it will be more simple to know the total number of discard based on one instance of discard count block with DT=3 
however I am okay with your proposal now since it did cause redundance and introduce complexing to check if value of DT=3 equal to sum value of  DT=1 and DT=2.
So if the consensus is to remove DT=3 from draft-ietf-xrblock-rtcp-xr-summary-stat, instead, using sum of DT=1 and DT=2, I think we should also remove DT=3 from the draft-ietf-xrblock-rtcp-xr-discard, am I right?

Otherwise, I just had some minor comments:

- Section 3.2 references draft-ietf-xrblock-rtcp-xr-discard, which is not a burst/gap metric draft, in the context of burst/gap metrics. This is confusing, and it would help to separate the discussion of the burst/gap discard metrics from the reference to the non-burst/gap discard draft.

[Qin]: I believe you are right and will separate this from the 1st paragraph of  section 3.2.

- Section 4.1.2: the term “derivation frame” is unclear. 

[Qin]: It should be changed into "derived frame" to get consistent with Picture Type definition in the section 2.1.
We divide Picture type into "key frame" and "derived frame" 

- Section 5.2 is insufficient, and needs to be updated in a manner analogous to the other recent RTCP XR blocks.

[Qin]: Okay.
-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
xrblock mailing list
xrblock@ietf.org
https://www.ietf.org/mailman/listinfo/xrblock