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

Benoit Claise <bclaise@cisco.com> Wed, 10 December 2014 13:17 UTC

Return-Path: <bclaise@cisco.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 955A31A1BEA for <xrblock@ietfa.amsl.com>; Wed, 10 Dec 2014 05:17:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 ChSgSC-PINk5 for <xrblock@ietfa.amsl.com>; Wed, 10 Dec 2014 05:17:23 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670351A1B61 for <xrblock@ietf.org>; Wed, 10 Dec 2014 05:17:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2502; q=dns/txt; s=iport; t=1418217443; x=1419427043; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1yqhMSD9ZzCzWRHYFvwOHKwYvm5+af5nfIPjgyHXKEA=; b=ZNk/OXBlvJBXD74gYAcbKwpK8UVpPnCRKbHrCYHZT3wJ0Ek6FGAPyQOh TRynK9T3s7X26dRg98jUm2+tm+PxyLcFTiGIT5qqvZCrYryToxjgy3lgm rYUmggdA9bpH3uFyxe/6Mj4ZS3cAqqiX4hJHoqVpQ9dRokzWUIA1iwPj9 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqcEANRGiFStJssW/2dsb2JhbABZg1jGZIVuAoEtAQEBAQF9hAIBAQEEOEEMBAsVAwkeBw8CNREGAQwBBQIBAReIHQ3XKQEBAQEBAQEBAQEBAQEBAQEBAQEBARePUDMHhDYBBJFCgXyDNYEMMIIsghCLYoIwgT89MIJDAQEB
X-IronPort-AV: E=Sophos;i="5.07,552,1413244800"; d="scan'208";a="264259001"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 10 Dec 2014 13:17:21 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sBADHLLp015902; Wed, 10 Dec 2014 13:17:21 GMT
Message-ID: <548847E1.90103@cisco.com>
Date: Wed, 10 Dec 2014 14:17:21 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, "Huangyihong (Rachel)" <rachel.huang@huawei.com>, Alissa Cooper <alissa@cooperw.in>
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>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C92A34E@AZ-FFEXMB04.global.avaya.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/2VYVXD-7JEbJTcWpFvijG1QNJTs
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: Wed, 10 Dec 2014 13:17:25 -0000

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)

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