Re: [xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-06

Qin Wu <bill.wu@huawei.com> Thu, 11 December 2014 02:53 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804B61A1B8F for <xrblock@ietfa.amsl.com>; Wed, 10 Dec 2014 18:53:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.422
X-Spam-Level:
X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGF248Pq04eI for <xrblock@ietfa.amsl.com>; Wed, 10 Dec 2014 18:53:21 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3910B1A1B75 for <xrblock@ietf.org>; Wed, 10 Dec 2014 18:53:21 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMS41709; Thu, 11 Dec 2014 02:53:18 +0000 (GMT)
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 11 Dec 2014 02:53:17 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.169]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Thu, 11 Dec 2014 10:53:05 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Benoit Claise <bclaise@cisco.com>, "Romascanu, Dan (Dan)" <dromasca@avaya.com>, "Huangyihong (Rachel)" <rachel.huang@huawei.com>, Alissa Cooper <alissa@cooperw.in>
Thread-Topic: [xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-06
Thread-Index: AQHQE2BunkaheK1Nx060js92yAmBGZyHfY+AgAAiM4CAAJP2AIAAFq2AgAFk0VA=
Date: Thu, 11 Dec 2014 02:53:05 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA8468EAF4@nkgeml501-mbs.china.huawei.com>
References: <D32FC842-9A83-4D05-8509-FAACEE043A4A@cooperw.in> <51E6A56BD6A85142B9D172C87FC3ABBB86293A40@nkgeml501-mbs.china.huawei.com> <5BD63A76-DEFB-4DC1-B1F2-348DBE4A5845@cooperw.in> <51E6A56BD6A85142B9D172C87FC3ABBB862968C3@nkgeml501-mbs.china.huawei.com> <9904FB1B0159DA42B0B887B7FA8119CA5C92A34E@AZ-FFEXMB04.global.avaya.com> <548847E1.90103@cisco.com>
In-Reply-To: <548847E1.90103@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.180]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/8f-aaKuGBdO9o7DY-y9Vq79KYN0
Cc: "gonzalo.camarillo@ericsson.com" <gonzalo.camarillo@ericsson.com>, "xrblock@ietf.org" <xrblock@ietf.org>
Subject: Re: [xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-06
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, 11 Dec 2014 02:53:23 -0000

-----邮件原件-----
发件人: Benoit Claise [mailto:bclaise@cisco.com] 
发送时间: 2014年12月10日 21:17
收件人: Romascanu, Dan (Dan); Huangyihong (Rachel); Alissa Cooper
抄送: xrblock@ietf.org; gonzalo.camarillo@ericsson.com; Qin Wu
主题: Re: [xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-06

On 10/12/2014 12:56, Romascanu, Dan (Dan) wrote:
>
>> -----Original Message-----
>> From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of 
>> Huangyihong
>> (Rachel)
>>
>>> = Appendix A =
>>> Doesn't it sort of defeat the purpose of the 6390 template to fill 
>>> out a
>> template with a bunch of links back to the definitions of the fields 
>> in other parts of the document, rather than putting those definitions 
>> directly in the template? I mean, isn't the point of the template to 
>> have all of the information concisely reported in one place?
>>
>>> [Rachel]: I referenced previous RFCs, like [RFC7243] [RFC7294]. But 
>>> it's okay
>> for me to have those definitions directly copied in the template if you want.
>>
>>
>>
>> Well, I guess I did not ask about this for those RFCs, but I would 
>> like to understand better what the point of the template is if all 
>> the templates end up linking the reader back to various sections of the document.
>>
>>
>>
>> [Rachel]: I didn't well involved in the 6390 template usage 
>> discussion. So others please correct me if I'm wrong. But as far as I 
>> remember, it is raised by the OPS AD who thinks we are defining new 
>> metrics while without following the 6390 template. But the drafts of 
>> xrblock are more focus on the RTCP XR report block definition. So 
>> Compromise is made that we use the 6390 template at the appendix for 
>> the metrics. Since most of the definitions in the template have been 
>> specified in the draft, we just simply reference them in the template.
>>
> Hi,
>
> Rachel's recollection is correct. This discussion happened when the first XRBLOCK documents hit the IESG table after RFC 6390 was published. Qin  was the main editor, Benoit was the OPS AD, Gonzalo was the RAI AD, and I was the document shepherd. Benoit asked to re-use the 6390 template, so that the metrics defined by XRBLOCK are formatted in a similar manner with metrics defined by other WGs in the IETF. The WG wanted that the RFC text keeps compatibility with previous XRBLOCK / RTCP-XR definitions. So we arrived at the solution to include the RFC 6390 style of definition in Annexes, using references in order to avoid duplication.
Correct.
The primary reason was that the RFC 6390 template definitions in the XRBLOCK documents could be reused when populating the performance metric registry (see http://tools.ietf.org/html/draft-ietf-ippm-metric-registry)

[Qin]: Agree with What both Dan and Benoit said here.
I think it might be helpful to optimize some places for the metrics represented using RFC6390 in the annex, and also it is no harm to add some clarification text in the annex.
e.g., for Units of Measurement, instead of referencing metric definition in some section, you can say something like:
"
This metric is expressed as a 16-bit unsigned integer value.
"
Also for measurement timing, besides referencing to specific section, you can also add some text to say:
"
This metric relies on the sequence number
interval to determine measurement timing.
"
For measurement method of " Unrepaired RTP Packet Loss Count Metric ", you can replace the original text with the following text:

"
* Method of Measurement or Calculation: See section 3, Unrepaired RTP Packet Loss Count Metric definition. It is directly measured and must be measured for
 the primary source RTP packets with no further chance of repair.
"
For measurement point, you can say something like:
"
It is measured at the receiving end of the RTP stream.
"
Instead.

Regards, Benoit
>
> Regards,
>
> Dan
>   
> .
>