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

Tom Taylor <tom.taylor.stds@gmail.com> Thu, 25 December 2014 02:41 UTC

Return-Path: <tom.taylor.stds@gmail.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 432731A6FE6; Wed, 24 Dec 2014 18:41:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id r3TIKIiEdGuS; Wed, 24 Dec 2014 18:41:50 -0800 (PST)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBCD81A6FE3; Wed, 24 Dec 2014 18:41:49 -0800 (PST)
Received: by mail-ig0-f172.google.com with SMTP id hl2so7520618igb.5; Wed, 24 Dec 2014 18:41:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=sQtGj6B7h+T3aNFFjUyDdUjAHS9Mmvi4uzUM14eKJHI=; b=McPs6kZN2A4yUzjY4KXz7A5upA7E0JOb3RQQqV6k7j/+cMw0gdBEUo9eGk5g8LPHGN 2K9bahhiJlzcWTyKT8Tx1tZwFRATAKHEKy4eSW2fTdlgEd9/5Jx+Wf644KoKdDMQFrkc Bxu1fP09nKM5YIxDIs7sF2ObrKOHep6YiyhWYK4Kx4KX1d1GxEVmKcku2PnHX9glRCXd pqXOxor0zJUT1zjGOsJqxXCVr7ITdufXnGx66L3cGO+6yp85qvyNkSAxdNIh69fL2MNZ ECaqmep1cI5MB4nMV5wVv/4nnQ1zFES1x5sA/aahYxNu4HWICi5kHOEUYH7tn8ZP6oE1 BjaA==
X-Received: by with SMTP id sc1mr3964593igb.12.1419475308853; Wed, 24 Dec 2014 18:41:48 -0800 (PST)
Received: from [] (dsl-173-206-8-163.tor.primus.ca. []) by mx.google.com with ESMTPSA id bd5sm8700617igb.14.2014. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Dec 2014 18:41:48 -0800 (PST)
Message-ID: <549B796F.30802@gmail.com>
Date: Wed, 24 Dec 2014 21:41:51 -0500
From: Tom Taylor <tom.taylor.stds@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Gen Art <gen-art@ietf.org>, draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@tools.ietf.org, "xrblock-chairs@tools.ietf.org" <xrblock-chairs@tools.ietf.org>, xrblock@ietf.org, Dan Romascanu <dromasca@avaya.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/gfzdJqobK3Upy503gerETGeQ-jM
X-Mailman-Approved-At: Thu, 01 Jan 2015 03:31:58 -0800
Subject: [xrblock] Last Call Review: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xrblock/>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Dec 2014 02:41:52 -0000

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".

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."

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.

4) Appendix A: The "Units of Measurement" are packets.

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.

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.

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 ...".

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

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