Re: [xrblock] Last Call Review: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07

"Huangyihong (Rachel)" <> Thu, 25 December 2014 08:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 398B71A875D; Thu, 25 Dec 2014 00:21:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wAv25oayki8y; Thu, 25 Dec 2014 00:21:13 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 638971A8754; Thu, 25 Dec 2014 00:21:12 -0800 (PST)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BNH72583; Thu, 25 Dec 2014 08:21:11 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 25 Dec 2014 08:21:10 +0000
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Thu, 25 Dec 2014 16:21:05 +0800
From: "Huangyihong (Rachel)" <>
To: Tom Taylor <>, Gen Art <>, "" <>, "" <>, "" <>, Dan Romascanu <>
Thread-Topic: Last Call Review: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07
Thread-Index: AQHQH+xxlg+sz2nR3UKYPgRhyojsNJyfzZPg
Date: Thu, 25 Dec 2014 08:21:05 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [xrblock] Last Call Review: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Dec 2014 08:21:15 -0000

Hi Tom,

Thank you for the nice Gen-ART review. Please see my replies inline starting with "[Rachel]".


> -----Original Message-----
> From: Tom Taylor []
> Sent: Thursday, December 25, 2014 10:42 AM
> To: Gen Art;;
>;; Dan Romascanu
> Subject: Last Call Review: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
> please see the FAQ at
> <>.
> Please resolve these comments along with any other Last Call comments you
> may receive.
> Document: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07
> Reviewer: Tom Taylor
> Review Date: 2014-12-24
> IETF LC End Date: 2014-12-26
> IESG Telechat date: 2015-01-08
> Summary: This document is mostly to publish as a Proposed Standard, with
> minor issues verging on editorial corrections.
> Major issues: None.
> Minor issues:
> 1) Second paragraph of Introduction: last sentence introduces the "repaired
> loss count". I found this confusing. Figure 1 shows you really meant "unrepaired
> loss count".

[Rachel]: This report block introduces two metrics : "unrepaired loss count" which is specified as the total number of packets finally lost after applying loss-repair methods. And "repaired loss count" is specified as the total number of packets which are fully repaired after applying loss-repair methods. And in this sentence, I meant "repaired loss count" because this metric is used to help calculating pre-repair loss count (pre-repair loss count = unrepaired loss count + repaired loss count). Maybe the name of "unrepaired loss count" is confusing. Would it better changing to "post-repair loss count"?
> 2) First paragraph of Section 3, third sentence: the ending currently reads:
>     "Some packets will not be repaired in the current
>     RTCP interval."
> I think your point is that some of these could be repaired later, so I suggest the
> text should be extended:
>     "Some packets will not be repaired in the current
>      RTCP interval, but could be repaired later."

[Rachel]: Right. Will fix it in the new version.

> 3) I question whether RFCs 4588 and 5109 are normative for this document,
> but I know this sort of thing is a difficult decision and I'll accept whatever the
> final outcome is.

[Rachel]: I agree with you that these two should be informative. 
> 4) Appendix A: The "Units of Measurement" are packets.

[Rachel]: According to RFC6390, Section 5.4.5, there's an example to show how to define a metric. Here's how it defines the "Units of Measurement":
Units of Measurement:  This metric is expressed as a fixed-point number with the binary point at the left edge of the field.  For example, a metric value of 12 means a loss rate of approximately 5%.
I consulted it to specify mine. 

> Nits/editorial comments:
> 1) First paragraph of introduction:
>        s/contains/contain/ at end of first line.
> Fourth sentence:
>     However, this metric is measured on media stream before
>     any loss repair mechanism, e.g., retransmission [RFC4588] and Forward
>     Error Correction (FEC) [RFC5109], is applied.
>     However, this metric is measured on the media stream before
>                                         ^^^
>     any loss repair mechanism, e.g., retransmission [RFC4588] or Forward
>                                                               ^^
>     Error Correction (FEC) [RFC5109], is applied.

[Rachel]: Okay. All the above nits will be fixed.

> I would break this paragraph into three parts. The first three sentences
> introduce the existing metric. The next two sentences, from "However, ..." to
> "... [RFC3550].", introduce the problem. The following two sentences, from
> "Consequently ..." through "... higher overhead.", give an attempted solution.
> The final sentence, I think, is the motivator for this document and I would
> merge it into the next paragraph.

[Rachel]: Good suggestion.

> 2) First paragrpah of Section 3: again, I suggest it be broken into three parts.
> The second part would begin with "Thus it is RECOMMENDED ...", and the
> third with "The sequence number range ...".

[Rachel]: Okay. So you're suggesting to break the big paragraph into 3 small ones, right?

> 3) The sentence preceding Figure 1 should identify "Figure 1" explicitly (via
> XML2RFC cross-reference if that is what you are using). It should also note that

[Rachel]: Okay. Will do.

> bit positions are given in octal -- the first time I've seen that in a document, but
> it's OK with me.

[Rachel]: This draft is just an RTCP XR extension to augment the report blocks defined in RFC3611. So the format is just in a manner consistent with other RTCP XR packets. All the RFCs produced in XRBLOCK wg specifying new report blocks have the same pattern. That's why I think it doesn't need to be clarified in this draft.

> 5) Section 5, third line: s/confidentially/confidentiality/

[Rachel]: Okay.