From bclaise@cisco.com  Sun May  5 14:06:43 2013
Return-Path: <bclaise@cisco.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723BE21F8675 for <pm-dir@ietfa.amsl.com>; Sun,  5 May 2013 14:06:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.556
X-Spam-Level: 
X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g37VmfuBGN5v for <pm-dir@ietfa.amsl.com>; Sun,  5 May 2013 14:06:37 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5511221F9734 for <pm-dir@ietf.org>; Sun,  5 May 2013 14:06:37 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r45L6a4j013432 for <pm-dir@ietf.org>; Sun, 5 May 2013 23:06:36 +0200 (CEST)
Received: from sweet-brew-5.cisco.com (sweet-brew-5.cisco.com [144.254.10.206]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r45L66uG006860 for <pm-dir@ietf.org>; Sun, 5 May 2013 23:06:16 +0200 (CEST)
Received: (from bclaise@localhost) by sweet-brew-5.cisco.com (8.13.8+Sun/8.13.6/Submit) id r45L638k023254 for pm-dir@ietf.org; Sun, 5 May 2013 23:06:03 +0200 (CEST)
Date: Sun, 5 May 2013 23:06:03 +0200
From: Benoit Claise <bclaise@cisco.com>
To: pm-dir@ietf.org
Message-ID: <20130505210603.GA23252@sweet-brew-5.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Subject: [pm-dir] Performance metrics doctors generated email
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 May 2013 21:06:43 -0000

Dear all,

This is an automatically generated email.  
It lists the IETF internet-drafts that reference the PMOL RFC 6390, as a normative or informative reference.
It also lists all the IETF internet-drafts that contain "performance metric".

Regards, Benoit

===========================================================

Normative References
--------------------
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 Active	
    
Informative References
----------------------
draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14   In IESG processing - ID Tracker state <IESG Evaluation::AD Followup>	
draft-ietf-xrblock-rtcp-xr-burst-gap-loss-12      In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-decodability-11        In IESG processing - ID Tracker state <Waiting for AD Go-Ahead::External Party>	
draft-ietf-xrblock-rtcp-xr-discard-13             In IESG processing - ID Tracker state <Publication Requested>	
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 Active	
draft-ietf-xrblock-rtcp-xr-jb-11                  Active	
draft-ietf-xrblock-rtcp-xr-loss-conceal-05        Active	
draft-ietf-xrblock-rtcp-xr-qoe-06                 Active	
draft-ietf-xrblock-rtcp-xr-summary-stat-11        In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-synchronization-04     Active	

drafts containing performance metric
------------------------------------
draft-ietf-alto-deployments-06                    Active	
draft-ietf-alto-protocol-14                       Active	
draft-ietf-bmwg-ca-bench-meth-04                  Active	
draft-ietf-ippm-rate-problem-03                   Active	
draft-ietf-ippm-testplan-rfc2680-02               Active	
draft-ietf-manet-smf-mib-07                       In IESG processing - ID Tracker state <AD Evaluation::Revised I-D Needed>	
draft-ietf-nvo3-framework-02                      Active	
draft-ietf-opsawg-oam-overview-08                 In IESG processing - ID Tracker state <Waiting for AD Go-Ahead::Revised I-D Needed>	
draft-ietf-pce-pcep-service-aware-00              Active	
draft-ietf-ppsp-peer-protocol-06                  Active	
draft-ietf-rtcweb-rtp-usage-06                    Active	
draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14   In IESG processing - ID Tracker state <IESG Evaluation::AD Followup>	
draft-ietf-xrblock-rtcp-xr-burst-gap-loss-12      In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-decodability-11        In IESG processing - ID Tracker state <Waiting for AD Go-Ahead::External Party>	
draft-ietf-xrblock-rtcp-xr-discard-13             In IESG processing - ID Tracker state <Publication Requested>	
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 Active	
draft-ietf-xrblock-rtcp-xr-jb-11                  Active	
draft-ietf-xrblock-rtcp-xr-loss-conceal-05        Active	
draft-ietf-xrblock-rtcp-xr-qoe-06                 Active	
draft-ietf-xrblock-rtcp-xr-summary-stat-11        In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-synchronization-04     Active	

From bclaise@cisco.com  Sun May 12 14:06:38 2013
Return-Path: <bclaise@cisco.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2650221F87B7 for <pm-dir@ietfa.amsl.com>; Sun, 12 May 2013 14:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.42
X-Spam-Level: 
X-Spam-Status: No, score=-10.42 tagged_above=-999 required=5 tests=[AWL=0.179,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7zhS3SLQr49 for <pm-dir@ietfa.amsl.com>; Sun, 12 May 2013 14:06:32 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 00B6921F8624 for <pm-dir@ietf.org>; Sun, 12 May 2013 14:06:31 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4CL6PZ1007256 for <pm-dir@ietf.org>; Sun, 12 May 2013 23:06:25 +0200 (CEST)
Received: from sweet-brew-5.cisco.com (sweet-brew-5.cisco.com [144.254.10.206]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4CL69XL018364 for <pm-dir@ietf.org>; Sun, 12 May 2013 23:06:19 +0200 (CEST)
Received: (from bclaise@localhost) by sweet-brew-5.cisco.com (8.13.8+Sun/8.13.6/Submit) id r4CL66rQ019122 for pm-dir@ietf.org; Sun, 12 May 2013 23:06:06 +0200 (CEST)
Date: Sun, 12 May 2013 23:06:06 +0200
From: Benoit Claise <bclaise@cisco.com>
To: pm-dir@ietf.org
Message-ID: <20130512210606.GA19108@sweet-brew-5.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Subject: [pm-dir] Performance metrics doctors generated email
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 May 2013 21:06:38 -0000

Dear all,

This is an automatically generated email.  
It lists the IETF internet-drafts that reference the PMOL RFC 6390, as a normative or informative reference.
It also lists all the IETF internet-drafts that contain "performance metric".

Regards, Benoit

===========================================================

Normative References
--------------------
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 Active	
    
Informative References
----------------------
draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14   In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-burst-gap-loss-12      In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-decodability-11        In IESG processing - ID Tracker state <Waiting for AD Go-Ahead::External Party>	
draft-ietf-xrblock-rtcp-xr-discard-13             In IESG processing - ID Tracker state <Publication Requested>	
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 Active	
draft-ietf-xrblock-rtcp-xr-jb-11                  In IESG processing - ID Tracker state <Publication Requested>	
draft-ietf-xrblock-rtcp-xr-loss-conceal-05        Active	
draft-ietf-xrblock-rtcp-xr-qoe-06                 Active	
draft-ietf-xrblock-rtcp-xr-summary-stat-11        In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-synchronization-04     Active	

drafts containing performance metric
------------------------------------
draft-ietf-alto-deployments-06                    Active	
draft-ietf-alto-protocol-15                       Active	
draft-ietf-bmwg-ca-bench-meth-04                  Active	
draft-ietf-ippm-rate-problem-03                   Active	
draft-ietf-ippm-testplan-rfc2680-02               Active	
draft-ietf-manet-smf-mib-07                       In IESG processing - ID Tracker state <AD Evaluation::Revised I-D Needed>	
draft-ietf-nvo3-framework-02                      Active	
draft-ietf-opsawg-oam-overview-08                 In IESG processing - ID Tracker state <Waiting for AD Go-Ahead::Revised I-D Needed>	
draft-ietf-pce-pcep-service-aware-00              Active	
draft-ietf-ppsp-peer-protocol-06                  Active	
draft-ietf-rtcweb-rtp-usage-06                    Active	
draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14   In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-burst-gap-loss-12      In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-decodability-11        In IESG processing - ID Tracker state <Waiting for AD Go-Ahead::External Party>	
draft-ietf-xrblock-rtcp-xr-discard-13             In IESG processing - ID Tracker state <Publication Requested>	
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 Active	
draft-ietf-xrblock-rtcp-xr-jb-11                  In IESG processing - ID Tracker state <Publication Requested>	
draft-ietf-xrblock-rtcp-xr-loss-conceal-05        Active	
draft-ietf-xrblock-rtcp-xr-qoe-06                 Active	
draft-ietf-xrblock-rtcp-xr-summary-stat-11        In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-synchronization-04     Active	

From gonzalo.camarillo@ericsson.com  Wed May 15 08:20:49 2013
Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BF521F8F4F for <pm-dir@ietfa.amsl.com>; Wed, 15 May 2013 08:20:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.023
X-Spam-Level: 
X-Spam-Status: No, score=-106.023 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-BHlMovI-Ox for <pm-dir@ietfa.amsl.com>; Wed, 15 May 2013 08:20:40 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id EDE0021F8ECB for <pm-dir@ietf.org>; Wed, 15 May 2013 08:20:39 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f536d000006e05-40-5193a7c599c5
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9C.F3.28165.5C7A3915; Wed, 15 May 2013 17:20:37 +0200 (CEST)
Received: from [131.160.126.54] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Wed, 15 May 2013 17:20:37 +0200
Message-ID: <5193A7C3.40906@ericsson.com>
Date: Wed, 15 May 2013 18:20:35 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Qin Wu <bill.wu@huawei.com>
References: <CD8499D5.4FA30%alan.d.clark@telchemy.com> <A64E8EB6A56342CB8423D1532A94709C@china.huawei.com> <51656EB3.9060300@cisco.com> <B8F9A780D330094D99AF023C5877DABA43A3C121@nkgeml501-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA43A3C121@nkgeml501-mbs.china.huawei.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+Jvre7R5ZMDDdbd17bYemwio8XEN8wW c6ZfZLU4+ljC4vHcBawWX3/+YLVYP/kSi8XRD5YWSztPsVv8PjSP1YHL42X/HEaPgyvnsHtM +b2R1WPnrLvsHi1H3rJ6LFnyk8njxdHt7B49l2Yzehybf44xgDOKyyYlNSezLLVI3y6BK+Pl 1vXsBW+tKlpXrmRpYFyp38XIySEhYCJxZvlFdghbTOLCvfVsXYxcHEICpxglOu41sUM4axgl 7v3ayQhSxSugKXF0429WEJtFQFXiZecxsDibgIXEllv3WUBsUYEoiX9vd0PVC0qcnPkELC4i IC/RsPkuI8hQZoFXTBK/r59lBnGEBRoYJRpXz2eCWHeRUWLi4VtgKzgFwiQOL/vHCHGgpMSi aZ1go5iBzmjd/psdwpaXaN46mxnEFhLQllj+rIVlAqPQLCTbZyFpmYWkZQEj8ypG9tzEzJz0 csNNjMAYOrjlt+4OxlPnRA4xSnOwKInzJnE1BgoJpCeWpGanphakFsUXleakFh9iZOLglGpg zNknu5lj38OHtaJXn3VW3TT9V/qunqV8Q2vjmltSFg8SelKr5oTPe3J4QaL904Osx4IsJzT/ zOg4kmG0W/7e3i9uZs353AUzmNYs59xYmNHgudZk7uXAE1dubjJtW/uA4dFMhaQT914xXPrH uf2E4ucCa8Gl7+p8k5zu/b0ntGJPi95PIfcd95RYijMSDbWYi4oTAeZ3IQpvAgAA
Cc: "Huangyihong \(Rachel\)" <rachel.huang@huawei.com>, Shida Schubert <shida@ntt-at.com>, "Dan \(Dan\)" <dromasca@avaya.com>, "asaeda@nict.go.jp" <asaeda@nict.go.jp>, Alan Clark <alan.d.clark@telchemy.com>, "glenzorn@gmail.com" <glenzorn@gmail.com>, Benoit Claise <bclaise@cisco.com>, "pm-dir@ietf.org" <pm-dir@ietf.org>, Al Morton <acmorton@att.com>
Subject: Re: [pm-dir] =?utf-8?b?562U5aSNOiBSRkM2MzkwIHJldmlldyBvZiBkcmFmdC1p?= =?utf-8?q?etf-xrblock-rtcp-xr-decodability?=
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2013 15:20:49 -0000

Hi Benoit,

what is the status of this? Can I progress this draft at this point?

Thanks,

Gonzalo

On 11/04/2013 5:14 AM, Qin Wu wrote:
> Hi,Benoit:
> As Alan observed in PM-DIR review, this draft does not define new metrics but refers to metrics that are
> clearly defined in a normative reference.
> I think we can skip RFC6390 template usage just like PDV draft(RFC6798) did, can't we?
> 
> Regards!
> -Qin
> -----邮件原件-----
> 发件人: Benoit Claise [mailto:bclaise@cisco.com] 
> 发送时间: 2013年4月10日 21:53
> 收件人: Qin Wu
> 抄送: Alan Clark; Gonzalo Camarillo; pm-dir@ietf.org; Dan (Dan); Shida Schubert; Huangyihong (Rachel); asaeda@nict.go.jp; glenzorn@gmail.com; Al Morton
> 主题: Re: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
> 
> Hi Qin,
> 
> And don't forget the RFC 6390 template usage.
> 
> Regards, Benoit
>> Hi, Alan:
>> Thank for your valuable comments.
>> We have updated the draft to incorporate your comments in the new version (-v11).
>> The diff is:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-decodability-11
>> Please also see my reply below.
>>
>> Regards!
>> -Qin
>> ----- Original Message -----
>> From: "Alan Clark" <alan.d.clark@telchemy.com>
>> To: "Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>; <pm-dir@ietf.org>; "Benoit Claise" <bclaise@cisco.com>; "Dan (Dan)" <dromasca@avaya.com>; "Shida Schubert" <shida@ntt-at.com>; <rachel.huang@huawei.com>; <bill.wu@huawei.com>; <asaeda@nict.go.jp>; <glenzorn@gmail.com>; "Al Morton" <acmorton@att.com>
>> Sent: Saturday, April 06, 2013 3:10 AM
>> Subject: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
>>
>>
>> There are quite a few issues with the draft - I can re-review as soon as
>> these are addressed.
>>
>> Alan Clark
>>
>>
>>
>> A. General Comments
>>   
>> This draft does not define new metrics but refers to metrics that are
>> clearly defined in a normative reference.  The normative reference (ETSI
>> TR101290) predates RFC6390 however does contain a fairly clear description
>> of the metrics with explanation of their usage. It is not recommended that
>> this draft redefines the metrics in RFC6390 template form
>>
>> [Qin]: Exactly.
>>
>> however there is
>> considerable scope for improvement in the clarity of definition of how these
>> metrics are used.
>>
>> [Qin]: Agree.
>>   
>> B. Applicability Section
>>   
>> 1.4 Applicability
>> Metrics only measure transport stream quality not content stream quality.
>> Also the metrics are not defined in this draft but are encodings of the
>> metrics defined in ETSI TS 101290.
>>   
>> Suggest
>>   
>> ³This block type allows a counts of MPEG Transport Stream quality metrics
>> that are measured in accordance with ETSI TR 101290 [ETSI] to be reported by
>> an endpoint.  These metrics are useful for identifying bitstream
>> packetization and transport stream encoding problems that may affect the
>> user¹s perception of a video service delivered over RTP.²
>>
>> [Qin]: Okay. Your proposed text have been incorporated in (-v11).
>>   
>> C. Metrics Definitions
>>   
>> C.1 General
>>   
>> For clarity the draft should preface the metrics definitions with a general
>> explanation of how these metrics relate to ETSI TR101290. TR101290 generally
>> defines error events and this draft contains counts of those metrics.
>>
>>   
>> If there are any ³edge² cases where a problem in one measurement interval
>> would be reflected in the count in the next measurement interval then this
>> should be articulated in the general description and also in the specific
>> metric.  For example, a sync byte error is defined as multiple consecutive
>> errored sync bytes and if this was reported in an interval it may have
>> occurred at the end of the preceding interval or at some time during the
>> present interval - hence the description should state that the count may
>> reflect a problem in the current or previous interval. This would also be
>> the case for PCR errors and even continuity count errors.
>>
>> [Qin]: Okay, I have added some text in the 2nd paragraph of section 3
>> and incorporated your suggested text in (v-11).
>>   
>> C.2  Sequence numbers
>>   
>> begin_seq and end_seq
>>   
>> These definitions simply say ³As defined inS² which requires the reader to
>> refer to another document. It is good practice to at least mention what the
>> definition refers to and then to include a reference that contains the
>> normative definition.
>>   
>> SoS..
>>   
>> ³begin_seq: 16 bits
>>
>> The RTP sequence number corresponding to the start of the measurement
>> period, as defined in Section 4.1 of RFC 3611²
>>
>> [Qin]: Fixed in (-v11).
>>   
>> C.3 Metrics definitions
>> The metrics definitions should contain a firmer statement of what is being
>> measured and, if the normative definition is in another standard, then
>> clearly state ³as defined in Section X.Y of NNNNN². This applies to all the
>> metrics definitions and the example below can be used as a template for
>>   
>> For example
>>   
>> Existing language S..
>>   
>> TS_sync_loss_count: 32 bits
>>   
>> Number of TS_sync_loss errors in the above sequence number interval.  It is
>> calculated based on the occurrence of errors for "TS_sync_loss"parameter
>> defined in the section 5.2.1 of [ETSI] (Also see section 5.5.1 of [ETSI]).
>>   
>> This is very vague language and it is unclear why the ³Also see² reference
>> is there.  A better approach is:
>>   
>> Replacement language (use this format for each of the metrics)
>>   
>> TS_sync_loss_count: 32 bits
>>   
>> A count of the number of TS_sync_loss errors that occurred in the above
>> sequence number interval.  A TS_sync_loss error occurs when there are two or
>> more consecutive incorrect sync bytes within the MPEG TS stream, as defined
>> in section 5.2.1 of [ETSI]. This parameter may be used as part of a Service
>> Availability calculation, as defined in section 5.5.1 of [ETSI].
>>
>> [Qin]: Fixed in (-v11).
>>   
>> C.4 Service Availability
>>   
>> Following on from the previous comment,  section 5.5.1 of TR101290 describes
>> a service availability error as a combination of TS_sync_loss, PAT_error and
>> PMT_error whereas draft-ietf-xrblock-rtcp-xr-decodability-10 does not
>> contain the PAT and PMT error metrics.  The resolution for this would either
>> be to remove the reference to 5.5.1 or to add the metrics required to
>> calculate the service availability.
>>   
>> [Qin]: Agree. I prefer to remove the reference to 5.5.1 since there was consensus in the past WGLC to this draft
>> that having a second report block later to cover the other parameters and get inline with concept of RFC6792
>> and letting this draft focus on PSI indpendent parameter reporting.
>> See details for the WGLC discussion in the following link:
>> http://www.ietf.org/mail-archive/web/xrblock/current/msg01032.html
>>
>> It is recommended that PAT_error , PAT_error_2,  PMT_error and PMT_error_2
>> be included as metrics as these ³are² generally present in MPEG Transport
>> streams and errors within these can prevent correct decoding of the stream.
>>   
>> C.5 PCR_error_count
>>   
>> PCR_error_count is defined twice - the second of these should be
>> PCR_accuracy_error_count
>>   
>>   [Qin]: Good catch and have fixed in (-v11).
>>
>>
>>
> 


From acmorton@att.com  Wed May 15 08:45:48 2013
Return-Path: <acmorton@att.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEA221F8733 for <pm-dir@ietfa.amsl.com>; Wed, 15 May 2013 08:45:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.223
X-Spam-Level: 
X-Spam-Status: No, score=-106.223 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUL3wA3FNLi6 for <pm-dir@ietfa.amsl.com>; Wed, 15 May 2013 08:45:43 -0700 (PDT)
Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id D877D21F86F5 for <pm-dir@ietf.org>; Wed, 15 May 2013 08:45:42 -0700 (PDT)
Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id BC59B120370; Wed, 15 May 2013 11:45:40 -0400 (EDT)
Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id 0BD87E26A2; Wed, 15 May 2013 11:45:23 -0400 (EDT)
Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Wed, 15 May 2013 11:45:34 -0400
From: "MORTON JR., ALFRED C (AL)" <acmorton@att.com>
To: Alan Clark <alan.d.clark@telchemy.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, Qin Wu <bill.wu@huawei.com>
Date: Wed, 15 May 2013 11:45:33 -0400
Thread-Topic: =?utf-8?B?562U5aSNOiBSRkM2MzkwIHJldmlldyBvZiBkcmFmdC1pZXRmLXhyYmxvY2st?= =?utf-8?B?cnRjcC14ci1kZWNvZGFiaWxpdHk=?=
Thread-Index: Ac5Rf8o7eiEQpvSsRoKHKPDMei3QHAAA0pcw
Message-ID: <F1312FAF1A1E624DA0972D1C9A91379A1BFFE38BF3@njfpsrvexg7.research.att.com>
References: <CD8499D5.4FA30%alan.d.clark@telchemy.com> <A64E8EB6A56342CB8423D1532A94709C@china.huawei.com> <51656EB3.9060300@cisco.com> <B8F9A780D330094D99AF023C5877DABA43A3C121@nkgeml501-mbs.china.huawei.com> <5193A7C3.40906@ericsson.com>
In-Reply-To: <5193A7C3.40906@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "Huangyihong \(Rachel\)" <rachel.huang@huawei.com>, Shida Schubert <shida@ntt-at.com>, "Dan \(Dan\)" <dromasca@avaya.com>, "asaeda@nict.go.jp" <asaeda@nict.go.jp>, "glenzorn@gmail.com" <glenzorn@gmail.com>, Benoit Claise <bclaise@cisco.com>, "pm-dir@ietf.org" <pm-dir@ietf.org>
Subject: Re: [pm-dir] =?utf-8?b?562U5aSNOiBSRkM2MzkwIHJldmlldyBvZiBkcmFmdC1p?= =?utf-8?q?etf-xrblock-rtcp-xr-decodability?=
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2013 15:45:48 -0000

QWxhbiwgDQpTaW5jZSB5b3UgcmV2aWV3ZWQgdGhpcyBkcmFmdCwgYXJlIHlvdSBzYXRpc2ZpZWQg
d2l0aCB0aGUgcmV2aXNpb25zPw0KQWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
PiBGcm9tOiBHb256YWxvIENhbWFyaWxsbyBbbWFpbHRvOkdvbnphbG8uQ2FtYXJpbGxvQGVyaWNz
c29uLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBNYXkgMTUsIDIwMTMgMTE6MjEgQU0NCj4gVG86
IFFpbiBXdQ0KPiBDYzogQmVub2l0IENsYWlzZTsgQWxhbiBDbGFyazsgcG0tZGlyQGlldGYub3Jn
OyBEYW4gKERhbik7IFNoaWRhIFNjaHViZXJ0Ow0KPiBIdWFuZ3lpaG9uZyAoUmFjaGVsKTsgYXNh
ZWRhQG5pY3QuZ28uanA7IGdsZW56b3JuQGdtYWlsLmNvbTsgTU9SVE9OIEpSLiwNCj4gQUxGUkVE
IEMgKEFMKQ0KPiBTdWJqZWN0OiBSZTog562U5aSNOiBSRkM2MzkwIHJldmlldyBvZiBkcmFmdC1p
ZXRmLXhyYmxvY2stcnRjcC14ci1kZWNvZGFiaWxpdHkNCj4gDQo+IEhpIEJlbm9pdCwNCj4gDQo+
IHdoYXQgaXMgdGhlIHN0YXR1cyBvZiB0aGlzPyBDYW4gSSBwcm9ncmVzcyB0aGlzIGRyYWZ0IGF0
IHRoaXMgcG9pbnQ/DQo+IA0KPiBUaGFua3MsDQo+IA0KPiBHb256YWxvDQo+IA0KPiBPbiAxMS8w
NC8yMDEzIDU6MTQgQU0sIFFpbiBXdSB3cm90ZToNCj4gPiBIaSxCZW5vaXQ6DQo+ID4gQXMgQWxh
biBvYnNlcnZlZCBpbiBQTS1ESVIgcmV2aWV3LCB0aGlzIGRyYWZ0IGRvZXMgbm90IGRlZmluZSBu
ZXcNCj4gbWV0cmljcyBidXQgcmVmZXJzIHRvIG1ldHJpY3MgdGhhdCBhcmUNCj4gPiBjbGVhcmx5
IGRlZmluZWQgaW4gYSBub3JtYXRpdmUgcmVmZXJlbmNlLg0KPiA+IEkgdGhpbmsgd2UgY2FuIHNr
aXAgUkZDNjM5MCB0ZW1wbGF0ZSB1c2FnZSBqdXN0IGxpa2UgUERWIGRyYWZ0KFJGQzY3OTgpDQo+
IGRpZCwgY2FuJ3Qgd2U/DQo+ID4NCj4gPiBSZWdhcmRzIQ0KPiA+IC1RaW4NCj4gPiAtLS0tLemC
ruS7tuWOn+S7ti0tLS0tDQo+ID4g5Y+R5Lu25Lq6OiBCZW5vaXQgQ2xhaXNlIFttYWlsdG86YmNs
YWlzZUBjaXNjby5jb21dDQo+ID4g5Y+R6YCB5pe26Ze0OiAyMDEz5bm0NOaciDEw5pelIDIxOjUz
DQo+ID4g5pS25Lu25Lq6OiBRaW4gV3UNCj4gPiDmioTpgIE6IEFsYW4gQ2xhcms7IEdvbnphbG8g
Q2FtYXJpbGxvOyBwbS1kaXJAaWV0Zi5vcmc7IERhbiAoRGFuKTsgU2hpZGENCj4gU2NodWJlcnQ7
IEh1YW5neWlob25nIChSYWNoZWwpOyBhc2FlZGFAbmljdC5nby5qcDsgZ2xlbnpvcm5AZ21haWwu
Y29tOyBBbA0KPiBNb3J0b24NCj4gPiDkuLvpopg6IFJlOiBSRkM2MzkwIHJldmlldyBvZiBkcmFm
dC1pZXRmLXhyYmxvY2stcnRjcC14ci1kZWNvZGFiaWxpdHkNCj4gPg0KPiA+IEhpIFFpbiwNCj4g
Pg0KPiA+IEFuZCBkb24ndCBmb3JnZXQgdGhlIFJGQyA2MzkwIHRlbXBsYXRlIHVzYWdlLg0KPiA+
DQo+ID4gUmVnYXJkcywgQmVub2l0DQo+ID4+IEhpLCBBbGFuOg0KPiA+PiBUaGFuayBmb3IgeW91
ciB2YWx1YWJsZSBjb21tZW50cy4NCj4gPj4gV2UgaGF2ZSB1cGRhdGVkIHRoZSBkcmFmdCB0byBp
bmNvcnBvcmF0ZSB5b3VyIGNvbW1lbnRzIGluIHRoZSBuZXcNCj4gdmVyc2lvbiAoLXYxMSkuDQo+
ID4+IFRoZSBkaWZmIGlzOg0KPiA+PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k
cmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci0NCj4gZGVjb2RhYmlsaXR5LTExDQo+ID4+IFBsZWFz
ZSBhbHNvIHNlZSBteSByZXBseSBiZWxvdy4NCj4gPj4NCj4gPj4gUmVnYXJkcyENCj4gPj4gLVFp
bg0KPiA+PiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4+IEZyb206ICJBbGFuIENs
YXJrIiA8YWxhbi5kLmNsYXJrQHRlbGNoZW15LmNvbT4NCj4gPj4gVG86ICJHb256YWxvIENhbWFy
aWxsbyIgPEdvbnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbT47IDxwbS0NCj4gZGlyQGlldGYu
b3JnPjsgIkJlbm9pdCBDbGFpc2UiIDxiY2xhaXNlQGNpc2NvLmNvbT47ICJEYW4gKERhbikiDQo+
IDxkcm9tYXNjYUBhdmF5YS5jb20+OyAiU2hpZGEgU2NodWJlcnQiIDxzaGlkYUBudHQtYXQuY29t
PjsNCj4gPHJhY2hlbC5odWFuZ0BodWF3ZWkuY29tPjsgPGJpbGwud3VAaHVhd2VpLmNvbT47IDxh
c2FlZGFAbmljdC5nby5qcD47DQo+IDxnbGVuem9ybkBnbWFpbC5jb20+OyAiQWwgTW9ydG9uIiA8
YWNtb3J0b25AYXR0LmNvbT4NCj4gPj4gU2VudDogU2F0dXJkYXksIEFwcmlsIDA2LCAyMDEzIDM6
MTAgQU0NCj4gPj4gU3ViamVjdDogUkZDNjM5MCByZXZpZXcgb2YgZHJhZnQtaWV0Zi14cmJsb2Nr
LXJ0Y3AteHItZGVjb2RhYmlsaXR5DQo+ID4+DQo+ID4+DQo+ID4+IFRoZXJlIGFyZSBxdWl0ZSBh
IGZldyBpc3N1ZXMgd2l0aCB0aGUgZHJhZnQgLSBJIGNhbiByZS1yZXZpZXcgYXMgc29vbg0KPiBh
cw0KPiA+PiB0aGVzZSBhcmUgYWRkcmVzc2VkLg0KPiA+Pg0KPiA+PiBBbGFuIENsYXJrDQo+ID4+
DQo+ID4+DQo+ID4+DQo+ID4+IEEuIEdlbmVyYWwgQ29tbWVudHMNCj4gPj4NCj4gPj4gVGhpcyBk
cmFmdCBkb2VzIG5vdCBkZWZpbmUgbmV3IG1ldHJpY3MgYnV0IHJlZmVycyB0byBtZXRyaWNzIHRo
YXQgYXJlDQo+ID4+IGNsZWFybHkgZGVmaW5lZCBpbiBhIG5vcm1hdGl2ZSByZWZlcmVuY2UuICBU
aGUgbm9ybWF0aXZlIHJlZmVyZW5jZQ0KPiAoRVRTSQ0KPiA+PiBUUjEwMTI5MCkgcHJlZGF0ZXMg
UkZDNjM5MCBob3dldmVyIGRvZXMgY29udGFpbiBhIGZhaXJseSBjbGVhcg0KPiBkZXNjcmlwdGlv
bg0KPiA+PiBvZiB0aGUgbWV0cmljcyB3aXRoIGV4cGxhbmF0aW9uIG9mIHRoZWlyIHVzYWdlLiBJ
dCBpcyBub3QgcmVjb21tZW5kZWQNCj4gdGhhdA0KPiA+PiB0aGlzIGRyYWZ0IHJlZGVmaW5lcyB0
aGUgbWV0cmljcyBpbiBSRkM2MzkwIHRlbXBsYXRlIGZvcm0NCj4gPj4NCj4gPj4gW1Fpbl06IEV4
YWN0bHkuDQo+ID4+DQo+ID4+IGhvd2V2ZXIgdGhlcmUgaXMNCj4gPj4gY29uc2lkZXJhYmxlIHNj
b3BlIGZvciBpbXByb3ZlbWVudCBpbiB0aGUgY2xhcml0eSBvZiBkZWZpbml0aW9uIG9mIGhvdw0K
PiB0aGVzZQ0KPiA+PiBtZXRyaWNzIGFyZSB1c2VkLg0KPiA+Pg0KPiA+PiBbUWluXTogQWdyZWUu
DQo+ID4+DQo+ID4+IEIuIEFwcGxpY2FiaWxpdHkgU2VjdGlvbg0KPiA+Pg0KPiA+PiAxLjQgQXBw
bGljYWJpbGl0eQ0KPiA+PiBNZXRyaWNzIG9ubHkgbWVhc3VyZSB0cmFuc3BvcnQgc3RyZWFtIHF1
YWxpdHkgbm90IGNvbnRlbnQgc3RyZWFtDQo+IHF1YWxpdHkuDQo+ID4+IEFsc28gdGhlIG1ldHJp
Y3MgYXJlIG5vdCBkZWZpbmVkIGluIHRoaXMgZHJhZnQgYnV0IGFyZSBlbmNvZGluZ3Mgb2YgdGhl
DQo+ID4+IG1ldHJpY3MgZGVmaW5lZCBpbiBFVFNJIFRTIDEwMTI5MC4NCj4gPj4NCj4gPj4gU3Vn
Z2VzdA0KPiA+Pg0KPiA+PiDCs1RoaXMgYmxvY2sgdHlwZSBhbGxvd3MgYSBjb3VudHMgb2YgTVBF
RyBUcmFuc3BvcnQgU3RyZWFtIHF1YWxpdHkNCj4gbWV0cmljcw0KPiA+PiB0aGF0IGFyZSBtZWFz
dXJlZCBpbiBhY2NvcmRhbmNlIHdpdGggRVRTSSBUUiAxMDEyOTAgW0VUU0ldIHRvIGJlDQo+IHJl
cG9ydGVkIGJ5DQo+ID4+IGFuIGVuZHBvaW50LiAgVGhlc2UgbWV0cmljcyBhcmUgdXNlZnVsIGZv
ciBpZGVudGlmeWluZyBiaXRzdHJlYW0NCj4gPj4gcGFja2V0aXphdGlvbiBhbmQgdHJhbnNwb3J0
IHN0cmVhbSBlbmNvZGluZyBwcm9ibGVtcyB0aGF0IG1heSBhZmZlY3QNCj4gdGhlDQo+ID4+IHVz
ZXLCuXMgcGVyY2VwdGlvbiBvZiBhIHZpZGVvIHNlcnZpY2UgZGVsaXZlcmVkIG92ZXIgUlRQLsKy
DQo+ID4+DQo+ID4+IFtRaW5dOiBPa2F5LiBZb3VyIHByb3Bvc2VkIHRleHQgaGF2ZSBiZWVuIGlu
Y29ycG9yYXRlZCBpbiAoLXYxMSkuDQo+ID4+DQo+ID4+IEMuIE1ldHJpY3MgRGVmaW5pdGlvbnMN
Cj4gPj4NCj4gPj4gQy4xIEdlbmVyYWwNCj4gPj4NCj4gPj4gRm9yIGNsYXJpdHkgdGhlIGRyYWZ0
IHNob3VsZCBwcmVmYWNlIHRoZSBtZXRyaWNzIGRlZmluaXRpb25zIHdpdGggYQ0KPiBnZW5lcmFs
DQo+ID4+IGV4cGxhbmF0aW9uIG9mIGhvdyB0aGVzZSBtZXRyaWNzIHJlbGF0ZSB0byBFVFNJIFRS
MTAxMjkwLiBUUjEwMTI5MA0KPiBnZW5lcmFsbHkNCj4gPj4gZGVmaW5lcyBlcnJvciBldmVudHMg
YW5kIHRoaXMgZHJhZnQgY29udGFpbnMgY291bnRzIG9mIHRob3NlIG1ldHJpY3MuDQo+ID4+DQo+
ID4+DQo+ID4+IElmIHRoZXJlIGFyZSBhbnkgwrNlZGdlwrIgY2FzZXMgd2hlcmUgYSBwcm9ibGVt
IGluIG9uZSBtZWFzdXJlbWVudA0KPiBpbnRlcnZhbA0KPiA+PiB3b3VsZCBiZSByZWZsZWN0ZWQg
aW4gdGhlIGNvdW50IGluIHRoZSBuZXh0IG1lYXN1cmVtZW50IGludGVydmFsIHRoZW4NCj4gdGhp
cw0KPiA+PiBzaG91bGQgYmUgYXJ0aWN1bGF0ZWQgaW4gdGhlIGdlbmVyYWwgZGVzY3JpcHRpb24g
YW5kIGFsc28gaW4gdGhlDQo+IHNwZWNpZmljDQo+ID4+IG1ldHJpYy4gIEZvciBleGFtcGxlLCBh
IHN5bmMgYnl0ZSBlcnJvciBpcyBkZWZpbmVkIGFzIG11bHRpcGxlDQo+IGNvbnNlY3V0aXZlDQo+
ID4+IGVycm9yZWQgc3luYyBieXRlcyBhbmQgaWYgdGhpcyB3YXMgcmVwb3J0ZWQgaW4gYW4gaW50
ZXJ2YWwgaXQgbWF5IGhhdmUNCj4gPj4gb2NjdXJyZWQgYXQgdGhlIGVuZCBvZiB0aGUgcHJlY2Vk
aW5nIGludGVydmFsIG9yIGF0IHNvbWUgdGltZSBkdXJpbmcNCj4gdGhlDQo+ID4+IHByZXNlbnQg
aW50ZXJ2YWwgLSBoZW5jZSB0aGUgZGVzY3JpcHRpb24gc2hvdWxkIHN0YXRlIHRoYXQgdGhlIGNv
dW50DQo+IG1heQ0KPiA+PiByZWZsZWN0IGEgcHJvYmxlbSBpbiB0aGUgY3VycmVudCBvciBwcmV2
aW91cyBpbnRlcnZhbC4gVGhpcyB3b3VsZCBhbHNvDQo+IGJlDQo+ID4+IHRoZSBjYXNlIGZvciBQ
Q1IgZXJyb3JzIGFuZCBldmVuIGNvbnRpbnVpdHkgY291bnQgZXJyb3JzLg0KPiA+Pg0KPiA+PiBb
UWluXTogT2theSwgSSBoYXZlIGFkZGVkIHNvbWUgdGV4dCBpbiB0aGUgMm5kIHBhcmFncmFwaCBv
ZiBzZWN0aW9uIDMNCj4gPj4gYW5kIGluY29ycG9yYXRlZCB5b3VyIHN1Z2dlc3RlZCB0ZXh0IGlu
ICh2LTExKS4NCj4gPj4NCj4gPj4gQy4yICBTZXF1ZW5jZSBudW1iZXJzDQo+ID4+DQo+ID4+IGJl
Z2luX3NlcSBhbmQgZW5kX3NlcQ0KPiA+Pg0KPiA+PiBUaGVzZSBkZWZpbml0aW9ucyBzaW1wbHkg
c2F5IMKzQXMgZGVmaW5lZCBpblPCsiB3aGljaCByZXF1aXJlcyB0aGUgcmVhZGVyDQo+IHRvDQo+
ID4+IHJlZmVyIHRvIGFub3RoZXIgZG9jdW1lbnQuIEl0IGlzIGdvb2QgcHJhY3RpY2UgdG8gYXQg
bGVhc3QgbWVudGlvbiB3aGF0DQo+IHRoZQ0KPiA+PiBkZWZpbml0aW9uIHJlZmVycyB0byBhbmQg
dGhlbiB0byBpbmNsdWRlIGEgcmVmZXJlbmNlIHRoYXQgY29udGFpbnMgdGhlDQo+ID4+IG5vcm1h
dGl2ZSBkZWZpbml0aW9uLg0KPiA+Pg0KPiA+PiBTb1MuLg0KPiA+Pg0KPiA+PiDCs2JlZ2luX3Nl
cTogMTYgYml0cw0KPiA+Pg0KPiA+PiBUaGUgUlRQIHNlcXVlbmNlIG51bWJlciBjb3JyZXNwb25k
aW5nIHRvIHRoZSBzdGFydCBvZiB0aGUgbWVhc3VyZW1lbnQNCj4gPj4gcGVyaW9kLCBhcyBkZWZp
bmVkIGluIFNlY3Rpb24gNC4xIG9mIFJGQyAzNjExwrINCj4gPj4NCj4gPj4gW1Fpbl06IEZpeGVk
IGluICgtdjExKS4NCj4gPj4NCj4gPj4gQy4zIE1ldHJpY3MgZGVmaW5pdGlvbnMNCj4gPj4gVGhl
IG1ldHJpY3MgZGVmaW5pdGlvbnMgc2hvdWxkIGNvbnRhaW4gYSBmaXJtZXIgc3RhdGVtZW50IG9m
IHdoYXQgaXMNCj4gYmVpbmcNCj4gPj4gbWVhc3VyZWQgYW5kLCBpZiB0aGUgbm9ybWF0aXZlIGRl
ZmluaXRpb24gaXMgaW4gYW5vdGhlciBzdGFuZGFyZCwgdGhlbg0KPiA+PiBjbGVhcmx5IHN0YXRl
IMKzYXMgZGVmaW5lZCBpbiBTZWN0aW9uIFguWSBvZiBOTk5OTsKyLiBUaGlzIGFwcGxpZXMgdG8g
YWxsDQo+IHRoZQ0KPiA+PiBtZXRyaWNzIGRlZmluaXRpb25zIGFuZCB0aGUgZXhhbXBsZSBiZWxv
dyBjYW4gYmUgdXNlZCBhcyBhIHRlbXBsYXRlIGZvcg0KPiA+Pg0KPiA+PiBGb3IgZXhhbXBsZQ0K
PiA+Pg0KPiA+PiBFeGlzdGluZyBsYW5ndWFnZSBTLi4NCj4gPj4NCj4gPj4gVFNfc3luY19sb3Nz
X2NvdW50OiAzMiBiaXRzDQo+ID4+DQo+ID4+IE51bWJlciBvZiBUU19zeW5jX2xvc3MgZXJyb3Jz
IGluIHRoZSBhYm92ZSBzZXF1ZW5jZSBudW1iZXIgaW50ZXJ2YWwuDQo+IEl0IGlzDQo+ID4+IGNh
bGN1bGF0ZWQgYmFzZWQgb24gdGhlIG9jY3VycmVuY2Ugb2YgZXJyb3JzIGZvcg0KPiAiVFNfc3lu
Y19sb3NzInBhcmFtZXRlcg0KPiA+PiBkZWZpbmVkIGluIHRoZSBzZWN0aW9uIDUuMi4xIG9mIFtF
VFNJXSAoQWxzbyBzZWUgc2VjdGlvbiA1LjUuMSBvZg0KPiBbRVRTSV0pLg0KPiA+Pg0KPiA+PiBU
aGlzIGlzIHZlcnkgdmFndWUgbGFuZ3VhZ2UgYW5kIGl0IGlzIHVuY2xlYXIgd2h5IHRoZSDCs0Fs
c28gc2VlwrINCj4gcmVmZXJlbmNlDQo+ID4+IGlzIHRoZXJlLiAgQSBiZXR0ZXIgYXBwcm9hY2gg
aXM6DQo+ID4+DQo+ID4+IFJlcGxhY2VtZW50IGxhbmd1YWdlICh1c2UgdGhpcyBmb3JtYXQgZm9y
IGVhY2ggb2YgdGhlIG1ldHJpY3MpDQo+ID4+DQo+ID4+IFRTX3N5bmNfbG9zc19jb3VudDogMzIg
Yml0cw0KPiA+Pg0KPiA+PiBBIGNvdW50IG9mIHRoZSBudW1iZXIgb2YgVFNfc3luY19sb3NzIGVy
cm9ycyB0aGF0IG9jY3VycmVkIGluIHRoZSBhYm92ZQ0KPiA+PiBzZXF1ZW5jZSBudW1iZXIgaW50
ZXJ2YWwuICBBIFRTX3N5bmNfbG9zcyBlcnJvciBvY2N1cnMgd2hlbiB0aGVyZSBhcmUNCj4gdHdv
IG9yDQo+ID4+IG1vcmUgY29uc2VjdXRpdmUgaW5jb3JyZWN0IHN5bmMgYnl0ZXMgd2l0aGluIHRo
ZSBNUEVHIFRTIHN0cmVhbSwgYXMNCj4gZGVmaW5lZA0KPiA+PiBpbiBzZWN0aW9uIDUuMi4xIG9m
IFtFVFNJXS4gVGhpcyBwYXJhbWV0ZXIgbWF5IGJlIHVzZWQgYXMgcGFydCBvZiBhDQo+IFNlcnZp
Y2UNCj4gPj4gQXZhaWxhYmlsaXR5IGNhbGN1bGF0aW9uLCBhcyBkZWZpbmVkIGluIHNlY3Rpb24g
NS41LjEgb2YgW0VUU0ldLg0KPiA+Pg0KPiA+PiBbUWluXTogRml4ZWQgaW4gKC12MTEpLg0KPiA+
Pg0KPiA+PiBDLjQgU2VydmljZSBBdmFpbGFiaWxpdHkNCj4gPj4NCj4gPj4gRm9sbG93aW5nIG9u
IGZyb20gdGhlIHByZXZpb3VzIGNvbW1lbnQsICBzZWN0aW9uIDUuNS4xIG9mIFRSMTAxMjkwDQo+
IGRlc2NyaWJlcw0KPiA+PiBhIHNlcnZpY2UgYXZhaWxhYmlsaXR5IGVycm9yIGFzIGEgY29tYmlu
YXRpb24gb2YgVFNfc3luY19sb3NzLA0KPiBQQVRfZXJyb3IgYW5kDQo+ID4+IFBNVF9lcnJvciB3
aGVyZWFzIGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLWRlY29kYWJpbGl0eS0xMCBkb2VzIG5v
dA0KPiA+PiBjb250YWluIHRoZSBQQVQgYW5kIFBNVCBlcnJvciBtZXRyaWNzLiAgVGhlIHJlc29s
dXRpb24gZm9yIHRoaXMgd291bGQNCj4gZWl0aGVyDQo+ID4+IGJlIHRvIHJlbW92ZSB0aGUgcmVm
ZXJlbmNlIHRvIDUuNS4xIG9yIHRvIGFkZCB0aGUgbWV0cmljcyByZXF1aXJlZCB0bw0KPiA+PiBj
YWxjdWxhdGUgdGhlIHNlcnZpY2UgYXZhaWxhYmlsaXR5Lg0KPiA+Pg0KPiA+PiBbUWluXTogQWdy
ZWUuIEkgcHJlZmVyIHRvIHJlbW92ZSB0aGUgcmVmZXJlbmNlIHRvIDUuNS4xIHNpbmNlIHRoZXJl
IHdhcw0KPiBjb25zZW5zdXMgaW4gdGhlIHBhc3QgV0dMQyB0byB0aGlzIGRyYWZ0DQo+ID4+IHRo
YXQgaGF2aW5nIGEgc2Vjb25kIHJlcG9ydCBibG9jayBsYXRlciB0byBjb3ZlciB0aGUgb3RoZXIg
cGFyYW1ldGVycw0KPiBhbmQgZ2V0IGlubGluZSB3aXRoIGNvbmNlcHQgb2YgUkZDNjc5Mg0KPiA+
PiBhbmQgbGV0dGluZyB0aGlzIGRyYWZ0IGZvY3VzIG9uIFBTSSBpbmRwZW5kZW50IHBhcmFtZXRl
ciByZXBvcnRpbmcuDQo+ID4+IFNlZSBkZXRhaWxzIGZvciB0aGUgV0dMQyBkaXNjdXNzaW9uIGlu
IHRoZSBmb2xsb3dpbmcgbGluazoNCj4gPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp
dmUvd2ViL3hyYmxvY2svY3VycmVudC9tc2cwMTAzMi5odG1sDQo+ID4+DQo+ID4+IEl0IGlzIHJl
Y29tbWVuZGVkIHRoYXQgUEFUX2Vycm9yICwgUEFUX2Vycm9yXzIsICBQTVRfZXJyb3IgYW5kDQo+
IFBNVF9lcnJvcl8yDQo+ID4+IGJlIGluY2x1ZGVkIGFzIG1ldHJpY3MgYXMgdGhlc2UgwrNhcmXC
siBnZW5lcmFsbHkgcHJlc2VudCBpbiBNUEVHDQo+IFRyYW5zcG9ydA0KPiA+PiBzdHJlYW1zIGFu
ZCBlcnJvcnMgd2l0aGluIHRoZXNlIGNhbiBwcmV2ZW50IGNvcnJlY3QgZGVjb2Rpbmcgb2YgdGhl
DQo+IHN0cmVhbS4NCj4gPj4NCj4gPj4gQy41IFBDUl9lcnJvcl9jb3VudA0KPiA+Pg0KPiA+PiBQ
Q1JfZXJyb3JfY291bnQgaXMgZGVmaW5lZCB0d2ljZSAtIHRoZSBzZWNvbmQgb2YgdGhlc2Ugc2hv
dWxkIGJlDQo+ID4+IFBDUl9hY2N1cmFjeV9lcnJvcl9jb3VudA0KPiA+Pg0KPiA+PiAgIFtRaW5d
OiBHb29kIGNhdGNoIGFuZCBoYXZlIGZpeGVkIGluICgtdjExKS4NCj4gPj4NCj4gPj4NCj4gPj4N
Cj4gPg0KDQo=

From acmorton@att.com  Wed May 15 08:59:59 2013
Return-Path: <acmorton@att.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A16811E80D1 for <pm-dir@ietfa.amsl.com>; Wed, 15 May 2013 08:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.434
X-Spam-Level: 
X-Spam-Status: No, score=-106.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMYMMg1oCL-v for <pm-dir@ietfa.amsl.com>; Wed, 15 May 2013 08:59:54 -0700 (PDT)
Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id E05CA21F87BB for <pm-dir@ietf.org>; Wed, 15 May 2013 08:59:53 -0700 (PDT)
Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 5E68C120438; Wed, 15 May 2013 11:59:52 -0400 (EDT)
Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-blue.research.att.com (Postfix) with ESMTP id 884A1F0365; Wed, 15 May 2013 11:59:53 -0400 (EDT)
Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Wed, 15 May 2013 11:59:53 -0400
From: "MORTON JR., ALFRED C (AL)" <acmorton@att.com>
To: Benoit Claise <bclaise@cisco.com>, "pm-dir@ietf.org" <pm-dir@ietf.org>
Date: Wed, 15 May 2013 11:59:52 -0400
Thread-Topic: [pm-dir] Performance metrics doctors generated email
Thread-Index: Ac5J1H3YSZdAHRuQTbaCmV+pVMYWPQHr+DWA
Message-ID: <F1312FAF1A1E624DA0972D1C9A91379A1BFFE38C05@njfpsrvexg7.research.att.com>
References: <20130505210603.GA23252@sweet-brew-5.cisco.com>
In-Reply-To: <20130505210603.GA23252@sweet-brew-5.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [pm-dir] Performance metrics doctors generated email
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2013 15:59:59 -0000

At the moment, I can reach the host I use to run the diff, so it's appended=
 below.

Review assignments are here:=20
https://docs.google.com/spreadsheet/ccc?key=3D0AmKrqWIOBsprdGZqMnB6dmx5bFJv=
VUhta3VLSjl3SkE#gid=3D0

regards,
Al
pm-dir admin

here's what changed over the last two weeks:

$ cat diff.txt
Diffs from Last Week -=3Dold, +=3Dnew
--------------------
--- pmol-old-content.txt        2013-04-30
+++ pmol-uniq-content.txt       2013-05-15 11:50:46.026976203 -0400
@@ -2 +2 @@
-draft-ietf-alto-protocol-14                       Active
+draft-ietf-alto-protocol-15                       Active
@@ -6 +5,0 @@
-draft-ietf-manet-olsrv2-mib-06                    In IESG processing - ID =
Tracker state <Waiting for AD Go-Ahead::Revised I-D Needed>
@@ -11 +10 @@
-draft-ietf-ppsp-peer-protocol-06                  In IESG processing - ID =
Tracker state <AD Evaluation>
+draft-ietf-ppsp-peer-protocol-06                  Active
@@ -13 +12 @@
-draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14   In IESG processing - ID =
Tracker state <IESG Evaluation::AD Followup>
+draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14   In IESG processing - ID =
Tracker state <RFC Ed Queue>
@@ -18 +17 @@
-draft-ietf-xrblock-rtcp-xr-jb-11                  Active
+draft-ietf-xrblock-rtcp-xr-jb-11                  In IESG processing - ID =
Tracker state <Publication Requested>
@@ -20 +19 @@
-draft-ietf-xrblock-rtcp-xr-qoe-06                 Active
+draft-ietf-xrblock-rtcp-xr-qoe-07                 Active


> -----Original Message-----
> From: pm-dir-bounces@ietf.org [mailto:pm-dir-bounces@ietf.org] On Behalf
> Of Benoit Claise
> Sent: Sunday, May 05, 2013 5:06 PM
> To: pm-dir@ietf.org
> Subject: [pm-dir] Performance metrics doctors generated email
>=20
> Dear all,
>=20
> This is an automatically generated email.
> It lists the IETF internet-drafts that reference the PMOL RFC 6390, as a
> normative or informative reference.
> It also lists all the IETF internet-drafts that contain "performance
> metric".
>=20
> Regards, Benoit
>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Normative References
> --------------------
> draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 Active
>=20
> Informative References
> ----------------------
> draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14   In IESG processing - ID
> Tracker state <IESG Evaluation::AD Followup>
> draft-ietf-xrblock-rtcp-xr-burst-gap-loss-12      In IESG processing - ID
> Tracker state <RFC Ed Queue>
> draft-ietf-xrblock-rtcp-xr-decodability-11        In IESG processing - ID
> Tracker state <Waiting for AD Go-Ahead::External Party>
> draft-ietf-xrblock-rtcp-xr-discard-13             In IESG processing - ID
> Tracker state <Publication Requested>
> draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 Active
> draft-ietf-xrblock-rtcp-xr-jb-11                  Active
> draft-ietf-xrblock-rtcp-xr-loss-conceal-05        Active
> draft-ietf-xrblock-rtcp-xr-qoe-06                 Active
> draft-ietf-xrblock-rtcp-xr-summary-stat-11        In IESG processing - ID
> Tracker state <RFC Ed Queue>
> draft-ietf-xrblock-rtcp-xr-synchronization-04     Active
>=20
> drafts containing performance metric
> ------------------------------------
> draft-ietf-alto-deployments-06                    Active
> draft-ietf-alto-protocol-14                       Active
> draft-ietf-bmwg-ca-bench-meth-04                  Active
> draft-ietf-ippm-rate-problem-03                   Active
> draft-ietf-ippm-testplan-rfc2680-02               Active
> draft-ietf-manet-smf-mib-07                       In IESG processing - ID
> Tracker state <AD Evaluation::Revised I-D Needed>
> draft-ietf-nvo3-framework-02                      Active
> draft-ietf-opsawg-oam-overview-08                 In IESG processing - ID
> Tracker state <Waiting for AD Go-Ahead::Revised I-D Needed>
> draft-ietf-pce-pcep-service-aware-00              Active
> draft-ietf-ppsp-peer-protocol-06                  Active
> draft-ietf-rtcweb-rtp-usage-06                    Active
> draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14   In IESG processing - ID
> Tracker state <IESG Evaluation::AD Followup>
> draft-ietf-xrblock-rtcp-xr-burst-gap-loss-12      In IESG processing - ID
> Tracker state <RFC Ed Queue>
> draft-ietf-xrblock-rtcp-xr-decodability-11        In IESG processing - ID
> Tracker state <Waiting for AD Go-Ahead::External Party>
> draft-ietf-xrblock-rtcp-xr-discard-13             In IESG processing - ID
> Tracker state <Publication Requested>
> draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 Active
> draft-ietf-xrblock-rtcp-xr-jb-11                  Active
> draft-ietf-xrblock-rtcp-xr-loss-conceal-05        Active
> draft-ietf-xrblock-rtcp-xr-qoe-06                 Active
> draft-ietf-xrblock-rtcp-xr-summary-stat-11        In IESG processing - ID
> Tracker state <RFC Ed Queue>
> draft-ietf-xrblock-rtcp-xr-synchronization-04     Active
> _______________________________________________
> pm-dir mailing list
> pm-dir@ietf.org
> https://www.ietf.org/mailman/listinfo/pm-dir

From alan.d.clark@telchemy.com  Thu May 16 02:28:31 2013
Return-Path: <alan.d.clark@telchemy.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D65F21F874E for <pm-dir@ietfa.amsl.com>; Thu, 16 May 2013 02:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.297
X-Spam-Level: **
X-Spam-Status: No, score=2.297 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qe+bvQ6NYtNa for <pm-dir@ietfa.amsl.com>; Thu, 16 May 2013 02:28:27 -0700 (PDT)
Received: from omx.cbeyond.com (omx.cbeyond.com [50.20.30.10]) by ietfa.amsl.com (Postfix) with ESMTP id CAFA621F8605 for <pm-dir@ietf.org>; Thu, 16 May 2013 02:28:26 -0700 (PDT)
X-SBRS: None
X-HAT: Sender Group None, Policy $ACCEPTED applied.
X-Hostname: omx01bay.sys.cbeyond.net
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjsDAIWllFFS47Nb/2dsb2JhbAANToM+RIJ4vW4DARZ9gxMBAQEDASMZATwFBwYBBgIOAwQBAQECAiMDAiMlBgMIAQEEAQ0FCYdxAwkNBZATmjJyiHINiGGBJosigSRTLAgrBwaCPIETA5VPjgCIT4FV
X-IronPort-AV: E=Sophos;i="4.87,683,1363147200"; d="scan'208";a="30567001"
Received: from ax113-4-82-227-179-91.fbx.proxad.net (HELO [192.168.1.37]) ([82.227.179.91]) by omx.cbeyond.com with ESMTP/TLS/DES-CBC3-SHA; 16 May 2013 05:28:18 -0400
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 16 May 2013 05:28:10 -0400
From: Alan Clark <alan.d.clark@telchemy.com>
To: Al Morton <acmorton@att.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, Qin Wu <bill.wu@huawei.com>
Message-ID: <CDBA1EEA.50DE7%alan.d.clark@telchemy.com>
Thread-Topic: =?Big5?B?tarOYA==?=: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
Thread-Index: Ac5Rf8o7eiEQpvSsRoKHKPDMei3QHAAA0pcwACUmZGM=
In-Reply-To: <F1312FAF1A1E624DA0972D1C9A91379A1BFFE38BF3@njfpsrvexg7.research.att.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Cc: "Huangyihong \(Rachel\)" <rachel.huang@huawei.com>, Shida Schubert <shida@ntt-at.com>, "Dan \(Dan\)" <dromasca@avaya.com>, "asaeda@nict.go.jp" <asaeda@nict.go.jp>, "glenzorn@gmail.com" <glenzorn@gmail.com>, Benoit Claise <bclaise@cisco.com>, "pm-dir@ietf.org" <pm-dir@ietf.org>
Subject: Re: [pm-dir] =?Big5?B?tarOYA==?=: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 May 2013 09:28:31 -0000

I am satisfied with the revisions

Regards

Alan


On 5/15/13 11:45 AM, "Al Morton" <acmorton@att.com> wrote:

> Alan,=20
> Since you reviewed this draft, are you satisfied with the revisions?
> Al
>=20
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
>> Sent: Wednesday, May 15, 2013 11:21 AM
>> To: Qin Wu
>> Cc: Benoit Claise; Alan Clark; pm-dir@ietf.org; Dan (Dan); Shida Schuber=
t;
>> Huangyihong (Rachel); asaeda@nict.go.jp; glenzorn@gmail.com; MORTON JR.,
>> ALFRED C (AL)
>> Subject: Re: =E7=AD=94=E5=A4=8D: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decoda=
bility
>>=20
>> Hi Benoit,
>>=20
>> what is the status of this? Can I progress this draft at this point?
>>=20
>> Thanks,
>>=20
>> Gonzalo
>>=20
>> On 11/04/2013 5:14 AM, Qin Wu wrote:
>>> Hi,Benoit:
>>> As Alan observed in PM-DIR review, this draft does not define new
>> metrics but refers to metrics that are
>>> clearly defined in a normative reference.
>>> I think we can skip RFC6390 template usage just like PDV draft(RFC6798)
>> did, can't we?
>>>=20
>>> Regards!
>>> -Qin
>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Benoit Claise [mailto:bclaise@cisco.com]
>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2013=E5=B9=B44=E6=9C=8810=E6=97=A5 21:53
>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu
>>> =E6=8A=84=E9=80=81: Alan Clark; Gonzalo Camarillo; pm-dir@ietf.org; Dan (Dan); Shid=
a
>> Schubert; Huangyihong (Rachel); asaeda@nict.go.jp; glenzorn@gmail.com; A=
l
>> Morton
>>> =E4=B8=BB=E9=A2=98: Re: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
>>>=20
>>> Hi Qin,
>>>=20
>>> And don't forget the RFC 6390 template usage.
>>>=20
>>> Regards, Benoit
>>>> Hi, Alan:
>>>> Thank for your valuable comments.
>>>> We have updated the draft to incorporate your comments in the new
>> version (-v11).
>>>> The diff is:
>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-xrblock-rtcp-xr-
>> decodability-11
>>>> Please also see my reply below.
>>>>=20
>>>> Regards!
>>>> -Qin
>>>> ----- Original Message -----
>>>> From: "Alan Clark" <alan.d.clark@telchemy.com>
>>>> To: "Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>; <pm-
>> dir@ietf.org>; "Benoit Claise" <bclaise@cisco.com>; "Dan (Dan)"
>> <dromasca@avaya.com>; "Shida Schubert" <shida@ntt-at.com>;
>> <rachel.huang@huawei.com>; <bill.wu@huawei.com>; <asaeda@nict.go.jp>;
>> <glenzorn@gmail.com>; "Al Morton" <acmorton@att.com>
>>>> Sent: Saturday, April 06, 2013 3:10 AM
>>>> Subject: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
>>>>=20
>>>>=20
>>>> There are quite a few issues with the draft - I can re-review as soon
>> as
>>>> these are addressed.
>>>>=20
>>>> Alan Clark
>>>>=20
>>>>=20
>>>>=20
>>>> A. General Comments
>>>>=20
>>>> This draft does not define new metrics but refers to metrics that are
>>>> clearly defined in a normative reference.  The normative reference
>> (ETSI
>>>> TR101290) predates RFC6390 however does contain a fairly clear
>> description
>>>> of the metrics with explanation of their usage. It is not recommended
>> that
>>>> this draft redefines the metrics in RFC6390 template form
>>>>=20
>>>> [Qin]: Exactly.
>>>>=20
>>>> however there is
>>>> considerable scope for improvement in the clarity of definition of how
>> these
>>>> metrics are used.
>>>>=20
>>>> [Qin]: Agree.
>>>>=20
>>>> B. Applicability Section
>>>>=20
>>>> 1.4 Applicability
>>>> Metrics only measure transport stream quality not content stream
>> quality.
>>>> Also the metrics are not defined in this draft but are encodings of th=
e
>>>> metrics defined in ETSI TS 101290.
>>>>=20
>>>> Suggest
>>>>=20
>>>> =C2=B3This block type allows a counts of MPEG Transport Stream quality
>> metrics
>>>> that are measured in accordance with ETSI TR 101290 [ETSI] to be
>> reported by
>>>> an endpoint.  These metrics are useful for identifying bitstream
>>>> packetization and transport stream encoding problems that may affect
>> the
>>>> user=C2=B9s perception of a video service delivered over RTP.=C2=B2
>>>>=20
>>>> [Qin]: Okay. Your proposed text have been incorporated in (-v11).
>>>>=20
>>>> C. Metrics Definitions
>>>>=20
>>>> C.1 General
>>>>=20
>>>> For clarity the draft should preface the metrics definitions with a
>> general
>>>> explanation of how these metrics relate to ETSI TR101290. TR101290
>> generally
>>>> defines error events and this draft contains counts of those metrics.
>>>>=20
>>>>=20
>>>> If there are any =C2=B3edge=C2=B2 cases where a problem in one measurement
>> interval
>>>> would be reflected in the count in the next measurement interval then
>> this
>>>> should be articulated in the general description and also in the
>> specific
>>>> metric.  For example, a sync byte error is defined as multiple
>> consecutive
>>>> errored sync bytes and if this was reported in an interval it may have
>>>> occurred at the end of the preceding interval or at some time during
>> the
>>>> present interval - hence the description should state that the count
>> may
>>>> reflect a problem in the current or previous interval. This would also
>> be
>>>> the case for PCR errors and even continuity count errors.
>>>>=20
>>>> [Qin]: Okay, I have added some text in the 2nd paragraph of section 3
>>>> and incorporated your suggested text in (v-11).
>>>>=20
>>>> C.2  Sequence numbers
>>>>=20
>>>> begin_seq and end_seq
>>>>=20
>>>> These definitions simply say =C2=B3As defined inS=C2=B2 which requires the rea=
der
>> to
>>>> refer to another document. It is good practice to at least mention wha=
t
>> the
>>>> definition refers to and then to include a reference that contains the
>>>> normative definition.
>>>>=20
>>>> SoS..
>>>>=20
>>>> =C2=B3begin_seq: 16 bits
>>>>=20
>>>> The RTP sequence number corresponding to the start of the measurement
>>>> period, as defined in Section 4.1 of RFC 3611=C2=B2
>>>>=20
>>>> [Qin]: Fixed in (-v11).
>>>>=20
>>>> C.3 Metrics definitions
>>>> The metrics definitions should contain a firmer statement of what is
>> being
>>>> measured and, if the normative definition is in another standard, then
>>>> clearly state =C2=B3as defined in Section X.Y of NNNNN=C2=B2. This applies to =
all
>> the
>>>> metrics definitions and the example below can be used as a template fo=
r
>>>>=20
>>>> For example
>>>>=20
>>>> Existing language S..
>>>>=20
>>>> TS_sync_loss_count: 32 bits
>>>>=20
>>>> Number of TS_sync_loss errors in the above sequence number interval.
>> It is
>>>> calculated based on the occurrence of errors for
>> "TS_sync_loss"parameter
>>>> defined in the section 5.2.1 of [ETSI] (Also see section 5.5.1 of
>> [ETSI]).
>>>>=20
>>>> This is very vague language and it is unclear why the =C2=B3Also see=C2=B2
>> reference
>>>> is there.  A better approach is:
>>>>=20
>>>> Replacement language (use this format for each of the metrics)
>>>>=20
>>>> TS_sync_loss_count: 32 bits
>>>>=20
>>>> A count of the number of TS_sync_loss errors that occurred in the abov=
e
>>>> sequence number interval.  A TS_sync_loss error occurs when there are
>> two or
>>>> more consecutive incorrect sync bytes within the MPEG TS stream, as
>> defined
>>>> in section 5.2.1 of [ETSI]. This parameter may be used as part of a
>> Service
>>>> Availability calculation, as defined in section 5.5.1 of [ETSI].
>>>>=20
>>>> [Qin]: Fixed in (-v11).
>>>>=20
>>>> C.4 Service Availability
>>>>=20
>>>> Following on from the previous comment,  section 5.5.1 of TR101290
>> describes
>>>> a service availability error as a combination of TS_sync_loss,
>> PAT_error and
>>>> PMT_error whereas draft-ietf-xrblock-rtcp-xr-decodability-10 does not
>>>> contain the PAT and PMT error metrics.  The resolution for this would
>> either
>>>> be to remove the reference to 5.5.1 or to add the metrics required to
>>>> calculate the service availability.
>>>>=20
>>>> [Qin]: Agree. I prefer to remove the reference to 5.5.1 since there wa=
s
>> consensus in the past WGLC to this draft
>>>> that having a second report block later to cover the other parameters
>> and get inline with concept of RFC6792
>>>> and letting this draft focus on PSI indpendent parameter reporting.
>>>> See details for the WGLC discussion in the following link:
>>>> http://www.ietf.org/mail-archive/web/xrblock/current/msg01032.html
>>>>=20
>>>> It is recommended that PAT_error , PAT_error_2,  PMT_error and
>> PMT_error_2
>>>> be included as metrics as these =C2=B3are=C2=B2 generally present in MPEG
>> Transport
>>>> streams and errors within these can prevent correct decoding of the
>> stream.
>>>>=20
>>>> C.5 PCR_error_count
>>>>=20
>>>> PCR_error_count is defined twice - the second of these should be
>>>> PCR_accuracy_error_count
>>>>=20
>>>>   [Qin]: Good catch and have fixed in (-v11).
>>>>=20
>>>>=20
>>>>=20
>>>=20
>=20



From gonzalo.camarillo@ericsson.com  Fri May 17 02:45:31 2013
Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC3221F9381 for <pm-dir@ietfa.amsl.com>; Fri, 17 May 2013 02:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.99
X-Spam-Level: 
X-Spam-Status: No, score=-105.99 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0tz6oNeQDqc for <pm-dir@ietfa.amsl.com>; Fri, 17 May 2013 02:45:26 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A99F021F9380 for <pm-dir@ietf.org>; Fri, 17 May 2013 02:45:25 -0700 (PDT)
X-AuditID: c1b4fb30-b7f8a6d000001a2d-ae-5195fc312d7c
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 90.94.06701.13CF5915; Fri, 17 May 2013 11:45:21 +0200 (CEST)
Received: from [131.160.126.54] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Fri, 17 May 2013 11:45:21 +0200
Message-ID: <5195FC30.5050809@ericsson.com>
Date: Fri, 17 May 2013 12:45:20 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Alan Clark <alan.d.clark@telchemy.com>
References: <CDBA1EEA.50DE7%alan.d.clark@telchemy.com>
In-Reply-To: <CDBA1EEA.50DE7%alan.d.clark@telchemy.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+Jvra7hn6mBBm8ea1hsPTaR0WLiG2aL OdMvslocfSxh8XjuAlaLrz9/sFqsn3yJxeLoB0uLpZ2n2C1+H5rH6sDl8bJ/DqPHwZVz2D2m /N7I6rFz1l12j5Yjb1k9liz5yeTx4uh2do+eS7MZPY7NP8cYwBnFZZOSmpNZllqkb5fAlbF7 9UTmgiduFRNmvGZsYPxo2cXIySEhYCJx4Ps2RghbTOLCvfVsILaQwClGiV/nmboYuYDsNYwS P88vYQZJ8ApoSzx/eIoFxGYRUJV4euI6WAObgIXEllv3weKiAlESc9Y9YIOoF5Q4OfMJWFxE QEviae8xsKHMAveZJPa8fcwM4ggLNDBKNK6ezwSx2kzi4eO/7CA2p4C5xMFvV9ggzpOU2PKi HSzOLKAp0br9N5QtL9G8dTYzRK+2xPJnLSwTGIVmIVk+C0nLLCQtCxiZVzGy5yZm5qSXm29i BMbPwS2/DXYwbrovdohRmoNFSZy3T3tqoJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGi/iN 2ee7Dpu/SZU9/Kqh7F7JswiVI8ei79SuO5Z1VielPM3k9NKMDfYxG4qt9+lJLb4RH6Gx7E5Z 58KLaUynth/syyhkk9e4PMmWbd6q5i0nvOb/V4nz1LZ0jD4Q5cPodGO1gKv74g/RGbJznbt2 PJv1eMt52xCZeF1xnyNXzi1buO7oq40JSizFGYmGWsxFxYkAepL2xm0CAAA=
Cc: Al Morton <acmorton@att.com>, Shida Schubert <shida@ntt-at.com>, "Dan \(Dan\)" <dromasca@avaya.com>, "asaeda@nict.go.jp" <asaeda@nict.go.jp>, "glenzorn@gmail.com" <glenzorn@gmail.com>, Benoit Claise <bclaise@cisco.com>, "pm-dir@ietf.org" <pm-dir@ietf.org>, Qin Wu <bill.wu@huawei.com>, "Huangyihong \(Rachel\)" <rachel.huang@huawei.com>
Subject: Re: [pm-dir] =?utf-8?b?562U5aSNOiBSRkM2MzkwIHJldmlldyBvZiBkcmFmdC1p?= =?utf-8?q?etf-xrblock-rtcp-xr-decodability?=
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 May 2013 09:45:31 -0000

Hi Alan,

thanks. I have just put this draft on the agenda of the May 30th telechat.

Cheers,

Gonzalo

On 16/05/2013 12:28 PM, Alan Clark wrote:
> I am satisfied with the revisions
> 
> Regards
> 
> Alan
> 
> 
> On 5/15/13 11:45 AM, "Al Morton" <acmorton@att.com> wrote:
> 
>> Alan, 
>> Since you reviewed this draft, are you satisfied with the revisions?
>> Al
>>
>>> -----Original Message-----
>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
>>> Sent: Wednesday, May 15, 2013 11:21 AM
>>> To: Qin Wu
>>> Cc: Benoit Claise; Alan Clark; pm-dir@ietf.org; Dan (Dan); Shida Schubert;
>>> Huangyihong (Rachel); asaeda@nict.go.jp; glenzorn@gmail.com; MORTON JR.,
>>> ALFRED C (AL)
>>> Subject: Re: 答复: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
>>>
>>> Hi Benoit,
>>>
>>> what is the status of this? Can I progress this draft at this point?
>>>
>>> Thanks,
>>>
>>> Gonzalo
>>>
>>> On 11/04/2013 5:14 AM, Qin Wu wrote:
>>>> Hi,Benoit:
>>>> As Alan observed in PM-DIR review, this draft does not define new
>>> metrics but refers to metrics that are
>>>> clearly defined in a normative reference.
>>>> I think we can skip RFC6390 template usage just like PDV draft(RFC6798)
>>> did, can't we?
>>>>
>>>> Regards!
>>>> -Qin
>>>> -----邮件原件-----
>>>> 发件人: Benoit Claise [mailto:bclaise@cisco.com]
>>>> 发送时间: 2013年4月10日 21:53
>>>> 收件人: Qin Wu
>>>> 抄送: Alan Clark; Gonzalo Camarillo; pm-dir@ietf.org; Dan (Dan); Shida
>>> Schubert; Huangyihong (Rachel); asaeda@nict.go.jp; glenzorn@gmail.com; Al
>>> Morton
>>>> 主题: Re: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
>>>>
>>>> Hi Qin,
>>>>
>>>> And don't forget the RFC 6390 template usage.
>>>>
>>>> Regards, Benoit
>>>>> Hi, Alan:
>>>>> Thank for your valuable comments.
>>>>> We have updated the draft to incorporate your comments in the new
>>> version (-v11).
>>>>> The diff is:
>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-
>>> decodability-11
>>>>> Please also see my reply below.
>>>>>
>>>>> Regards!
>>>>> -Qin
>>>>> ----- Original Message -----
>>>>> From: "Alan Clark" <alan.d.clark@telchemy.com>
>>>>> To: "Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>; <pm-
>>> dir@ietf.org>; "Benoit Claise" <bclaise@cisco.com>; "Dan (Dan)"
>>> <dromasca@avaya.com>; "Shida Schubert" <shida@ntt-at.com>;
>>> <rachel.huang@huawei.com>; <bill.wu@huawei.com>; <asaeda@nict.go.jp>;
>>> <glenzorn@gmail.com>; "Al Morton" <acmorton@att.com>
>>>>> Sent: Saturday, April 06, 2013 3:10 AM
>>>>> Subject: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
>>>>>
>>>>>
>>>>> There are quite a few issues with the draft - I can re-review as soon
>>> as
>>>>> these are addressed.
>>>>>
>>>>> Alan Clark
>>>>>
>>>>>
>>>>>
>>>>> A. General Comments
>>>>>
>>>>> This draft does not define new metrics but refers to metrics that are
>>>>> clearly defined in a normative reference.  The normative reference
>>> (ETSI
>>>>> TR101290) predates RFC6390 however does contain a fairly clear
>>> description
>>>>> of the metrics with explanation of their usage. It is not recommended
>>> that
>>>>> this draft redefines the metrics in RFC6390 template form
>>>>>
>>>>> [Qin]: Exactly.
>>>>>
>>>>> however there is
>>>>> considerable scope for improvement in the clarity of definition of how
>>> these
>>>>> metrics are used.
>>>>>
>>>>> [Qin]: Agree.
>>>>>
>>>>> B. Applicability Section
>>>>>
>>>>> 1.4 Applicability
>>>>> Metrics only measure transport stream quality not content stream
>>> quality.
>>>>> Also the metrics are not defined in this draft but are encodings of the
>>>>> metrics defined in ETSI TS 101290.
>>>>>
>>>>> Suggest
>>>>>
>>>>> ³This block type allows a counts of MPEG Transport Stream quality
>>> metrics
>>>>> that are measured in accordance with ETSI TR 101290 [ETSI] to be
>>> reported by
>>>>> an endpoint.  These metrics are useful for identifying bitstream
>>>>> packetization and transport stream encoding problems that may affect
>>> the
>>>>> user¹s perception of a video service delivered over RTP.²
>>>>>
>>>>> [Qin]: Okay. Your proposed text have been incorporated in (-v11).
>>>>>
>>>>> C. Metrics Definitions
>>>>>
>>>>> C.1 General
>>>>>
>>>>> For clarity the draft should preface the metrics definitions with a
>>> general
>>>>> explanation of how these metrics relate to ETSI TR101290. TR101290
>>> generally
>>>>> defines error events and this draft contains counts of those metrics.
>>>>>
>>>>>
>>>>> If there are any ³edge² cases where a problem in one measurement
>>> interval
>>>>> would be reflected in the count in the next measurement interval then
>>> this
>>>>> should be articulated in the general description and also in the
>>> specific
>>>>> metric.  For example, a sync byte error is defined as multiple
>>> consecutive
>>>>> errored sync bytes and if this was reported in an interval it may have
>>>>> occurred at the end of the preceding interval or at some time during
>>> the
>>>>> present interval - hence the description should state that the count
>>> may
>>>>> reflect a problem in the current or previous interval. This would also
>>> be
>>>>> the case for PCR errors and even continuity count errors.
>>>>>
>>>>> [Qin]: Okay, I have added some text in the 2nd paragraph of section 3
>>>>> and incorporated your suggested text in (v-11).
>>>>>
>>>>> C.2  Sequence numbers
>>>>>
>>>>> begin_seq and end_seq
>>>>>
>>>>> These definitions simply say ³As defined inS² which requires the reader
>>> to
>>>>> refer to another document. It is good practice to at least mention what
>>> the
>>>>> definition refers to and then to include a reference that contains the
>>>>> normative definition.
>>>>>
>>>>> SoS..
>>>>>
>>>>> ³begin_seq: 16 bits
>>>>>
>>>>> The RTP sequence number corresponding to the start of the measurement
>>>>> period, as defined in Section 4.1 of RFC 3611²
>>>>>
>>>>> [Qin]: Fixed in (-v11).
>>>>>
>>>>> C.3 Metrics definitions
>>>>> The metrics definitions should contain a firmer statement of what is
>>> being
>>>>> measured and, if the normative definition is in another standard, then
>>>>> clearly state ³as defined in Section X.Y of NNNNN². This applies to all
>>> the
>>>>> metrics definitions and the example below can be used as a template for
>>>>>
>>>>> For example
>>>>>
>>>>> Existing language S..
>>>>>
>>>>> TS_sync_loss_count: 32 bits
>>>>>
>>>>> Number of TS_sync_loss errors in the above sequence number interval.
>>> It is
>>>>> calculated based on the occurrence of errors for
>>> "TS_sync_loss"parameter
>>>>> defined in the section 5.2.1 of [ETSI] (Also see section 5.5.1 of
>>> [ETSI]).
>>>>>
>>>>> This is very vague language and it is unclear why the ³Also see²
>>> reference
>>>>> is there.  A better approach is:
>>>>>
>>>>> Replacement language (use this format for each of the metrics)
>>>>>
>>>>> TS_sync_loss_count: 32 bits
>>>>>
>>>>> A count of the number of TS_sync_loss errors that occurred in the above
>>>>> sequence number interval.  A TS_sync_loss error occurs when there are
>>> two or
>>>>> more consecutive incorrect sync bytes within the MPEG TS stream, as
>>> defined
>>>>> in section 5.2.1 of [ETSI]. This parameter may be used as part of a
>>> Service
>>>>> Availability calculation, as defined in section 5.5.1 of [ETSI].
>>>>>
>>>>> [Qin]: Fixed in (-v11).
>>>>>
>>>>> C.4 Service Availability
>>>>>
>>>>> Following on from the previous comment,  section 5.5.1 of TR101290
>>> describes
>>>>> a service availability error as a combination of TS_sync_loss,
>>> PAT_error and
>>>>> PMT_error whereas draft-ietf-xrblock-rtcp-xr-decodability-10 does not
>>>>> contain the PAT and PMT error metrics.  The resolution for this would
>>> either
>>>>> be to remove the reference to 5.5.1 or to add the metrics required to
>>>>> calculate the service availability.
>>>>>
>>>>> [Qin]: Agree. I prefer to remove the reference to 5.5.1 since there was
>>> consensus in the past WGLC to this draft
>>>>> that having a second report block later to cover the other parameters
>>> and get inline with concept of RFC6792
>>>>> and letting this draft focus on PSI indpendent parameter reporting.
>>>>> See details for the WGLC discussion in the following link:
>>>>> http://www.ietf.org/mail-archive/web/xrblock/current/msg01032.html
>>>>>
>>>>> It is recommended that PAT_error , PAT_error_2,  PMT_error and
>>> PMT_error_2
>>>>> be included as metrics as these ³are² generally present in MPEG
>>> Transport
>>>>> streams and errors within these can prevent correct decoding of the
>>> stream.
>>>>>
>>>>> C.5 PCR_error_count
>>>>>
>>>>> PCR_error_count is defined twice - the second of these should be
>>>>> PCR_accuracy_error_count
>>>>>
>>>>>   [Qin]: Good catch and have fixed in (-v11).
>>>>>
>>>>>
>>>>>
>>>>
>>
> 
> 


From bclaise@cisco.com  Sun May 19 14:06:36 2013
Return-Path: <bclaise@cisco.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8839B21F8629 for <pm-dir@ietfa.amsl.com>; Sun, 19 May 2013 14:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.41
X-Spam-Level: 
X-Spam-Status: No, score=-10.41 tagged_above=-999 required=5 tests=[AWL=0.189,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVB3+Kajw469 for <pm-dir@ietfa.amsl.com>; Sun, 19 May 2013 14:06:30 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id BB9FF21F8681 for <pm-dir@ietf.org>; Sun, 19 May 2013 14:06:26 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4JL6PRb009447 for <pm-dir@ietf.org>; Sun, 19 May 2013 23:06:25 +0200 (CEST)
Received: from sweet-brew-5.cisco.com (sweet-brew-5.cisco.com [144.254.10.206]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4JL67mC021853 for <pm-dir@ietf.org>; Sun, 19 May 2013 23:06:17 +0200 (CEST)
Received: (from bclaise@localhost) by sweet-brew-5.cisco.com (8.13.8+Sun/8.13.6/Submit) id r4JL64TI013796 for pm-dir@ietf.org; Sun, 19 May 2013 23:06:04 +0200 (CEST)
Date: Sun, 19 May 2013 23:06:04 +0200
From: Benoit Claise <bclaise@cisco.com>
To: pm-dir@ietf.org
Message-ID: <20130519210604.GA13794@sweet-brew-5.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Subject: [pm-dir] Performance metrics doctors generated email
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 May 2013 21:06:36 -0000

Dear all,

This is an automatically generated email.  
It lists the IETF internet-drafts that reference the PMOL RFC 6390, as a normative or informative reference.
It also lists all the IETF internet-drafts that contain "performance metric".

Regards, Benoit

===========================================================

Normative References
--------------------
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 Active	
    
Informative References
----------------------
draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14   In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-burst-gap-loss-12      In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-decodability-11        In IESG processing - ID Tracker state <IESG Evaluation>	
draft-ietf-xrblock-rtcp-xr-discard-13             In IESG processing - ID Tracker state <Publication Requested>	
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 Active	
draft-ietf-xrblock-rtcp-xr-jb-11                  In IESG processing - ID Tracker state <In Last Call>	
draft-ietf-xrblock-rtcp-xr-loss-conceal-05        Active	
draft-ietf-xrblock-rtcp-xr-qoe-07                 Active	
draft-ietf-xrblock-rtcp-xr-summary-stat-11        In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-synchronization-04     Active	

drafts containing performance metric
------------------------------------
draft-ietf-alto-deployments-06                    Active	
draft-ietf-alto-protocol-15                       Active	
draft-ietf-bmwg-ca-bench-meth-04                  Active	
draft-ietf-ippm-rate-problem-03                   Active	
draft-ietf-ippm-testplan-rfc2680-02               Active	
draft-ietf-manet-smf-mib-07                       In IESG processing - ID Tracker state <AD Evaluation::Revised I-D Needed>	
draft-ietf-nvo3-framework-02                      Active	
draft-ietf-opsawg-oam-overview-08                 In IESG processing - ID Tracker state <Waiting for AD Go-Ahead::Revised I-D Needed>	
draft-ietf-pce-pcep-service-aware-00              Active	
draft-ietf-ppsp-peer-protocol-06                  Active	
draft-ietf-rtcweb-rtp-usage-06                    Active	
draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14   In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-burst-gap-loss-12      In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-decodability-11        In IESG processing - ID Tracker state <IESG Evaluation>	
draft-ietf-xrblock-rtcp-xr-discard-13             In IESG processing - ID Tracker state <Publication Requested>	
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 Active	
draft-ietf-xrblock-rtcp-xr-jb-11                  In IESG processing - ID Tracker state <In Last Call>	
draft-ietf-xrblock-rtcp-xr-loss-conceal-05        Active	
draft-ietf-xrblock-rtcp-xr-qoe-07                 Active	
draft-ietf-xrblock-rtcp-xr-summary-stat-11        In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-synchronization-04     Active	

From bclaise@cisco.com  Thu May 23 15:16:53 2013
Return-Path: <bclaise@cisco.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA5221F978E for <pm-dir@ietfa.amsl.com>; Thu, 23 May 2013 15:16:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.432
X-Spam-Level: 
X-Spam-Status: No, score=-10.432 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOwx2AdNPS9B for <pm-dir@ietfa.amsl.com>; Thu, 23 May 2013 15:16:31 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1159821F9853 for <pm-dir@ietf.org>; Thu, 23 May 2013 14:31:32 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4NLVUS3010738 for <pm-dir@ietf.org>; Thu, 23 May 2013 23:31:30 +0200 (CEST)
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4NLUxXp009799; Thu, 23 May 2013 23:31:09 +0200 (CEST)
Message-ID: <519E8A93.9050601@cisco.com>
Date: Thu, 23 May 2013 23:30:59 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "pm-dir@ietf.org" <pm-dir@ietf.org>
References: <201305231512.r4NFCMN4006908@irp-view13.cisco.com>
In-Reply-To: <201305231512.r4NFCMN4006908@irp-view13.cisco.com>
X-Forwarded-Message-Id: <201305231512.r4NFCMN4006908@irp-view13.cisco.com>
Content-Type: multipart/mixed; boundary="------------090101020606050809080400"
Cc: Fred Baker <Fred@cisco.com>
Subject: [pm-dir] Fred's script (was: draft-nguyen-manet-ecds-mib and Performance Metrics)
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 May 2013 22:16:53 -0000

This is a multi-part message in MIME format.
--------------090101020606050809080400
Content-Type: multipart/alternative;
 boundary="------------080801000606030207040805"


--------------080801000606030207040805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear pm-dir,

Discussing the pm-dir goals with Fred Baker today, Fred quickly compiled 
a script: it sends an email to all draft authors whose draft contains 
"performance metric". The goal is to notify the authors of the RFC 6390 
existence
See an example below.

Thanks Fred for helping the performance metric directorate.

Regards, Benoit



-------- Original Message --------
Subject: 	draft-nguyen-manet-ecds-mib and Performance Metrics
Date: 	Thu, 23 May 2013 08:12:22 -0700 (PDT)
From: 	Fred Baker <fred@cisco.com>
To: 	draft-nguyen-manet-ecds-mib@tools.ietf.org
CC: 	bclaise@cisco.com



Hi:

I have a question for you. Your document mentions performance metrics.
Would you kindly take a look at RFC 6390 to see if any of its
considerations apply to it?  "No" is an acceptable response, of
course; the point is to ask the question.

6390 Guidelines for Considering New Performance Metric Development. A.
      Clark, B. Claise. October 2011. (Format: TXT=49930 bytes) (Also
      BCP0170) (Status: BEST CURRENT PRACTICE)





--------------080801000606030207040805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Dear pm-dir,<br>
    <br>
    Discussing the pm-dir goals with Fred Baker today, Fred quickly
    compiled a script: it sends an email to all draft authors whose
    draft contains "performance metric". The goal is to notify the
    authors of the RFC 6390 existence<br>
    See an example below.<br>
    <br>
    Thanks Fred for helping the performance metric directorate.<br>
    <br>
    Regards, Benoit<br>
    <br>
    <div class="moz-forward-container"><br>
      <br>
      -------- Original Message --------
      <table class="moz-email-headers-table" border="0" cellpadding="0"
        cellspacing="0">
        <tbody>
          <tr>
            <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Subject:
            </th>
            <td>draft-nguyen-manet-ecds-mib and Performance Metrics</td>
          </tr>
          <tr>
            <th nowrap="nowrap" valign="BASELINE" align="RIGHT">Date: </th>
            <td>Thu, 23 May 2013 08:12:22 -0700 (PDT)</td>
          </tr>
          <tr>
            <th nowrap="nowrap" valign="BASELINE" align="RIGHT">From: </th>
            <td>Fred Baker <a class="moz-txt-link-rfc2396E" href="mailto:fred@cisco.com">&lt;fred@cisco.com&gt;</a></td>
          </tr>
          <tr>
            <th nowrap="nowrap" valign="BASELINE" align="RIGHT">To: </th>
            <td><a class="moz-txt-link-abbreviated" href="mailto:draft-nguyen-manet-ecds-mib@tools.ietf.org">draft-nguyen-manet-ecds-mib@tools.ietf.org</a></td>
          </tr>
          <tr>
            <th nowrap="nowrap" valign="BASELINE" align="RIGHT">CC: </th>
            <td><a class="moz-txt-link-abbreviated" href="mailto:bclaise@cisco.com">bclaise@cisco.com</a></td>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      <pre>Hi:

I have a question for you. Your document mentions performance metrics.
Would you kindly take a look at RFC 6390 to see if any of its
considerations apply to it?  "No" is an acceptable response, of
course; the point is to ask the question.

6390 Guidelines for Considering New Performance Metric Development. A.
     Clark, B. Claise. October 2011. (Format: TXT=49930 bytes) (Also
     BCP0170) (Status: BEST CURRENT PRACTICE)


</pre>
      <br>
    </div>
    <br>
  </body>
</html>

--------------080801000606030207040805--

--------------090101020606050809080400
Content-Type: text/plain; charset=windows-1252;
 name="Attached Message Part"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="Attached Message Part"


--------------090101020606050809080400--

From bclaise@cisco.com  Thu May 23 15:28:42 2013
Return-Path: <bclaise@cisco.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B87621F988A for <pm-dir@ietfa.amsl.com>; Thu, 23 May 2013 15:28:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.836
X-Spam-Level: 
X-Spam-Status: No, score=-9.836 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFkfizvPSj0R for <pm-dir@ietfa.amsl.com>; Thu, 23 May 2013 15:28:36 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 18E0121F98A9 for <pm-dir@ietf.org>; Thu, 23 May 2013 14:46:41 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4NLkeLK012025 for <pm-dir@ietf.org>; Thu, 23 May 2013 23:46:41 +0200 (CEST)
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4NLjtdf027864; Thu, 23 May 2013 23:46:06 +0200 (CEST)
Message-ID: <519E8E13.9090002@cisco.com>
Date: Thu, 23 May 2013 23:45:55 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "pm-dir@ietf.org" <pm-dir@ietf.org>
References: <8C48B86A895913448548E6D15DA7553B8F4454@xmb-rcd-x09.cisco.com>
In-Reply-To: <8C48B86A895913448548E6D15DA7553B8F4454@xmb-rcd-x09.cisco.com>
X-Forwarded-Message-Id: <8C48B86A895913448548E6D15DA7553B8F4454@xmb-rcd-x09.cisco.com>
Content-Type: multipart/mixed; boundary="------------020803030204060209020406"
Cc: Fred Baker <Fred@cisco.com>
Subject: [pm-dir] Fwd: Re:  Performance metrics doctors generated email
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 May 2013 22:28:42 -0000

This is a multi-part message in MIME format.
--------------020803030204060209020406
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear pm-dir,

Some more help from Fred.
All the drafts containing "performance metrics", along with the specific 
section.
That should help identifying the drafts that are important to review.

Regards, Benoit




--------------020803030204060209020406
Content-Type: text/plain; charset=windows-1252;
 name="aa.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
 filename="aa.txt"

http://datatracker.ietf.org/doc/draft-ashwood-nvo3-operational-requirement
http://tools.ietf.org/html/draft-ashwood-nvo3-operational-requirement
  "NVO3 Operational Requirements", Peter Ashwood-Smith, Ranga Iyengar,
  Tina Tsou, Ali Sajassi, Mohamed Boucadair, Christian Jacquenet, Masahiro
  Daikoku, 31-Jan-13

 
   compliance to both the service-level and network-level metric
   objectives/specifications.  Performance Management typically consists
   of measuring performance metrics, e.g., Frame Loss, Frame Delay,
   Frame Delay Variation (aka Jitter), Frame throughput, Frame discard,
   etc., across managed entities when the managed entities are in
   available state.  Performance Management is suspended across
   unavailable managed entities.

http://datatracker.ietf.org/doc/draft-bagnulo-ippm-new-registry
http://tools.ietf.org/html/draft-bagnulo-ippm-new-registry
  "A registry for commonly used metrics", Marcelo Bagnulo, Trevor
  Burbridge, Sam Crawford, Philip Eardley, Al Morton, 15-Jan-13

  "A registry for commonly used metrics. Independent registries", Marcelo
  Bagnulo, Trevor Burbridge, Sam Crawford, Philip Eardley, Al Morton,
  15-Jan-13

 
   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330,
              May 1998.

   [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay Variation
              Metric for IP Performance Metrics (IPPM)", RFC 3393,
              November 2002.

   [RFC4148]  Stephan, E., "IP Performance Metrics (IPPM) Metrics
              Registry", BCP 108, RFC 4148, August 2005.

   [RFC6248]  Morton, A., "RFC 4148 and the IP Performance Metrics
              (IPPM) Registry of Metrics Are Obsolete", RFC 6248,
              April 2011.

http://datatracker.ietf.org/doc/draft-bagnulo-ippm-new-registry-independent
http://tools.ietf.org/html/draft-bagnulo-ippm-new-registry-independent
  "A registry for commonly used metrics. Independent registries", Marcelo
  Bagnulo, Trevor Burbridge, Sam Crawford, Philip Eardley, Al Morton,
  15-Jan-13

 
   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330,
              May 1998.

              Metric for IP Performance Metrics (IPPM)", RFC 3393,
              November 2002.

   [RFC4148]  Stephan, E., "IP Performance Metrics (IPPM) Metrics
              Registry", BCP 108, RFC 4148, August 2005.

   [RFC6248]  Morton, A., "RFC 4148 and the IP Performance Metrics
              (IPPM) Registry of Metrics Are Obsolete", RFC 6248,
              April 2011.

http://datatracker.ietf.org/doc/draft-bormann-intarea-alfi
http://tools.ietf.org/html/draft-bormann-intarea-alfi
  "Adaptation Layer Fragmentation Indication", Carsten Bormann, 10-Mar-13

 
   Often, adaption layer fragmentation schemes reduce some performance
   metric, such as the packet delivery probability.  Application or
   transport protocols may be able to reduce the maximum size of packets
   they send, e.g.  by transport layer segmentation or choice of
   application layer data object size, which may have less of a
   performance impact.  It would therefore be desirable for them to know
   about any adaptation layer fragmentation that is going on, so they
   can choose packet sizes that minimize adaptation layer fragmentation.

   At the IP layer, fragmentation can be detected using a number of
   mechanisms used in Packetization Layer Path MTU Discovery [RFC4821].
   However, adaptation layer fragmentation schemes are often designed to
   be "transparent", i.e.  there is no way at higher layers to find out
   whether they had to be employed (except maybe by elaborate
   measurement schemes targeting one of the impacted performance
   metrics; this approach does not appear to be viable) [WEI].

   Generally speaking, ALFI can be used as a mechanism to indicate any
   significant, step function degradation of some performance metric
   based on packet size.  However, as the mechanism can only collect a
   single value for the entire path (i.e., one IFMUALTU and one
   FFMUALTU), the performance degradation indicated SHOULD be
   significant.  In other words, ALFI indications SHOULD NOT be set for
   segmentation implementations where segmentation causes limited
   performance impact.  E.g., AAL5 implementations SHOULD NOT set ALFI.

   The originator of a packet MAY, for occasional probing, insert an
   ALFI option into packets where it can choose the packet size and the
   performance metrics of which are important to the application.

http://datatracker.ietf.org/doc/draft-boucadair-connectivity-provisioning-profile
http://tools.ietf.org/html/draft-boucadair-connectivity-provisioning-profile
  "IP/MPLS Connectivity Provisioning Profile", Mohamed Boucadair,
  Christian Jacquenet, Ning Wang, 25-Sep-12

 
   This document describes the Connectivity Provisioning Profile (CPP)
   and proposes a CPP Template to capture IP connectivity requirements
   to be met in the context of delivery of services (e.g.  Voice over IP
   or IP TV) which are to be plugged upon an IP/MPLS infrastructure.
   The CPP defines the set of IP transfer parameters to be supported by
   the underlying IP/MPLS transport network together with a reachability
   scope and bandwidth/capacity needs.  Appropriate performance metrics
   such as one-way delay, one-way delay variation are used to
   characterize an IP transfer service.  Both global and restricted
   reachability scopes can be captured in the CPP.

   The CPP defines the set of IP/MPLS transfer guarantees to be offered
   by the underlying IP/MPLS transport network together with a
   reachability scope and capacity needs.  Appropriate performance
   metrics such as one-way delay or one-way delay variation are used to
   characterize the IP transfer service.  Guarantees related to
   availability and resiliency are also included in the CPP.

   QoS guarantees denote a set of IP transfer performance metrics which
   characterize the quality of the IP transfer treatment to be
   experienced (when crossing an IP transport infrastructure) by a flow
   issued or destined to a (set of) "Customer Node(s)".

   IP performance metrics can be expressed as qualitative or
   quantitative parameters.  When quantitative metrics are used, maximum
   or average numerical values are provided together with a validity
   interval which should be indicated in the measurement method.

   Several performance metrics have been defined such as:
   o  Traffic Loss [RFC2680]
   o  One way delay [RFC2679]
   o  One way delay variation [RFC3393]
   The value of these parameters may be specific to a given path or a
   given scope (e.g., between two "Customer Nodes").  Concretely, IP
   performance metric value indicated in a CPP should reflect the
   measurement between a set of "Customer Node" or between a "Customer
   Node" and Provider Nodes attached to the IP network.

   [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay Variation
              Metric for IP Performance Metrics (IPPM)", RFC 3393,
              November 2002.

http://datatracker.ietf.org/doc/draft-boucadair-lmap-considerations
http://tools.ietf.org/html/draft-boucadair-lmap-considerations
  "Large scale Measurement of Access network Performance (LMAP):
  Requirements and Issues from a Network Provider Perspective", Mohamed
  Boucadair, Christian Jacquenet, 18-Feb-13

 
   performance metrics should be accessed by customers so that they can
   appreciate the level of quality associated to the services they have
   subscribed to.  These data should be updated on a regular basis to
   adequately reflect the actual status of any service.  These
   indicators (including a combination thereof) should be described and
   listed in the agreement (see Section 2.13 of
   [I-D.boucadair-connectivity-provisioning-profile]).

   As discussed in [I-D.boucadair-connectivity-provisioning-profile],
   performance metrics are not the only relevant indicators to
   characterize the connectivity service delivered to the customer;
   other important technical clauses (e.g., reachability scope, traffic
   conformance, availability, etc.) need also to be taken into account.

http://datatracker.ietf.org/doc/draft-boucadair-network-automation-requirements
http://tools.ietf.org/html/draft-boucadair-network-automation-requirements
  "Requirements for Automated (Configuration) Management", Mohamed
  Boucadair, Christian Jacquenet, 14-Dec-12

 
   Configuring a set of devices to deliver a service takes time.  In
   addition, depending on the complexity of the service, erroneous
   configurations may occur at the cost of jeopardizing the overall
   quality of a service, if not causing service disruption.  From this
   perspective, some performance indicators must be defined and measured
   to assess:
   o  The time to deliver a service, from subscription to operation.
      Such indicator may be further decomposed into elementary
      performance metrics, e.g., the time it takes to complete the
      configurations tasks that are specific to the enforcement of a

http://datatracker.ietf.org/doc/draft-chen-coloring-based-ipfpm-framework
http://tools.ietf.org/html/draft-chen-coloring-based-ipfpm-framework
  "Coloring based IP Flow Performance Measurement Framework", Mach Chen,
  Hongming Liu, Yuanbin Yin, 24-Feb-13

 
   In passive performance measurement, no artificial traffic is injected
   into the flow and measurements are taken to record the performance
   metrics of the real traffic.  The Multiprotocol Label Switching
   (MPLS) PM protocol [RFC6374] for packet loss is an example of passive
   performance measurement.  By periodically inserting auxiliary
   Operations, Administration, and Maintenance (OAM) packets, the
   traffic is delimited by the OAM packets into consecutive blocks, and
   the receivers count the packets and calculate the packets loss each
   block.

   The MCP is responsible for calculating the final performance metrics
   according to the received measurement data from the MPs (actually
   from the DCPs).  For packet loss, based on each color block, the
   difference between the total counts received from all upstream MPs
   and the total counts received from all downstream MPs are the lost
   packet numbers.  The MCP must make sure that the counts from the
   upstream MPs and downstream MPs are related to the same color block.
   For packet delay (e.g., one way delay), the difference between the
   timestamps from the downstream MP and upstream MP is the packet
   delay.  Similarly to packet loss, the MCP must make sure the two
   timestamps are based on the same colored packet.

http://datatracker.ietf.org/doc/draft-dhody-pce-pcep-service-aware
http://tools.ietf.org/html/draft-dhody-pce-pcep-service-aware
  "Extensions to the Path Computation Element Communication Protocol
  (PCEP) to compute service aware Label Switched Path (LSP).", Dhruv
  Dhody, Vishwas Manral, Zafar Ali, George Swallow, Kenji Kumaki,
  25-Feb-13

 
   PCEP supporting this draft SHOULD provide mechanism to support
   different Metric requirements for different Layers.  This is
   important as the network performance metric would be different for
   Packet and Optical (TDM, LSC etc) Layers.  In order to allow
   different Metric-Value to be applied within different network layers,
   multiple METRIC objects of the same type MAY be present.  In such a
   case, the first METRIC object specifies an metric for the higher-
   layer network, and subsequent METRIC objects specify objection
   functions of the subsequent lower-layer networks.

http://datatracker.ietf.org/doc/draft-dong-l3vpn-pm-framework
http://tools.ietf.org/html/draft-dong-l3vpn-pm-framework
  "A Framework for L3VPN Performance Monitoring", Jie Dong, Zhenbin Li,
  Bhavani Parise, 17-Apr-13

 
   Level 3 Virtual Private Network (L3VPN) [RFC4364] service is widely
   deployed to provide enterprise VPN, Voice over IP (VoIP), video,
   mobile backhaul, etc.  services.  Most of these services are
   sensitive to the packet loss and delay.  The capability to measure
   and monitor performance metrics for packet loss, delay, as well as
   related metrics is essential for meeting the Service Level Agreement
   (SLA).  This measurement capability also provides operators with
   greater visibility into the performance characteristics of the
   services in their networks, and provides diagnostic information in
   case of performance degradation or failure and helps for fault
   localization.

http://datatracker.ietf.org/doc/draft-eardley-lmap-framework
http://tools.ietf.org/html/draft-eardley-lmap-framework
  "A framework for large-scale measurements", Philip Eardley, Trevor
  Burbridge, Al Morton, 25-Feb-13

 
   o  Extensible - it should be easy to add or modify tests, for example
      an improved test methodology or to measure a performance metric
      not previously considered important (eg bufferbloat).

http://datatracker.ietf.org/doc/draft-eardley-lmap-terminology
http://tools.ietf.org/html/draft-eardley-lmap-terminology
  "Terminology for Large MeAsurement Platforms (LMAP)", Philip Eardley, Al
  Morton, Marcelo Bagnulo, Trevor Burbridge, 2-May-13

 
   It is worth explaining how the terms defined here compare with those
   in [RFC2330], "Framework for IP Performance Metrics".  The definition
   of Metric is taken from RFC2330.  The definition of Measurement
   Method is (we believe) equivalent in RFC2330's terms to a measurement
   methodology for a singleton metric.  A set of Measurement Tasks
   defined by a Measurement Schedule relates to RFC2330's concept of a
   sample metric.

   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330, May
              1998.

   [I-D.mathis-ippm-model-based-metrics]
              Mathis, M. and A. Morton, "Model Based Internet
              Performance Metrics", draft-mathis-ippm-model-based-
              metrics-01 (work in progress), February 2013.

http://datatracker.ietf.org/doc/draft-fan-opsawg-packet-loss
http://tools.ietf.org/html/draft-fan-opsawg-packet-loss
  "IP Packet loss rate measurement testing and problem statement", Peng
  Fan, Lu Huang, 18-Feb-13

 
   IP packet loss rate is one of the important metrics that are
   frequently used to measure IP performance of a data path or link.  A
   general framework of IP performance metrics is provided in [RFC2330],
   including fundamental concepts definition and issues related to
   defining sound metrics and methodologies.  [RFC2680] and [RFC6673]
   further define metrics for one-way and round-trip packet loss.

   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330,
              May 1998.

http://datatracker.ietf.org/doc/draft-iab-cc-workshop-report
http://tools.ietf.org/html/draft-iab-cc-workshop-report
  "Report from the IAB/IRTF Workshop on Congestion Control for Interactive
  Real-Time Communication", Hannes Tschofenig, Lars Eggert, Zaheduzzaman
  Sarker, 2-Apr-13

 
   Measurement tools that allow an end user to determine the performance
   of his or her network, including latency, is seen as a promising
   approach to motivate network operators to upgrade their equipment and
   to make use of AQM algorithms.  Measurement tools would allow users
   to determine how bad their networks perform and to complain to their
   ISP, thereby creating a market force.  As to what the right
   performance measurement metrics are, it was noted that the intent of
   the IETF IP Performance Metrics (IPPM) working group [28] was to
   develop such metrics to qualify networks.  That work may have begun
   before its time, but there have been recent attempts to re-visit the
   measurement work and an effort by the FCC has gotten a lot of
   attention recently (see [29], [30]).

   [28]  IETF, "IETF IP Performance Metrics (ippm) Working Group",
         Jan. 2012.

http://datatracker.ietf.org/doc/draft-ietf-alto-deployments
http://tools.ietf.org/html/draft-ietf-alto-deployments
  "ALTO Deployment Considerations", Martin Stiemerling, Sebastian Kiesel,
  Stefano Previdi, 25-Feb-13

 
   To construct an effective monitoring infrastructure, the ISP should
   (1) define the performance metrics to be monitored; (2) and identify
   and deploy data sources to collect data to compute the performance
   metrics.  We discuss both below.

   o  Performance metrics that are closely related to the instantaneous
      congestion status.  The definition of alternate approaches for
      congestion control is explicitly out of the scope of ALTO.
      Instead, other appropriate means, such as using TCP based
      transport, have to be used to avoid congestion.

http://datatracker.ietf.org/doc/draft-ietf-alto-protocol
http://tools.ietf.org/html/draft-ietf-alto-protocol
  "ALTO Protocol", Richard Alimi, Reinaldo Penno, Yang Yang, 21-May-13

 
   Applications that use an ALTO Service can benefit from better
   knowledge of the network to avoid network bottlenecks.  For example,
   a peer-to-peer overlay application can use information provided by an
   ALTO Service to avoid selecting peers connected with low bandwidth
   links.  By using ALTO information, applications can reduce the
   reliance on obtaining network information through third-party
   databases; applications relying on measuring path performance metrics
   themselves can reduce the measurement overhead by conducting only
   fine-tuning or fault-tolerant measurements on top of ALTO
   information.

http://datatracker.ietf.org/doc/draft-ietf-bmwg-ca-bench-meth
http://tools.ietf.org/html/draft-ietf-bmwg-ca-bench-meth
  "Benchmarking Methodology for Content-Aware Network Devices", Mike
  Hamilton, Sarah Banks, 6-Feb-13

 
   The end goal of this methodology is to generate performance metrics
   in a lab environment that will closely relate to actual observed
   performance on production networks.  By utilizing dynamic traffic
   patterns relevant to modern networks, this methodology should be able
   to closely tie laboratory and production metrics.  It should be
   further noted than any metrics acquired from production networks
   SHOULD be captured according to the policies and procedures of the
   IPPM or PMOL working groups.

   The IETF has historically provided guidance and information on TCP
   stack considerations.  This methodology is strictly focused on
   performance metrics at layers above 4, thus does not specifically
   define any TCP stack configuration parameters of either the tester or
   the DUTs.  The TCP configuration of the tester MUST remain constant
   across all DUTs in order to ensure comparable results.  While the
   following list of references is not exhaustive, each document
   contains a relevant discussion on TCP stack considerations.

http://datatracker.ietf.org/doc/draft-ietf-ippm-rate-problem
http://tools.ietf.org/html/draft-ietf-ippm-rate-problem
  "Rate Measurement Test Protocol Problem Statement", Al Morton,
  23-Apr-13

 
   This memo presents an access rate-measurement problem statement for
   test protocols to measure IP Performance Metrics.  The rate
   measurement scenario has wide-spread attention of Internet access
   subscribers and seemingly all industry players, including regulators.
   Key test protocol aspects require the ability to control packet size
   on the tested path and enable asymmetrical packet size testing in a
   controller-responder architecture.

   There are many possible rate measurement scenarios.  This memo
   describes one rate measurement problem and presents a rate-
   measurement problem statement for test protocols to measure IP
   Performance Metrics (IPPM).

   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330, May
              1998.

   [RFC6703]  Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
              IP Network Performance Metrics: Different Points of View",
              RFC 6703, August 2012.

   [I-D.mathis-ippm-model-based-metrics]
              Mathis, M. and A. Morton, "Model Based Internet
              Performance Metrics", draft-mathis-ippm-model-based-
              metrics-01 (work in progress), February 2013.

http://datatracker.ietf.org/doc/draft-ietf-ippm-testplan-rfc2680
http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680
  "Test Plan and Results for Advancing RFC 2680 on the Standards Track",
  Len Ciavattone, Ruediger Geib, Al Morton, Matthias Wieser, 17-Feb-13

 
   This memo proposes to advance a performance metric RFC along the
   standards track, specifically RFC 2680 on One-way Loss Metrics.
   Observing that the metric definitions themselves should be the
   primary focus rather than the implementations of metrics, this memo
   describes the test procedures to evaluate specific metric requirement
   clauses to determine if the requirement has been interpreted and
   implemented as intended.  Two completely independent implementations
   have been tested against the key specifications of RFC 2680.

   The IETF (IP Performance Metrics working group, IPPM) has considered
   how to advance their metrics along the standards track since 2001.

   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330,
              May 1998.

   [RFC6576]  Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP
              Performance Metrics (IPPM) Standard Advancement Testing",
              BCP 176, RFC 6576, March 2012.

   [RFC6703]  Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
              IP Network Performance Metrics: Different Points of View",
              RFC 6703, August 2012.

http://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib
http://tools.ietf.org/html/draft-ietf-manet-smf-mib
  "Definition of Managed Objects for the Manet Simplified Multicast
  Framework Relay Set Process", Robert Cole, Joseph Macker, Brian Adamson,
  21-Mar-13

 
   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes objects for configuring aspects of the
   Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc
   Networks (MANETs).  The SMF-MIB also reports state information,
   performance metrics, and notifications.  In addition to
   configuration, the additional state and performance information is
   useful to operators troubleshooting multicast forwarding problems.

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes objects for configuring aspects of a
   process implementing Simplified Multicast Forwarding (SMF) [RFC6621]
   for Mobile Ad-Hoc Networks (MANETs).  SMF provides multicast
   Duplicate Packet Detection (DPD) and supports algorithms for
   constructing an estimate of a MANET Minimum Connected Dominating Set
   (MCDS) for efficient multicast forwarding.  The SMF-MIB also reports
   state information, performance metrics, and notifications.  In
   addition to configuration, this additional state and performance
   information is useful to operators troubleshooting multicast
   forwarding problems.

http://datatracker.ietf.org/doc/draft-ietf-nvo3-framework
http://tools.ietf.org/html/draft-ietf-nvo3-framework
  "Framework for DC Network Virtualization", Marc Lasserre, Florin Balus,
  Thomas Morin, Nabil Bitar, Yakov Rekhter, 4-Feb-13

 
          o Performance metrics (throughput, delay, loss, jitter)

http://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview
http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview
  "An Overview of Operations, Administration, and Maintenance (OAM)
  Mechanisms", Tal Mizrahi, Nurit Sprecher, Elisa Bellagamba, Yaacov
  Weingarten, 9-Jan-13

 
   o OWAMP and TWAMP:
      The One Way Active Measurement Protocol (OWAMP) and the Two Way
      Active Measurement Protocols (TWAMP) are two protocols defined in
      the IP Performance Metrics (IPPM) working group in the IETF. These
      protocols allow delay and packet loss measurement in IP networks.

   |           +--------------------------------------+-----+----------+
   |           | Bidirectional Forwarding Detection   |Prof.| RFC 5885 |
   |           | for the Pseudowire Virtual Circuit   |     |          |
   |           | Connectivity Verification (VCCV)     |     |          |
   |           | [BFD-VCCV]                           |     |          |
   |           +--------------------------------------+-----+----------+
   |           | Using the Generic Associated Channel |Inf. | RFC 6423 |
   |           | Label for Pseudowire in the MPLS     |     |          |
   |           | Transport Profile (MPLS-TP)          |     |          |
   |           | [PW-G-ACh]                           |     |          |
   |           +--------------------------------------+-----+----------+
   |           | Pseudowire (PW) Operations,          |Misc.| RFC 6310 |
   |           | Administration, and Maintenance (OAM)|     |          |
   |           | Message Mapping [PW-Map]             |     |          |
   +-----------+--------------------------------------+-----+----------+
   |OWAMP and  | A One-way Active Measurement Protocol|Tool | RFC 4656 |
   |TWAMP      | [OWAMP]                              |     |          |
   |           +--------------------------------------+-----+----------+
   |           | A Two-Way Active Measurement Protocol|Tool | RFC 5357 |
   |           | [TWAMP]                              |     |          |
   |           +--------------------------------------+-----+----------+
   |           | Framework for IP Performance Metrics |Misc.| RFC 2330 |
   |           | [IPPM-FW]                            |     |          |
   |           +--------------------------------------+-----+----------+
   |           | IPPM Metrics for Measuring           |Misc.| RFC 2678 |
   |           | Connectivity [IPPM-Con]              |     |          |
   |           +--------------------------------------+-----+----------+
   |           | A One-way Delay Metric for IPPM      |Misc.| RFC 2679 |
   |           | [IPPM-1DM]                           |     |          |
   |           +--------------------------------------+-----+----------+
   |           | A One-way Packet Loss Metric for IPPM|Misc.| RFC 2680 |
   |           | [IPPM-1LM]                           |     |          |
   |           +--------------------------------------+-----+----------+
   |           | A Round-trip Delay Metric for IPPM   |Misc.| RFC 2681 |
   |           | [IPPM-2DM]                           |     |          |
   +-----------+--------------------------------------+-----+----------+
                 Table 1 Summary of IETF OAM Related RFCs

   [IPPM-FW]     Paxson, V., Almes, G., Mahdavi, J., and Mathis, M.,
                 "Framework for IP Performance Metrics", RFC 2330, May
                 1998.

http://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware
http://tools.ietf.org/html/draft-ietf-pce-pcep-service-aware
  "Extensions to the Path Computation Element Communication Protocol
  (PCEP) to compute service aware Label Switched Path (LSP).", Dhruv
  Dhody, Vishwas Manral, Zafar Ali, George Swallow, Kenji Kumaki,
  26-Mar-13

 
   PCEP supporting this draft SHOULD provide mechanism to support
   different Metric requirements for different Layers.  This is
   important as the network performance metric would be different for
   Packet and Optical (TDM, LSC etc) Layers.  In order to allow
   different Metric-Value to be applied within different network layers,
   multiple METRIC objects of the same type MAY be present.  In such a
   case, the first METRIC object specifies an metric for the higher-
   layer network, and subsequent METRIC objects specify objection
   functions of the subsequent lower-layer networks.

http://datatracker.ietf.org/doc/draft-ietf-ppsp-peer-protocol
http://tools.ietf.org/html/draft-ietf-ppsp-peer-protocol
  "Peer-to-Peer Streaming Peer Protocol (PPSPP)", A. Bakker, Riccardo
  Petrocco, Victor Grishchenko, 11-Feb-13

 
   [RFC4150]  Dietz, R. and R. Cole, "Transport Performance Metrics
              MIB", RFC 4150, August 2005.

http://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage
http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage
  "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP",
  Colin Perkins, Magnus Westerlund, Joerg Ott, 25-Feb-13

 
   5.   Still open if any RTCP XR performance metrics are needed, as
        discussed in Section 8.

http://datatracker.ietf.org/doc/draft-keranen-ipv6day-measurements
http://tools.ietf.org/html/draft-keranen-ipv6day-measurements
  "Some Measurements on World IPv6 Day from End-User Perspective", Ari
  Keränen, Jari Arkko, 11-Sep-12

 
   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330,
              May 1998.

http://datatracker.ietf.org/doc/draft-ko-ippm-streaming-performance
http://tools.ietf.org/html/draft-ko-ippm-streaming-performance
  "Model-Based Estimation of Streaming Performance", Ken Ko, 18-Feb-13

 
   [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
             "Framework for IP Performance Metrics", RFC 2330, May
             1998.

http://datatracker.ietf.org/doc/draft-leiwm-avtcore-mprtp-ra
http://tools.ietf.org/html/draft-leiwm-avtcore-mprtp-ra
  "Multipath RTP based on RTP Relay Application (MPRTP-RA)", Lei Weimin,
  Wei Zhang, Shaowei Liu, 12-Mar-13

 
   For a multimedia session, the media transmission path from the source to its
   receiver is usually the default IP path determined by routing protocols,
   such as OSPF. However, the default IP path usually is not optimal and
   sometimes even when the path goes through different ISP networks. If the
   media transmission path is switched to another path, referred to as a relay
   path, which goes through one or more relay nodes, and if network bandwidth
   and other performance metrics between the endpoints and its neighboring
   relay nodes and between two successive relay nodes if they exist can be
   ensured, the quality of the received media can be improved.

http://datatracker.ietf.org/doc/draft-linsner-lmap-use-cases
http://tools.ietf.org/html/draft-linsner-lmap-use-cases
  "Large-Scale Broadband Measurement Use Cases", Marc Linsner, Philip
  Eardley, Trevor Burbridge, 25-Feb-13

 
      5.  The performance metrics are whatever the operator wants to
      benchmark. As well as QoE measures, it may want to measure some
      network-specific parameters.

      o  Performance metrics: A regulator and operator are generally
      interested in the same performance metrics. Both would like
      standardised metrics, though this is more important for
      regulators.

http://datatracker.ietf.org/doc/draft-mathis-ippm-model-based-metrics
http://tools.ietf.org/html/draft-mathis-ippm-model-based-metrics
  "Model Based Internet Performance Metrics", Matt Mathis, Al Morton,
  25-Feb-13

 
                Model Based Internet Performance Metrics
              draft-mathis-ippm-model-based-metrics-01.txt

   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330,
              May 1998.

http://datatracker.ietf.org/doc/draft-morton-ippm-2330-update
http://tools.ietf.org/html/draft-morton-ippm-2330-update
  "Advanced Stream and Sampling Framework for IPPM", Joachim Fabini, Al
  Morton, 22-Feb-13

 
   To obtain repeatable results in modern networks, test descriptions
   need an expanded stream parameter framework that also augments
   aspects specified as Type-P for test packets.  This memo proposes to
   update the IP Performance Metrics (IPPM) Framework with advanced
   considerations for measurement methodology and testing.  The existing
   framework mostly assumes deterministic connectivity, and that a
   single test stream will represent the characteristics of the path
   when it is aggregated with other flows.  Networks have evolved and
   test stream descriptions must evolve with them, otherwise unexpected
   network features may dominate the measured performance.  This memo
   describes new stream parameters for both network characterization and
   support of application design using IPPM metrics.

   The IETF IP Performance Metrics (IPPM) working group first created a
   framework for metric development in [RFC2330].  This framework has
   stood the test of time and enabled development of many fundamental
   metrics, while only being updated once in a specific area [RFC5835].

   The scope of his memo is to describe useful stream parameters in
   addition to the information in Section 11.1 of [RFC2330] and
   described in [RFC3432] for periodic streams.  The purpose is to
   foster repeatable measurement results in modern networks by
   highlighting the key aspects of test streams and packets and make
   them part of the IPPM performance metric framework.

   3.  Access technology may change during testing.  A range of transfer
       capacities and access methods may be encountered during a test
       session.  When different interfaces are used, the host seeking
       access will be aware of the technology change which
       differentiates this form of path change from other changes in
       network state.  Section 14 of [RFC2330] treats the possibility
       that a host may have more than one attachment to the network, and
       also that assessment of the measurement path (route) is valid for
       some length of time (in Section 5 and Section 7 of [RFC2330]).
       Here we combine these two considerations under the assumption
       that changes may be more frequent and possibly have greater
       consequences on performance metrics.

   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330,
              May 1998.

   [RFC6576]  Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP
              Performance Metrics (IPPM) Standard Advancement Testing",
              BCP 176, RFC 6576, March 2012.

   [RFC6703]  Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
              IP Network Performance Metrics: Different Points of View",
              RFC 6703, August 2012.

http://datatracker.ietf.org/doc/draft-morton-ippm-2680-bis
http://tools.ietf.org/html/draft-morton-ippm-2680-bis
  "A One-Way Loss Metric for IPPM", Guy Almes, Sunil Kalidindi, Matthew
  Zekauskas, Al Morton, 17-Feb-13

 
   [1] Paxson, V., Almes,G., Mahdavi, J. and M. Mathis, "Framework for
   IP Performance Metrics", RFC 2330, May 1998.

   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330,
              May 1998.

   [RFC6576]  Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP
              Performance Metrics (IPPM) Standard Advancement Testing",
              BCP 176, RFC 6576, March 2012.

   [RFC6703]  Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
              IP Network Performance Metrics: Different Points of View",
              RFC 6703, August 2012.

http://datatracker.ietf.org/doc/draft-morton-ippm-lmap-path
http://tools.ietf.org/html/draft-morton-ippm-lmap-path
  "A Reference Path and Measurement Points for LMAP", Marcelo Bagnulo,
  Trevor Burbridge, Sam Crawford, Philip Eardley, Al Morton, 25-Feb-13

 
   This document defines a reference path for Large-scale Measurement of
   Broadband Access Performance (LMAP) and measurement points for
   commonly used performance metrics.

   This document defines a reference path for Large-scale Measurement of
   Broadband Access Performance (LMAP).  The series of IP Performance
   Metrics (IPPM) RFCs have developed terms that are generally useful
   for path description (section 5 of [RFC2330]).  There are a limited
   number of additional terms needing definition here, and they will be
   defined in this memo.

   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330,
              May 1998.

   [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay Variation
              Metric for IP Performance Metrics (IPPM)", RFC 3393,
              November 2002.

   [RFC4148]  Stephan, E., "IP Performance Metrics (IPPM) Metrics
              Registry", BCP 108, RFC 4148, August 2005.

   [RFC6248]  Morton, A., "RFC 4148 and the IP Performance Metrics
              (IPPM) Registry of Metrics Are Obsolete", RFC 6248,
              April 2011.

http://datatracker.ietf.org/doc/draft-nandakumar-mmusic-sdp-mux-attributes
http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes
  "A Framework for SDP Attributes when Multiplexing", Suhas Nandakumar,
  25-Apr-13

 
   [MEDIA_LOOPBACK] adds new SDP media types and attributes, which
   enable establishment of media sessions where the media is looped back
   to the transmitter.  Such media sessions will serve as monitoring and
   troubleshooting tools by providing the means for measurement of more
   advanced VoIP, Real-time Text and Video over IP performance metrics.

http://datatracker.ietf.org/doc/draft-nguyen-manet-ecds-mib
http://tools.ietf.org/html/draft-nguyen-manet-ecds-mib
  "Definition of Managed Objects for the MANET Essential Connected
  Dominating Set (E-CDS) Process", James Nguyen, Robert Cole, 3-Jan-13

 
   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes objects for configuring aspects of the
   Essential Connected Dominating Set (E-CDS) process for Mobile Ad-Hoc
   Networks (MANETs).  The ECDS-MIB also reports state information,
   performance metrics, and notifications.  In addition to
   configuration, the additional state and performance information is
   useful to operators troubleshooting multicast forwarding problems.

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes objects for configuring aspects of a
   process implementing the Essential-Connected Dominating Set (E-CDS)
   [RFC5614] algorithm for Mobile Ad-Hoc Networks (MANETs).  The E-CDS
   process transforms a 2-hop neighborhood topology information set for
   routers to dynamically perform relay self-election to form a
   Connected Dominating Set (CDS).  The ECDS-MIB, an extension to the
   SMF-MIB [draft-ietf-manet-smf-mib-06], reports state information,
   performance metrics, and notifications.  In addition to
   configuration, this additional state and performance information is
   useful to operators troubleshooting multicast forwarding problems.

http://datatracker.ietf.org/doc/draft-nichols-tsvwg-codel
http://tools.ietf.org/html/draft-nichols-tsvwg-codel
  "Controlled Delay Active Queue Management", Kathleen Nichols, Van
  Jacobson, 25-Feb-13

 
   The target value derives from an analytically derived range which
   was further studied with many simulations. Analysis centers on a
   single TCP connection since this is easiest to analyze and is more
   difficult to keep utilization high than with more connections. With
   a sufficiently large buffer, the link utilization for the single TCP
   flow can reach 100% but the delay will increase. If no queue is
   permitted, A Reno TCP will only get 75% utilization. We want a value
   for the target, the maximum acceptable standing queue, that gets a
   good utilization for the long-lived TCP flow while holding down the
   delay. Conceptually, if this TCP connection were sharing the link
   with other short-lived flows, it would be able to achieve an
   excellent utilization while presenting a short delay to these other,
   possibly interactive, flows. Fortunately, analysis shows that a very
   small standing queue gives close to 100% utilization and this holds
   for Reno, Cubic, and Westwood. Pictures of this can be seen at
   [TSV84]. The analysis was done by normalizing the queue size to a
   percentage of RTT and using the average "power" (throughput over
   delay) performance metric. The ideal range for the permitted
   standing queue is between 5 and 10% of the RTT of the TCP
   connection.

http://datatracker.ietf.org/doc/draft-retana-rtgwg-eacp
http://tools.ietf.org/html/draft-retana-rtgwg-eacp
  "A Framework and Requirements for Energy Aware Control Planes", Alvaro
  Retana, Russ White, Manuel Paul, 13-Feb-13

 
   This document provides a background, a framework for understanding
   and managing the tradeoffs between modifications made to network
   protocols to conserve energy and network performance metrics and
   requirements, and a set of requirements for protocol designers to
   consider in proposals for new control plane protocols or
   modifications to existing control plane protocols.  It is intended to
   encourage work on mechanisms that will reduce network energy usage
   while providing perspective on balancing energy usage against
   performance.  The ultimate goal is to provide the tools and knowledge
   necessary for protocol designers to modify network protocols to best
   balance efficiency against performance, and to provide the background
   information network operators will need to intelligently deploy and
   use protocol modifications to network protocols.

   The reader should further differentiate between the components of an
   energy management system, namely energy monitoring and energy
   control.  Energy monitoring deals with the collection of information
   related to energy utilization and characteristics, as described in
   [EMAN].  Energy control relates to directly influencing the
   optimization and/or efficiency of devices in the network.  The focus
   of this document is on understanding the tradeoffs between
   modifications made to network protocols to conserve energy and
   network performance metrics and requirements, not on the functions,
   steps or procedures required for energy monitoring.

http://datatracker.ietf.org/doc/draft-savage-eigrp
http://tools.ietf.org/html/draft-savage-eigrp
  "Enhanced Interior Gateway Routing Protocol", Donald Slice, Steven
  Moore, James Ng, Russ White, Donnie, 28-Feb-13

 
The use of the vector metrics allows EIGRP to compute paths based on
any of four (bandwidth, delay, reliability, and load) path selection
schemes. The schemes are distinguished based on the choice of the key
measured network performance metric.

http://datatracker.ietf.org/doc/draft-spp-cdni-rr-foot-cap-semantics
http://tools.ietf.org/html/draft-spp-cdni-rr-foot-cap-semantics
  "CDNI Request Routing: Footprint and Capabilities Semantics", Jan
  Seedorf, Jon Peterson, Stefano Previdi, Ray van Brandenburg, Kevin Ma,
  25-Feb-13

 
   At a first glance, several broad categories of capabilities seem
   useful to convey via an advertisement interface (and indeed many such
   candidate capabilities have been suggested in CDNI drafts, see
   Section 2).  However, advertising capabilities that change highly
   dynamically (e.g. real-time delivery performance metrics, CDN
   resource load, or other highly dynamically changing QoS information)
   should probably not be in scope for the CDNI FCI.  First, out of the
   multitude of possible metrics and capabilities, it is hard to agree
   on a subset and the precise metrics to be used.  Second, and perhaps
   more importantly, it seems not feasible to specify such highly
   dynamically changing capabilities and the corresponding metrics
   within the CDNI charter time-frame.

http://datatracker.ietf.org/doc/draft-sun-ippm-twamp-flowbased
http://tools.ietf.org/html/draft-sun-ippm-twamp-flowbased
  "TWAMP Flow-based Performance Measurement", Lishun Sun, Fang Yu,
  Xiangyang Gong, 8-Feb-13

 
   [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay Variation
              Metric for IP Performance Metrics (IPPM)", RFC 3393,
              November 2002.

http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf
http://tools.ietf.org/html/draft-suznjevic-tsvwg-mtd-tcmtf
  "Maximum Tolerable Delays when using Tunneling Compressed Multiplexed
  Traffic Flows", Mirko Suznjevic, Jose Saldana, 12-Dec-12

 
   The study [Claypool_Latency] evaluated players' performance of
   certain tasks while increasing latency, and reported latencies in
   which the performance dropped below 75% of the performance under
   unimpaired network conditions.  While measuring objective performance
   metrics, this method highly underestimates the impact of delays on
   players' QoE.  Further studies accessing a particular game genre

   [TGPP_TR26.944]
              3rd Generation Partnership Project;, "Technical
              Specification Group Services and System Aspects; End-to-
              end multimedia services performance metrics", 3GPP TR
              26.944  version 9.0.0 , 2012.

http://datatracker.ietf.org/doc/draft-tempia-opsawg-p3m
http://tools.ietf.org/html/draft-tempia-opsawg-p3m
  "A packet based method for passive performance monitoring", Alessandro
  Capello, Mauro Cociglio, Luca Castaldelli, Alberto Bonda, 25-Feb-13

 
   [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay Variation
              Metric for IP Performance Metrics (IPPM)", RFC 3393,
              November 2002.

http://datatracker.ietf.org/doc/draft-zahariadis-roll-metrics-composition
http://tools.ietf.org/html/draft-zahariadis-roll-metrics-composition
  "Design Guidelines for Routing Metrics Composition in LLN", Theodore
  Zahariadis, Panagiotis Trakadas, 23-Nov-12

 
   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC2330, May 1998.

http://datatracker.ietf.org/doc/draft-zhang-icnrg-pid-naming-scheme
http://tools.ietf.org/html/draft-zhang-icnrg-pid-naming-scheme
  "PID: A Generic Naming Schema for Information-centric Network", Xinwen
  Zhang, Ravi Ravindran, Haiyong Xie, Guoqiang Wang, 20-Feb-13

 
   The P:I:D naming lends itself to allow consuming and producing
   applications to choose naming semantic that meets requirements in
   terms of reliability, security or performance metrics.  The naming
   format follows a P:I:D format, where I identifies the named entity
   with a local or global scope, and D is the authority which could
   resolve the entity's location(s), and P securely binds the content
   object to I. For content routing I:D is the relevant portion.  As I
   could be a hierarchical or flat name, several options for content
   routing are possible.  In one case separate ICN domains can be built
   that are optimized to deal with either flat or hierarchical, where
   name-resolution service allows the request to be directed to the
   appropriate domain criterion determined by the publisher, consumer or
   based on certain routing policies.  In another case, a content
   routing domain can be built where the name-resolution infrastructure
   is enabled to deal with both flat and hierarchical names, where
   irrespective of the type of naming, a separate locator space exists
   to resolve the content name to its location(s).

http://datatracker.ietf.org/doc/draft-zheng-l3vpn-pm-analysis
http://tools.ietf.org/html/draft-zheng-l3vpn-pm-analysis
  "Performance Monitoring Analysis for L3VPN", Lianshu Zheng, Zhenbin Li,
  Bhavani Parise, 17-Apr-13

 
   Level 3 Virtual Private Network (L3VPN) [RFC4364]service is widely
   deployed in the production network.  It is deployed to provide
   enterprise interconnection, Voice over IP (VoIP), video, mobile, etc.
   services.  Most of these services are sensitive to the packet loss
   and delay.  The capability to measure and monitor performance metrics
   for packet loss, delay, as well as related metrics is essential for
   SLA.  The requirement for SLA measurement for MPLS networks has been
   documented in [RFC4377].

http://datatracker.ietf.org/doc/draft-zong-integration-example
http://tools.ietf.org/html/draft-zong-integration-example
  "Integration Examples of DECADE System", Ning Zong, Xiaohui Chen,
  Zhigang Huang, Lijiang Chen, Hongqiang Liu, 16-Feb-13

 
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Native Application Client  . . . . . . . . . . . . . . . .  6
     2.2.  INS Server . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  INS Client . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.4.  INS Operations . . . . . . . . . . . . . . . . . . . . . .  6
     2.5.  INS System . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.6.  INS Client API . . . . . . . . . . . . . . . . . . . . . .  6
     2.7.  INS-enabled Application Client . . . . . . . . . . . . . .  6
     2.8.  INS Service Provider . . . . . . . . . . . . . . . . . . .  6
     2.9.  INS Portal . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  INS Client API . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Integration of P2P File Sharing and INS System . . . . . . . .  7
     4.1.  Integration Architecture . . . . . . . . . . . . . . . . .  7
       4.1.1.  Message Flow . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Concluding Remarks . . . . . . . . . . . . . . . . . . . . 10
   5.  Integration of P2P Live Streaming and INS System . . . . . . . 10
     5.1.  Integration Architecture . . . . . . . . . . . . . . . . . 10
       5.1.1.  Data Access Messages . . . . . . . . . . . . . . . . . 10
       5.1.2.  Control Messages . . . . . . . . . . . . . . . . . . . 10
     5.2.  Design Considerations  . . . . . . . . . . . . . . . . . . 11
       5.2.1.  Improve Efficiency for Each Connection . . . . . . . . 11
       5.2.2.  Reduce Control Latency . . . . . . . . . . . . . . . . 11
   6.  Integration of ALTO and INS System for File Distribution . . . 12
     6.1.  Architecture . . . . . . . . . . . . . . . . . . . . . . . 12
       6.1.1.  CP Uploading Procedure . . . . . . . . . . . . . . . . 13
       6.1.2.  End User Downloading Procedure . . . . . . . . . . . . 14
   7.  Test Environment and Settings  . . . . . . . . . . . . . . . . 15
     7.1.  Test Settings  . . . . . . . . . . . . . . . . . . . . . . 15
     7.2.  Test Environment for P2P Live Streaming Example  . . . . . 15
       7.2.1.  INS Server . . . . . . . . . . . . . . . . . . . . . . 16
       7.2.2.  P2P Live Streaming Client  . . . . . . . . . . . . . . 16
       7.2.3.  Tracker  . . . . . . . . . . . . . . . . . . . . . . . 16
       7.2.4.  Streaming Source Server  . . . . . . . . . . . . . . . 16
       7.2.5.  Test Controller  . . . . . . . . . . . . . . . . . . . 16
     7.3.  Test Environment for P2P File Sharing Example  . . . . . . 17
       7.3.1.  INS Server . . . . . . . . . . . . . . . . . . . . . . 17
       7.3.2.  Vuze Client  . . . . . . . . . . . . . . . . . . . . . 17
       7.3.3.  Tracker  . . . . . . . . . . . . . . . . . . . . . . . 17
       7.3.4.  Test Controller  . . . . . . . . . . . . . . . . . . . 17
       7.3.5.  HTTP Server  . . . . . . . . . . . . . . . . . . . . . 18
       7.3.6.  PlanetLab Manager  . . . . . . . . . . . . . . . . . . 18
     7.4.  Test Environment for Combined ALTO and INS File
           Distribution System  . . . . . . . . . . . . . . . . . . . 18
   8.  Performance Analysis . . . . . . . . . . . . . . . . . . . . . 18
     8.1.  Performance Metrics  . . . . . . . . . . . . . . . . . . . 18

8.1.  Performance Metrics


--------------020803030204060209020406
Content-Type: application/octet-stream;
 name="c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="c"

ZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItYnVyc3QtZ2FwLWRpc2NhcmQtMTQudHh0DQpk
cmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1idXJzdC1nYXAtbG9zcy0xMi50eHQNCmRyYWZ0
LWlldGYteHJibG9jay1ydGNwLXhyLWRlY29kYWJpbGl0eS0xMS50eHQNCmRyYWZ0LWlldGYt
eHJibG9jay1ydGNwLXhyLWRpc2NhcmQtMTQudHh0DQpkcmFmdC1pZXRmLXhyYmxvY2stcnRj
cC14ci1kaXNjYXJkLXJsZS1tZXRyaWNzLTA1LnR4dA0KZHJhZnQtaWV0Zi14cmJsb2NrLXJ0
Y3AteHItamItMTEudHh0DQpkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1sb3NzLWNvbmNl
YWwtMDUudHh0DQpkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1xb2UtMDcudHh0DQpkcmFm
dC1pZXRmLXhyYmxvY2stcnRjcC14ci1zdW1tYXJ5LXN0YXQtMTEudHh0DQpkcmFmdC1pZXRm
LXhyYmxvY2stcnRjcC14ci1zeW5jaHJvbml6YXRpb24tMDQudHh0DQpkcmFmdC1pb250YS1t
dWx0aXBhcnR5LW1ldHJpY3MtZnJhbWV3b3JrLTAwLnR4dA0KZHJhZnQtaW9udGEtc3BhdGlh
bC1tZXRyaWNzLW11bHRpcGFydHktc2VydmljZXMtMDEudHh0DQpkcmFmdC1tb3J0b24taXBw
bS0yNjc5LWJpcy0wMi50eHQNCmRyYWZ0LXlvdXJ0Y2hlbmtvLWNpc2NvLWllcy0wNS50eHQN
Cg==
--------------020803030204060209020406
Content-Type: application/octet-stream;
 name="a"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="a"

ZHJhZnQtYXNod29vZC1udm8zLW9wZXJhdGlvbmFsLXJlcXVpcmVtZW50LTAyLnR4dA0KZHJh
ZnQtYmFnbnVsby1pcHBtLW5ldy1yZWdpc3RyeS0wMC50eHQNCmRyYWZ0LWJhZ251bG8taXBw
bS1uZXctcmVnaXN0cnktaW5kZXBlbmRlbnQtMDAudHh0DQpkcmFmdC1ib3JtYW5uLWludGFy
ZWEtYWxmaS0wMy50eHQNCmRyYWZ0LWJvdWNhZGFpci1jb25uZWN0aXZpdHktcHJvdmlzaW9u
aW5nLXByb2ZpbGUtMDIudHh0DQpkcmFmdC1ib3VjYWRhaXItbG1hcC1jb25zaWRlcmF0aW9u
cy0wMC50eHQNCmRyYWZ0LWJvdWNhZGFpci1uZXR3b3JrLWF1dG9tYXRpb24tcmVxdWlyZW1l
bnRzLTAwLnR4dA0KZHJhZnQtY2hlbi1jb2xvcmluZy1iYXNlZC1pcGZwbS1mcmFtZXdvcmst
MDEudHh0DQpkcmFmdC1kaG9keS1wY2UtcGNlcC1zZXJ2aWNlLWF3YXJlLTA1LnR4dA0KZHJh
ZnQtZG9uZy1sM3Zwbi1wbS1mcmFtZXdvcmstMDEudHh0DQpkcmFmdC1lYXJkbGV5LWxtYXAt
ZnJhbWV3b3JrLTAxLnR4dA0KZHJhZnQtZWFyZGxleS1sbWFwLXRlcm1pbm9sb2d5LTAxLnR4
dA0KZHJhZnQtZmFuLW9wc2F3Zy1wYWNrZXQtbG9zcy0wMC50eHQNCmRyYWZ0LWlhYi1jYy13
b3Jrc2hvcC1yZXBvcnQtMDEudHh0DQpkcmFmdC1pZXRmLWFsdG8tZGVwbG95bWVudHMtMDYu
dHh0DQpkcmFmdC1pZXRmLWFsdG8tcHJvdG9jb2wtMTYudHh0DQpkcmFmdC1pZXRmLWJtd2ct
Y2EtYmVuY2gtbWV0aC0wNC50eHQNCmRyYWZ0LWlldGYtaXBwbS1yYXRlLXByb2JsZW0tMDMu
dHh0DQpkcmFmdC1pZXRmLWlwcG0tdGVzdHBsYW4tcmZjMjY4MC0wMi50eHQNCmRyYWZ0LWll
dGYtbWFuZXQtc21mLW1pYi0wNy50eHQNCmRyYWZ0LWlldGYtbnZvMy1mcmFtZXdvcmstMDIu
dHh0DQpkcmFmdC1pZXRmLW9wc2F3Zy1vYW0tb3ZlcnZpZXctMDgudHh0DQpkcmFmdC1pZXRm
LXBjZS1wY2VwLXNlcnZpY2UtYXdhcmUtMDAudHh0DQpkcmFmdC1pZXRmLXBwc3AtcGVlci1w
cm90b2NvbC0wNi50eHQNCmRyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0wNi50eHQNCmRy
YWZ0LWlldGYteHJibG9jay1ydGNwLXhyLWJ1cnN0LWdhcC1kaXNjYXJkLTE0LnR4dA0KZHJh
ZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItYnVyc3QtZ2FwLWxvc3MtMTIudHh0DQpkcmFmdC1p
ZXRmLXhyYmxvY2stcnRjcC14ci1kZWNvZGFiaWxpdHktMTEudHh0DQpkcmFmdC1pZXRmLXhy
YmxvY2stcnRjcC14ci1kaXNjYXJkLTE0LnR4dA0KZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3At
eHItZGlzY2FyZC1ybGUtbWV0cmljcy0wNS50eHQNCmRyYWZ0LWlldGYteHJibG9jay1ydGNw
LXhyLWpiLTExLnR4dA0KZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItbG9zcy1jb25jZWFs
LTA1LnR4dA0KZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lLTA3LnR4dA0KZHJhZnQt
aWV0Zi14cmJsb2NrLXJ0Y3AteHItc3VtbWFyeS1zdGF0LTExLnR4dA0KZHJhZnQtaWV0Zi14
cmJsb2NrLXJ0Y3AteHItc3luY2hyb25pemF0aW9uLTA0LnR4dA0KZHJhZnQtaW9udGEtbXVs
dGlwYXJ0eS1tZXRyaWNzLWZyYW1ld29yay0wMC50eHQNCmRyYWZ0LWlvbnRhLXNwYXRpYWwt
bWV0cmljcy1tdWx0aXBhcnR5LXNlcnZpY2VzLTAxLnR4dA0KZHJhZnQta2VyYW5lbi1pcHY2
ZGF5LW1lYXN1cmVtZW50cy0wNC50eHQNCmRyYWZ0LWtvLWlwcG0tc3RyZWFtaW5nLXBlcmZv
cm1hbmNlLTAwLnR4dA0KZHJhZnQtbGVpd20tYXZ0Y29yZS1tcHJ0cC1yYS0wMC50eHQNCmRy
YWZ0LWxpbnNuZXItbG1hcC11c2UtY2FzZXMtMDIudHh0DQpkcmFmdC1tYXRoaXMtaXBwbS1t
b2RlbC1iYXNlZC1tZXRyaWNzLTAxLnR4dA0KZHJhZnQtbW9ydG9uLWlwcG0tMjMzMC11cGRh
dGUtMDEudHh0DQpkcmFmdC1tb3J0b24taXBwbS0yNjc5LWJpcy0wMi50eHQNCmRyYWZ0LW1v
cnRvbi1pcHBtLTI2ODAtYmlzLTAwLnR4dA0KZHJhZnQtbW9ydG9uLWlwcG0tbG1hcC1wYXRo
LTAxLnR4dA0KZHJhZnQtbmFuZGFrdW1hci1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzLTAy
LnR4dA0KZHJhZnQtbmd1eWVuLW1hbmV0LWVjZHMtbWliLTAyLnR4dA0KZHJhZnQtbmljaG9s
cy10c3Z3Zy1jb2RlbC0wMS50eHQNCmRyYWZ0LXJldGFuYS1ydGd3Zy1lYWNwLTAxLnR4dA0K
ZHJhZnQtc2F2YWdlLWVpZ3JwLTAwLnR4dA0KZHJhZnQtc3BwLWNkbmktcnItZm9vdC1jYXAt
c2VtYW50aWNzLTA0LnR4dA0KZHJhZnQtc3VuLWlwcG0tdHdhbXAtZmxvd2Jhc2VkLTAwLnR4
dA0KZHJhZnQtc3V6bmpldmljLXRzdndnLW10ZC10Y210Zi0wMC50eHQNCmRyYWZ0LXRlbXBp
YS1vcHNhd2ctcDNtLTAzLnR4dA0KZHJhZnQteW91cnRjaGVua28tY2lzY28taWVzLTA1LnR4
dA0KZHJhZnQtemFoYXJpYWRpcy1yb2xsLW1ldHJpY3MtY29tcG9zaXRpb24tMDQudHh0DQpk
cmFmdC16aGFuZy1pY25yZy1waWQtbmFtaW5nLXNjaGVtZS0wMi50eHQNCmRyYWZ0LXpoZW5n
LWwzdnBuLXBtLWFuYWx5c2lzLTAxLnR4dA0KZHJhZnQtem9uZy1pbnRlZ3JhdGlvbi1leGFt
cGxlLTAwLnR4dA0K
--------------020803030204060209020406
Content-Type: application/octet-stream;
 name="d"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="d"

ZHJhZnQtYXNod29vZC1udm8zLW9wZXJhdGlvbmFsLXJlcXVpcmVtZW50LTAyLnR4dA0KZHJh
ZnQtYmFnbnVsby1pcHBtLW5ldy1yZWdpc3RyeS0wMC50eHQNCmRyYWZ0LWJhZ251bG8taXBw
bS1uZXctcmVnaXN0cnktaW5kZXBlbmRlbnQtMDAudHh0DQpkcmFmdC1ib3JtYW5uLWludGFy
ZWEtYWxmaS0wMy50eHQNCmRyYWZ0LWJvdWNhZGFpci1jb25uZWN0aXZpdHktcHJvdmlzaW9u
aW5nLXByb2ZpbGUtMDIudHh0DQpkcmFmdC1ib3VjYWRhaXItbG1hcC1jb25zaWRlcmF0aW9u
cy0wMC50eHQNCmRyYWZ0LWJvdWNhZGFpci1uZXR3b3JrLWF1dG9tYXRpb24tcmVxdWlyZW1l
bnRzLTAwLnR4dA0KZHJhZnQtY2hlbi1jb2xvcmluZy1iYXNlZC1pcGZwbS1mcmFtZXdvcmst
MDEudHh0DQpkcmFmdC1kaG9keS1wY2UtcGNlcC1zZXJ2aWNlLWF3YXJlLTA1LnR4dA0KZHJh
ZnQtZG9uZy1sM3Zwbi1wbS1mcmFtZXdvcmstMDEudHh0DQpkcmFmdC1lYXJkbGV5LWxtYXAt
ZnJhbWV3b3JrLTAxLnR4dA0KZHJhZnQtZWFyZGxleS1sbWFwLXRlcm1pbm9sb2d5LTAxLnR4
dA0KZHJhZnQtZmFuLW9wc2F3Zy1wYWNrZXQtbG9zcy0wMC50eHQNCmRyYWZ0LWlhYi1jYy13
b3Jrc2hvcC1yZXBvcnQtMDEudHh0DQpkcmFmdC1pZXRmLWFsdG8tZGVwbG95bWVudHMtMDYu
dHh0DQpkcmFmdC1pZXRmLWFsdG8tcHJvdG9jb2wtMTYudHh0DQpkcmFmdC1pZXRmLWJtd2ct
Y2EtYmVuY2gtbWV0aC0wNC50eHQNCmRyYWZ0LWlldGYtaXBwbS1yYXRlLXByb2JsZW0tMDMu
dHh0DQpkcmFmdC1pZXRmLWlwcG0tdGVzdHBsYW4tcmZjMjY4MC0wMi50eHQNCmRyYWZ0LWll
dGYtbWFuZXQtc21mLW1pYi0wNy50eHQNCmRyYWZ0LWlldGYtbnZvMy1mcmFtZXdvcmstMDIu
dHh0DQpkcmFmdC1pZXRmLW9wc2F3Zy1vYW0tb3ZlcnZpZXctMDgudHh0DQpkcmFmdC1pZXRm
LXBjZS1wY2VwLXNlcnZpY2UtYXdhcmUtMDAudHh0DQpkcmFmdC1pZXRmLXBwc3AtcGVlci1w
cm90b2NvbC0wNi50eHQNCmRyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0wNi50eHQNCmRy
YWZ0LWtlcmFuZW4taXB2NmRheS1tZWFzdXJlbWVudHMtMDQudHh0DQpkcmFmdC1rby1pcHBt
LXN0cmVhbWluZy1wZXJmb3JtYW5jZS0wMC50eHQNCmRyYWZ0LWxlaXdtLWF2dGNvcmUtbXBy
dHAtcmEtMDAudHh0DQpkcmFmdC1saW5zbmVyLWxtYXAtdXNlLWNhc2VzLTAyLnR4dA0KZHJh
ZnQtbWF0aGlzLWlwcG0tbW9kZWwtYmFzZWQtbWV0cmljcy0wMS50eHQNCmRyYWZ0LW1vcnRv
bi1pcHBtLTIzMzAtdXBkYXRlLTAxLnR4dA0KZHJhZnQtbW9ydG9uLWlwcG0tMjY4MC1iaXMt
MDAudHh0DQpkcmFmdC1tb3J0b24taXBwbS1sbWFwLXBhdGgtMDEudHh0DQpkcmFmdC1uYW5k
YWt1bWFyLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMDIudHh0DQpkcmFmdC1uZ3V5ZW4t
bWFuZXQtZWNkcy1taWItMDIudHh0DQpkcmFmdC1uaWNob2xzLXRzdndnLWNvZGVsLTAxLnR4
dA0KZHJhZnQtcmV0YW5hLXJ0Z3dnLWVhY3AtMDEudHh0DQpkcmFmdC1zYXZhZ2UtZWlncnAt
MDAudHh0DQpkcmFmdC1zcHAtY2RuaS1yci1mb290LWNhcC1zZW1hbnRpY3MtMDQudHh0DQpk
cmFmdC1zdW4taXBwbS10d2FtcC1mbG93YmFzZWQtMDAudHh0DQpkcmFmdC1zdXpuamV2aWMt
dHN2d2ctbXRkLXRjbXRmLTAwLnR4dA0KZHJhZnQtdGVtcGlhLW9wc2F3Zy1wM20tMDMudHh0
DQpkcmFmdC16YWhhcmlhZGlzLXJvbGwtbWV0cmljcy1jb21wb3NpdGlvbi0wNC50eHQNCmRy
YWZ0LXpoYW5nLWljbnJnLXBpZC1uYW1pbmctc2NoZW1lLTAyLnR4dA0KZHJhZnQtemhlbmct
bDN2cG4tcG0tYW5hbHlzaXMtMDEudHh0DQpkcmFmdC16b25nLWludGVncmF0aW9uLWV4YW1w
bGUtMDAudHh0DQo=
--------------020803030204060209020406
Content-Type: application/octet-stream;
 name="b"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="b"

UkZDIDYzOTANClJGQzYzOTANCg==
--------------020803030204060209020406--

From acmorton@att.com  Thu May 23 17:14:40 2013
Return-Path: <acmorton@att.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C615921F8EA4 for <pm-dir@ietfa.amsl.com>; Thu, 23 May 2013 17:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.373
X-Spam-Level: 
X-Spam-Status: No, score=-106.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6N03dF+S+3Y for <pm-dir@ietfa.amsl.com>; Thu, 23 May 2013 17:14:34 -0700 (PDT)
Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 79AC721F8CEC for <pm-dir@ietf.org>; Thu, 23 May 2013 17:14:34 -0700 (PDT)
Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 50B541207CA; Thu, 23 May 2013 20:14:33 -0400 (EDT)
Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-blue.research.att.com (Postfix) with ESMTP id E7854F0370; Thu, 23 May 2013 20:14:33 -0400 (EDT)
Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Thu, 23 May 2013 20:14:33 -0400
From: "MORTON JR., ALFRED C (AL)" <acmorton@att.com>
To: Benoit Claise <bclaise@cisco.com>, "pm-dir@ietf.org" <pm-dir@ietf.org>
Date: Thu, 23 May 2013 20:14:32 -0400
Thread-Topic: [pm-dir] Fwd: Re:  Performance metrics doctors generated email
Thread-Index: Ac5YBOloeRfMk1YUSX2vIqHdOZyQHQADSNLF
Message-ID: <F1312FAF1A1E624DA0972D1C9A91379A1C9F20EB12@njfpsrvexg7.research.att.com>
References: <8C48B86A895913448548E6D15DA7553B8F4454@xmb-rcd-x09.cisco.com>, <519E8E13.9090002@cisco.com>
In-Reply-To: <519E8E13.9090002@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Fred Baker <Fred@cisco.com>
Subject: Re: [pm-dir] Fwd: Re:  Performance metrics doctors generated email
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2013 00:14:40 -0000

Nice, a few paragraphs from the draft provide enough context=20
to see if the use of "performance metric" is something the Directorate
should consider.  Thanks Fred.

As I've said in the past, if we were running Fred's script weekly,
we would need to consider only on the diffs from last week,
so we can add new reviewer assignments.  Since this benefits me
the most, I'd be willing to add the differencing lines to the script...

Without carping on too long here, we have quite a few outstanding assignmen=
ts
and drafts needing volunteers to review:
https://docs.google.com/spreadsheet/ccc?key=3D0AmKrqWIOBsprdGZqMnB6dmx5bFJv=
VUhta3VLSjl3SkE#gid=3D0

regards,
Al

________________________________________
From: pm-dir-bounces@ietf.org [pm-dir-bounces@ietf.org] On Behalf Of Benoit=
 Claise [bclaise@cisco.com]
Sent: Thursday, May 23, 2013 5:45 PM
To: pm-dir@ietf.org
Cc: Fred Baker
Subject: [pm-dir] Fwd: Re:  Performance metrics doctors generated email

Dear pm-dir,

Some more help from Fred.
All the drafts containing "performance metrics", along with the specific
section.
That should help identifying the drafts that are important to review.

Regards, Benoit=

From bclaise@cisco.com  Fri May 24 01:34:08 2013
Return-Path: <bclaise@cisco.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6916021F96BE for <pm-dir@ietfa.amsl.com>; Fri, 24 May 2013 01:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.127
X-Spam-Level: 
X-Spam-Status: No, score=-10.127 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZmmCZG9ObOy for <pm-dir@ietfa.amsl.com>; Fri, 24 May 2013 01:34:04 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0549521F96C1 for <pm-dir@ietf.org>; Fri, 24 May 2013 01:34:00 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4O8XwpQ013985; Fri, 24 May 2013 10:33:58 +0200 (CEST)
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4O8WWLP013071; Fri, 24 May 2013 10:32:53 +0200 (CEST)
Message-ID: <519F25A0.70502@cisco.com>
Date: Fri, 24 May 2013 10:32:32 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Nguyen, James H CIV USARMY CERDEC (US)" <james.h.nguyen4.civ@mail.mil>
References: <201305231512.r4NFCMN4006908@irp-view13.cisco.com> <3DC26342A93F204C804384C87DDBECBF3DADF508@ucolhp9k.easf.csd.disa.mil>
In-Reply-To: <3DC26342A93F204C804384C87DDBECBF3DADF508@ucolhp9k.easf.csd.disa.mil>
Content-Type: multipart/alternative; boundary="------------020705050308060505020007"
Cc: "draft-nguyen-manet-ecds-mib@tools.ietf.org" <draft-nguyen-manet-ecds-mib@tools.ietf.org>, draft-ietf-manet-smf-mib@tools.ietf.org, Fred Baker <fred@cisco.com>, me <bclaise@cisco.com>, Adrian Farrel <adrian@olddog.co.uk>, "pm-dir@ietf.org" <pm-dir@ietf.org>
Subject: Re: [pm-dir] draft-nguyen-manet-ecds-mib and Performance Metrics (UNCLASSIFIED)
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2013 08:34:08 -0000

This is a multi-part message in MIME format.
--------------020705050308060505020007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi James, draft-ietf-manet-smf-mib authors,

Agreed, RFC 6390 doesn't apply here.
See the email exchange regarding draft-ietf-manet-olsrv2-mib below, 
which I reviewed part of the performance metric directorate.
Like Ulrich did for draft-ietf-manet-olsrv2-mib, it might better to use 
"performance information" instead of "performance metrics" in your draft.

    Benoit,

    thank you very much for this review. I agree that using the term
    "performance information" instead of "performance metrics" is a good
    idea. We will make the change.

    Best regards
    Ulrich

    On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise<bclaise@cisco.com>  wrote:

    Dear all,

    I reviewedhttp://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, from a
    performance metric directorate point of view.

    This draft doesn't contain any reference to RFC6390, but contains
    "performance metric". Hence this review was triggered. For details about the
    directorate, see
    http://www.ietf.org/iesg/directorate/performance-metrics.html


    Definition of Managed Objects for the  Optimized Link State Routing
    Protocol version 2

    Abstract

        This document defines the Management Information Base (MIB) module
        for configuring and managing the Optimized Link State Routing
        protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
        into state information, performance metrics, and notifications.  This
        additional state and performance information is useful to
        troubleshoot problems and performance issues of the routing protocol.
        Different levels of compliance allow implementers to use smaller
        subsets of all defined objects, allowing for this MIB module to be
        deployed on more constrained routers.


    Basically, all performance metrics come from this table:

        o  olsrv2InterfacePerfTable - records performance counters for each
           active OLSRv2 interface on this device. selected path to each
           destination for which any such path is known.  This table has
           AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed via
           nhdpIfIndex from the NHDP-MIB.

    NHDP-MIB is RFC 6779:
        NhdpInterfacePerfEntry ::=
           SEQUENCE {
              nhdpIfHelloMessageXmits
                 Counter32,
              nhdpIfHelloMessageRecvd
                 Counter32,
              nhdpIfHelloMessageXmitAccumulatedSize
                 Counter64,
              nhdpIfHelloMessageRecvdAccumulatedSize
                 Counter64,
              nhdpIfHelloMessageTriggeredXmits
                 Counter32,
              nhdpIfHelloMessagePeriodicXmits
                 Counter32,
              nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
                 Counter32,
              nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
                 Counter32,
              nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
                 Counter32
           }


    This draft contains similar objects in olsrv2InterfacePerfTable :

         Olsrv2InterfacePerfEntry ::=
            SEQUENCE {
               olsrv2IfTcMessageXmits
                  Counter32,
               olsrv2IfTcMessageRecvd
                  Counter32,
               olsrv2IfTcMessageXmitAccumulatedSize
                  Counter64,
               olsrv2IfTcMessageRecvdAccumulatedSize
                  Counter64,
               olsrv2IfTcMessageTriggeredXmits
                  Counter32,
               olsrv2IfTcMessagePeriodicXmits
                  Counter32,
               olsrv2IfTcMessageForwardedXmits
                  Counter32,
               olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
                  Counter32
            }


    Personally, I don't believe that those objects should be subject to the RFC
    6390 template definition. (Performance Metric Definition Template, section
    5.4.4, RFC 6390).
    First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was not
    subject to it
    Second reason: these objects are not really performance metrics, but mainly
    basic monitoring objects.

    Since RFC 6779 uses the term performance information (in the abstract), I
    would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not
    the "performance metric". That would avoid some confusion. However, keeping
    the olsrv2InterfacePerfTable OID name is perfectly fine, for consistency
    reason with RFC 6779.

    Regards, Benoit


Regards, Benoit
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Fred,
>
> There are two counters that are defined for performance metrics.  Please see
> below.  As we stated it in Section 9 "Applicability Statement," ECDS-MIB is
> an extension of SMF-MIB.  Thus, ECDS-MIB's inherited SMF-MIB's performance
> metrics.
>
> As I can see, ECDS-MIB does apply 6390's (i), (ii), (iii), and somewhat
> (iv).  Please let me know if you have any suggestion to improve the draft.
>
>
>        (i) the degree to which its absence would cause significant loss
>        of information on the behavior or performance of the application
>        or system being measured
>
>        (ii) the correlation between the Performance Metric, the QoS, and
>        the QoE delivered to the user (person or other application)
>
>        (iii) the degree to which the Performance Metric is able to
>        support the identification and location of problems affecting
>        service quality
>
>        (iv) the requirement to develop policies (Service Level Agreement,
>        and potentially Service Level Contract) based on the Performance
>        Metric
>
>
>
> --
>   -- E-CDS Performance Group
>   --
>
>   ecdsPerformanceGroup OBJECT IDENTIFIER ::= { ecdsMIBObjects 3 }
>
>   ecdsInEcdsChange OBJECT-TYPE
>           SYNTAX          Counter32
>           MAX-ACCESS      read-only
>           STATUS          current
>           DESCRIPTION
>                   "This object indicates how many times the current
>                    node is configured to be in E-CDS."
>   ::= { ecdsPerformanceGroup 1 }
>
>   ecdsCurrentRtrPriValueChange OBJECT-TYPE
>           SYNTAX          Counter32
>           MAX-ACCESS      read-only
>           STATUS          current
>           DESCRIPTION
>                   "This object indicates how many times the Router
>                    Priority of the current node has been changed."
>   ::= { ecdsPerformanceGroup 2 }
>
>
>
> James Nguyen
> US Army CERDEC S&TCD
> Email: james.h.nguyen4.civ@mail.mil
> Phone:  443-395-5628
>
>
> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]
> Sent: Thursday, May 23, 2013 11:12 AM
> To: draft-nguyen-manet-ecds-mib@tools.ietf.org
> Cc: bclaise@cisco.com
> Subject: draft-nguyen-manet-ecds-mib and Performance Metrics
>
> Hi:
>
> I have a question for you. Your document mentions performance metrics.
> Would you kindly take a look at RFC 6390 to see if any of its considerations
> apply to it?  "No" is an acceptable response, of course; the point is to ask
> the question.
>
> 6390 Guidelines for Considering New Performance Metric Development. A.
>       Clark, B. Claise. October 2011. (Format: TXT=49930 bytes) (Also
>       BCP0170) (Status: BEST CURRENT PRACTICE)
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>


--------------020705050308060505020007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi James, draft-ietf-manet-smf-mib
      authors,<br>
      <br>
      Agreed, RFC 6390 doesn't apply here.<br>
      See the email exchange regarding draft-ietf-manet-olsrv2-mib
      below, which I reviewed part of the performance metric
      directorate.<br>
      Like Ulrich did for draft-ietf-manet-olsrv2-mib, it might better
      to use "performance information" instead of "performance metrics"
      in your draft.<br>
      <blockquote>
        <pre wrap="">Benoit,

thank you very much for this review. I agree that using the term
"performance information" instead of "performance metrics" is a good
idea. We will make the change.

Best regards
Ulrich

On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise <a class="moz-txt-link-rfc2396E" href="mailto:bclaise@cisco.com">&lt;bclaise@cisco.com&gt;</a> wrote:
</pre>
        <pre wrap="">Dear all,

I reviewed <a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06">http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06</a>, from a
performance metric directorate point of view.

This draft doesn't contain any reference to RFC6390, but contains
"performance metric". Hence this review was triggered. For details about the
directorate, see
<a class="moz-txt-link-freetext" href="http://www.ietf.org/iesg/directorate/performance-metrics.html">http://www.ietf.org/iesg/directorate/performance-metrics.html</a>


Definition of Managed Objects for the  Optimized Link State Routing
Protocol version 2

Abstract

   This document defines the Management Information Base (MIB) module
   for configuring and managing the Optimized Link State Routing
   protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
   into state information, performance metrics, and notifications.  This
   additional state and performance information is useful to
   troubleshoot problems and performance issues of the routing protocol.
   Different levels of compliance allow implementers to use smaller
   subsets of all defined objects, allowing for this MIB module to be
   deployed on more constrained routers.


Basically, all performance metrics come from this table:

   o  olsrv2InterfacePerfTable - records performance counters for each
      active OLSRv2 interface on this device. selected path to each
      destination for which any such path is known.  This table has
      AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed via
      nhdpIfIndex from the NHDP-MIB.

NHDP-MIB is RFC 6779:
   NhdpInterfacePerfEntry ::=
      SEQUENCE {
         nhdpIfHelloMessageXmits
            Counter32,
         nhdpIfHelloMessageRecvd
            Counter32,
         nhdpIfHelloMessageXmitAccumulatedSize
            Counter64,
         nhdpIfHelloMessageRecvdAccumulatedSize
            Counter64,
         nhdpIfHelloMessageTriggeredXmits
            Counter32,
         nhdpIfHelloMessagePeriodicXmits
            Counter32,
         nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
            Counter32,
         nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
            Counter32,
         nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
            Counter32
      }


This draft contains similar objects in olsrv2InterfacePerfTable :

    Olsrv2InterfacePerfEntry ::=
       SEQUENCE {
          olsrv2IfTcMessageXmits
             Counter32,
          olsrv2IfTcMessageRecvd
             Counter32,
          olsrv2IfTcMessageXmitAccumulatedSize
             Counter64,
          olsrv2IfTcMessageRecvdAccumulatedSize
             Counter64,
          olsrv2IfTcMessageTriggeredXmits
             Counter32,
          olsrv2IfTcMessagePeriodicXmits
             Counter32,
          olsrv2IfTcMessageForwardedXmits
             Counter32,
          olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
             Counter32
       }


Personally, I don't believe that those objects should be subject to the RFC
6390 template definition. (Performance Metric Definition Template, section
5.4.4, RFC 6390).
First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was not
subject to it
Second reason: these objects are not really performance metrics, but mainly
basic monitoring objects.

Since RFC 6779 uses the term performance information (in the abstract), I
would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not
the "performance metric". That would avoid some confusion. However, keeping
the olsrv2InterfacePerfTable OID name is perfectly fine, for consistency
reason with RFC 6779.

Regards, Benoit

</pre>
      </blockquote>
      <br>
      Regards, Benoit<br>
    </div>
    <blockquote
cite="mid:3DC26342A93F204C804384C87DDBECBF3DADF508@ucolhp9k.easf.csd.disa.mil"
      type="cite">
      <pre wrap="">Classification: UNCLASSIFIED
Caveats: NONE

Fred,

There are two counters that are defined for performance metrics.  Please see
below.  As we stated it in Section 9 "Applicability Statement," ECDS-MIB is
an extension of SMF-MIB.  Thus, ECDS-MIB's inherited SMF-MIB's performance
metrics.  

As I can see, ECDS-MIB does apply 6390's (i), (ii), (iii), and somewhat
(iv).  Please let me know if you have any suggestion to improve the draft.


      (i) the degree to which its absence would cause significant loss
      of information on the behavior or performance of the application
      or system being measured

      (ii) the correlation between the Performance Metric, the QoS, and
      the QoE delivered to the user (person or other application)

      (iii) the degree to which the Performance Metric is able to
      support the identification and location of problems affecting
      service quality

      (iv) the requirement to develop policies (Service Level Agreement,
      and potentially Service Level Contract) based on the Performance
      Metric



--
 -- E-CDS Performance Group
 --

 ecdsPerformanceGroup OBJECT IDENTIFIER ::= { ecdsMIBObjects 3 }

 ecdsInEcdsChange OBJECT-TYPE
         SYNTAX          Counter32
         MAX-ACCESS      read-only
         STATUS          current
         DESCRIPTION
                 "This object indicates how many times the current
                  node is configured to be in E-CDS."
 ::= { ecdsPerformanceGroup 1 }

 ecdsCurrentRtrPriValueChange OBJECT-TYPE
         SYNTAX          Counter32
         MAX-ACCESS      read-only
         STATUS          current
         DESCRIPTION
                 "This object indicates how many times the Router
                  Priority of the current node has been changed."
 ::= { ecdsPerformanceGroup 2 }



James Nguyen
US Army CERDEC S&amp;TCD
Email: <a class="moz-txt-link-abbreviated" href="mailto:james.h.nguyen4.civ@mail.mil">james.h.nguyen4.civ@mail.mil</a>
Phone:  443-395-5628


-----Original Message-----
From: Fred Baker [<a class="moz-txt-link-freetext" href="mailto:fred@cisco.com">mailto:fred@cisco.com</a>] 
Sent: Thursday, May 23, 2013 11:12 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:draft-nguyen-manet-ecds-mib@tools.ietf.org">draft-nguyen-manet-ecds-mib@tools.ietf.org</a>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:bclaise@cisco.com">bclaise@cisco.com</a>
Subject: draft-nguyen-manet-ecds-mib and Performance Metrics

Hi:

I have a question for you. Your document mentions performance metrics.
Would you kindly take a look at RFC 6390 to see if any of its considerations
apply to it?  "No" is an acceptable response, of course; the point is to ask
the question.

6390 Guidelines for Considering New Performance Metric Development. A.
     Clark, B. Claise. October 2011. (Format: TXT=49930 bytes) (Also
     BCP0170) (Status: BEST CURRENT PRACTICE)


Classification: UNCLASSIFIED
Caveats: NONE


</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------020705050308060505020007--

From dromasca@avaya.com  Fri May 24 01:47:23 2013
Return-Path: <dromasca@avaya.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD55521F9051 for <pm-dir@ietfa.amsl.com>; Fri, 24 May 2013 01:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.432
X-Spam-Level: 
X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLB8SYK92Vma for <pm-dir@ietfa.amsl.com>; Fri, 24 May 2013 01:47:17 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0693A21F96C0 for <pm-dir@ietf.org>; Fri, 24 May 2013 01:47:07 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkYGAGUon1GHCzI1/2dsb2JhbABZgkQjITDCIoEBFnSCIwEBAQEDEhtMDAQCAQgNAQMDAQEBCx0HMhQJCAIEAQ0FCBqHawGdR5wqF41bgREgEQYBBoJtYQOdfIp/gViBN4FxNQ
X-IronPort-AV: E=Sophos;i="4.87,733,1363147200"; d="scan'208,217";a="10528174"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 May 2013 04:47:05 -0400
Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 May 2013 04:42:54 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.02.0328.009; Fri, 24 May 2013 04:47:02 -0400
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Benoit Claise <bclaise@cisco.com>, "pm-dir@ietf.org" <pm-dir@ietf.org>
Thread-Topic: [pm-dir] Fred's script (was: draft-nguyen-manet-ecds-mib and Performance Metrics)
Thread-Index: AQHOWAM740WHBkCpPkOA3isod8rClZkUBKNQ
Date: Fri, 24 May 2013 08:47:03 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA17664C@AZ-FFEXMB04.global.avaya.com>
References: <201305231512.r4NFCMN4006908@irp-view13.cisco.com> <519E8A93.9050601@cisco.com>
In-Reply-To: <519E8A93.9050601@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.46]
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA17664CAZFFEXMB04globala_"
MIME-Version: 1.0
Cc: Fred Baker <Fred@cisco.com>
Subject: Re: [pm-dir] Fred's script (was: draft-nguyen-manet-ecds-mib and	Performance Metrics)
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2013 08:47:23 -0000

--_000_9904FB1B0159DA42B0B887B7FA8119CA17664CAZFFEXMB04globala_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I like the idea, and I have two questions:


-          Is not the way the question is asked too general - especially fo=
r somebody who may be exposed for the first time to RFC 6390? Should we not=
 rather be more specific about what we mean by 'if any of its consideration=
s apply to it?'

-          When is this message sent? At IETFLC - this looks late to me and=
 certainly for authors who were not aware about 6390 previously. If at draf=
t-00 or the first draft that contains references to 'performance metrics' -=
 we need to avoid sending messages at each update.



Regards,



Dan




From: pm-dir-bounces@ietf.org [mailto:pm-dir-bounces@ietf.org] On Behalf Of=
 Benoit Claise
Sent: Friday, May 24, 2013 12:31 AM
To: pm-dir@ietf.org
Cc: Fred Baker
Subject: [pm-dir] Fred's script (was: draft-nguyen-manet-ecds-mib and Perfo=
rmance Metrics)

Dear pm-dir,

Discussing the pm-dir goals with Fred Baker today, Fred quickly compiled a =
script: it sends an email to all draft authors whose draft contains "perfor=
mance metric". The goal is to notify the authors of the RFC 6390 existence
See an example below.

Thanks Fred for helping the performance metric directorate.

Regards, Benoit


-------- Original Message --------
Subject:

draft-nguyen-manet-ecds-mib and Performance Metrics

Date:

Thu, 23 May 2013 08:12:22 -0700 (PDT)

From:

Fred Baker <fred@cisco.com><mailto:fred@cisco.com>

To:

draft-nguyen-manet-ecds-mib@tools.ietf.org<mailto:draft-nguyen-manet-ecds-m=
ib@tools.ietf.org>

CC:

bclaise@cisco.com<mailto:bclaise@cisco.com>



Hi:



I have a question for you. Your document mentions performance metrics.

Would you kindly take a look at RFC 6390 to see if any of its

considerations apply to it?  "No" is an acceptable response, of

course; the point is to ask the question.



6390 Guidelines for Considering New Performance Metric Development. A.

     Clark, B. Claise. October 2011. (Format: TXT=3D49930 bytes) (Also

     BCP0170) (Status: BEST CURRENT PRACTICE)







--_000_9904FB1B0159DA42B0B887B7FA8119CA17664CAZFFEXMB04globala_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	color:black;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:902259200;
	mso-list-type:hybrid;
	mso-list-template-ids:-728449798 52737898 67698691 67698693 67698689 67698=
691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:Arial;}
@list l1
	{mso-list-id:1136217233;
	mso-list-type:hybrid;
	mso-list-template-ids:2105454130 237289200 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:Arial;
	color:#1F497D;}
@list l2
	{mso-list-id:1565946912;
	mso-list-type:hybrid;
	mso-list-template-ids:583968262 67698703 67698713 67698715 67698703 676987=
13 67698715 67698703 67698713 67698715;}
@list l2:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I like the idea, and I ha=
ve two questions:
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<pre style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo3">=
<![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&quot;Cali=
bri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-list:Ign=
ore">-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]><sp=
an dir=3D"LTR"></span><span style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Is not the way the questio=
n is asked too general &#8211; especially for somebody who may be exposed f=
or the first time to RFC 6390? Should we not rather be more specific about =
what we mean </span><span style=3D"font-family:&quot;Calibri&quot;,&quot;sa=
ns-serif&quot;;color:#1F497D">by &#8216;</span><span style=3D"font-family:&=
quot;Calibri&quot;,&quot;sans-serif&quot;">if any of its considerations app=
ly to it?&#8217; <o:p></o:p></span></pre>
<pre style=3D"margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo3">=
<![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&quot;Cali=
bri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-list:Ign=
ore">-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]><sp=
an dir=3D"LTR"></span><span style=3D"font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;">When is this message sent? At IETFLC &#8211; this looks l=
ate to me and certainly for authors who were not aware about 6390 previousl=
y. If at draft-00 or the first draft that contains references to &#8216;per=
formance metrics&#8217; &#8211; we need to avoid sending messages at each u=
pdate. <o:p></o:p></span></pre>
<pre><span style=3D"font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"=
><o:p>&nbsp;</o:p></span></pre>
<pre><span style=3D"font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"=
>Regards,<o:p></o:p></span></pre>
<pre><span style=3D"font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"=
><o:p>&nbsp;</o:p></span></pre>
<pre><span style=3D"font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"=
>Dan<o:p></o:p></span></pre>
<pre><span style=3D"font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"=
><o:p>&nbsp;</o:p></span></pre>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><spa=
n style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif=
&quot;;color:windowtext"> pm-dir-bounces@ietf.org [mailto:pm-dir-bounces@ie=
tf.org]
<b>On Behalf Of </b>Benoit Claise<br>
<b>Sent:</b> Friday, May 24, 2013 12:31 AM<br>
<b>To:</b> pm-dir@ietf.org<br>
<b>Cc:</b> Fred Baker<br>
<b>Subject:</b> [pm-dir] Fred's script (was: draft-nguyen-manet-ecds-mib an=
d Performance Metrics)<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Dear pm-dir,<br>
<br>
Discussing the pm-dir goals with Fred Baker today, Fred quickly compiled a =
script: it sends an email to all draft authors whose draft contains &quot;p=
erformance metric&quot;. The goal is to notify the authors of the RFC 6390 =
existence<br>
See an example below.<br>
<br>
Thanks Fred for helping the performance metric directorate.<br>
<br>
Regards, Benoit<o:p></o:p></p>
<div>
<p class=3D"MsoNormal"><br>
<br>
-------- Original Message -------- <o:p></o:p></p>
<table class=3D"MsoNormalTable" border=3D"0" cellspacing=3D"0" cellpadding=
=3D"0">
<tbody>
<tr>
<td nowrap=3D"" valign=3D"top" style=3D"padding:0in 0in 0in 0in">
<p class=3D"MsoNormal" align=3D"right" style=3D"text-align:right"><b>Subjec=
t: <o:p></o:p></b></p>
</td>
<td style=3D"padding:0in 0in 0in 0in">
<p class=3D"MsoNormal">draft-nguyen-manet-ecds-mib and Performance Metrics<=
o:p></o:p></p>
</td>
</tr>
<tr>
<td nowrap=3D"" valign=3D"top" style=3D"padding:0in 0in 0in 0in">
<p class=3D"MsoNormal" align=3D"right" style=3D"text-align:right"><b>Date: =
<o:p></o:p></b></p>
</td>
<td style=3D"padding:0in 0in 0in 0in">
<p class=3D"MsoNormal">Thu, 23 May 2013 08:12:22 -0700 (PDT)<o:p></o:p></p>
</td>
</tr>
<tr>
<td nowrap=3D"" valign=3D"top" style=3D"padding:0in 0in 0in 0in">
<p class=3D"MsoNormal" align=3D"right" style=3D"text-align:right"><b>From: =
<o:p></o:p></b></p>
</td>
<td style=3D"padding:0in 0in 0in 0in">
<p class=3D"MsoNormal">Fred Baker <a href=3D"mailto:fred@cisco.com">&lt;fre=
d@cisco.com&gt;</a><o:p></o:p></p>
</td>
</tr>
<tr>
<td nowrap=3D"" valign=3D"top" style=3D"padding:0in 0in 0in 0in">
<p class=3D"MsoNormal" align=3D"right" style=3D"text-align:right"><b>To: <o=
:p></o:p></b></p>
</td>
<td style=3D"padding:0in 0in 0in 0in">
<p class=3D"MsoNormal"><a href=3D"mailto:draft-nguyen-manet-ecds-mib@tools.=
ietf.org">draft-nguyen-manet-ecds-mib@tools.ietf.org</a><o:p></o:p></p>
</td>
</tr>
<tr>
<td nowrap=3D"" valign=3D"top" style=3D"padding:0in 0in 0in 0in">
<p class=3D"MsoNormal" align=3D"right" style=3D"text-align:right"><b>CC: <o=
:p></o:p></b></p>
</td>
<td style=3D"padding:0in 0in 0in 0in">
<p class=3D"MsoNormal"><a href=3D"mailto:bclaise@cisco.com">bclaise@cisco.c=
om</a><o:p></o:p></p>
</td>
</tr>
</tbody>
</table>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p>
<pre>Hi:<o:p></o:p></pre>
<pre><o:p>&nbsp;</o:p></pre>
<pre>I have a question for you. Your document mentions performance metrics.=
<o:p></o:p></pre>
<pre>Would you kindly take a look at RFC 6390 to see if any of its<o:p></o:=
p></pre>
<pre>considerations apply to it?&nbsp; &quot;No&quot; is an acceptable resp=
onse, of<o:p></o:p></pre>
<pre>course; the point is to ask the question.<o:p></o:p></pre>
<pre><o:p>&nbsp;</o:p></pre>
<pre>6390 Guidelines for Considering New Performance Metric Development. A.=
<o:p></o:p></pre>
<pre>&nbsp;&nbsp;&nbsp;&nbsp; Clark, B. Claise. October 2011. (Format: TXT=
=3D49930 bytes) (Also<o:p></o:p></pre>
<pre>&nbsp;&nbsp;&nbsp;&nbsp; BCP0170) (Status: BEST CURRENT PRACTICE)<o:p>=
</o:p></pre>
<pre><o:p>&nbsp;</o:p></pre>
<pre><o:p>&nbsp;</o:p></pre>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</body>
</html>

--_000_9904FB1B0159DA42B0B887B7FA8119CA17664CAZFFEXMB04globala_--

From bclaise@cisco.com  Fri May 24 01:56:31 2013
Return-Path: <bclaise@cisco.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BAE21F9677 for <pm-dir@ietfa.amsl.com>; Fri, 24 May 2013 01:56:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.424
X-Spam-Level: 
X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXdJmTl+vnAb for <pm-dir@ietfa.amsl.com>; Fri, 24 May 2013 01:56:26 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3A32221F9642 for <pm-dir@ietf.org>; Fri, 24 May 2013 01:56:22 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4O8uG4o016756; Fri, 24 May 2013 10:56:16 +0200 (CEST)
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4O8tZ4i004915; Fri, 24 May 2013 10:55:50 +0200 (CEST)
Message-ID: <519F2B07.7040204@cisco.com>
Date: Fri, 24 May 2013 10:55:35 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
References: <201305231512.r4NFCMN4006908@irp-view13.cisco.com> <519E8A93.9050601@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA17664C@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA17664C@AZ-FFEXMB04.global.avaya.com>
Content-Type: multipart/alternative; boundary="------------050300090806030900090704"
Cc: "pm-dir@ietf.org" <pm-dir@ietf.org>, Fred Baker <Fred@cisco.com>
Subject: Re: [pm-dir] Fred's script
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2013 08:56:31 -0000

This is a multi-part message in MIME format.
--------------050300090806030900090704
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Dan,

This was sent to every single draft, individual or WG document, 
regardless of its state, that contains "performance metric".
I see it like a one shot action for now.
I believe it achieved his goal: bringing RFC 6390 awareness.
Sure, it could be repeated in the future, and sure, the text could be 
improved.

Regards, Benoit

> I like the idea, and I have two questions:
>
> -           Is not the way the question is asked too general -- especially for somebody who may be exposed for the first time to RFC 6390? Should we not rather be more specific about what we meanby 'if any of its considerations apply to it?'
> -           When is this message sent? At IETFLC -- this looks late to me and certainly for authors who were not aware about 6390 previously. If at draft-00 or the first draft that contains references to 'performance metrics' -- we need to avoid sending messages at each update.
>   
>   
> Regards,
>   
> Dan
>   
>
> *From:*pm-dir-bounces@ietf.org [mailto:pm-dir-bounces@ietf.org] *On 
> Behalf Of *Benoit Claise
> *Sent:* Friday, May 24, 2013 12:31 AM
> *To:* pm-dir@ietf.org
> *Cc:* Fred Baker
> *Subject:* [pm-dir] Fred's script (was: draft-nguyen-manet-ecds-mib 
> and Performance Metrics)
>
> Dear pm-dir,
>
> Discussing the pm-dir goals with Fred Baker today, Fred quickly 
> compiled a script: it sends an email to all draft authors whose draft 
> contains "performance metric". The goal is to notify the authors of 
> the RFC 6390 existence
> See an example below.
>
> Thanks Fred for helping the performance metric directorate.
>
> Regards, Benoit
>
>
>
> -------- Original Message --------
>
> *Subject: *
>
> 	
>
> draft-nguyen-manet-ecds-mib and Performance Metrics
>
> *Date: *
>
> 	
>
> Thu, 23 May 2013 08:12:22 -0700 (PDT)
>
> *From: *
>
> 	
>
> Fred Baker <fred@cisco.com> <mailto:fred@cisco.com>
>
> *To: *
>
> 	
>
> draft-nguyen-manet-ecds-mib@tools.ietf.org 
> <mailto:draft-nguyen-manet-ecds-mib@tools.ietf.org>
>
> *CC: *
>
> 	
>
> bclaise@cisco.com <mailto:bclaise@cisco.com>
>
> Hi:
>   
> I have a question for you. Your document mentions performance metrics.
> Would you kindly take a look at RFC 6390 to see if any of its
> considerations apply to it?  "No" is an acceptable response, of
> course; the point is to ask the question.
>   
> 6390 Guidelines for Considering New Performance Metric Development. A.
>       Clark, B. Claise. October 2011. (Format: TXT=49930 bytes) (Also
>       BCP0170) (Status: BEST CURRENT PRACTICE)
>   
>   
>


--------------050300090806030900090704
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi Dan,<br>
      <br>
      This was sent to every single draft, individual or WG document,
      regardless of its state, that contains "performance metric".<br>
      I see it like a one shot action for now. <br>
      I believe it achieved his goal: bringing RFC 6390 awareness.<br>
      Sure, it could be repeated in the future, and sure, the text could
      be improved.<br>
      <br>
      Regards, Benoit<br>
      <br>
    </div>
    <blockquote
cite="mid:9904FB1B0159DA42B0B887B7FA8119CA17664C@AZ-FFEXMB04.global.avaya.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Word 12 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	color:black;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:902259200;
	mso-list-type:hybrid;
	mso-list-template-ids:-728449798 52737898 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:Arial;}
@list l1
	{mso-list-id:1136217233;
	mso-list-type:hybrid;
	mso-list-template-ids:2105454130 237289200 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	mso-ansi-font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:Arial;
	color:#1F497D;}
@list l2
	{mso-list-id:1565946912;
	mso-list-type:hybrid;
	mso-list-template-ids:583968262 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">I
            like the idea, and I have two questions:
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <pre style="margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo3"><!--[if !supportLists]--><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style="mso-list:Ignore">-<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]--><span dir="LTR"></span><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Is not the way the question is asked too general &#8211; especially for somebody who may be exposed for the first time to RFC 6390? Should we not rather be more specific about what we mean </span><span style="font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">by &#8216;</span><span style="font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">if any of its considerations apply to it?&#8217; <o:p></o:p></span></pre>
        <pre style="margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo3"><!--[if !supportLists]--><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style="mso-list:Ignore">-<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><!--[endif]--><span dir="LTR"></span><span style="font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">When is this message sent? At IETFLC &#8211; this looks late to me and certainly for authors who were not aware about 6390 previously. If at draft-00 or the first draft that contains references to &#8216;performance metrics&#8217; &#8211; we need to avoid sending messages at each update.</span></pre>
      </div>
    </blockquote>
    <blockquote
cite="mid:9904FB1B0159DA42B0B887B7FA8119CA17664C@AZ-FFEXMB04.global.avaya.com"
      type="cite">
      <div class="WordSection1">
        <pre style="margin-left:.5in;text-indent:-.25in;mso-list:l1 level1 lfo3"><span style="font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"> <o:p></o:p></span></pre>
        <pre><span style="font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></pre>
        <pre><span style="font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">Regards,<o:p></o:p></span></pre>
        <pre><span style="font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></pre>
        <pre><span style="font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">Dan<o:p></o:p></span></pre>
        <pre><span style="font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"><o:p>&nbsp;</o:p></span></pre>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div style="border:none;border-left:solid blue 1.5pt;padding:0in
          0in 0in 4.0pt">
          <div>
            <div style="border:none;border-top:solid #B5C4DF
              1.0pt;padding:3.0pt 0in 0in 0in">
              <p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">From:</span></b><span
style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;color:windowtext">
                  <a class="moz-txt-link-abbreviated" href="mailto:pm-dir-bounces@ietf.org">pm-dir-bounces@ietf.org</a>
                  [<a class="moz-txt-link-freetext" href="mailto:pm-dir-bounces@ietf.org">mailto:pm-dir-bounces@ietf.org</a>]
                  <b>On Behalf Of </b>Benoit Claise<br>
                  <b>Sent:</b> Friday, May 24, 2013 12:31 AM<br>
                  <b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:pm-dir@ietf.org">pm-dir@ietf.org</a><br>
                  <b>Cc:</b> Fred Baker<br>
                  <b>Subject:</b> [pm-dir] Fred's script (was:
                  draft-nguyen-manet-ecds-mib and Performance Metrics)<o:p></o:p></span></p>
            </div>
          </div>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <p class="MsoNormal" style="margin-bottom:12.0pt">Dear pm-dir,<br>
            <br>
            Discussing the pm-dir goals with Fred Baker today, Fred
            quickly compiled a script: it sends an email to all draft
            authors whose draft contains "performance metric". The goal
            is to notify the authors of the RFC 6390 existence<br>
            See an example below.<br>
            <br>
            Thanks Fred for helping the performance metric directorate.<br>
            <br>
            Regards, Benoit<o:p></o:p></p>
          <div>
            <p class="MsoNormal"><br>
              <br>
              -------- Original Message -------- <o:p></o:p></p>
            <table class="MsoNormalTable" border="0" cellpadding="0"
              cellspacing="0">
              <tbody>
                <tr>
                  <td style="padding:0in 0in 0in 0in" nowrap="nowrap"
                    valign="top">
                    <p class="MsoNormal" style="text-align:right"
                      align="right"><b>Subject: <o:p></o:p></b></p>
                  </td>
                  <td style="padding:0in 0in 0in 0in">
                    <p class="MsoNormal">draft-nguyen-manet-ecds-mib and
                      Performance Metrics<o:p></o:p></p>
                  </td>
                </tr>
                <tr>
                  <td style="padding:0in 0in 0in 0in" nowrap="nowrap"
                    valign="top">
                    <p class="MsoNormal" style="text-align:right"
                      align="right"><b>Date: <o:p></o:p></b></p>
                  </td>
                  <td style="padding:0in 0in 0in 0in">
                    <p class="MsoNormal">Thu, 23 May 2013 08:12:22 -0700
                      (PDT)<o:p></o:p></p>
                  </td>
                </tr>
                <tr>
                  <td style="padding:0in 0in 0in 0in" nowrap="nowrap"
                    valign="top">
                    <p class="MsoNormal" style="text-align:right"
                      align="right"><b>From: <o:p></o:p></b></p>
                  </td>
                  <td style="padding:0in 0in 0in 0in">
                    <p class="MsoNormal">Fred Baker <a
                        moz-do-not-send="true"
                        href="mailto:fred@cisco.com">&lt;fred@cisco.com&gt;</a><o:p></o:p></p>
                  </td>
                </tr>
                <tr>
                  <td style="padding:0in 0in 0in 0in" nowrap="nowrap"
                    valign="top">
                    <p class="MsoNormal" style="text-align:right"
                      align="right"><b>To: <o:p></o:p></b></p>
                  </td>
                  <td style="padding:0in 0in 0in 0in">
                    <p class="MsoNormal"><a moz-do-not-send="true"
                        href="mailto:draft-nguyen-manet-ecds-mib@tools.ietf.org">draft-nguyen-manet-ecds-mib@tools.ietf.org</a><o:p></o:p></p>
                  </td>
                </tr>
                <tr>
                  <td style="padding:0in 0in 0in 0in" nowrap="nowrap"
                    valign="top">
                    <p class="MsoNormal" style="text-align:right"
                      align="right"><b>CC: <o:p></o:p></b></p>
                  </td>
                  <td style="padding:0in 0in 0in 0in">
                    <p class="MsoNormal"><a moz-do-not-send="true"
                        href="mailto:bclaise@cisco.com">bclaise@cisco.com</a><o:p></o:p></p>
                  </td>
                </tr>
              </tbody>
            </table>
            <p class="MsoNormal" style="margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p>
            <pre>Hi:<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>I have a question for you. Your document mentions performance metrics.<o:p></o:p></pre>
            <pre>Would you kindly take a look at RFC 6390 to see if any of its<o:p></o:p></pre>
            <pre>considerations apply to it?&nbsp; "No" is an acceptable response, of<o:p></o:p></pre>
            <pre>course; the point is to ask the question.<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>6390 Guidelines for Considering New Performance Metric Development. A.<o:p></o:p></pre>
            <pre>&nbsp;&nbsp;&nbsp;&nbsp; Clark, B. Claise. October 2011. (Format: TXT=49930 bytes) (Also<o:p></o:p></pre>
            <pre>&nbsp;&nbsp;&nbsp;&nbsp; BCP0170) (Status: BEST CURRENT PRACTICE)<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          </div>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------050300090806030900090704--

From adrian@olddog.co.uk  Fri May 24 02:26:24 2013
Return-Path: <adrian@olddog.co.uk>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C6B21F938E; Fri, 24 May 2013 02:26:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.091
X-Spam-Level: 
X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=-1.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, TRACKER_ID=2.003]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSGGS42lVeff; Fri, 24 May 2013 02:26:18 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4EA21F933B; Fri, 24 May 2013 02:26:17 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4O9QDjw014798;  Fri, 24 May 2013 10:26:13 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4O9QBpO014773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 May 2013 10:26:12 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Benoit Claise'" <bclaise@cisco.com>, "'Nguyen, James H CIV USARMY CERDEC \(US\)'" <james.h.nguyen4.civ@mail.mil>
References: <201305231512.r4NFCMN4006908@irp-view13.cisco.com> <3DC26342A93F204C804384C87DDBECBF3DADF508@ucolhp9k.easf.csd.disa.mil> <519F25A0.70502@cisco.com>
In-Reply-To: <519F25A0.70502@cisco.com>
Date: Fri, 24 May 2013 10:26:10 +0100
Message-ID: <056b01ce5860$bafed290$30fc77b0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_056F_01CE5869.1CC9F150"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFt5VD+u7/ZzOgrC0mFlTA9gvmqaQJjdZgFAly+7hKZrvMTAA==
Content-Language: en-gb
Cc: draft-nguyen-manet-ecds-mib@tools.ietf.org, draft-ietf-manet-smf-mib@tools.ietf.org, manet@ietf.org, pm-dir@ietf.org, 'Fred Baker' <fred@cisco.com>
Subject: Re: [pm-dir] draft-nguyen-manet-ecds-mib and Performance Metrics (UNCLASSIFIED)
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2013 09:26:24 -0000

This is a multipart message in MIME format.

------=_NextPart_000_056F_01CE5869.1CC9F150
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Benoit,
 
Thanks for cutting me in on this thread.
 
I do think this type of discussion should take place on WG mailing lists so I am
copying MANET on this reply.
 
It appears that the phrase "performance metric" causes alarm bells to ring in
several fire stations around the world. Although I strongly resent words or
phrases being captured for more specific and focused meaning than they deserve,
it is also clear that the pain caused by having a hundred firemen show up on
your doorstep at 3am is sufficient (unless you like firemen at 3am ;-) to
warrant taking Benoit's advice.
 
- Avoid the term "performance metric" unless you mean it in the
 sense of RFC 6390 (or be prepared to have a fight)
- Use the term "performance information" or maybe "performance
  counters"
 
<VBS>
 
Adrian
 
From: Benoit Claise [mailto:bclaise@cisco.com] 
Sent: 24 May 2013 09:33
To: Nguyen, James H CIV USARMY CERDEC (US)
Cc: Fred Baker; draft-nguyen-manet-ecds-mib@tools.ietf.org; me;
draft-ietf-manet-smf-mib@tools.ietf.org; pm-dir@ietf.org; Adrian Farrel
Subject: Re: draft-nguyen-manet-ecds-mib and Performance Metrics (UNCLASSIFIED)
 
Hi James, draft-ietf-manet-smf-mib authors,

Agreed, RFC 6390 doesn't apply here.
See the email exchange regarding draft-ietf-manet-olsrv2-mib below, which I
reviewed part of the performance metric directorate.
Like Ulrich did for draft-ietf-manet-olsrv2-mib, it might better to use
"performance information" instead of "performance metrics" in your draft.
Benoit,
 
thank you very much for this review. I agree that using the term
"performance information" instead of "performance metrics" is a good
idea. We will make the change.
 
Best regards
Ulrich
 
On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise  <mailto:bclaise@cisco.com>
<bclaise@cisco.com> wrote:
Dear all,
 
I reviewed http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, from a
performance metric directorate point of view.
 
This draft doesn't contain any reference to RFC6390, but contains
"performance metric". Hence this review was triggered. For details about the
directorate, see
http://www.ietf.org/iesg/directorate/performance-metrics.html
 
 
Definition of Managed Objects for the  Optimized Link State Routing
Protocol version 2
 
Abstract
 
   This document defines the Management Information Base (MIB) module
   for configuring and managing the Optimized Link State Routing
   protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
   into state information, performance metrics, and notifications.  This
   additional state and performance information is useful to
   troubleshoot problems and performance issues of the routing protocol.
   Different levels of compliance allow implementers to use smaller
   subsets of all defined objects, allowing for this MIB module to be
   deployed on more constrained routers.
 
 
Basically, all performance metrics come from this table:
 
   o  olsrv2InterfacePerfTable - records performance counters for each
      active OLSRv2 interface on this device. selected path to each
      destination for which any such path is known.  This table has
      AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed via
      nhdpIfIndex from the NHDP-MIB.
 
NHDP-MIB is RFC 6779:
   NhdpInterfacePerfEntry ::=
      SEQUENCE {
         nhdpIfHelloMessageXmits
            Counter32,
         nhdpIfHelloMessageRecvd
            Counter32,
         nhdpIfHelloMessageXmitAccumulatedSize
            Counter64,
         nhdpIfHelloMessageRecvdAccumulatedSize
            Counter64,
         nhdpIfHelloMessageTriggeredXmits
            Counter32,
         nhdpIfHelloMessagePeriodicXmits
            Counter32,
         nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
            Counter32,
         nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
            Counter32,
         nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
            Counter32
      }
 
 
This draft contains similar objects in olsrv2InterfacePerfTable :
 
    Olsrv2InterfacePerfEntry ::=
       SEQUENCE {
          olsrv2IfTcMessageXmits
             Counter32,
          olsrv2IfTcMessageRecvd
             Counter32,
          olsrv2IfTcMessageXmitAccumulatedSize
             Counter64,
          olsrv2IfTcMessageRecvdAccumulatedSize
             Counter64,
          olsrv2IfTcMessageTriggeredXmits
             Counter32,
          olsrv2IfTcMessagePeriodicXmits
             Counter32,
          olsrv2IfTcMessageForwardedXmits
             Counter32,
          olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
             Counter32
       }
 
 
Personally, I don't believe that those objects should be subject to the RFC
6390 template definition. (Performance Metric Definition Template, section
5.4.4, RFC 6390).
First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was not
subject to it
Second reason: these objects are not really performance metrics, but mainly
basic monitoring objects.
 
Since RFC 6779 uses the term performance information (in the abstract), I
would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not
the "performance metric". That would avoid some confusion. However, keeping
the olsrv2InterfacePerfTable OID name is perfectly fine, for consistency
reason with RFC 6779.
 
Regards, Benoit
 

Regards, Benoit
Classification: UNCLASSIFIED
Caveats: NONE
 
Fred,
 
There are two counters that are defined for performance metrics.  Please see
below.  As we stated it in Section 9 "Applicability Statement," ECDS-MIB is
an extension of SMF-MIB.  Thus, ECDS-MIB's inherited SMF-MIB's performance
metrics.  
 
As I can see, ECDS-MIB does apply 6390's (i), (ii), (iii), and somewhat
(iv).  Please let me know if you have any suggestion to improve the draft.
 
 
      (i) the degree to which its absence would cause significant loss
      of information on the behavior or performance of the application
      or system being measured
 
      (ii) the correlation between the Performance Metric, the QoS, and
      the QoE delivered to the user (person or other application)
 
      (iii) the degree to which the Performance Metric is able to
      support the identification and location of problems affecting
      service quality
 
      (iv) the requirement to develop policies (Service Level Agreement,
      and potentially Service Level Contract) based on the Performance
      Metric
 
 
 
--
 -- E-CDS Performance Group
 --
 
 ecdsPerformanceGroup OBJECT IDENTIFIER ::= { ecdsMIBObjects 3 }
 
 ecdsInEcdsChange OBJECT-TYPE
         SYNTAX          Counter32
         MAX-ACCESS      read-only
         STATUS          current
         DESCRIPTION
                 "This object indicates how many times the current
                  node is configured to be in E-CDS."
 ::= { ecdsPerformanceGroup 1 }
 
 ecdsCurrentRtrPriValueChange OBJECT-TYPE
         SYNTAX          Counter32
         MAX-ACCESS      read-only
         STATUS          current
         DESCRIPTION
                 "This object indicates how many times the Router
                  Priority of the current node has been changed."
 ::= { ecdsPerformanceGroup 2 }
 
 
 
James Nguyen
US Army CERDEC S&TCD
Email: james.h.nguyen4.civ@mail.mil
Phone:  443-395-5628
 
 
-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com] 
Sent: Thursday, May 23, 2013 11:12 AM
To: draft-nguyen-manet-ecds-mib@tools.ietf.org
Cc: bclaise@cisco.com
Subject: draft-nguyen-manet-ecds-mib and Performance Metrics
 
Hi:
 
I have a question for you. Your document mentions performance metrics.
Would you kindly take a look at RFC 6390 to see if any of its considerations
apply to it?  "No" is an acceptable response, of course; the point is to ask
the question.
 
6390 Guidelines for Considering New Performance Metric Development. A.
     Clark, B. Claise. October 2011. (Format: TXT=49930 bytes) (Also
     BCP0170) (Status: BEST CURRENT PRACTICE)
 
 
Classification: UNCLASSIFIED
Caveats: NONE
 
 
 

------=_NextPart_000_056F_01CE5869.1CC9F150
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DProgId content=3DWord.Document><meta =
name=3DGenerator content=3D"Microsoft Word 14"><meta name=3DOriginator =
content=3D"Microsoft Word 14"><link rel=3DFile-List =
href=3D"cid:filelist.xml@01CE5868.A47C5DA0"><!--[if gte mso 9]><xml>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
</o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:WordDocument>
<w:SpellingState>Clean</w:SpellingState>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:EnvelopeVis/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>EN-GB</w:LidThemeOther>
<w:LidThemeAsian>X-NONE</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:DoNotExpandShiftReturn/>
<w:BreakWrappedTables/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val=3D"Cambria Math"/>
<m:brkBin m:val=3D"before"/>
<m:brkBinSub m:val=3D"&#45;-"/>
<m:smallFrac m:val=3D"off"/>
<m:dispDef/>
<m:lMargin m:val=3D"0"/>
<m:rMargin m:val=3D"0"/>
<m:defJc m:val=3D"centerGroup"/>
<m:wrapIndent m:val=3D"1440"/>
<m:intLim m:val=3D"subSup"/>
<m:naryLim m:val=3D"undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState=3D"false" DefUnhideWhenUsed=3D"true" =
DefSemiHidden=3D"true" DefQFormat=3D"false" DefPriority=3D"99" =
LatentStyleCount=3D"267">
<w:LsdException Locked=3D"false" Priority=3D"0" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Normal"/>
<w:LsdException Locked=3D"false" Priority=3D"9" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"heading 1"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 2"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 3"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 4"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 5"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 6"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 7"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 8"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 9"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 1"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 2"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 3"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 4"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 5"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 6"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 7"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 8"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 9"/>
<w:LsdException Locked=3D"false" Priority=3D"35" QFormat=3D"true" =
Name=3D"caption"/>
<w:LsdException Locked=3D"false" Priority=3D"10" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Title"/>
<w:LsdException Locked=3D"false" Priority=3D"1" Name=3D"Default =
Paragraph Font"/>
<w:LsdException Locked=3D"false" Priority=3D"11" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtitle"/>
<w:LsdException Locked=3D"false" Priority=3D"22" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Strong"/>
<w:LsdException Locked=3D"false" Priority=3D"20" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Emphasis"/>
<w:LsdException Locked=3D"false" Priority=3D"59" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Table Grid"/>
<w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =
Name=3D"Placeholder Text"/>
<w:LsdException Locked=3D"false" Priority=3D"1" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"No Spacing"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 1"/>
<w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =
Name=3D"Revision"/>
<w:LsdException Locked=3D"false" Priority=3D"34" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"List Paragraph"/>
<w:LsdException Locked=3D"false" Priority=3D"29" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Quote"/>
<w:LsdException Locked=3D"false" Priority=3D"30" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Quote"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"19" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Emphasis"/>
<w:LsdException Locked=3D"false" Priority=3D"21" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Emphasis"/>
<w:LsdException Locked=3D"false" Priority=3D"31" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Reference"/>
<w:LsdException Locked=3D"false" Priority=3D"32" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Reference"/>
<w:LsdException Locked=3D"false" Priority=3D"33" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Book Title"/>
<w:LsdException Locked=3D"false" Priority=3D"37" Name=3D"Bibliography"/>
<w:LsdException Locked=3D"false" Priority=3D"39" QFormat=3D"true" =
Name=3D"TOC Heading"/>
</w:LatentStyles>
</xml><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-536870145 1073786111 1 0 415 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-520081665 -1073717157 41 0 66047 0;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:modern;
	mso-font-pitch:fixed;
	mso-font-signature:-520092929 1073806591 9 0 415 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:purple;
	text-decoration:underline;
	text-underline:single;}
pre
	{mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:Calibri;
	color:black;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	mso-ascii-font-family:Consolas;
	mso-fareast-font-family:Calibri;
	mso-hansi-font-family:Consolas;
	mso-bidi-font-family:Consolas;
	color:black;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-style-unhide:no;
	mso-ansi-font-size:11.0pt;
	mso-bidi-font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-fareast-font-family:Calibri;
	mso-hansi-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	font-size:10.0pt;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;
	mso-header-margin:36.0pt;
	mso-footer-margin:36.0pt;
	mso-paper-source:0;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 10]><style>/* Style Definitions */
table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman","serif";}
</style><![endif]--><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=3Dwhite =
lang=3DEN-GB link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'><div class=3DWordSection1><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New Roman";color:#1F497D'>Hi =
Benoit,<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New Roman";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New Roman";color:#1F497D'>Thanks for cutting me in on =
this thread.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New Roman";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New Roman";color:#1F497D'>I do think this type of =
discussion should take place on WG mailing lists so I am copying MANET =
on this reply.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New Roman";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New Roman";color:#1F497D'>It appears that the phrase =
&quot;performance metric&quot; causes alarm bells to ring in several =
fire stations around the world. Although I strongly resent words or =
phrases being captured for more specific and focused meaning than they =
deserve, it is also clear that the pain caused by having a hundred =
firemen show up on your doorstep at 3am is sufficient (unless you like =
firemen at 3am ;-) to warrant taking Benoit's =
advice.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New Roman";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New Roman";color:#1F497D'>- Avoid the term =
&quot;performance metric&quot; unless you mean it in =
the<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New Roman";color:#1F497D'> <span =
style=3D'mso-spacerun:yes'>&nbsp;</span>sense of RFC 6390 (or be =
prepared to have a fight)<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New Roman";color:#1F497D'>- Use the term =
&quot;performance information&quot; or maybe =
&quot;performance<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New Roman";color:#1F497D'><span =
style=3D'mso-spacerun:yes'>&nbsp; =
</span>counters&quot;<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New Roman";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New =
Roman";color:#1F497D'>&lt;VBS&gt;<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New Roman";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New Roman";color:#1F497D'>Adrian<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-bidi-fon=
t-family:"Times New =
Roman";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div =
style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt'><div><div style=3D'border:none;border-top:solid #B5C4DF =
1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal><b><span =
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-f=
ont-family:"Times New =
Roman";color:windowtext;mso-ansi-language:EN-US'>From:</span></b><span =
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-f=
ont-family:"Times New Roman";color:windowtext;mso-ansi-language:EN-US'> =
Benoit Claise [mailto:bclaise@cisco.com] <br><b>Sent:</b> 24 May 2013 =
09:33<br><b>To:</b> Nguyen, James H CIV USARMY CERDEC (US)<br><b>Cc:</b> =
Fred Baker; draft-nguyen-manet-ecds-mib@tools.ietf.org; me; =
draft-ietf-manet-smf-mib@tools.ietf.org; pm-dir@ietf.org; Adrian =
Farrel<br><b>Subject:</b> Re: draft-nguyen-manet-ecds-mib and =
Performance Metrics (UNCLASSIFIED)<o:p></o:p></span></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><p class=3DMsoNormal><span =
style=3D'mso-fareast-font-family:"Times New Roman"'>Hi James, =
draft-ietf-manet-smf-mib authors,<br><br>Agreed, RFC 6390 doesn't apply =
here.<br>See the email exchange regarding draft-ietf-manet-olsrv2-mib =
below, which I reviewed part of the performance metric =
directorate.<br>Like Ulrich did for draft-ietf-manet-olsrv2-mib, it =
might better to use &quot;performance information&quot; instead of =
&quot;performance metrics&quot; in your =
draft.<o:p></o:p></span></p><pre>Benoit,<o:p></o:p></pre><pre><o:p>&nbsp;=
</o:p></pre><pre>thank you very much for this review. I agree that using =
the term<o:p></o:p></pre><pre>&quot;performance information&quot; =
instead of &quot;performance metrics&quot; is a =
good<o:p></o:p></pre><pre>idea. We will make the =
change.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Best =
regards<o:p></o:p></pre><pre>Ulrich<o:p></o:p></pre><pre><o:p>&nbsp;</o:p=
></pre><pre>On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise <a =
href=3D"mailto:bclaise@cisco.com">&lt;bclaise@cisco.com&gt;</a> =
wrote:<o:p></o:p></pre><pre>Dear =
all,<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>I reviewed <a =
href=3D"http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06">http:/=
/tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06</a>, from =
a<o:p></o:p></pre><pre>performance metric directorate point of =
view.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>This draft =
doesn't contain any reference to RFC6390, but =
contains<o:p></o:p></pre><pre>&quot;performance metric&quot;. Hence this =
review was triggered. For details about =
the<o:p></o:p></pre><pre>directorate, see<o:p></o:p></pre><pre><a =
href=3D"http://www.ietf.org/iesg/directorate/performance-metrics.html">ht=
tp://www.ietf.org/iesg/directorate/performance-metrics.html</a><o:p></o:p=
></pre><pre><o:p>&nbsp;</o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Defin=
ition of Managed Objects for the<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>Optimized Link State Routing<o:p></o:p></pre><pre>Protocol =
version =
2<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Abstract<o:p></o:p></p=
re><pre><o:p>&nbsp;</o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp; </span>This document defines the =
Management Information Base (MIB) module<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp; </span>for configuring and =
managing the Optimized Link State Routing<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp; </span>protocol version 2 =
(OLSRv2).<span style=3D'mso-spacerun:yes'>&nbsp; </span>The OLSRv2-MIB =
module is structured<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp; </span>into state information, =
performance metrics, and notifications.<span =
style=3D'mso-spacerun:yes'>&nbsp; </span>This<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp; </span>additional state and =
performance information is useful to<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp; </span><span =
style=3D'mso-spacerun:yes'>&nbsp;</span>troubleshoot problems and =
performance issues of the routing protocol.<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp; </span>Different levels of =
compliance allow implementers to use smaller<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp; </span>subsets of all defined =
objects, allowing for this MIB module to be<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp; </span>deployed on more =
constrained =
routers.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><o:p>&nbsp;</o:=
p></pre><pre>Basically, all performance metrics come from this =
table:<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp; </span>o<span =
style=3D'mso-spacerun:yes'>&nbsp; </span>olsrv2InterfacePerfTable - =
records performance counters for each<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>active =
OLSRv2 interface on this device. selected path to =
each<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>destination for which any such path is known.<span =
style=3D'mso-spacerun:yes'>&nbsp; </span>This table =
has<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed =
via<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>nhdpIfIndex from the =
NHDP-MIB.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>NHDP-MIB is =
RFC 6779:<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp; </span>NhdpInterfacePerfEntry =
::=3D<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>SEQUENCE {<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span>nhdpIfHelloMessageXmits<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span>nhdpIfHelloMessageRecvd<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; =
</span>nhdpIfHelloMessageXmitAccumulatedSize<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; </span>Counter64,<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; =
</span>nhdpIfHelloMessageRecvdAccumulatedSize<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; </span>Counter64,<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span>nhdpIfHelloMessageTriggeredXmits<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span>nhdpIfHelloMessagePeriodicXmits<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; =
</span>nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount<o:p></o:p>=
</pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; =
</span>nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount<o:p></o:p></pr=
e><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; =
</span>nhdpIfHelloMessageXmitAccumulatedLostNeighborCount<o:p></o:p></pre=
><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; </span>Counter32<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>}<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><o:p>&nbsp;</o:=
p></pre><pre>This draft contains similar objects in =
olsrv2InterfacePerfTable =
:<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp; =
</span>Olsrv2InterfacePerfEntry ::=3D<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>SEQUENCE {<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; </span>olsrv2IfTcMessageXmits<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; </span>olsrv2IfTcMessageRecvd<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; =
</span>olsrv2IfTcMessageXmitAccumulatedSize<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter64,<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; =
</span>olsrv2IfTcMessageRecvdAccumulatedSize<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter64,<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; =
</span>olsrv2IfTcMessageTriggeredXmits<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;</span>olsrv2IfTcMessagePeriodicXm=
its<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; =
</span>olsrv2IfTcMessageForwardedXmits<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; =
</span>olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount<o:p></o:p></pre><=
pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>}<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><o:p>&nbsp;</o:=
p></pre><pre>Personally, I don't believe that those objects should be =
subject to the RFC<o:p></o:p></pre><pre>6390 template definition. =
(Performance Metric Definition Template, =
section<o:p></o:p></pre><pre>5.4.4, RFC =
6390).<o:p></o:p></pre><pre>First reason: NhdpInterfacePerfEntry, from =
NHDP-MIB [RFC 6779] was not<o:p></o:p></pre><pre>subject to =
it<o:p></o:p></pre><pre>Second reason: these objects are not really =
performance metrics, but mainly<o:p></o:p></pre><pre>basic monitoring =
objects.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Since RFC 6779 =
uses the term performance information (in the abstract), =
I<o:p></o:p></pre><pre>would propose that draft-ietf-manet-olsrv2-mib =
also uses this term, and not<o:p></o:p></pre><pre>the &quot;performance =
metric&quot;. That would avoid some confusion. However, =
keeping<o:p></o:p></pre><pre>the olsrv2InterfacePerfTable OID name is =
perfectly fine, for consistency<o:p></o:p></pre><pre>reason with RFC =
6779.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Regards, =
Benoit<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><p =
class=3DMsoNormal><span style=3D'mso-fareast-font-family:"Times New =
Roman"'><br>Regards, Benoit<o:p></o:p></span></p></div><blockquote =
style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><pre>Classification: =
UNCLASSIFIED<o:p></o:p></pre><pre>Caveats: =
NONE<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Fred,<o:p></o:p></p=
re><pre><o:p>&nbsp;</o:p></pre><pre>There are two counters that are =
defined for performance metrics.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>Please see<o:p></o:p></pre><pre>below.<span =
style=3D'mso-spacerun:yes'>&nbsp; </span>As we stated it in Section 9 =
&quot;Applicability Statement,&quot; ECDS-MIB is<o:p></o:p></pre><pre>an =
extension of SMF-MIB.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>Thus, ECDS-MIB's inherited SMF-MIB's =
performance<o:p></o:p></pre><pre>metrics.<span =
style=3D'mso-spacerun:yes'>&nbsp; =
</span><o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>As I can see, =
ECDS-MIB does apply 6390's (i), (ii), (iii), and =
somewhat<o:p></o:p></pre><pre>(iv).<span =
style=3D'mso-spacerun:yes'>&nbsp; </span>Please let me know if you have =
any suggestion to improve the =
draft.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><o:p>&nbsp;</o:p>=
</pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>(i) the =
degree to which its absence would cause significant =
loss<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>of =
information on the behavior or performance of the =
application<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>or =
system being =
measured<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>(ii) =
the correlation between the Performance Metric, the QoS, =
and<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>the QoE =
delivered to the user (person or other =
application)<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>(iii) =
the degree to which the Performance Metric is able =
to<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>support =
the identification and location of problems =
affecting<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>service =
quality<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>(iv) =
the requirement to develop policies (Service Level =
Agreement,<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>and =
potentially Service Level Contract) based on the =
Performance<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp; </span><span =
style=3D'mso-spacerun:yes'>&nbsp;</span>Metric<o:p></o:p></pre><pre><o:p>=
&nbsp;</o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><o:p>&nbsp;</o:p></pre=
><pre>--<o:p></o:p></pre><pre> -- E-CDS Performance =
Group<o:p></o:p></pre><pre> =
--<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre> =
ecdsPerformanceGroup OBJECT IDENTIFIER ::=3D { ecdsMIBObjects 3 =
}<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre> ecdsInEcdsChange =
OBJECT-TYPE<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span>SYNTAX<span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; </span>Counter32<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span>MAX-ACCESS<span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>read-only<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span>STATUS<span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; </span>current<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span>DESCRIPTION<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>&quot;This =
object indicates how many times the current<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>node is =
configured to be in E-CDS.&quot;<o:p></o:p></pre><pre> ::=3D { =
ecdsPerformanceGroup 1 =
}<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre> =
ecdsCurrentRtrPriValueChange OBJECT-TYPE<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span>SYNTAX<span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; </span>Counter32<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span>MAX-ACCESS<span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>read-only<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span>STATUS<span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; </span>current<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span>DESCRIPTION<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>&quot;This =
object indicates how many times the Router<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Priority =
of the current node has been changed.&quot;<o:p></o:p></pre><pre> ::=3D =
{ ecdsPerformanceGroup 2 =
}<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><o:p>&nbsp;</o:p></pre=
><pre><o:p>&nbsp;</o:p></pre><pre>James Nguyen<o:p></o:p></pre><pre>US =
Army CERDEC S&amp;TCD<o:p></o:p></pre><pre>Email: <a =
href=3D"mailto:james.h.nguyen4.civ@mail.mil">james.h.nguyen4.civ@mail.mil=
</a><o:p></o:p></pre><pre>Phone:<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>443-395-5628<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><o:p=
>&nbsp;</o:p></pre><pre>-----Original =
Message-----<o:p></o:p></pre><pre>From: Fred Baker [<a =
href=3D"mailto:fred@cisco.com">mailto:fred@cisco.com</a>] =
<o:p></o:p></pre><pre>Sent: Thursday, May 23, 2013 11:12 =
AM<o:p></o:p></pre><pre>To: <a =
href=3D"mailto:draft-nguyen-manet-ecds-mib@tools.ietf.org">draft-nguyen-m=
anet-ecds-mib@tools.ietf.org</a><o:p></o:p></pre><pre>Cc: <a =
href=3D"mailto:bclaise@cisco.com">bclaise@cisco.com</a><o:p></o:p></pre><=
pre>Subject: draft-nguyen-manet-ecds-mib and Performance =
Metrics<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Hi:<o:p></o:p></=
pre><pre><o:p>&nbsp;</o:p></pre><pre>I have a question for you. Your =
document mentions performance metrics.<o:p></o:p></pre><pre>Would you =
kindly take a look at RFC 6390 to see if any of its =
considerations<o:p></o:p></pre><pre>apply to it?<span =
style=3D'mso-spacerun:yes'>&nbsp; </span>&quot;No&quot; is an acceptable =
response, of course; the point is to ask<o:p></o:p></pre><pre>the =
question.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>6390 =
Guidelines for Considering New Performance Metric Development. =
A.<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp; </span>Clark, B. =
Claise. October 2011. (Format: TXT=3D49930 bytes) =
(Also<o:p></o:p></pre><pre><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp; </span>BCP0170) =
(Status: BEST CURRENT =
PRACTICE)<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><o:p>&nbsp;</o=
:p></pre><pre>Classification: UNCLASSIFIED<o:p></o:p></pre><pre>Caveats: =
NONE<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><o:p>&nbsp;</o:p></=
pre></blockquote><p class=3DMsoNormal><span =
style=3D'mso-fareast-font-family:"Times New =
Roman"'><o:p>&nbsp;</o:p></span></p></div></div></body></html>
------=_NextPart_000_056F_01CE5869.1CC9F150--


From bclaise@cisco.com  Fri May 24 03:04:03 2013
Return-Path: <bclaise@cisco.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A057D21F96C2; Fri, 24 May 2013 03:04:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.129
X-Spam-Level: 
X-Spam-Status: No, score=-9.129 tagged_above=-999 required=5 tests=[AWL=-1.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, TRACKER_ID=2.003]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwqmrqpVEofW; Fri, 24 May 2013 03:03:58 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id CE60021F969E; Fri, 24 May 2013 03:03:57 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4OA3sI3024465; Fri, 24 May 2013 12:03:54 +0200 (CEST)
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4OA2YEg008197; Fri, 24 May 2013 12:02:49 +0200 (CEST)
Message-ID: <519F3ABA.6090703@cisco.com>
Date: Fri, 24 May 2013 12:02:34 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: adrian@olddog.co.uk
References: <201305231512.r4NFCMN4006908@irp-view13.cisco.com> <3DC26342A93F204C804384C87DDBECBF3DADF508@ucolhp9k.easf.csd.disa.mil> <519F25A0.70502@cisco.com> <056b01ce5860$bafed290$30fc77b0$@olddog.co.uk>
In-Reply-To: <056b01ce5860$bafed290$30fc77b0$@olddog.co.uk>
Content-Type: multipart/alternative; boundary="------------030609020605040409000007"
Cc: "'Nguyen, James H CIV USARMY CERDEC \(US\)'" <james.h.nguyen4.civ@mail.mil>, manet@ietf.org, draft-nguyen-manet-ecds-mib@tools.ietf.org, draft-ietf-manet-smf-mib@tools.ietf.org, 'Fred Baker' <fred@cisco.com>, pm-dir@ietf.org
Subject: Re: [pm-dir] draft-nguyen-manet-ecds-mib and Performance Metrics (UNCLASSIFIED)
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2013 10:04:03 -0000

This is a multi-part message in MIME format.
--------------030609020605040409000007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Adrian,

> Hi Benoit,
>
> Thanks for cutting me in on this thread.
>
> I do think this type of discussion should take place on WG mailing 
> lists so I am copying MANET on this reply.
>
> It appears that the phrase "performance metric" causes alarm bells to 
> ring in several fire stations around the world. Although I strongly 
> resent words or phrases being captured for more specific and focused 
> meaning than they deserve, it is also clear that the pain caused by 
> having a hundred firemen show up on your doorstep at 3am is sufficient 
> (unless you like firemen at 3am ;-) to warrant taking Benoit's advice.
>
> - Avoid the term "performance metric" unless you mean it in the
>
> sense of RFC 6390 (or be prepared to have a fight)
>
This is simply not correct!
Based on my two messages below (for the 2 drafts):

    Since RFC 6779 uses the term performance information (in the abstract), I

    would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not

    the "performance metric". That would avoid some confusion.

    ...

    Like
    Ulrich did for draft-ietf-manet-olsrv2-mib, it might better to use
    "performance information" instead of "performance metrics" in your
    draft.

These are advice, and should be considered as such.

Regards, Benoit

> - Use the term "performance information" or maybe "performance
>
> counters"
>
> <VBS>
>
> Adrian
>
> *From:*Benoit Claise [mailto:bclaise@cisco.com]
> *Sent:* 24 May 2013 09:33
> *To:* Nguyen, James H CIV USARMY CERDEC (US)
> *Cc:* Fred Baker; draft-nguyen-manet-ecds-mib@tools.ietf.org; me; 
> draft-ietf-manet-smf-mib@tools.ietf.org; pm-dir@ietf.org; Adrian Farrel
> *Subject:* Re: draft-nguyen-manet-ecds-mib and Performance Metrics 
> (UNCLASSIFIED)
>
> Hi James, draft-ietf-manet-smf-mib authors,
>
> Agreed, RFC 6390 doesn't apply here.
> See the email exchange regarding draft-ietf-manet-olsrv2-mib below, 
> which I reviewed part of the performance metric directorate.
> Like Ulrich did for draft-ietf-manet-olsrv2-mib, it might better to 
> use "performance information" instead of "performance metrics" in your 
> draft.
>
> Benoit,
>   
> thank you very much for this review. I agree that using the term
> "performance information" instead of "performance metrics" is a good
> idea. We will make the change.
>   
> Best regards
> Ulrich
>   
> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise<bclaise@cisco.com>  <mailto:bclaise@cisco.com>  wrote:
> Dear all,
>   
> I reviewedhttp://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, from a
> performance metric directorate point of view.
>   
> This draft doesn't contain any reference to RFC6390, but contains
> "performance metric". Hence this review was triggered. For details about the
> directorate, see
> http://www.ietf.org/iesg/directorate/performance-metrics.html
>   
>   
> Definition of Managed Objects for the   Optimized Link State Routing
> Protocol version 2
>   
> Abstract
>   
>     This document defines the Management Information Base (MIB) module
>     for configuring and managing the Optimized Link State Routing
>     protocol version 2 (OLSRv2).   The OLSRv2-MIB module is structured
>     into state information, performance metrics, and notifications.   This
>     additional state and performance information is useful to
>      troubleshoot problems and performance issues of the routing protocol.
>     Different levels of compliance allow implementers to use smaller
>     subsets of all defined objects, allowing for this MIB module to be
>     deployed on more constrained routers.
>   
>   
> Basically, all performance metrics come from this table:
>   
>     o   olsrv2InterfacePerfTable - records performance counters for each
>        active OLSRv2 interface on this device. selected path to each
>        destination for which any such path is known.   This table has
>        AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed via
>        nhdpIfIndex from the NHDP-MIB.
>   
> NHDP-MIB is RFC 6779:
>     NhdpInterfacePerfEntry ::=
>        SEQUENCE {
>           nhdpIfHelloMessageXmits
>              Counter32,
>           nhdpIfHelloMessageRecvd
>              Counter32,
>           nhdpIfHelloMessageXmitAccumulatedSize
>              Counter64,
>           nhdpIfHelloMessageRecvdAccumulatedSize
>              Counter64,
>           nhdpIfHelloMessageTriggeredXmits
>              Counter32,
>           nhdpIfHelloMessagePeriodicXmits
>              Counter32,
>           nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
>              Counter32,
>           nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
>              Counter32,
>           nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
>              Counter32
>        }
>   
>   
> This draft contains similar objects in olsrv2InterfacePerfTable :
>   
>      Olsrv2InterfacePerfEntry ::=
>         SEQUENCE {
>            olsrv2IfTcMessageXmits
>               Counter32,
>            olsrv2IfTcMessageRecvd
>               Counter32,
>            olsrv2IfTcMessageXmitAccumulatedSize
>               Counter64,
>            olsrv2IfTcMessageRecvdAccumulatedSize
>               Counter64,
>            olsrv2IfTcMessageTriggeredXmits
>               Counter32,
>             olsrv2IfTcMessagePeriodicXmits
>               Counter32,
>            olsrv2IfTcMessageForwardedXmits
>               Counter32,
>            olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
>               Counter32
>         }
>   
>   
> Personally, I don't believe that those objects should be subject to the RFC
> 6390 template definition. (Performance Metric Definition Template, section
> 5.4.4, RFC 6390).
> First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was not
> subject to it
> Second reason: these objects are not really performance metrics, but mainly
> basic monitoring objects.
>   
> Since RFC 6779 uses the term performance information (in the abstract), I
> would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not
> the "performance metric". That would avoid some confusion. However, keeping
> the olsrv2InterfacePerfTable OID name is perfectly fine, for consistency
> reason with RFC 6779.
>   
> Regards, Benoit
>   
>
>
> Regards, Benoit
>
>     Classification: UNCLASSIFIED
>
>     Caveats: NONE
>
>       
>
>     Fred,
>
>       
>
>     There are two counters that are defined for performance metrics.   Please see
>
>     below.   As we stated it in Section 9 "Applicability Statement," ECDS-MIB is
>
>     an extension of SMF-MIB.   Thus, ECDS-MIB's inherited SMF-MIB's performance
>
>     metrics.   
>
>       
>
>     As I can see, ECDS-MIB does apply 6390's (i), (ii), (iii), and somewhat
>
>     (iv).   Please let me know if you have any suggestion to improve the draft.
>
>       
>
>       
>
>            (i) the degree to which its absence would cause significant loss
>
>            of information on the behavior or performance of the application
>
>            or system being measured
>
>       
>
>            (ii) the correlation between the Performance Metric, the QoS, and
>
>            the QoE delivered to the user (person or other application)
>
>       
>
>            (iii) the degree to which the Performance Metric is able to
>
>            support the identification and location of problems affecting
>
>            service quality
>
>       
>
>            (iv) the requirement to develop policies (Service Level Agreement,
>
>            and potentially Service Level Contract) based on the Performance
>
>             Metric
>
>       
>
>       
>
>       
>
>     --
>
>       -- E-CDS Performance Group
>
>       --
>
>       
>
>       ecdsPerformanceGroup OBJECT IDENTIFIER ::= { ecdsMIBObjects 3 }
>
>       
>
>       ecdsInEcdsChange OBJECT-TYPE
>
>               SYNTAX           Counter32
>
>               MAX-ACCESS       read-only
>
>               STATUS           current
>
>               DESCRIPTION
>
>                       "This object indicates how many times the current
>
>                        node is configured to be in E-CDS."
>
>       ::= { ecdsPerformanceGroup 1 }
>
>       
>
>       ecdsCurrentRtrPriValueChange OBJECT-TYPE
>
>               SYNTAX           Counter32
>
>               MAX-ACCESS       read-only
>
>               STATUS           current
>
>               DESCRIPTION
>
>                       "This object indicates how many times the Router
>
>                        Priority of the current node has been changed."
>
>       ::= { ecdsPerformanceGroup 2 }
>
>       
>
>       
>
>       
>
>     James Nguyen
>
>     US Army CERDEC S&TCD
>
>     Email:james.h.nguyen4.civ@mail.mil  <mailto:james.h.nguyen4.civ@mail.mil>
>
>     Phone:   443-395-5628
>
>       
>
>       
>
>     -----Original Message-----
>
>     From: Fred Baker [mailto:fred@cisco.com]
>
>     Sent: Thursday, May 23, 2013 11:12 AM
>
>     To:draft-nguyen-manet-ecds-mib@tools.ietf.org  <mailto:draft-nguyen-manet-ecds-mib@tools.ietf.org>
>
>     Cc:bclaise@cisco.com  <mailto:bclaise@cisco.com>
>
>     Subject: draft-nguyen-manet-ecds-mib and Performance Metrics
>
>       
>
>     Hi:
>
>       
>
>     I have a question for you. Your document mentions performance metrics.
>
>     Would you kindly take a look at RFC 6390 to see if any of its considerations
>
>     apply to it?   "No" is an acceptable response, of course; the point is to ask
>
>     the question.
>
>       
>
>     6390 Guidelines for Considering New Performance Metric Development. A.
>
>           Clark, B. Claise. October 2011. (Format: TXT=49930 bytes) (Also
>
>           BCP0170) (Status: BEST CURRENT PRACTICE)
>
>       
>
>       
>
>     Classification: UNCLASSIFIED
>
>     Caveats: NONE
>
>       
>
>       
>


--------------030609020605040409000007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi Adrian,<br>
      <br>
    </div>
    <blockquote cite="mid:056b01ce5860$bafed290$30fc77b0$@olddog.co.uk"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="ProgId" content="Word.Document">
      <meta name="Generator" content="Microsoft Word 14">
      <meta name="Originator" content="Microsoft Word 14">
      <link rel="File-List" href="cid:filelist.xml@01CE5868.A47C5DA0">
      <!--[if gte mso 9]><xml>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
</o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:WordDocument>
<w:SpellingState>Clean</w:SpellingState>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:EnvelopeVis/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>EN-GB</w:LidThemeOther>
<w:LidThemeAsian>X-NONE</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:DoNotExpandShiftReturn/>
<w:BreakWrappedTables/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val="Cambria Math"/>
<m:brkBin m:val="before"/>
<m:brkBinSub m:val="&#45;-"/>
<m:smallFrac m:val="off"/>
<m:dispDef/>
<m:lMargin m:val="0"/>
<m:rMargin m:val="0"/>
<m:defJc m:val="centerGroup"/>
<m:wrapIndent m:val="1440"/>
<m:intLim m:val="subSup"/>
<m:naryLim m:val="undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true" DefSemiHidden="true" DefQFormat="false" DefPriority="99" LatentStyleCount="267">
<w:LsdException Locked="false" Priority="0" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" Priority="39" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" Name="toc 9"/>
<w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" Priority="10" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" Priority="11" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" Priority="22" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" Priority="59" SemiHidden="false" UnhideWhenUsed="false" Name="Table Grid"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false" UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false" UnhideWhenUsed="false" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false" UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false" UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false" UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false" UnhideWhenUsed="false" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false" UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" SemiHidden="false" UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
</w:LatentStyles>
</xml><![endif]-->
      <style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-536870145 1073786111 1 0 415 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-520081665 -1073717157 41 0 66047 0;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:modern;
	mso-font-pitch:fixed;
	mso-font-signature:-520092929 1073806591 9 0 415 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:purple;
	text-decoration:underline;
	text-underline:single;}
pre
	{mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:Calibri;
	color:black;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;
	mso-ascii-font-family:Consolas;
	mso-fareast-font-family:Calibri;
	mso-hansi-font-family:Consolas;
	mso-bidi-font-family:Consolas;
	color:black;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-style-unhide:no;
	mso-ansi-font-size:11.0pt;
	mso-bidi-font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-fareast-font-family:Calibri;
	mso-hansi-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	font-size:10.0pt;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;
	mso-header-margin:36.0pt;
	mso-footer-margin:36.0pt;
	mso-paper-source:0;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 10]><style>/* Style Definitions */
table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman","serif";}
</style><![endif]--><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D">Hi Benoit,<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D">Thanks for cutting me in on
            this thread.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D">I do think this type of
            discussion should take place on WG mailing lists so I am
            copying MANET on this reply.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D">It appears that the phrase
            "performance metric" causes alarm bells to ring in several
            fire stations around the world. Although I strongly resent
            words or phrases being captured for more specific and
            focused meaning than they deserve, it is also clear that the
            pain caused by having a hundred firemen show up on your
            doorstep at 3am is sufficient (unless you like firemen at
            3am ;-) to warrant taking Benoit's advice.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D">- Avoid the term "performance
            metric" unless you mean it in the<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D"> <span
              style="mso-spacerun:yes">&nbsp;</span>sense of RFC 6390 (or be
            prepared to have a fight)</span></p>
      </div>
    </blockquote>
    This is simply not correct!<br>
    Based on my two messages below (for the 2 drafts):<br>
    <blockquote>
      <pre>Since RFC 6779 uses the term performance information (in the abstract), I<o:p></o:p></pre>
      <pre>would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not<o:p></o:p></pre>
      <pre>the "performance metric". That would avoid some confusion.

...

<span style="mso-fareast-font-family:&quot;Times New Roman&quot;">Like 
Ulrich did for draft-ietf-manet-olsrv2-mib, it might better to use 
"performance information" instead of "performance metrics" in your 
draft.</span>
</pre>
    </blockquote>
    These are advice, and should be considered as such.<br>
    <br>
    Regards, Benoit<br>
    <pre>
</pre>
    <blockquote cite="mid:056b01ce5860$bafed290$30fc77b0$@olddog.co.uk"
      type="cite">
      <div class="WordSection1">
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D"><o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D">- Use the term "performance
            information" or maybe "performance<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D"><span
              style="mso-spacerun:yes">&nbsp; </span>counters"<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D">&lt;VBS&gt;<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D">Adrian<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;mso-bidi-font-family:&quot;Times
            New Roman&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
        <div style="border:none;border-left:solid blue 1.5pt;padding:0cm
          0cm 0cm 4.0pt">
          <div>
            <div style="border:none;border-top:solid #B5C4DF
              1.0pt;padding:3.0pt 0cm 0cm 0cm">
              <p class="MsoNormal"><b><span
                    style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;mso-fareast-font-family:&quot;Times
                    New
                    Roman&quot;;color:windowtext;mso-ansi-language:EN-US"
                    lang="EN-US">From:</span></b><span
                  style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;;mso-fareast-font-family:&quot;Times
                  New
                  Roman&quot;;color:windowtext;mso-ansi-language:EN-US"
                  lang="EN-US"> Benoit Claise [<a class="moz-txt-link-freetext" href="mailto:bclaise@cisco.com">mailto:bclaise@cisco.com</a>]
                  <br>
                  <b>Sent:</b> 24 May 2013 09:33<br>
                  <b>To:</b> Nguyen, James H CIV USARMY CERDEC (US)<br>
                  <b>Cc:</b> Fred Baker;
                  <a class="moz-txt-link-abbreviated" href="mailto:draft-nguyen-manet-ecds-mib@tools.ietf.org">draft-nguyen-manet-ecds-mib@tools.ietf.org</a>; me;
                  <a class="moz-txt-link-abbreviated" href="mailto:draft-ietf-manet-smf-mib@tools.ietf.org">draft-ietf-manet-smf-mib@tools.ietf.org</a>;
                  <a class="moz-txt-link-abbreviated" href="mailto:pm-dir@ietf.org">pm-dir@ietf.org</a>; Adrian Farrel<br>
                  <b>Subject:</b> Re: draft-nguyen-manet-ecds-mib and
                  Performance Metrics (UNCLASSIFIED)<o:p></o:p></span></p>
            </div>
          </div>
          <p class="MsoNormal"><o:p>&nbsp;</o:p></p>
          <div>
            <p class="MsoNormal"><span
                style="mso-fareast-font-family:&quot;Times New
                Roman&quot;">Hi James, draft-ietf-manet-smf-mib authors,<br>
                <br>
                Agreed, RFC 6390 doesn't apply here.<br>
                See the email exchange regarding
                draft-ietf-manet-olsrv2-mib below, which I reviewed part
                of the performance metric directorate.<br>
                Like Ulrich did for draft-ietf-manet-olsrv2-mib, it
                might better to use "performance information" instead of
                "performance metrics" in your draft.<o:p></o:p></span></p>
            <pre>Benoit,<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>thank you very much for this review. I agree that using the term<o:p></o:p></pre>
            <pre>"performance information" instead of "performance metrics" is a good<o:p></o:p></pre>
            <pre>idea. We will make the change.<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>Best regards<o:p></o:p></pre>
            <pre>Ulrich<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise <a moz-do-not-send="true" href="mailto:bclaise@cisco.com">&lt;bclaise@cisco.com&gt;</a> wrote:<o:p></o:p></pre>
            <pre>Dear all,<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>I reviewed <a moz-do-not-send="true" href="http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06">http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06</a>, from a<o:p></o:p></pre>
            <pre>performance metric directorate point of view.<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>This draft doesn't contain any reference to RFC6390, but contains<o:p></o:p></pre>
            <pre>"performance metric". Hence this review was triggered. For details about the<o:p></o:p></pre>
            <pre>directorate, see<o:p></o:p></pre>
            <pre><a moz-do-not-send="true" href="http://www.ietf.org/iesg/directorate/performance-metrics.html">http://www.ietf.org/iesg/directorate/performance-metrics.html</a><o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>Definition of Managed Objects for the<span style="mso-spacerun:yes">&nbsp; </span>Optimized Link State Routing<o:p></o:p></pre>
            <pre>Protocol version 2<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>Abstract<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp; </span>This document defines the Management Information Base (MIB) module<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp; </span>for configuring and managing the Optimized Link State Routing<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp; </span>protocol version 2 (OLSRv2).<span style="mso-spacerun:yes">&nbsp; </span>The OLSRv2-MIB module is structured<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp; </span>into state information, performance metrics, and notifications.<span style="mso-spacerun:yes">&nbsp; </span>This<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp; </span>additional state and performance information is useful to<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp; </span><span style="mso-spacerun:yes">&nbsp;</span>troubleshoot problems and performance issues of the routing protocol.<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp; </span>Different levels of compliance allow implementers to use smaller<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp; </span>subsets of all defined objects, allowing for this MIB module to be<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp; </span>deployed on more constrained routers.<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>Basically, all performance metrics come from this table:<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp; </span>o<span style="mso-spacerun:yes">&nbsp; </span>olsrv2InterfacePerfTable - records performance counters for each<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>active OLSRv2 interface on this device. selected path to each<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>destination for which any such path is known.<span style="mso-spacerun:yes">&nbsp; </span>This table has<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed via<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>nhdpIfIndex from the NHDP-MIB.<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>NHDP-MIB is RFC 6779:<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp; </span>NhdpInterfacePerfEntry ::=<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>SEQUENCE {<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>nhdpIfHelloMessageXmits<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>nhdpIfHelloMessageRecvd<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>nhdpIfHelloMessageXmitAccumulatedSize<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter64,<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>nhdpIfHelloMessageRecvdAccumulatedSize<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter64,<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>nhdpIfHelloMessageTriggeredXmits<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>nhdpIfHelloMessagePeriodicXmits<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>nhdpIfHelloMessageXmitAccumulatedLostNeighborCount<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>}<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>This draft contains similar objects in olsrv2InterfacePerfTable :<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp; </span>Olsrv2InterfacePerfEntry ::=<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>SEQUENCE {<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>olsrv2IfTcMessageXmits<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>olsrv2IfTcMessageRecvd<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>olsrv2IfTcMessageXmitAccumulatedSize<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter64,<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>olsrv2IfTcMessageRecvdAccumulatedSize<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter64,<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>olsrv2IfTcMessageTriggeredXmits<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="mso-spacerun:yes">&nbsp;&nbsp;</span>olsrv2IfTcMessagePeriodicXmits<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>olsrv2IfTcMessageForwardedXmits<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32,<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>}<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>Personally, I don't believe that those objects should be subject to the RFC<o:p></o:p></pre>
            <pre>6390 template definition. (Performance Metric Definition Template, section<o:p></o:p></pre>
            <pre>5.4.4, RFC 6390).<o:p></o:p></pre>
            <pre>First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was not<o:p></o:p></pre>
            <pre>subject to it<o:p></o:p></pre>
            <pre>Second reason: these objects are not really performance metrics, but mainly<o:p></o:p></pre>
            <pre>basic monitoring objects.<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>Since RFC 6779 uses the term performance information (in the abstract), I<o:p></o:p></pre>
            <pre>would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not<o:p></o:p></pre>
            <pre>the "performance metric". That would avoid some confusion. However, keeping<o:p></o:p></pre>
            <pre>the olsrv2InterfacePerfTable OID name is perfectly fine, for consistency<o:p></o:p></pre>
            <pre>reason with RFC 6779.<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>Regards, Benoit<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <p class="MsoNormal"><span
                style="mso-fareast-font-family:&quot;Times New
                Roman&quot;"><br>
                Regards, Benoit<o:p></o:p></span></p>
          </div>
          <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
            <pre>Classification: UNCLASSIFIED<o:p></o:p></pre>
            <pre>Caveats: NONE<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>Fred,<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>There are two counters that are defined for performance metrics.<span style="mso-spacerun:yes">&nbsp; </span>Please see<o:p></o:p></pre>
            <pre>below.<span style="mso-spacerun:yes">&nbsp; </span>As we stated it in Section 9 "Applicability Statement," ECDS-MIB is<o:p></o:p></pre>
            <pre>an extension of SMF-MIB.<span style="mso-spacerun:yes">&nbsp; </span>Thus, ECDS-MIB's inherited SMF-MIB's performance<o:p></o:p></pre>
            <pre>metrics.<span style="mso-spacerun:yes">&nbsp; </span><o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>As I can see, ECDS-MIB does apply 6390's (i), (ii), (iii), and somewhat<o:p></o:p></pre>
            <pre>(iv).<span style="mso-spacerun:yes">&nbsp; </span>Please let me know if you have any suggestion to improve the draft.<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>(i) the degree to which its absence would cause significant loss<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>of information on the behavior or performance of the application<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>or system being measured<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>(ii) the correlation between the Performance Metric, the QoS, and<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>the QoE delivered to the user (person or other application)<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>(iii) the degree to which the Performance Metric is able to<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>support the identification and location of problems affecting<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>service quality<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>(iv) the requirement to develop policies (Service Level Agreement,<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>and potentially Service Level Contract) based on the Performance<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp; </span><span style="mso-spacerun:yes">&nbsp;</span>Metric<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>--<o:p></o:p></pre>
            <pre> -- E-CDS Performance Group<o:p></o:p></pre>
            <pre> --<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre> ecdsPerformanceGroup OBJECT IDENTIFIER ::= { ecdsMIBObjects 3 }<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre> ecdsInEcdsChange OBJECT-TYPE<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>SYNTAX<span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>MAX-ACCESS<span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>read-only<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>STATUS<span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>current<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>DESCRIPTION<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>"This object indicates how many times the current<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>node is configured to be in E-CDS."<o:p></o:p></pre>
            <pre> ::= { ecdsPerformanceGroup 1 }<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre> ecdsCurrentRtrPriValueChange OBJECT-TYPE<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>SYNTAX<span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Counter32<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>MAX-ACCESS<span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>read-only<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>STATUS<span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>current<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>DESCRIPTION<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>"This object indicates how many times the Router<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Priority of the current node has been changed."<o:p></o:p></pre>
            <pre> ::= { ecdsPerformanceGroup 2 }<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>James Nguyen<o:p></o:p></pre>
            <pre>US Army CERDEC S&amp;TCD<o:p></o:p></pre>
            <pre>Email: <a moz-do-not-send="true" href="mailto:james.h.nguyen4.civ@mail.mil">james.h.nguyen4.civ@mail.mil</a><o:p></o:p></pre>
            <pre>Phone:<span style="mso-spacerun:yes">&nbsp; </span>443-395-5628<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>-----Original Message-----<o:p></o:p></pre>
            <pre>From: Fred Baker [<a moz-do-not-send="true" href="mailto:fred@cisco.com">mailto:fred@cisco.com</a>] <o:p></o:p></pre>
            <pre>Sent: Thursday, May 23, 2013 11:12 AM<o:p></o:p></pre>
            <pre>To: <a moz-do-not-send="true" href="mailto:draft-nguyen-manet-ecds-mib@tools.ietf.org">draft-nguyen-manet-ecds-mib@tools.ietf.org</a><o:p></o:p></pre>
            <pre>Cc: <a moz-do-not-send="true" href="mailto:bclaise@cisco.com">bclaise@cisco.com</a><o:p></o:p></pre>
            <pre>Subject: draft-nguyen-manet-ecds-mib and Performance Metrics<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>Hi:<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>I have a question for you. Your document mentions performance metrics.<o:p></o:p></pre>
            <pre>Would you kindly take a look at RFC 6390 to see if any of its considerations<o:p></o:p></pre>
            <pre>apply to it?<span style="mso-spacerun:yes">&nbsp; </span>"No" is an acceptable response, of course; the point is to ask<o:p></o:p></pre>
            <pre>the question.<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>6390 Guidelines for Considering New Performance Metric Development. A.<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp; </span>Clark, B. Claise. October 2011. (Format: TXT=49930 bytes) (Also<o:p></o:p></pre>
            <pre><span style="mso-spacerun:yes">&nbsp;&nbsp;&nbsp;&nbsp; </span>BCP0170) (Status: BEST CURRENT PRACTICE)<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre>Classification: UNCLASSIFIED<o:p></o:p></pre>
            <pre>Caveats: NONE<o:p></o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
            <pre><o:p>&nbsp;</o:p></pre>
          </blockquote>
          <p class="MsoNormal"><span
              style="mso-fareast-font-family:&quot;Times New
              Roman&quot;"><o:p>&nbsp;</o:p></span></p>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------030609020605040409000007--

From fred@cisco.com  Thu May 23 21:07:28 2013
Return-Path: <fred@cisco.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C47021F94F9 for <pm-dir@ietfa.amsl.com>; Thu, 23 May 2013 21:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.395
X-Spam-Level: 
X-Spam-Status: No, score=-110.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNu9MX0Mvg+N for <pm-dir@ietfa.amsl.com>; Thu, 23 May 2013 21:07:16 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id DA58F21F93F6 for <pm-dir@ietf.org>; Thu, 23 May 2013 21:07:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7260; q=dns/txt; s=iport; t=1369368436; x=1370578036; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hYLrk7Ee10VqzfZC0Hag5gh34kHVQH7ZaD+L3bTyuYY=; b=H3MQ6keBYxmvXaGic7Cok110r+V0DTkm58RMOrSWicldOrKFMMI+eTBz MsIBYN4PL4WYhoodXD8Cw4cGivnmZuYnWst32/PZcLvduBe9+87Enh7y3 xj/bU5T3CvwRVpBWPN5foDv3Vie0eU8pj31mgApUlTLWl88m5sqTvjmda 8=;
X-Files: get-refs : 2846
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmoYADXnnlGtJXG//2dsb2JhbABZgwgwuzSGdIELFnSCIwEBAQMBeQULAgEIEQQBAQskAjAdCAIEDgUIBodxCAYMtiOEGo1bgRExB4JzYQOPfohmkBeDD4FxNQ
X-IronPort-AV: E=Sophos;i="4.87,732,1363132800"; d="scan'208";a="214513427"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 24 May 2013 04:07:15 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4O47FRB017899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 May 2013 04:07:15 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 23 May 2013 23:07:14 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: "MORTON JR., ALFRED C (AL)" <acmorton@att.com>
Thread-Topic: [pm-dir] Fwd: Re:  Performance metrics doctors generated email
Thread-Index: AQHOWBOs0Sy2SHvZB0SicB2nSzHvLJkUC/6A
Date: Fri, 24 May 2013 04:07:14 +0000
Message-ID: <8C48B86A895913448548E6D15DA7553B8F53D0@xmb-rcd-x09.cisco.com>
References: <8C48B86A895913448548E6D15DA7553B8F4454@xmb-rcd-x09.cisco.com>, <519E8E13.9090002@cisco.com> <F1312FAF1A1E624DA0972D1C9A91379A1C9F20EB12@njfpsrvexg7.research.att.com>
In-Reply-To: <F1312FAF1A1E624DA0972D1C9A91379A1C9F20EB12@njfpsrvexg7.research.att.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.19.64.117]
Content-Type: multipart/mixed; boundary="_002_8C48B86A895913448548E6D15DA7553B8F53D0xmbrcdx09ciscocom_"
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 24 May 2013 04:59:34 -0700
Cc: "Benoit Claise \(bclaise\)" <bclaise@cisco.com>, "pm-dir@ietf.org" <pm-dir@ietf.org>
Subject: Re: [pm-dir] Fwd: Re:  Performance metrics doctors generated email
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2013 04:07:28 -0000

--_002_8C48B86A895913448548E6D15DA7553B8F53D0xmbrcdx09ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25B234A583B54C4C972A1B3FFBF36B7A@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable

I'm not sure what you're asking for. If by "Fred's script" you mean the scr=
ipt that Benoit runs, have at it. If you mean the script I ran this morning=
, it's actually two. I have attached a small perl script I wrote some years=
 ago and find useful; I think of it as a "paragraph grep". It's arguments a=
re

get-refs <file> [-nc] [-word]* [word]*
      The file is a text file
      -nc means to observe case; by default it is case-agnostic
      -<word> means that if the word is present in a paragraph, do NOT expo=
rt the paragraph=20
      <word> means that if the word is present in a paragraph, DO export th=
e paragraph=20

It basically prints out paragraphs (in the 1-or-more 60-column line sense) =
that contain one or more of the <words> and none of the -<words>. A word, b=
y the way, may contain an arbitrary amount of white space including line fe=
eds.

With this in hand, I then wrote

#!/bin/csh
foreach draft ($*)
     echo $draft
     echo ' '
     get-refs $draft 'performance metric'
end

It would be simple enough to pipe that into a file and take a diff -c -w ag=
ainst the previous week's version.


On May 23, 2013, at 5:14 PM, "MORTON JR., ALFRED C (AL)" <acmorton@att.com>
 wrote:

> Nice, a few paragraphs from the draft provide enough context=20
> to see if the use of "performance metric" is something the Directorate
> should consider.  Thanks Fred.
>=20
> As I've said in the past, if we were running Fred's script weekly,
> we would need to consider only on the diffs from last week,
> so we can add new reviewer assignments.  Since this benefits me
> the most, I'd be willing to add the differencing lines to the script...
>=20
> Without carping on too long here, we have quite a few outstanding assignm=
ents
> and drafts needing volunteers to review:
> https://docs.google.com/spreadsheet/ccc?key=3D0AmKrqWIOBsprdGZqMnB6dmx5bF=
JvVUhta3VLSjl3SkE#gid=3D0
>=20
> regards,
> Al
>=20
> ________________________________________
> From: pm-dir-bounces@ietf.org [pm-dir-bounces@ietf.org] On Behalf Of Beno=
it Claise [bclaise@cisco.com]
> Sent: Thursday, May 23, 2013 5:45 PM
> To: pm-dir@ietf.org
> Cc: Fred Baker
> Subject: [pm-dir] Fwd: Re:  Performance metrics doctors generated email
>=20
> Dear pm-dir,
>=20
> Some more help from Fred.
> All the drafts containing "performance metrics", along with the specific
> section.
> That should help identifying the drafts that are important to review.
>=20
> Regards, Benoit

------------------------------------------------------
8 issues in virtual infrastructure
http://dcrocker.net/#fallacies


--_002_8C48B86A895913448548E6D15DA7553B8F53D0xmbrcdx09ciscocom_
Content-Type: application/octet-stream; name="get-refs"
Content-Description: get-refs
Content-Disposition: attachment; filename="get-refs"; size=2846;
	creation-date="Fri, 24 May 2013 04:07:14 GMT";
	modification-date="Fri, 24 May 2013 04:07:14 GMT"
Content-ID: <386A9D5B461C2842A760ECA4905EAB45@emea.cisco.com>
Content-Transfer-Encoding: base64

IyEvdXNyL2Jpbi9wZXJsIC13IA0KIw0KIyBzb3J0IG9mIGEgcGFyYWdyYXBoIGdyZXANCiMgdXNh
Z2U6IGdldC1yZWZzIHsgLSB8IDxmaWxlPiB9IFstbmNdIHtzZWFyY2ggdGFnc30NCiMgYSBzZWFy
Y2ggdGFnIGlzIGJ5IGRlZmluaXRpb24gc29tZXRoaW5nIHRoYXQgZWl0aGVyIGluY2x1ZGVzIG9y
IGV4Y2x1ZGVzDQojIGEgcGFyYWdyYXBoIGZyb20gY29uc2lkZXJhdGlvbi4gdGhlIGNoYXJhY3Rl
ciAnLScgbWFrZXMgaXQgYW4gZXhjbHVzaW9uLg0KDQpAaW5jbHVkZXMgICA9ICgpOw0KQGV4Y2x1
ZGVzICAgPSAoKTsNCiRwYXJhZ3JhcGggID0gJyc7DQokaWdub3JlY2FzZSA9ICd5ZXMnOw0KDQoj
UGFyc2UgYXJndW1lbnRzIGludG8gYSBmaWxlLCBhbiBleGNsdXNpb24gbGlzdCwgYW5kIGluIGlu
Y2x1c2lvbiBsaXN0DQoNCmlmICggJCNBUkdWIDwgMSApIHsNCiAgICBwcmludGYgU1RERVJSICJ1
c2FnZTogZ2V0LXJlZnMgeyAtIHwgPGZpbGU+IH0gWy1uY10gezxzZWFyY2ggdGFncz4gW3stYW5k
fC1BTkR9IHN0ZWFyY2ggdGFnXSp9XG4iOw0KICAgIHByaW50ZiBTVERFUlIgIiAgICAgICAnLScg
cmVhZHMgU1RESU5cbiI7DQogICAgcHJpbnRmIFNUREVSUiAiICAgICAgICc8ZmlsZT4nIHJlYWRz
IHRoZSBmaWxlXG4iOw0KICAgIHByaW50ZiBTVERFUlIgIiAgICAgICAnLW5jJyB0ZWxscyBpdCB0
byBpZ25vcmUgY2FzZVxuIjsNCiAgICBwcmludGYgU1RERVJSICIgICAgICAgPHNlYXJjaCB0YWdz
PjogcHJpbnQgcGFyYWdyYXBocyBjb250YWluaW5nIHRoZXNlIGNoYXJhY3RlciBzdHJpbmdzXG4i
Ow0KICAgIHByaW50ZiBTVERFUlIgIiAgICAgICAnLWFuZCcgcmVxdWlyZXMgQUxTTyB0aGUgZm9s
bG93aW5nIHNlYXJjaCB0YWdcbiI7DQogICAgZXhpdCAxOw0KfQ0KDQokZmlsZSA9IHNoaWZ0IEBB
UkdWOw0KDQpwYXJzZToNCmZvcmVhY2ggJHdvcmQgKDAuLiQjQVJHVikgew0KICAgIG5leHQgcGFy
c2UgaWYgKCAnJyBlcSAkQVJHVlskd29yZF0gKTsNCiAgICBAd29yZHMgPSBzcGxpdCAvXHMrLywg
JEFSR1ZbJHdvcmRdOw0KICAgICRzdHJpbmcgPSBqb2luICdccysnLCBAd29yZHM7DQogICAgaWYg
KCAkc3RyaW5nIGVxICctbmMnICkgew0KICAgICAgICAkaWdub3JlY2FzZSA9ICdubyc7DQogICAg
fQ0KICAgIGVsc2lmICggJHN0cmluZyA9fiAvXi0vICkgew0KICAgICAgICBwdXNoIEBleGNsdWRl
cywgc3Vic3RyKCAkc3RyaW5nLCAxICk7DQogICAgfQ0KICAgIGVsc2Ugew0KICAgICAgICBwdXNo
IEBpbmNsdWRlcywgJHN0cmluZzsNCiAgICB9DQp9DQoNCiMgc2NhbiB0aGUgZmlsZQ0KDQppZiAo
ICctJyBlcSAkZmlsZSApIHsNCiAgICBzZWFyY2goU1RESU4pOw0KfQ0KZWxzZSB7DQogICAgb3Bl
biBGSUxFLCAnPCcsICRmaWxlIG9yIGRpZSAidXNhZ2U6IGdldC1yZWZzIDxmaWxlPiB7c2VhcmNo
IHRhZ3N9XG4iOw0KICAgIHNlYXJjaChGSUxFKTsNCiAgICBjbG9zZSBGSUxFOw0KfQ0KDQojIHNl
YXJjaCBwYXJhZ3JhcGhzOyBwdWxsZWQgdG8gYSBzdWJyb3V0aW5lIHRvIG1ha2UgU1RESU4gdnMg
RklMRSB3b3JrDQpzdWIgc2VhcmNoIHsNCiAgICBteSAkaW5wdXQgPSBzaGlmdDsNCiAgICBkbyB7
DQogICAgICAgICRwYXJhZ3JhcGggPSAnJzsNCiAgICAgICAgJG9rICAgICAgICA9ICcnOw0KDQog
ICAgICAgICMgY29uY2F0ZW5hdGUgbGluZXMgdG8gZm9ybSBhIHBhcmFncmFwaA0KICAgICAgbGlu
ZToNCiAgICAgICAgd2hpbGUgKDwkaW5wdXQ+KSB7DQoNCiAgICAgICAgICAgICNwcmludGYgIiVz
IiwgJF87DQogICAgICAgICAgICB3aGlsZSAoL1xzJC8pIHsNCiAgICAgICAgICAgICAgICBjaG9w
OyAgICAjIHJlbW92ZSB0cmFpbGluZyB3aGl0ZSBzcGFjZQ0KICAgICAgICAgICAgfQ0KICAgICAg
ICAgICAgJHBhcmFncmFwaCA9ICRwYXJhZ3JhcGggLiAkXyAuICJcbiI7DQogICAgICAgICAgICBs
YXN0IGxpbmUgaWYgKC9eJC8pOw0KICAgICAgICB9DQoNCiAgICAgICAgIyBkbyB3ZSBoYXZlIGFu
ICJleGNsdWRlIiBoaXQ/IElnbm9yZSBjYXNlLg0KICAgICAgICBmb3JlYWNoICR3b3JkIChAZXhj
bHVkZXMpIHsNCiAgICAgICAgICAgIGlmICggJ3llcycgZXEgJGlnbm9yZWNhc2UgKSB7DQogICAg
ICAgICAgICAgICAgJG9rID0gJ25vJyBpZiAoICRwYXJhZ3JhcGggPX4gLyR3b3JkL2kgKTsNCiAg
ICAgICAgICAgIH0NCiAgICAgICAgICAgIGVsc2Ugew0KICAgICAgICAgICAgICAgICRvayA9ICdu
bycgaWYgKCAkcGFyYWdyYXBoID1+IC8kd29yZC8gKTsNCiAgICAgICAgICAgIH0NCiAgICAgICAg
fQ0KDQogICAgICAgIGlmICggJ25vJyBuZSAkb2sgKSB7DQoNCiAgICAgICAgICAgICMgZG8gd2Ug
aGF2ZSBhbiAiaW5jbHVkZSIgaGl0PyBJZ25vcmUgY2FzZS4NCiAgICAgICAgICAgIGZvcmVhY2gg
JHdvcmQgKEBpbmNsdWRlcykgew0KICAgICAgICAgICAgICAgIGlmICggJ3llcycgZXEgJGlnbm9y
ZWNhc2UgKSB7DQogICAgICAgICAgICAgICAgICAgICRvayA9ICd5ZXMnIGlmICggJHBhcmFncmFw
aCA9fiAvJHdvcmQvaSApOw0KICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICBlbHNl
IHsNCiAgICAgICAgICAgICAgICAgICAgJG9rID0gJ3llcycgaWYgKCAkcGFyYWdyYXBoID1+IC8k
d29yZC8gKTsNCiAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICB9DQoNCiAgICAgICAgICAg
ICMgaWYgd2UgZm91bmQgYW4gImluY2x1ZGUiIGhpdCwgcHJpbnQgdGhlIHBhcmFncmFwaCBvdXQN
CiAgICAgICAgICAgIHByaW50ZiBTVERPVVQgIiVzIiwgJHBhcmFncmFwaCBpZiAoICd5ZXMnIGVx
ICRvayApOw0KICAgICAgICB9DQogICAgfSB1bnRpbCAoIGVvZigkaW5wdXQpICk7DQp9DQo=

--_002_8C48B86A895913448548E6D15DA7553B8F53D0xmbrcdx09ciscocom_--

From acmorton@att.com  Fri May 24 05:18:45 2013
Return-Path: <acmorton@att.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5315821F9608 for <pm-dir@ietfa.amsl.com>; Fri, 24 May 2013 05:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.396
X-Spam-Level: 
X-Spam-Status: No, score=-106.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPpkwmvJHV+5 for <pm-dir@ietfa.amsl.com>; Fri, 24 May 2013 05:18:39 -0700 (PDT)
Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 77ED921F9648 for <pm-dir@ietf.org>; Fri, 24 May 2013 05:18:36 -0700 (PDT)
Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 459BA1201D5; Fri, 24 May 2013 08:18:35 -0400 (EDT)
Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-blue.research.att.com (Postfix) with ESMTP id EAF2FF0367; Fri, 24 May 2013 08:18:35 -0400 (EDT)
Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Fri, 24 May 2013 08:18:35 -0400
From: "MORTON JR., ALFRED C (AL)" <acmorton@att.com>
To: "Fred Baker (fred)" <fred@cisco.com>
Date: Fri, 24 May 2013 08:18:35 -0400
Thread-Topic: [pm-dir] Fwd: Re:  Performance metrics doctors generated email
Thread-Index: AQHOWBOs0Sy2SHvZB0SicB2nSzHvLJkUC/6AgAAu9oA=
Message-ID: <F1312FAF1A1E624DA0972D1C9A91379A1C9F469C4F@njfpsrvexg7.research.att.com>
References: <8C48B86A895913448548E6D15DA7553B8F4454@xmb-rcd-x09.cisco.com>, <519E8E13.9090002@cisco.com> <F1312FAF1A1E624DA0972D1C9A91379A1C9F20EB12@njfpsrvexg7.research.att.com> <8C48B86A895913448548E6D15DA7553B8F53D0@xmb-rcd-x09.cisco.com>
In-Reply-To: <8C48B86A895913448548E6D15DA7553B8F53D0@xmb-rcd-x09.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Benoit Claise \(bclaise\)" <bclaise@cisco.com>, "pm-dir@ietf.org" <pm-dir@ietf.org>
Subject: Re: [pm-dir] Fwd: Re:  Performance metrics doctors generated email
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2013 12:18:45 -0000

> -----Original Message-----
> From: Fred Baker (fred) [mailto:fred@cisco.com]
...
> With this in hand, I then wrote
>=20
> #!/bin/csh
> foreach draft ($*)
>      echo $draft
>      echo ' '
>      get-refs $draft 'performance metric'
> end
>=20
> It would be simple enough to pipe that into a file and take a diff -c -w
> against the previous week's version.
>=20

Yes, that's what I was thinking more or less, running on Benoit's host that
generates weekly e-mail to the pm-dir list.

thanks,
Al


From robert.g.cole.civ@mail.mil  Fri May 24 05:55:15 2013
Return-Path: <robert.g.cole.civ@mail.mil>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F3A21F8FDC; Fri, 24 May 2013 05:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZFqiDtTiGcK; Fri, 24 May 2013 05:55:10 -0700 (PDT)
Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6461121F85EE; Fri, 24 May 2013 05:55:10 -0700 (PDT)
Received: from UCOLHP3P.easf.csd.disa.mil (131.64.100.155) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 24 May 2013 12:55:04 +0000
Received: from UCOLHP9H.easf.csd.disa.mil ([169.254.5.190]) by UCOLHP3P.easf.csd.disa.mil ([131.64.100.155]) with mapi id 14.03.0123.003; Fri, 24 May 2013 12:54:56 +0000
From: "Cole, Robert G CIV USARMY CERDEC (US)" <robert.g.cole.civ@mail.mil>
To: Benoit Claise <bclaise@cisco.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Thread-Topic: draft-nguyen-manet-ecds-mib and Performance Metrics (UNCLASSIFIED)
Thread-Index: AQHOV8sGWVHgdInXtkehgls0oum9CZkUAuEAgAAO/ACAAAosAIAALgeQ
Date: Fri, 24 May 2013 12:54:51 +0000
Message-ID: <B9468E58D6A0A84AAD66FE4E694BEABB55E30AE6@ucolhp9h.easf.csd.disa.mil>
References: <201305231512.r4NFCMN4006908@irp-view13.cisco.com> <3DC26342A93F204C804384C87DDBECBF3DADF508@ucolhp9k.easf.csd.disa.mil> <519F25A0.70502@cisco.com> <056b01ce5860$bafed290$30fc77b0$@olddog.co.uk> <519F3ABA.6090703@cisco.com>
In-Reply-To: <519F3ABA.6090703@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [131.64.62.4]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0012_01CE585C.5BFCC210"
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 24 May 2013 05:58:28 -0700
Cc: "Nguyen, James H CIV USARMY CERDEC \(US\)" <james.h.nguyen4.civ@mail.mil>, "manet@ietf.org" <manet@ietf.org>, "draft-nguyen-manet-ecds-mib@tools.ietf.org" <draft-nguyen-manet-ecds-mib@tools.ietf.org>, "draft-ietf-manet-smf-mib@tools.ietf.org" <draft-ietf-manet-smf-mib@tools.ietf.org>, 'Fred Baker' <fred@cisco.com>, "pm-dir@ietf.org" <pm-dir@ietf.org>
Subject: Re: [pm-dir] draft-nguyen-manet-ecds-mib and Performance Metrics (UNCLASSIFIED)
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2013 12:55:15 -0000

------=_NextPart_000_0012_01CE585C.5BFCC210
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Classification: UNCLASSIFIED
Caveats: NONE

I agree that we should be more precise in our naming and descriptions.  This
question is showing up often in our MIB discussions.  I have made it a habit
of placing these counters within a PerformanceGroup instead of a
StatisticsGroup because I felt that Statistics implied we were collecting
statistical data (e.g., averages) instead of performance data (counts).  But
I agree that using the term Performance Metric goes too far and is not a
correct description of the data.  Going forward I'll try to be more
consistent and use the term 'Performance Information' as you all suggest and
as we did in RFC 6779.

Thanks,
Bob

Robert G. Cole
Comm:  443.395.8744
Email: robert.g.cole@us.army.mil


-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com] 
Sent: Friday, May 24, 2013 6:03 AM
To: adrian@olddog.co.uk
Cc: Nguyen, James H CIV USARMY CERDEC (US); 'Fred Baker';
draft-nguyen-manet-ecds-mib@tools.ietf.org;
draft-ietf-manet-smf-mib@tools.ietf.org; pm-dir@ietf.org; manet@ietf.org
Subject: Re: draft-nguyen-manet-ecds-mib and Performance Metrics
(UNCLASSIFIED)

Hi Adrian,



	Hi Benoit,

	 

	Thanks for cutting me in on this thread.

	 

	I do think this type of discussion should take place on WG mailing
lists so I am copying MANET on this reply.

	 

	It appears that the phrase "performance metric" causes alarm bells
to ring in several fire stations around the world. Although I strongly
resent words or phrases being captured for more specific and focused meaning
than they deserve, it is also clear that the pain caused by having a hundred
firemen show up on your doorstep at 3am is sufficient (unless you like
firemen at 3am ;-) to warrant taking Benoit's advice.

	 

	- Avoid the term "performance metric" unless you mean it in the

	 sense of RFC 6390 (or be prepared to have a fight)

This is simply not correct!
Based on my two messages below (for the 2 drafts):


	Since RFC 6779 uses the term performance information (in the
abstract), I
	would propose that draft-ietf-manet-olsrv2-mib also uses this term,
and not
	the "performance metric". That would avoid some confusion.
	
	...
	
	Like 
	Ulrich did for draft-ietf-manet-olsrv2-mib, it might better to use 
	"performance information" instead of "performance metrics" in your 
	draft.

These are advice, and should be considered as such.

Regards, Benoit



	

	- Use the term "performance information" or maybe "performance

	  counters"

	 

	<VBS>

	 

	Adrian

	 

	From: Benoit Claise [mailto:bclaise@cisco.com
<blockedmailto:bclaise@cisco.com> ] 
	Sent: 24 May 2013 09:33
	To: Nguyen, James H CIV USARMY CERDEC (US)
	Cc: Fred Baker; draft-nguyen-manet-ecds-mib@tools.ietf.org; me;
draft-ietf-manet-smf-mib@tools.ietf.org; pm-dir@ietf.org; Adrian Farrel
	Subject: Re: draft-nguyen-manet-ecds-mib and Performance Metrics
(UNCLASSIFIED)

	 

	Hi James, draft-ietf-manet-smf-mib authors,
	
	Agreed, RFC 6390 doesn't apply here.
	See the email exchange regarding draft-ietf-manet-olsrv2-mib below,
which I reviewed part of the performance metric directorate.
	Like Ulrich did for draft-ietf-manet-olsrv2-mib, it might better to
use "performance information" instead of "performance metrics" in your
draft.

	Benoit,
	 
	thank you very much for this review. I agree that using the term
	"performance information" instead of "performance metrics" is a good
	idea. We will make the change.
	 
	Best regards
	Ulrich
	 
	On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise <bclaise@cisco.com>
<blockedmailto:bclaise@cisco.com>  wrote:
	Dear all,
	 
	I reviewed http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06
<blockedhttp://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06> , from a
	performance metric directorate point of view.
	 
	This draft doesn't contain any reference to RFC6390, but contains
	"performance metric". Hence this review was triggered. For details
about the
	directorate, see
	http://www.ietf.org/iesg/directorate/performance-metrics.html
<blockedhttp://www.ietf.org/iesg/directorate/performance-metrics.html> 
	 
	 
	Definition of Managed Objects for the  Optimized Link State Routing
	Protocol version 2
	 
	Abstract
	 
	   This document defines the Management Information Base (MIB)
module
	   for configuring and managing the Optimized Link State Routing
	   protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
	   into state information, performance metrics, and notifications.
This
	   additional state and performance information is useful to
	   troubleshoot problems and performance issues of the routing
protocol.
	   Different levels of compliance allow implementers to use smaller
	   subsets of all defined objects, allowing for this MIB module to
be
	   deployed on more constrained routers.
	 
	 
	Basically, all performance metrics come from this table:
	 
	   o  olsrv2InterfacePerfTable - records performance counters for
each
	      active OLSRv2 interface on this device. selected path to each
	      destination for which any such path is known.  This table has
	      AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed
via
	      nhdpIfIndex from the NHDP-MIB.
	 
	NHDP-MIB is RFC 6779:
	   NhdpInterfacePerfEntry ::=
	      SEQUENCE {
	         nhdpIfHelloMessageXmits
	            Counter32,
	         nhdpIfHelloMessageRecvd
	            Counter32,
	         nhdpIfHelloMessageXmitAccumulatedSize
	            Counter64,
	         nhdpIfHelloMessageRecvdAccumulatedSize
	            Counter64,
	         nhdpIfHelloMessageTriggeredXmits
	            Counter32,
	         nhdpIfHelloMessagePeriodicXmits
	            Counter32,
	         nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
	            Counter32,
	         nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
	            Counter32,
	         nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
	            Counter32
	      }
	 
	 
	This draft contains similar objects in olsrv2InterfacePerfTable :
	 
	    Olsrv2InterfacePerfEntry ::=
	       SEQUENCE {
	          olsrv2IfTcMessageXmits
	             Counter32,
	          olsrv2IfTcMessageRecvd
	             Counter32,
	          olsrv2IfTcMessageXmitAccumulatedSize
	             Counter64,
	          olsrv2IfTcMessageRecvdAccumulatedSize
	             Counter64,
	          olsrv2IfTcMessageTriggeredXmits
	             Counter32,
	          olsrv2IfTcMessagePeriodicXmits
	             Counter32,
	          olsrv2IfTcMessageForwardedXmits
	             Counter32,
	          olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
	             Counter32
	       }
	 
	 
	Personally, I don't believe that those objects should be subject to
the RFC
	6390 template definition. (Performance Metric Definition Template,
section
	5.4.4, RFC 6390).
	First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was
not
	subject to it
	Second reason: these objects are not really performance metrics, but
mainly
	basic monitoring objects.
	 
	Since RFC 6779 uses the term performance information (in the
abstract), I
	would propose that draft-ietf-manet-olsrv2-mib also uses this term,
and not
	the "performance metric". That would avoid some confusion. However,
keeping
	the olsrv2InterfacePerfTable OID name is perfectly fine, for
consistency
	reason with RFC 6779.
	 
	Regards, Benoit
	 

	
	Regards, Benoit

		Classification: UNCLASSIFIED
		Caveats: NONE
		 
		Fred,
		 
		There are two counters that are defined for performance
metrics.  Please see
		below.  As we stated it in Section 9 "Applicability
Statement," ECDS-MIB is
		an extension of SMF-MIB.  Thus, ECDS-MIB's inherited
SMF-MIB's performance
		metrics.  
		 
		As I can see, ECDS-MIB does apply 6390's (i), (ii), (iii),
and somewhat
		(iv).  Please let me know if you have any suggestion to
improve the draft.
		 
		 
		      (i) the degree to which its absence would cause
significant loss
		      of information on the behavior or performance of the
application
		      or system being measured
		 
		      (ii) the correlation between the Performance Metric,
the QoS, and
		      the QoE delivered to the user (person or other
application)
		 
		      (iii) the degree to which the Performance Metric is
able to
		      support the identification and location of problems
affecting
		      service quality
		 
		      (iv) the requirement to develop policies (Service
Level Agreement,
		      and potentially Service Level Contract) based on the
Performance
		      Metric
		 
		 
		 
		--
		 -- E-CDS Performance Group
		 --
		 
		 ecdsPerformanceGroup OBJECT IDENTIFIER ::= { ecdsMIBObjects
3 }
		 
		 ecdsInEcdsChange OBJECT-TYPE
		         SYNTAX          Counter32
		         MAX-ACCESS      read-only
		         STATUS          current
		         DESCRIPTION
		                 "This object indicates how many times the
current
		                  node is configured to be in E-CDS."
		 ::= { ecdsPerformanceGroup 1 }
		 
		 ecdsCurrentRtrPriValueChange OBJECT-TYPE
		         SYNTAX          Counter32
		         MAX-ACCESS      read-only
		         STATUS          current
		         DESCRIPTION
		                 "This object indicates how many times the
Router
		                  Priority of the current node has been
changed."
		 ::= { ecdsPerformanceGroup 2 }
		 
		 
		 
		James Nguyen
		US Army CERDEC S&TCD
		Email: james.h.nguyen4.civ@mail.mil
		Phone:  443-395-5628
		 
		 
		-----Original Message-----
		From: Fred Baker [mailto:fred@cisco.com
<blockedmailto:fred@cisco.com> ] 
		Sent: Thursday, May 23, 2013 11:12 AM
		To: draft-nguyen-manet-ecds-mib@tools.ietf.org
		Cc: bclaise@cisco.com
		Subject: draft-nguyen-manet-ecds-mib and Performance Metrics
		 
		Hi:
		 
		I have a question for you. Your document mentions
performance metrics.
		Would you kindly take a look at RFC 6390 to see if any of
its considerations
		apply to it?  "No" is an acceptable response, of course; the
point is to ask
		the question.
		 
		6390 Guidelines for Considering New Performance Metric
Development. A.
		     Clark, B. Claise. October 2011. (Format: TXT=49930
bytes) (Also
		     BCP0170) (Status: BEST CURRENT PRACTICE)
		 
		 
		Classification: UNCLASSIFIED
		Caveats: NONE
		 
		 

	 



Classification: UNCLASSIFIED
Caveats: NONE



------=_NextPart_000_0012_01CE585C.5BFCC210
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw
ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g
R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290
IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG
A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE
AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/
PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X
3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt
upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7
f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK
AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ
gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/
ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1
K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx
Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO
8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K
ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDMEEgMA0GCSqGSIb3DQEBBQUA
MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM
MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTMwMjI2MDAwMDAwWhcN
MTYwMjI1MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww
CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1DT0xFLlJP
QkVSVC5HUkFOT1QuMTM2NjU2MDM5MDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOqO
/17DG7aYs9uSnP/+p6Gsq8VEWYasP2AFK4fLX6EddXT0Xbpl+6D65ocPNoVOejCt3xTUZTUpcujL
ca/fkpqdpIgyqLY/TwXncfjejcKneIkXb9xAUfAfjIU1S+GVQCZx5qWrRwqhvGq5LHadRDZh5FN/
71vZyqrqCAg/NqYEvn8O0WlQefyhCOnbBDS06o0Xs2MhNVmaoMq0+9owe0sc3Tom3TxE6FqsJ0lf
5D7BK5x7qyAE3OdbMCxHIIbFYfayGr43zucoJgx73fFYPlMhC1FL5tzWdoaudbJcS3CxgQo3xF+v
7LwtAscs1MnrTs0xR5WlUrGIYNYU7cIPZD8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh
eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js
L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL
CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFPWwve21KZ20gQuIqDaDVMnON8uNMGgGCCsGAQUFBwEB
BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku
Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyb2JlcnQu
Zy5jb2xlQHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN
AQEFBQADggEBABxQGaSlVFdP9mklREX71YtmZGbQcR8xvgT/VAWAS5wBtmAsQ6A9DWj3OoAqCBUk
lqaxMyqsfIkVMRMOw+U5RSj5A8fDnnzMuvtooPbpb4gQxH9fQ8ELFluuMpD1cx/pZT+zARV3ClZX
6g2aZolBtk17r/2/dsRcvhO8uIOpI6IFYToCn6ZfnrXXSMKf74LAfigeXpsay23M8Vv9HTVPMUyg
AVQl9uEyOApG9V10gNqUihZcJIOz6lpUG2xJ50npdKPBhAwcZLZXKqIHchthupFDFbKFbf3VGPV5
KVer+zC/5D0IUZzdUWtPSERWi+OFOfipi75Y5oIYHoY/U36HV1cwggUCMIID6qADAgECAgMwQR0w
DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM
MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x
MzAyMjYwMDAwMDBaFw0xNjAyMjUyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu
IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk
BgNVBAMTHUNPTEUuUk9CRVJULkdSQU5PVC4xMzY2NTYwMzkwMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAq4oVK/5DQ8R/9nLb97oeOJPzP7qjER2TA2ue96H+4ZHs8GGFtiN1jciBqfKr
ce0iINLWxbeeCUR62zPQCLxfp2EG0/C1zz6W7E7O7z5CnPPeDF+IpaeM4yB1kztkGx6ONNAJMJ+k
oxbJxgEGE+RY51EQUYKwOSi8hq+IandF5hP6krnLHg16DARSr29h3NHmFrfCkkPIcrSMNXZLFI5X
JIInqpfgQPeR9MxKPTh970N375hcZHY/uPZJQpydKVdolrmX0BbT5soL5dEZ3RAXlK4fzTCgyEK7
0c4IGbpqq/spzPztl7w64hN1sbbmM+mBKGmI7a/PfqFCotYKMlSpgQIDAQABo4IBrTCCAakwHwYD
VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny
bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc
MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUUEcYiStZfaVzV72TgQ+2OA00
1jQwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v
RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud
EQQ9MDuBGXJvYmVydC5nLmNvbGVAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMzY2NTYw
MzkwQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU
AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAUIuG9wQM+L5Nn5s06siK
fLFn1zTwubJzuQmWIKj0PeRhcXyEZtYdiR2p5YQWS7Z/g+WlsSCJGVjk4sK3UCYPQKV8xbEVh9Us
SGOUuIDKP7GAswgy8h9XAFDJfSPa9Vtzl8AgNLZiTUJfsn7N6uIOFiwWsHLr5MlvH+kbeNhY6wQ/
SuXyoR6IXAjAbm657Rb4lgdITn85Uuetk4kvsP08Vct/LfFPoJEHVHliov5zuvtAFzYPfu9bsmr0
CZ2LT8oljcncGG3/Nxt1XfYZJCCkxbav5Dq+t5eFcT69lYbcbliG3Us3ztCp7edfgBs9mzSbkPjC
tLPki80GqY4Uacrb5TCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT
AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ
MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow
XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww
CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ
s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4
zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY
zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf
VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G
A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU
uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG
A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC
AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs
oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB
AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U
Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC
hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul
M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl
cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3
i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW
LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y
U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz
SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5
eYelN5IWqYQgkmMxggL+MIIC+gIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv
dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg
Q0EtMjkCAzBBHTAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xMzA1MjQxMjU0NTRaMCMGCSqGSIb3DQEJBDEWBBRNyr2z2scgCDISB1OXFWXn
vaRDLzAkBgkqhkiG9w0BCQ8xFzAVMAoGCCqGSIb3DQMHMAcGBSsOAwIaMHMGCSsGAQQBgjcQBDFm
MGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E
MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDMEEgMHUGCyqGSIb3DQEJ
EAILMWagZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL
EwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTI5AgMwQSAwDQYJKoZI
hvcNAQEBBQAEggEAkjJEodces7QtS+jCHh0qVKPrugioWVf0ogQW8EZmXoK3LPCyMAuhHNsWuvc2
ZzK7r/n3myffBrNKT67oQFUoCP6yAhXODqsyu3N46y3WQgoVzbg54KAsjb3kuhDY32r9ojntEetH
DtcCO+4TqMU+3UapU5aIfxegrYwmjCr8fG23U0NOxBBcrmf6sfo8qyZB+Ky7Q/XFZFHxcuHlTRj9
OfQgEtvUYVxstZO3VniL8F64VvW5oEVCo0k28/OLvsfdTmsvNxDQlbIFdiA9lRAVkKVjh0CJuthd
51dOcE0/JzhnBwWuTsmtNdDcRt9IYGOm8I65s2MeunDisYOuCFPKJQAAAAAAAA==

------=_NextPart_000_0012_01CE585C.5BFCC210--

From james.h.nguyen4.civ@mail.mil  Fri May 24 06:25:17 2013
Return-Path: <james.h.nguyen4.civ@mail.mil>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275F821F8689 for <pm-dir@ietfa.amsl.com>; Fri, 24 May 2013 06:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWXXgDZHAA0l for <pm-dir@ietfa.amsl.com>; Fri, 24 May 2013 06:25:11 -0700 (PDT)
Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9745921F8733 for <pm-dir@ietf.org>; Fri, 24 May 2013 06:24:58 -0700 (PDT)
Received: from UCOLHP3A.easf.csd.disa.mil (131.64.100.148) by UCOLHP4Z.easf.csd.disa.mil (131.64.100.6) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 24 May 2013 13:24:51 +0000
Received: from UCOLHP9K.easf.csd.disa.mil ([169.254.3.230]) by UCOLHP3A.easf.csd.disa.mil ([131.64.100.148]) with mapi id 14.03.0123.003; Fri, 24 May 2013 13:24:51 +0000
From: "Nguyen, James H CIV USARMY CERDEC (US)" <james.h.nguyen4.civ@mail.mil>
To: Benoit Claise <bclaise@cisco.com>
Thread-Topic: draft-nguyen-manet-ecds-mib and Performance Metrics (UNCLASSIFIED)
Thread-Index: AQHOWFlxETGVjKlfWke/gZBVQCaaxpkUUs2g
Date: Fri, 24 May 2013 13:24:56 +0000
Message-ID: <3DC26342A93F204C804384C87DDBECBF3DADF5E0@ucolhp9k.easf.csd.disa.mil>
References: <201305231512.r4NFCMN4006908@irp-view13.cisco.com> <3DC26342A93F204C804384C87DDBECBF3DADF508@ucolhp9k.easf.csd.disa.mil> <519F25A0.70502@cisco.com>
In-Reply-To: <519F25A0.70502@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [131.64.62.4]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0048_01CE5860.8AE10330"
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 24 May 2013 06:56:36 -0700
Cc: "draft-nguyen-manet-ecds-mib@tools.ietf.org" <draft-nguyen-manet-ecds-mib@tools.ietf.org>, Adrian Farrel <adrian@olddog.co.uk>, "draft-ietf-manet-smf-mib@tools.ietf.org" <draft-ietf-manet-smf-mib@tools.ietf.org>, "pm-dir@ietf.org" <pm-dir@ietf.org>, Fred Baker <fred@cisco.com>
Subject: Re: [pm-dir] draft-nguyen-manet-ecds-mib and Performance Metrics (UNCLASSIFIED)
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2013 13:25:17 -0000

------=_NextPart_000_0048_01CE5860.8AE10330
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Classification: UNCLASSIFIED
Caveats: NONE

Fred, Benoit, et al,

Sorry about the confusion.  After read section 5 of 6390, ECDS-MIB does not
apply here.  I agree to the use of "performance information."

James Nguyen
US Army CERDEC S&TCD
Email: james.h.nguyen4.civ@mail.mil
Phone:  443-395-5628

-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com] 
Sent: Friday, May 24, 2013 4:33 AM
To: Nguyen, James H CIV USARMY CERDEC (US)
Cc: Fred Baker; draft-nguyen-manet-ecds-mib@tools.ietf.org; me;
draft-ietf-manet-smf-mib@tools.ietf.org; pm-dir@ietf.org; Adrian Farrel
Subject: Re: draft-nguyen-manet-ecds-mib and Performance Metrics
(UNCLASSIFIED)

Hi James, draft-ietf-manet-smf-mib authors,

Agreed, RFC 6390 doesn't apply here.
See the email exchange regarding draft-ietf-manet-olsrv2-mib below, which I
reviewed part of the performance metric directorate.
Like Ulrich did for draft-ietf-manet-olsrv2-mib, it might better to use
"performance information" instead of "performance metrics" in your draft.


	Benoit,
	
	thank you very much for this review. I agree that using the term
	"performance information" instead of "performance metrics" is a good
	idea. We will make the change.
	
	Best regards
	Ulrich
	
	On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise <bclaise@cisco.com>
<mailto:bclaise@cisco.com>  wrote:
	Dear all,
	
	I reviewed
http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, from a
	performance metric directorate point of view.
	
	This draft doesn't contain any reference to RFC6390, but contains
	"performance metric". Hence this review was triggered. For details
about the
	directorate, see
	http://www.ietf.org/iesg/directorate/performance-metrics.html
	
	
	Definition of Managed Objects for the  Optimized Link State Routing
	Protocol version 2
	
	Abstract
	
	   This document defines the Management Information Base (MIB)
module
	   for configuring and managing the Optimized Link State Routing
	   protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
	   into state information, performance metrics, and notifications.
This
	   additional state and performance information is useful to
	   troubleshoot problems and performance issues of the routing
protocol.
	   Different levels of compliance allow implementers to use smaller
	   subsets of all defined objects, allowing for this MIB module to
be
	   deployed on more constrained routers.
	
	
	Basically, all performance metrics come from this table:
	
	   o  olsrv2InterfacePerfTable - records performance counters for
each
	      active OLSRv2 interface on this device. selected path to each
	      destination for which any such path is known.  This table has
	      AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed
via
	      nhdpIfIndex from the NHDP-MIB.
	
	NHDP-MIB is RFC 6779:
	   NhdpInterfacePerfEntry ::=
	      SEQUENCE {
	         nhdpIfHelloMessageXmits
	            Counter32,
	         nhdpIfHelloMessageRecvd
	            Counter32,
	         nhdpIfHelloMessageXmitAccumulatedSize
	            Counter64,
	         nhdpIfHelloMessageRecvdAccumulatedSize
	            Counter64,
	         nhdpIfHelloMessageTriggeredXmits
	            Counter32,
	         nhdpIfHelloMessagePeriodicXmits
	            Counter32,
	         nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
	            Counter32,
	         nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
	            Counter32,
	         nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
	            Counter32
	      }
	
	
	This draft contains similar objects in olsrv2InterfacePerfTable :
	
	    Olsrv2InterfacePerfEntry ::=
	       SEQUENCE {
	          olsrv2IfTcMessageXmits
	             Counter32,
	          olsrv2IfTcMessageRecvd
	             Counter32,
	          olsrv2IfTcMessageXmitAccumulatedSize
	             Counter64,
	          olsrv2IfTcMessageRecvdAccumulatedSize
	             Counter64,
	          olsrv2IfTcMessageTriggeredXmits
	             Counter32,
	          olsrv2IfTcMessagePeriodicXmits
	             Counter32,
	          olsrv2IfTcMessageForwardedXmits
	             Counter32,
	          olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
	             Counter32
	       }
	
	
	Personally, I don't believe that those objects should be subject to
the RFC
	6390 template definition. (Performance Metric Definition Template,
section
	5.4.4, RFC 6390).
	First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was
not
	subject to it
	Second reason: these objects are not really performance metrics, but
mainly
	basic monitoring objects.
	
	Since RFC 6779 uses the term performance information (in the
abstract), I
	would propose that draft-ietf-manet-olsrv2-mib also uses this term,
and not
	the "performance metric". That would avoid some confusion. However,
keeping
	the olsrv2InterfacePerfTable OID name is perfectly fine, for
consistency
	reason with RFC 6779.
	
	Regards, Benoit
	


Regards, Benoit


	Classification: UNCLASSIFIED
	Caveats: NONE
	
	Fred,
	
	There are two counters that are defined for performance metrics.
Please see
	below.  As we stated it in Section 9 "Applicability Statement,"
ECDS-MIB is
	an extension of SMF-MIB.  Thus, ECDS-MIB's inherited SMF-MIB's
performance
	metrics.  
	
	As I can see, ECDS-MIB does apply 6390's (i), (ii), (iii), and
somewhat
	(iv).  Please let me know if you have any suggestion to improve the
draft.
	
	
	      (i) the degree to which its absence would cause significant
loss
	      of information on the behavior or performance of the
application
	      or system being measured
	
	      (ii) the correlation between the Performance Metric, the QoS,
and
	      the QoE delivered to the user (person or other application)
	
	      (iii) the degree to which the Performance Metric is able to
	      support the identification and location of problems affecting
	      service quality
	
	      (iv) the requirement to develop policies (Service Level
Agreement,
	      and potentially Service Level Contract) based on the
Performance
	      Metric
	
	
	
	--
	 -- E-CDS Performance Group
	 --
	
	 ecdsPerformanceGroup OBJECT IDENTIFIER ::= { ecdsMIBObjects 3 }
	
	 ecdsInEcdsChange OBJECT-TYPE
	         SYNTAX          Counter32
	         MAX-ACCESS      read-only
	         STATUS          current
	         DESCRIPTION
	                 "This object indicates how many times the current
	                  node is configured to be in E-CDS."
	 ::= { ecdsPerformanceGroup 1 }
	
	 ecdsCurrentRtrPriValueChange OBJECT-TYPE
	         SYNTAX          Counter32
	         MAX-ACCESS      read-only
	         STATUS          current
	         DESCRIPTION
	                 "This object indicates how many times the Router
	                  Priority of the current node has been changed."
	 ::= { ecdsPerformanceGroup 2 }
	
	
	
	James Nguyen
	US Army CERDEC S&TCD
	Email: james.h.nguyen4.civ@mail.mil
	Phone:  443-395-5628
	
	
	-----Original Message-----
	From: Fred Baker [mailto:fred@cisco.com] 
	Sent: Thursday, May 23, 2013 11:12 AM
	To: draft-nguyen-manet-ecds-mib@tools.ietf.org
	Cc: bclaise@cisco.com
	Subject: draft-nguyen-manet-ecds-mib and Performance Metrics
	
	Hi:
	
	I have a question for you. Your document mentions performance
metrics.
	Would you kindly take a look at RFC 6390 to see if any of its
considerations
	apply to it?  "No" is an acceptable response, of course; the point
is to ask
	the question.
	
	6390 Guidelines for Considering New Performance Metric Development.
A.
	     Clark, B. Claise. October 2011. (Format: TXT=49930 bytes) (Also
	     BCP0170) (Status: BEST CURRENT PRACTICE)
	
	
	Classification: UNCLASSIFIED
	Caveats: NONE
	
	



Classification: UNCLASSIFIED
Caveats: NONE



------=_NextPart_000_0048_01CE5860.8AE10330
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISwjCCA3Aw
ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g
R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290
IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG
A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE
AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/
PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X
3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt
upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7
f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK
AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ
gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/
ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1
K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx
Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO
8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K
ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtDCCA5ygAwIBAgIDIzkxMA0GCSqGSIb3DQEBBQUA
MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM
MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQwHhcNMTEwNjIyMDAwMDAwWhcN
MTQwNjIxMjM1OTU5WjB2MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww
CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSMwIQYDVQQDExpOR1VZRU4u
SkFNRVMuSE4uMTM5Mzc2NTEzMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMWhoyiY
EPfriy4L2fQOjm3IZ1zyTlBQ7KG5tbv9PYyw7H4DGI2jvSenfw4WGhNl1l/gsrqnSVuWBGmNbJWp
WAvtsgvzhm5Xssi36/tDkXmAr7sIXelFVKoWC5Q0aTFIWe0OltDtByPYQhBGLQAd/g2zCXPLsvq2
R/Q+FgjXSr6p9jPOShN39wZe+OKAC+NLTvZUuuPqNYp38jn+AJw3USuXJweSl44LopnEWRZhQYpg
U5Jf999pp6oS8gR0zNXZTbtrKuRa+nzfjSuQtble4w1Rc/GRuTVBk0mwUTyl6nnUDtTY1ML6jVNE
iFdcGEpcoyxLW+u6xskftsDtxoYEBXMCAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFFSqcyrHs3fq
zSJAeUh7EfunmSKCMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3JsL0RP
REVNQUlMQ0FfMjQuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgELCTAL
BglghkgBZQIBCxMwHQYDVR0OBBYEFJTCtL8IRNk2WQhIiUibdHr3anu6MGgGCCsGAQUFBwEBBFww
WjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjQuY2Vy
MCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlKQU1FUy5OR1VZ
RU41QFVTLkFSTVkuTUlMMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcNAQEF
BQADggEBAJp3KkGZpjT8RbG4Cfsik5H/uQWn+WS5IrN/JhXrsPFhS1Jlp//eTHg9PrWDV4y6WCB2
dnMLMh1mOjeJnuz6KE2BjInpOj4NWtwoww2H/ppq8bgrmW86KFMhteEL2kj5gSkuvhVNHNVj8ov/
yGyBJ13cHSdMU21oO5sSq15cEoJ8fbYTUmt34+Toh4q8vRO2oVpdZXx5fJd3ub/VolGY7WESSdDV
3B06OKs1q5SA5buVV743xnJjfnwOgEk2rC4GN/jV2p7IbEJw7OwQrFACVjdTSbotWNKt23JOzVJu
mY01lE+Zcx6IGSmjpiiFNTg6kOoBykys1s5eHhO3deu/6EkwggT/MIID56ADAgECAgMjOS8wDQYJ
KoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoG
A1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yNDAeFw0xMTA2
MjIwMDAwMDBaFw0xNDA2MjEyMzU5NTlaMHYxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv
dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExIzAhBgNV
BAMTGk5HVVlFTi5KQU1FUy5ITi4xMzkzNzY1MTMxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAw/R86/FEH3wIY0h6S/bm/Fe2XN6jUlH7egpWKA2+tHg22hPTEBJ8WgZEitsW1I+nnXgL
GgNBPvuHlfsbhftkP7iSYW0as7rWAZC/Xmke+bGNE9EHswsx6yg0vDs1aJr6G+A6OSMxSNzOGn8O
fuUvHVYClOJ9YVzozPvTGZ+0F3qWjJ8inmLGWJVE48fjlIlcuAsJVNsXf4jKtcWEvvrWDTIgwJG3
tDdwv571QHhc4yfWycaZccL+Ibrfm5T0pZyZZAu+1UCUmVHKg7T/RTgeYinnuHMtx9jnM+bLUKWU
SAq65ZQS+TwHJI5Bpi516uTv2CZOlKxzommXiOYnlkjmxwIDAQABo4IBrTCCAakwHwYDVR0jBBgw
FoAUVKpzKsezd+rNIkB5SHsR+6eZIoIwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2NybC5kaXNh
Lm1pbC9jcmwvRE9ERU1BSUxDQV8yNC5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQcMBowCwYJ
YIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUkYJ8+Iomb2hK5Y3iFTFxrccz2IEwaAYI
KwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24vRE9ERU1B
SUxDQV8yNC5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1UdEQQ9MDuB
GUpBTUVTLk5HVVlFTjVAVVMuQVJNWS5NSUygHgYKKwYBBAGCNxQCA6AQDA4xMzkzNzY1MTMxQG1p
bDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIGCCsG
AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAKWeFP2mWVzpu7FPybJ3r0d3Ip2fX
LINLeWbVhK68c8BNzBGeh3XCl3DmvcHGA74eNFiPBTeGVbgDhDoivNil+PU5Mh8zL+3AotG4Pf26
c10Fou4wMD++QBno8XdFf+fNEoklSBcy0B+/1FUx1yWlaQIE2kAlXdRk6vmYycRl8IfDseVgdtGA
TXmy4l8fE7q5w+vKp03Ajkkup/8c3ESMzyXQmL13DnWh9k3U+nevr0PyD7QJ4RDaTR0bfwqdPYbQ
iXKZRB7gTsG1vDfxD96SSrgFDrJ3Dy+WcHkDg37ephEyOH61FPmRwBc6oqviSgoU/qDIGuRWk1Jn
0Jshd+8HlzCCBY8wggR3oAMCAQICAUUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAW
BgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNV
BAMTDURvRCBSb290IENBIDIwHhcNMDkwMTI2MjAyNjE1WhcNMTUwMTI1MjAyNjE1WjBdMQswCQYD
VQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsT
A1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTI0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEApS5YeqHe5ppb9gLx1dTcNSOae24oZHQacDyWHczCn3QEPAw5kiEIDRJOoNc3qNLJxied
KPpV17IXBBnOMrzweZ71aKsuzM83BLL4CmWaSSAUJcG8EmqgQm0bCLSHoUIiqxOZ2gIBOR9eCFdr
YN4TfmhqfkH1iYA4ev2XstLilks2gGK27CW70A+no81RqPfSeVWQNCaj5FzNu2gmdAk3oeavzeQ+
mUf/f8JHvGWEujIpow7wwqJbeuqySn0LxsNurL0Qf0+pdjo9AgEsKjC098ig0pg6fAjQWokPtYqC
+g0wHn7W0ce2QyexKKkM47MHeN9iZJpFjE7Nrw6unFg23wIDAQABo4ICWjCCAlYwDgYDVR0PAQH/
BAQDAgGGMB8GA1UdIwQYMBaAFEl0uwxeunr+AlTve6DGlcYJgHCWMB0GA1UdDgQWBBRUqnMqx7N3
6s0iQHlIexH7p5kigjAMBgNVHSQEBTADgAEAMBIGA1UdEwEB/wQIMAYBAf8CAQAwgZ8GA1UdIASB
lzCBlDALBglghkgBZQIBCwUwCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELCjALBglghkgBZQIBCxIw
CwYJYIZIAWUCAQsTMAsGCWCGSAFlAgELFDAMBgpghkgBZQMCAQMGMAwGCmCGSAFlAwIBAwcwDAYK
YIZIAWUDAgEDCDAMBgpghkgBZQMCAQMNMAwGCmCGSAFlAwIBAxEwPwYDVR0fBDgwNjA0oDKgMIYu
aHR0cDovL2NybC5kaXNhLm1pbC9nZXRjcmw/RG9EJTIwUm9vdCUyMENBJTIwMjCB/gYIKwYBBQUH
AQEEgfEwge4wPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0SXNzdWVkVG8/RG9E
JTIwUm9vdCUyMENBJTIwMjAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgYgGCCsG
AQUFBzAChnxsZGFwOi8vY3JsLmdkcy5kaXNhLm1pbC9jbiUzZERvRCUyMFJvb3QlMjBDQSUyMDIl
MmNvdSUzZFBLSSUyY291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTP2NB
Q2VydGlmaWNhdGU7YmluYXJ5MA0GCSqGSIb3DQEBBQUAA4IBAQByFtw5c2NNk+k3HM+y7ZzYTfcM
MkqJnrPKuvMErHFmMaYqvbp9VNgvCWNKiAjobBOh7F57VhcwLcjS7deNR0RpzxFvy9jnUnW1Uciq
HWnwGR8w8AfHNr3ODN47dv0Kzsu2E7rWhYvxXBKRyq/ofxKorC2L1nZQlOw2+qMP38Yy6sdzRvyE
GpovxOgnHEjCRjb2F+ztZzIPuKLgt9JekAYTlCFhQ2x98ztrZe3j26j/xZuykufrX+7vv/M5jLP1
F9KG1cNsSjpsP56v6FsdNlumJhVGC0Zrx9SAqueuHLgrTvohcp9fn4GvtO5byZcpiXzp3HjiTuB0
n9KGeGaix5ioMYIDMjCCAy4CAQEwZDBdMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zl
cm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENB
LTI0AgMjOS8wCQYFKw4DAhoFAKCCAaMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTMwNTI0MTMyNDUxWjAjBgkqhkiG9w0BCQQxFgQUNvXxh8yIiyXQ6MlKnNuzLTCB
uHUwWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcw
DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwcwYJKwYBBAGCNxAEMWYwZDBdMQsw
CQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNV
BAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTI0AgMjOTEwdQYLKoZIhvcNAQkQAgsxZqBk
MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM
MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjQCAyM5MTANBgkqhkiG9w0BAQEF
AASCAQB0Gp0mrxKd7+VA1S7qo2dYUzwRx/N7e2qJC+tJliYUfoPWEQMD/9xD2wIRJfiVPRUT3miE
bXaCY+ocIJOPSuD0UTuKCD39Rmgd5FZksipwCm5Pnvvva3k6FBvMsWpFl4iuAjiHcgeyKZyvoSEf
n9haxdAu92+ZSS0YaVc7i1ZOB+MbFQI7CZpwfDgvErl+Nt9WJG4CG3YVKioP7wLEBhOxGR3RAdXE
uvsJbzji8Xa83hIPIqbd2DtaWs7/fMymIU0adPyMGowtCM3sfBf/rpBvM1iq0LBOji864INV5Ar3
yD7/y4DIVBMl50jgDsGVQDqJ1SsQxvFkQm2SVuh3w6gHAAAAAAAA

------=_NextPart_000_0048_01CE5860.8AE10330--

From bclaise@cisco.com  Fri May 24 08:09:05 2013
Return-Path: <bclaise@cisco.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D95421F9424 for <pm-dir@ietfa.amsl.com>; Fri, 24 May 2013 08:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.194
X-Spam-Level: 
X-Spam-Status: No, score=-10.194 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgU0xtchaq30 for <pm-dir@ietfa.amsl.com>; Fri, 24 May 2013 08:09:01 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E2B0721F91B2 for <pm-dir@ietf.org>; Fri, 24 May 2013 08:08:59 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4OF8FqF028410; Fri, 24 May 2013 17:08:15 +0200 (CEST)
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4OF6Xbu018636; Fri, 24 May 2013 17:06:48 +0200 (CEST)
Message-ID: <519F81F9.5070903@cisco.com>
Date: Fri, 24 May 2013 17:06:33 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Qin Wu <bill.wu@huawei.com>
References: <CD8499D5.4FA30%alan.d.clark@telchemy.com> <A64E8EB6A56342CB8423D1532A94709C@china.huawei.com> <51656EB3.9060300@cisco.com> <B8F9A780D330094D99AF023C5877DABA43A3C121@nkgeml501-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA43A3C121@nkgeml501-mbs.china.huawei.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "Huangyihong \(Rachel\)" <rachel.huang@huawei.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, "Dan \(Dan\)" <dromasca@avaya.com>, "asaeda@nict.go.jp" <asaeda@nict.go.jp>, Alan Clark <alan.d.clark@telchemy.com>, "glenzorn@gmail.com" <glenzorn@gmail.com>, Shida Schubert <shida@ntt-at.com>, "pm-dir@ietf.org" <pm-dir@ietf.org>, Al Morton <acmorton@att.com>
Subject: Re: [pm-dir] =?utf-8?b?562U5aSNOiBSRkM2MzkwIHJldmlldyBvZiBkcmFmdC1p?= =?utf-8?q?etf-xrblock-rtcp-xr-decodability?=
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2013 15:09:05 -0000

Hi Qin,
> Hi,Benoit:
> As Alan observed in PM-DIR review, this draft does not define new metrics but refers to metrics that are
> clearly defined in a normative reference.
> I think we can skip RFC6390 template usage just like PDV draft(RFC6798) did, can't we?
I finally had to the time to review this document, which is on the IESG 
telechat on Thursday.
Basically, Alan is right, the answer is "yes, you can skip RFC6390"
And I'm balloting "no objection".
For once, I don't have any DISCUSS on your document. I thought I would 
let you know. ;-)

Regards, Benoit
>
> Regards!
> -Qin
> -----邮件原件-----
> 发件人: Benoit Claise [mailto:bclaise@cisco.com]
> 发送时间: 2013年4月10日 21:53
> 收件人: Qin Wu
> 抄送: Alan Clark; Gonzalo Camarillo; pm-dir@ietf.org; Dan (Dan); Shida Schubert; Huangyihong (Rachel); asaeda@nict.go.jp; glenzorn@gmail.com; Al Morton
> 主题: Re: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
>
> Hi Qin,
>
> And don't forget the RFC 6390 template usage.
>
> Regards, Benoit
>> Hi, Alan:
>> Thank for your valuable comments.
>> We have updated the draft to incorporate your comments in the new version (-v11).
>> The diff is:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-decodability-11
>> Please also see my reply below.
>>
>> Regards!
>> -Qin
>> ----- Original Message -----
>> From: "Alan Clark" <alan.d.clark@telchemy.com>
>> To: "Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>; <pm-dir@ietf.org>; "Benoit Claise" <bclaise@cisco.com>; "Dan (Dan)" <dromasca@avaya.com>; "Shida Schubert" <shida@ntt-at.com>; <rachel.huang@huawei.com>; <bill.wu@huawei.com>; <asaeda@nict.go.jp>; <glenzorn@gmail.com>; "Al Morton" <acmorton@att.com>
>> Sent: Saturday, April 06, 2013 3:10 AM
>> Subject: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
>>
>>
>> There are quite a few issues with the draft - I can re-review as soon as
>> these are addressed.
>>
>> Alan Clark
>>
>>
>>
>> A. General Comments
>>    
>> This draft does not define new metrics but refers to metrics that are
>> clearly defined in a normative reference.  The normative reference (ETSI
>> TR101290) predates RFC6390 however does contain a fairly clear description
>> of the metrics with explanation of their usage. It is not recommended that
>> this draft redefines the metrics in RFC6390 template form
>>
>> [Qin]: Exactly.
>>
>> however there is
>> considerable scope for improvement in the clarity of definition of how these
>> metrics are used.
>>
>> [Qin]: Agree.
>>    
>> B. Applicability Section
>>    
>> 1.4 Applicability
>> Metrics only measure transport stream quality not content stream quality.
>> Also the metrics are not defined in this draft but are encodings of the
>> metrics defined in ETSI TS 101290.
>>    
>> Suggest
>>    
>> ³This block type allows a counts of MPEG Transport Stream quality metrics
>> that are measured in accordance with ETSI TR 101290 [ETSI] to be reported by
>> an endpoint.  These metrics are useful for identifying bitstream
>> packetization and transport stream encoding problems that may affect the
>> user¹s perception of a video service delivered over RTP.²
>>
>> [Qin]: Okay. Your proposed text have been incorporated in (-v11).
>>    
>> C. Metrics Definitions
>>    
>> C.1 General
>>    
>> For clarity the draft should preface the metrics definitions with a general
>> explanation of how these metrics relate to ETSI TR101290. TR101290 generally
>> defines error events and this draft contains counts of those metrics.
>>
>>    
>> If there are any ³edge² cases where a problem in one measurement interval
>> would be reflected in the count in the next measurement interval then this
>> should be articulated in the general description and also in the specific
>> metric.  For example, a sync byte error is defined as multiple consecutive
>> errored sync bytes and if this was reported in an interval it may have
>> occurred at the end of the preceding interval or at some time during the
>> present interval - hence the description should state that the count may
>> reflect a problem in the current or previous interval. This would also be
>> the case for PCR errors and even continuity count errors.
>>
>> [Qin]: Okay, I have added some text in the 2nd paragraph of section 3
>> and incorporated your suggested text in (v-11).
>>    
>> C.2  Sequence numbers
>>    
>> begin_seq and end_seq
>>    
>> These definitions simply say ³As defined inS² which requires the reader to
>> refer to another document. It is good practice to at least mention what the
>> definition refers to and then to include a reference that contains the
>> normative definition.
>>    
>> SoS..
>>    
>> ³begin_seq: 16 bits
>>
>> The RTP sequence number corresponding to the start of the measurement
>> period, as defined in Section 4.1 of RFC 3611²
>>
>> [Qin]: Fixed in (-v11).
>>    
>> C.3 Metrics definitions
>> The metrics definitions should contain a firmer statement of what is being
>> measured and, if the normative definition is in another standard, then
>> clearly state ³as defined in Section X.Y of NNNNN². This applies to all the
>> metrics definitions and the example below can be used as a template for
>>    
>> For example
>>    
>> Existing language S..
>>    
>> TS_sync_loss_count: 32 bits
>>    
>> Number of TS_sync_loss errors in the above sequence number interval.  It is
>> calculated based on the occurrence of errors for "TS_sync_loss"parameter
>> defined in the section 5.2.1 of [ETSI] (Also see section 5.5.1 of [ETSI]).
>>    
>> This is very vague language and it is unclear why the ³Also see² reference
>> is there.  A better approach is:
>>    
>> Replacement language (use this format for each of the metrics)
>>    
>> TS_sync_loss_count: 32 bits
>>    
>> A count of the number of TS_sync_loss errors that occurred in the above
>> sequence number interval.  A TS_sync_loss error occurs when there are two or
>> more consecutive incorrect sync bytes within the MPEG TS stream, as defined
>> in section 5.2.1 of [ETSI]. This parameter may be used as part of a Service
>> Availability calculation, as defined in section 5.5.1 of [ETSI].
>>
>> [Qin]: Fixed in (-v11).
>>    
>> C.4 Service Availability
>>    
>> Following on from the previous comment,  section 5.5.1 of TR101290 describes
>> a service availability error as a combination of TS_sync_loss, PAT_error and
>> PMT_error whereas draft-ietf-xrblock-rtcp-xr-decodability-10 does not
>> contain the PAT and PMT error metrics.  The resolution for this would either
>> be to remove the reference to 5.5.1 or to add the metrics required to
>> calculate the service availability.
>>    
>> [Qin]: Agree. I prefer to remove the reference to 5.5.1 since there was consensus in the past WGLC to this draft
>> that having a second report block later to cover the other parameters and get inline with concept of RFC6792
>> and letting this draft focus on PSI indpendent parameter reporting.
>> See details for the WGLC discussion in the following link:
>> http://www.ietf.org/mail-archive/web/xrblock/current/msg01032.html
>>
>> It is recommended that PAT_error , PAT_error_2,  PMT_error and PMT_error_2
>> be included as metrics as these ³are² generally present in MPEG Transport
>> streams and errors within these can prevent correct decoding of the stream.
>>    
>> C.5 PCR_error_count
>>    
>> PCR_error_count is defined twice - the second of these should be
>> PCR_accuracy_error_count
>>    
>>    [Qin]: Good catch and have fixed in (-v11).
>>
>>
>>
>
>


From vinayakh@gmail.com  Sat May 25 14:50:30 2013
Return-Path: <vinayakh@gmail.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31DD21F869F for <pm-dir@ietfa.amsl.com>; Sat, 25 May 2013 14:50:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmGQU1V1jecZ for <pm-dir@ietfa.amsl.com>; Sat, 25 May 2013 14:50:24 -0700 (PDT)
Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id BA93421F86BB for <pm-dir@ietf.org>; Sat, 25 May 2013 14:50:15 -0700 (PDT)
Received: by mail-pd0-f173.google.com with SMTP id v14so4109257pde.32 for <pm-dir@ietf.org>; Sat, 25 May 2013 14:50:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Whzdlk0mM6NsMZluvmbqQXyHWzkGQ5XEW44dwnqD5wM=; b=faA4T04UUwt6ke/ooRygEL32xQFE8UgAywhTSPRNk7t+i7QL9jEC39g8Q2TyDXZhpW XoMPJHWAbfA0NSTDTi+/CFX9I011GureErud+YLRj/8S3IlBA5obdlb6Bz7wJxwl7qH/ MAoE7Nch5bR0HlfK1/iF3jxbrDQs5fGgqeN8U6VXNIdqkWSxENDBmkd1NQKxqE2BPpYX H+zMpTddnPOOLNddAY96gucZ+LvNeHUQP/7qtZxvmw4y9uVaRElnS1DaeZUXG1+UyrHo /XxOTb8F2ZYjAkiwlScNI0fIQuRF5/dCv42skHVBlrOq8vpmxgM0QYFHROcMs7QifU6F pG1g==
MIME-Version: 1.0
X-Received: by 10.68.185.162 with SMTP id fd2mr23294225pbc.176.1369518615483;  Sat, 25 May 2013 14:50:15 -0700 (PDT)
Received: by 10.66.156.234 with HTTP; Sat, 25 May 2013 14:50:15 -0700 (PDT)
In-Reply-To: <CAKe6YvNdEW1iggzdxEw4yRPryYWVbCexoXGJjnr6XZhtFfPCjQ@mail.gmail.com>
References: <CAKe6YvNdEW1iggzdxEw4yRPryYWVbCexoXGJjnr6XZhtFfPCjQ@mail.gmail.com>
Date: Sun, 26 May 2013 03:20:15 +0530
Message-ID: <CAKe6YvM7oK7f2pVbKEzp0p9UAR-GXXK1uT430t1GQB7kEhgy5Q@mail.gmail.com>
From: Vinayak Hegde <vinayakh@gmail.com>
To: pm-dir@ietf.org, asaeda@nict.go.jp, Rachel@huawei.com, sunseawq@huawei.com
Content-Type: multipart/alternative; boundary=047d7bd6b1fc96daab04dd91e6bc
Subject: Re: [pm-dir] Review of xrblock rtcp xr synchronization Version 5
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 May 2013 21:50:30 -0000

--047d7bd6b1fc96daab04dd91e6bc
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Used the wrong alias in the initial mail. Please reply to this mail as I
have fixedc the mail address.

-- Vinayak

On Sun, May 26, 2013 at 3:15 AM, Vinayak Hegde <vinayakh@gmail.com> wrote:

> Hi,
>
> I reveiewd the  xrblock rtcp xr synchronization Version 5 draft at
>
> The draft does specify and fulfill all the requirements of RFC 6390
>
> Comments are below:
>
> Section 3.2
> Initial Synchronization Delay: 32 bits
>
> The selection of units in 1/65536 seconds seems arbitrary (inspite of the
> fact that it could make bit arithmetic easier). I would suggest to use may
> be denote each bit as 1/10000 or 1/100000 (too granualr ?) units. This
> could be much more useful for interaction with humans such as in reading
> debug output (which is likely since this is a synchronization delay).
>
> Section 4.2
> For the offset constant <RFSO> it is not clear what the 8-bit is. Either
> you can note it here or reference it.
>
> -- Vinayak
>

--047d7bd6b1fc96daab04dd91e6bc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<br><br>Used the wrong alias in the initial mail. Please reply to this m=
ail as I have fixedc the mail address.<br><br>-- Vinayak<br><br><div class=
=3D"gmail_quote">On Sun, May 26, 2013 at 3:15 AM, Vinayak Hegde <span dir=
=3D"ltr">&lt;<a href=3D"mailto:vinayakh@gmail.com" target=3D"_blank">vinaya=
kh@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi,<br><br>I reveiewd the=A0 xrblock rtcp xr=
 synchronization Version 5 draft at <br><br>The draft does specify and fulf=
ill all the requirements of RFC 6390<br>
<br>Comments are below:<br><br>Section 3.2<br>Initial Synchronization Delay=
: 32 bits<br>
<br>The selection of units in 1/65536 seconds seems arbitrary (inspite of t=
he fact that it could make bit arithmetic easier). I would suggest to use m=
ay be denote each bit as 1/10000 or 1/100000 (too granualr ?) units. This c=
ould be much more useful for interaction with humans such as in reading deb=
ug output (which is likely since this is a synchronization delay).<br>

<br>Section 4.2 <br>For the offset constant &lt;RFSO&gt; it is not clear wh=
at the 8-bit is. Either you can note it here or reference it.<span class=3D=
"HOEnZb"><font color=3D"#888888"><br><br>-- Vinayak<br>
</font></span></blockquote></div><br>

--047d7bd6b1fc96daab04dd91e6bc--

From bclaise@cisco.com  Sun May 26 14:06:35 2013
Return-Path: <bclaise@cisco.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B9F21F9019 for <pm-dir@ietfa.amsl.com>; Sun, 26 May 2013 14:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.406
X-Spam-Level: 
X-Spam-Status: No, score=-10.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGKECtZd8zd7 for <pm-dir@ietfa.amsl.com>; Sun, 26 May 2013 14:06:29 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF6D21F8F33 for <pm-dir@ietf.org>; Sun, 26 May 2013 14:06:29 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4QL6NCI010968 for <pm-dir@ietf.org>; Sun, 26 May 2013 23:06:24 +0200 (CEST)
Received: from sweet-brew-5.cisco.com (sweet-brew-5.cisco.com [144.254.10.206]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4QL66Oa022455 for <pm-dir@ietf.org>; Sun, 26 May 2013 23:06:16 +0200 (CEST)
Received: (from bclaise@localhost) by sweet-brew-5.cisco.com (8.13.8+Sun/8.13.6/Submit) id r4QL62Le005568 for pm-dir@ietf.org; Sun, 26 May 2013 23:06:02 +0200 (CEST)
Date: Sun, 26 May 2013 23:06:02 +0200
From: Benoit Claise <bclaise@cisco.com>
To: pm-dir@ietf.org
Message-ID: <20130526210602.GA5566@sweet-brew-5.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Subject: [pm-dir] Performance metrics doctors generated email
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 May 2013 21:06:35 -0000

Dear all,

This is an automatically generated email.  
It lists the IETF internet-drafts that reference the PMOL RFC 6390, as a normative or informative reference.
It also lists all the IETF internet-drafts that contain "performance metric".

Regards, Benoit

===========================================================

Normative References
--------------------
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 Active	
    
Informative References
----------------------
draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14   In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-decodability-11        In IESG processing - ID Tracker state <IESG Evaluation>	
draft-ietf-xrblock-rtcp-xr-discard-14             In IESG processing - ID Tracker state <In Last Call>	
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 Active	
draft-ietf-xrblock-rtcp-xr-jb-11                  In IESG processing - ID Tracker state <In Last Call>	
draft-ietf-xrblock-rtcp-xr-loss-conceal-05        Active	
draft-ietf-xrblock-rtcp-xr-qoe-07                 Active	
draft-ietf-xrblock-rtcp-xr-summary-stat-11        In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-synchronization-05     Active	

drafts containing performance metric
------------------------------------
draft-ietf-alto-deployments-06                    Active	
draft-ietf-alto-protocol-16                       Active	
draft-ietf-bmwg-ca-bench-meth-04                  Active	
draft-ietf-ippm-rate-problem-03                   Active	
draft-ietf-ippm-testplan-rfc2680-02               Active	
draft-ietf-manet-smf-mib-07                       In IESG processing - ID Tracker state <AD Evaluation::Revised I-D Needed>	
draft-ietf-nvo3-framework-02                      Active	
draft-ietf-opsawg-oam-overview-08                 In IESG processing - ID Tracker state <Waiting for AD Go-Ahead::Revised I-D Needed>	
draft-ietf-pce-pcep-service-aware-00              Active	
draft-ietf-ppsp-peer-protocol-06                  Active	
draft-ietf-rtcweb-rtp-usage-06                    Active	
draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14   In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-decodability-11        In IESG processing - ID Tracker state <IESG Evaluation>	
draft-ietf-xrblock-rtcp-xr-discard-14             In IESG processing - ID Tracker state <In Last Call>	
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 Active	
draft-ietf-xrblock-rtcp-xr-jb-11                  In IESG processing - ID Tracker state <In Last Call>	
draft-ietf-xrblock-rtcp-xr-loss-conceal-05        Active	
draft-ietf-xrblock-rtcp-xr-qoe-07                 Active	
draft-ietf-xrblock-rtcp-xr-summary-stat-11        In IESG processing - ID Tracker state <RFC Ed Queue>	
draft-ietf-xrblock-rtcp-xr-synchronization-05     Active	

From gonzalo.camarillo@ericsson.com  Sun May 26 23:38:10 2013
Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9E221F942B for <pm-dir@ietfa.amsl.com>; Sun, 26 May 2013 23:38:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.198
X-Spam-Level: 
X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgqmpYsbf2fO for <pm-dir@ietfa.amsl.com>; Sun, 26 May 2013 23:38:05 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7860821F920B for <pm-dir@ietf.org>; Sun, 26 May 2013 23:38:04 -0700 (PDT)
X-AuditID: c1b4fb30-b7f8a6d000001a2d-9e-51a2ff4a453b
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C7.87.06701.A4FF2A15; Mon, 27 May 2013 08:38:03 +0200 (CEST)
Received: from [131.160.126.70] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Mon, 27 May 2013 08:37:58 +0200
Message-ID: <51A2FF45.1030609@ericsson.com>
Date: Mon, 27 May 2013 09:37:57 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
References: <CD8499D5.4FA30%alan.d.clark@telchemy.com> <A64E8EB6A56342CB8423D1532A94709C@china.huawei.com> <51656EB3.9060300@cisco.com> <B8F9A780D330094D99AF023C5877DABA43A3C121@nkgeml501-mbs.china.huawei.com> <519F81F9.5070903@cisco.com>
In-Reply-To: <519F81F9.5070903@cisco.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvra73/0WBBt/eM1lsPTaR0WLiG2aL OdMvslocfSxh8XjuAlaLrz9/sFqsn3yJxeLoB0uLpZ2n2C1+H5rH6sDl8bJ/DqPHwZVz2D2m /N7I6rFz1l12j5Yjb1k9liz5yeTx4uh2do+eS7MZPY7NP8cYwBnFZZOSmpNZllqkb5fAlTHr wR+Wgu92Fbeeb2JqYLxn1MXIwSEhYCJx/551FyMnkCkmceHeerYuRi4OIYFTjBKfpzczQzhr GCV+3ZnHClLFK6AtsebeOjYQm0VAVeJK/28WEJtNwEJiy637YLaoQJTEnHUP2CDqBSVOznwC FhcBqu/fuoUFZCizwBMmiemdyxlBHGGBBkaJxtXzmSDWvQNat+Yl2DpOAU2Jkxs/skEcKCmx 5UU7O4jNDBRv3f4bypaXaN46mxnEFgI6b/mzFpYJjEKzkGyfhaRlFpKWBYzMqxjZcxMzc9LL zTcxAiPo4JbfBjsYN90XO8QozcGiJM7bpz01UEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPj vKNCjrGt1jVbVPTqkufNC9qzOy/XfneJzUYF2UVf61zthS5Oci4W/dJvvCR52Y9rd8VDF7/I 02m+ELouuqTyWIZkl8q330uuOAtOK2aeIO7ixn5Lh+XehYbCw58ush2btlyy1To7cbvRUxuj n0pXWufUvvToXeQZyBRwcGpxxJxf619Jf7BXYinOSDTUYi4qTgQAEAW1AG4CAAA=
Cc: "Huangyihong \(Rachel\)" <rachel.huang@huawei.com>, "Dan \(Dan\)" <dromasca@avaya.com>, "asaeda@nict.go.jp" <asaeda@nict.go.jp>, Alan Clark <alan.d.clark@telchemy.com>, "glenzorn@gmail.com" <glenzorn@gmail.com>, Shida Schubert <shida@ntt-at.com>, "pm-dir@ietf.org" <pm-dir@ietf.org>, Qin Wu <bill.wu@huawei.com>, Al Morton <acmorton@att.com>
Subject: Re: [pm-dir] =?utf-8?b?562U5aSNOiBSRkM2MzkwIHJldmlldyBvZiBkcmFmdC1p?= =?utf-8?q?etf-xrblock-rtcp-xr-decodability?=
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 May 2013 06:38:10 -0000

Thanks for your note, Benoit :-)

Gonzalo

On 24/05/2013 6:06 PM, Benoit Claise wrote:
> Hi Qin,
>> Hi,Benoit:
>> As Alan observed in PM-DIR review, this draft does not define new
>> metrics but refers to metrics that are
>> clearly defined in a normative reference.
>> I think we can skip RFC6390 template usage just like PDV
>> draft(RFC6798) did, can't we?
> I finally had to the time to review this document, which is on the IESG
> telechat on Thursday.
> Basically, Alan is right, the answer is "yes, you can skip RFC6390"
> And I'm balloting "no objection".
> For once, I don't have any DISCUSS on your document. I thought I would
> let you know. ;-)
> 
> Regards, Benoit
>>
>> Regards!
>> -Qin
>> -----邮件原件-----
>> 发件人: Benoit Claise [mailto:bclaise@cisco.com]
>> 发送时间: 2013年4月10日 21:53
>> 收件人: Qin Wu
>> 抄送: Alan Clark; Gonzalo Camarillo; pm-dir@ietf.org; Dan (Dan); Shida
>> Schubert; Huangyihong (Rachel); asaeda@nict.go.jp; glenzorn@gmail.com;
>> Al Morton
>> 主题: Re: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
>>
>> Hi Qin,
>>
>> And don't forget the RFC 6390 template usage.
>>
>> Regards, Benoit
>>> Hi, Alan:
>>> Thank for your valuable comments.
>>> We have updated the draft to incorporate your comments in the new
>>> version (-v11).
>>> The diff is:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-decodability-11
>>>
>>> Please also see my reply below.
>>>
>>> Regards!
>>> -Qin
>>> ----- Original Message -----
>>> From: "Alan Clark" <alan.d.clark@telchemy.com>
>>> To: "Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>;
>>> <pm-dir@ietf.org>; "Benoit Claise" <bclaise@cisco.com>; "Dan (Dan)"
>>> <dromasca@avaya.com>; "Shida Schubert" <shida@ntt-at.com>;
>>> <rachel.huang@huawei.com>; <bill.wu@huawei.com>; <asaeda@nict.go.jp>;
>>> <glenzorn@gmail.com>; "Al Morton" <acmorton@att.com>
>>> Sent: Saturday, April 06, 2013 3:10 AM
>>> Subject: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
>>>
>>>
>>> There are quite a few issues with the draft - I can re-review as soon as
>>> these are addressed.
>>>
>>> Alan Clark
>>>
>>>
>>>
>>> A. General Comments
>>>    This draft does not define new metrics but refers to metrics that are
>>> clearly defined in a normative reference.  The normative reference (ETSI
>>> TR101290) predates RFC6390 however does contain a fairly clear
>>> description
>>> of the metrics with explanation of their usage. It is not recommended
>>> that
>>> this draft redefines the metrics in RFC6390 template form
>>>
>>> [Qin]: Exactly.
>>>
>>> however there is
>>> considerable scope for improvement in the clarity of definition of
>>> how these
>>> metrics are used.
>>>
>>> [Qin]: Agree.
>>>    B. Applicability Section
>>>    1.4 Applicability
>>> Metrics only measure transport stream quality not content stream
>>> quality.
>>> Also the metrics are not defined in this draft but are encodings of the
>>> metrics defined in ETSI TS 101290.
>>>    Suggest
>>>    ³This block type allows a counts of MPEG Transport Stream quality
>>> metrics
>>> that are measured in accordance with ETSI TR 101290 [ETSI] to be
>>> reported by
>>> an endpoint.  These metrics are useful for identifying bitstream
>>> packetization and transport stream encoding problems that may affect the
>>> user¹s perception of a video service delivered over RTP.²
>>>
>>> [Qin]: Okay. Your proposed text have been incorporated in (-v11).
>>>    C. Metrics Definitions
>>>    C.1 General
>>>    For clarity the draft should preface the metrics definitions with
>>> a general
>>> explanation of how these metrics relate to ETSI TR101290. TR101290
>>> generally
>>> defines error events and this draft contains counts of those metrics.
>>>
>>>    If there are any ³edge² cases where a problem in one measurement
>>> interval
>>> would be reflected in the count in the next measurement interval then
>>> this
>>> should be articulated in the general description and also in the
>>> specific
>>> metric.  For example, a sync byte error is defined as multiple
>>> consecutive
>>> errored sync bytes and if this was reported in an interval it may have
>>> occurred at the end of the preceding interval or at some time during the
>>> present interval - hence the description should state that the count may
>>> reflect a problem in the current or previous interval. This would
>>> also be
>>> the case for PCR errors and even continuity count errors.
>>>
>>> [Qin]: Okay, I have added some text in the 2nd paragraph of section 3
>>> and incorporated your suggested text in (v-11).
>>>    C.2  Sequence numbers
>>>    begin_seq and end_seq
>>>    These definitions simply say ³As defined inS² which requires the
>>> reader to
>>> refer to another document. It is good practice to at least mention
>>> what the
>>> definition refers to and then to include a reference that contains the
>>> normative definition.
>>>    SoS..
>>>    ³begin_seq: 16 bits
>>>
>>> The RTP sequence number corresponding to the start of the measurement
>>> period, as defined in Section 4.1 of RFC 3611²
>>>
>>> [Qin]: Fixed in (-v11).
>>>    C.3 Metrics definitions
>>> The metrics definitions should contain a firmer statement of what is
>>> being
>>> measured and, if the normative definition is in another standard, then
>>> clearly state ³as defined in Section X.Y of NNNNN². This applies to
>>> all the
>>> metrics definitions and the example below can be used as a template for
>>>    For example
>>>    Existing language S..
>>>    TS_sync_loss_count: 32 bits
>>>    Number of TS_sync_loss errors in the above sequence number
>>> interval.  It is
>>> calculated based on the occurrence of errors for "TS_sync_loss"parameter
>>> defined in the section 5.2.1 of [ETSI] (Also see section 5.5.1 of
>>> [ETSI]).
>>>    This is very vague language and it is unclear why the ³Also see²
>>> reference
>>> is there.  A better approach is:
>>>    Replacement language (use this format for each of the metrics)
>>>    TS_sync_loss_count: 32 bits
>>>    A count of the number of TS_sync_loss errors that occurred in the
>>> above
>>> sequence number interval.  A TS_sync_loss error occurs when there are
>>> two or
>>> more consecutive incorrect sync bytes within the MPEG TS stream, as
>>> defined
>>> in section 5.2.1 of [ETSI]. This parameter may be used as part of a
>>> Service
>>> Availability calculation, as defined in section 5.5.1 of [ETSI].
>>>
>>> [Qin]: Fixed in (-v11).
>>>    C.4 Service Availability
>>>    Following on from the previous comment,  section 5.5.1 of TR101290
>>> describes
>>> a service availability error as a combination of TS_sync_loss,
>>> PAT_error and
>>> PMT_error whereas draft-ietf-xrblock-rtcp-xr-decodability-10 does not
>>> contain the PAT and PMT error metrics.  The resolution for this would
>>> either
>>> be to remove the reference to 5.5.1 or to add the metrics required to
>>> calculate the service availability.
>>>    [Qin]: Agree. I prefer to remove the reference to 5.5.1 since
>>> there was consensus in the past WGLC to this draft
>>> that having a second report block later to cover the other parameters
>>> and get inline with concept of RFC6792
>>> and letting this draft focus on PSI indpendent parameter reporting.
>>> See details for the WGLC discussion in the following link:
>>> http://www.ietf.org/mail-archive/web/xrblock/current/msg01032.html
>>>
>>> It is recommended that PAT_error , PAT_error_2,  PMT_error and
>>> PMT_error_2
>>> be included as metrics as these ³are² generally present in MPEG
>>> Transport
>>> streams and errors within these can prevent correct decoding of the
>>> stream.
>>>    C.5 PCR_error_count
>>>    PCR_error_count is defined twice - the second of these should be
>>> PCR_accuracy_error_count
>>>       [Qin]: Good catch and have fixed in (-v11).
>>>
>>>
>>>
>>
>>
> 


From bill.wu@huawei.com  Fri May 24 17:58:17 2013
Return-Path: <bill.wu@huawei.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD13521E804A for <pm-dir@ietfa.amsl.com>; Fri, 24 May 2013 17:58:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.373
X-Spam-Level: 
X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3Rq3NqhuUq1 for <pm-dir@ietfa.amsl.com>; Fri, 24 May 2013 17:58:13 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BC19921F9497 for <pm-dir@ietf.org>; Fri, 24 May 2013 17:58:11 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATD57100; Sat, 25 May 2013 00:58:09 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 25 May 2013 01:57:50 +0100
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 25 May 2013 01:58:06 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Sat, 25 May 2013 08:57:58 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Benoit Claise <bclaise@cisco.com>
Thread-Topic: =?utf-8?B?562U5aSNOiBSRkM2MzkwIHJldmlldyBvZiBkcmFmdC1pZXRmLXhyYmxvY2st?= =?utf-8?Q?rtcp-xr-decodability?=
Thread-Index: AQHOWJChmddorPziYE+rMnEBzNxpE5kVFHMg
Date: Sat, 25 May 2013 00:57:57 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA43B3B87A@nkgeml501-mbs.china.huawei.com>
References: <CD8499D5.4FA30%alan.d.clark@telchemy.com> <A64E8EB6A56342CB8423D1532A94709C@china.huawei.com> <51656EB3.9060300@cisco.com> <B8F9A780D330094D99AF023C5877DABA43A3C121@nkgeml501-mbs.china.huawei.com> <519F81F9.5070903@cisco.com>
In-Reply-To: <519F81F9.5070903@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.149]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Tue, 28 May 2013 04:32:32 -0700
Cc: "Huangyihong \(Rachel\)" <rachel.huang@huawei.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, "Dan \(Dan\)" <dromasca@avaya.com>, "asaeda@nict.go.jp" <asaeda@nict.go.jp>, Alan Clark <alan.d.clark@telchemy.com>, "glenzorn@gmail.com" <glenzorn@gmail.com>, Shida Schubert <shida@ntt-at.com>, "pm-dir@ietf.org" <pm-dir@ietf.org>, Al Morton <acmorton@att.com>
Subject: Re: [pm-dir] =?utf-8?b?562U5aSNOiBSRkM2MzkwIHJldmlldyBvZiBkcmFmdC1p?= =?utf-8?q?etf-xrblock-rtcp-xr-decodability?=
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 May 2013 00:58:17 -0000

VGhhbmtzIEJlbm9pdC4gWW91IGFyZSB2ZXJ5IGtpbmQsOi0pIQ0KDQpSZWdhcmRzIQ0KLVFpbg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJlbm9pdCBDbGFpc2UgW21haWx0bzpi
Y2xhaXNlQGNpc2NvLmNvbV0gDQpTZW50OiBGcmlkYXksIE1heSAyNCwgMjAxMyAxMTowNyBQTQ0K
VG86IFFpbiBXdQ0KQ2M6IEFsYW4gQ2xhcms7IEdvbnphbG8gQ2FtYXJpbGxvOyBwbS1kaXJAaWV0
Zi5vcmc7IERhbiAoRGFuKTsgU2hpZGEgU2NodWJlcnQ7IEh1YW5neWlob25nIChSYWNoZWwpOyBh
c2FlZGFAbmljdC5nby5qcDsgZ2xlbnpvcm5AZ21haWwuY29tOyBBbCBNb3J0b24NClN1YmplY3Q6
IFJlOiDnrZTlpI06IFJGQzYzOTAgcmV2aWV3IG9mIGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhy
LWRlY29kYWJpbGl0eQ0KDQpIaSBRaW4sDQo+IEhpLEJlbm9pdDoNCj4gQXMgQWxhbiBvYnNlcnZl
ZCBpbiBQTS1ESVIgcmV2aWV3LCB0aGlzIGRyYWZ0IGRvZXMgbm90IGRlZmluZSBuZXcgbWV0cmlj
cyBidXQgcmVmZXJzIHRvIG1ldHJpY3MgdGhhdCBhcmUNCj4gY2xlYXJseSBkZWZpbmVkIGluIGEg
bm9ybWF0aXZlIHJlZmVyZW5jZS4NCj4gSSB0aGluayB3ZSBjYW4gc2tpcCBSRkM2MzkwIHRlbXBs
YXRlIHVzYWdlIGp1c3QgbGlrZSBQRFYgZHJhZnQoUkZDNjc5OCkgZGlkLCBjYW4ndCB3ZT8NCkkg
ZmluYWxseSBoYWQgdG8gdGhlIHRpbWUgdG8gcmV2aWV3IHRoaXMgZG9jdW1lbnQsIHdoaWNoIGlz
IG9uIHRoZSBJRVNHIA0KdGVsZWNoYXQgb24gVGh1cnNkYXkuDQpCYXNpY2FsbHksIEFsYW4gaXMg
cmlnaHQsIHRoZSBhbnN3ZXIgaXMgInllcywgeW91IGNhbiBza2lwIFJGQzYzOTAiDQpBbmQgSSdt
IGJhbGxvdGluZyAibm8gb2JqZWN0aW9uIi4NCkZvciBvbmNlLCBJIGRvbid0IGhhdmUgYW55IERJ
U0NVU1Mgb24geW91ciBkb2N1bWVudC4gSSB0aG91Z2h0IEkgd291bGQgDQpsZXQgeW91IGtub3cu
IDstKQ0KDQpSZWdhcmRzLCBCZW5vaXQNCj4NCj4gUmVnYXJkcyENCj4gLVFpbg0KPiAtLS0tLemC
ruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogQmVub2l0IENsYWlzZSBbbWFpbHRvOmJjbGFp
c2VAY2lzY28uY29tXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTPlubQ05pyIMTDml6UgMjE6NTMNCj4g
5pS25Lu25Lq6OiBRaW4gV3UNCj4g5oqE6YCBOiBBbGFuIENsYXJrOyBHb256YWxvIENhbWFyaWxs
bzsgcG0tZGlyQGlldGYub3JnOyBEYW4gKERhbik7IFNoaWRhIFNjaHViZXJ0OyBIdWFuZ3lpaG9u
ZyAoUmFjaGVsKTsgYXNhZWRhQG5pY3QuZ28uanA7IGdsZW56b3JuQGdtYWlsLmNvbTsgQWwgTW9y
dG9uDQo+IOS4u+mimDogUmU6IFJGQzYzOTAgcmV2aWV3IG9mIGRyYWZ0LWlldGYteHJibG9jay1y
dGNwLXhyLWRlY29kYWJpbGl0eQ0KPg0KPiBIaSBRaW4sDQo+DQo+IEFuZCBkb24ndCBmb3JnZXQg
dGhlIFJGQyA2MzkwIHRlbXBsYXRlIHVzYWdlLg0KPg0KPiBSZWdhcmRzLCBCZW5vaXQNCj4+IEhp
LCBBbGFuOg0KPj4gVGhhbmsgZm9yIHlvdXIgdmFsdWFibGUgY29tbWVudHMuDQo+PiBXZSBoYXZl
IHVwZGF0ZWQgdGhlIGRyYWZ0IHRvIGluY29ycG9yYXRlIHlvdXIgY29tbWVudHMgaW4gdGhlIG5l
dyB2ZXJzaW9uICgtdjExKS4NCj4+IFRoZSBkaWZmIGlzOg0KPj4gaHR0cDovL3d3dy5pZXRmLm9y
Zy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItZGVjb2RhYmlsaXR5LTEx
DQo+PiBQbGVhc2UgYWxzbyBzZWUgbXkgcmVwbHkgYmVsb3cuDQo+Pg0KPj4gUmVnYXJkcyENCj4+
IC1RaW4NCj4+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4+IEZyb206ICJBbGFuIENs
YXJrIiA8YWxhbi5kLmNsYXJrQHRlbGNoZW15LmNvbT4NCj4+IFRvOiAiR29uemFsbyBDYW1hcmls
bG8iIDxHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20+OyA8cG0tZGlyQGlldGYub3JnPjsg
IkJlbm9pdCBDbGFpc2UiIDxiY2xhaXNlQGNpc2NvLmNvbT47ICJEYW4gKERhbikiIDxkcm9tYXNj
YUBhdmF5YS5jb20+OyAiU2hpZGEgU2NodWJlcnQiIDxzaGlkYUBudHQtYXQuY29tPjsgPHJhY2hl
bC5odWFuZ0BodWF3ZWkuY29tPjsgPGJpbGwud3VAaHVhd2VpLmNvbT47IDxhc2FlZGFAbmljdC5n
by5qcD47IDxnbGVuem9ybkBnbWFpbC5jb20+OyAiQWwgTW9ydG9uIiA8YWNtb3J0b25AYXR0LmNv
bT4NCj4+IFNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAwNiwgMjAxMyAzOjEwIEFNDQo+PiBTdWJqZWN0
OiBSRkM2MzkwIHJldmlldyBvZiBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1kZWNvZGFiaWxp
dHkNCj4+DQo+Pg0KPj4gVGhlcmUgYXJlIHF1aXRlIGEgZmV3IGlzc3VlcyB3aXRoIHRoZSBkcmFm
dCAtIEkgY2FuIHJlLXJldmlldyBhcyBzb29uIGFzDQo+PiB0aGVzZSBhcmUgYWRkcmVzc2VkLg0K
Pj4NCj4+IEFsYW4gQ2xhcmsNCj4+DQo+Pg0KPj4NCj4+IEEuIEdlbmVyYWwgQ29tbWVudHMNCj4+
ICAgIA0KPj4gVGhpcyBkcmFmdCBkb2VzIG5vdCBkZWZpbmUgbmV3IG1ldHJpY3MgYnV0IHJlZmVy
cyB0byBtZXRyaWNzIHRoYXQgYXJlDQo+PiBjbGVhcmx5IGRlZmluZWQgaW4gYSBub3JtYXRpdmUg
cmVmZXJlbmNlLiAgVGhlIG5vcm1hdGl2ZSByZWZlcmVuY2UgKEVUU0kNCj4+IFRSMTAxMjkwKSBw
cmVkYXRlcyBSRkM2MzkwIGhvd2V2ZXIgZG9lcyBjb250YWluIGEgZmFpcmx5IGNsZWFyIGRlc2Ny
aXB0aW9uDQo+PiBvZiB0aGUgbWV0cmljcyB3aXRoIGV4cGxhbmF0aW9uIG9mIHRoZWlyIHVzYWdl
LiBJdCBpcyBub3QgcmVjb21tZW5kZWQgdGhhdA0KPj4gdGhpcyBkcmFmdCByZWRlZmluZXMgdGhl
IG1ldHJpY3MgaW4gUkZDNjM5MCB0ZW1wbGF0ZSBmb3JtDQo+Pg0KPj4gW1Fpbl06IEV4YWN0bHku
DQo+Pg0KPj4gaG93ZXZlciB0aGVyZSBpcw0KPj4gY29uc2lkZXJhYmxlIHNjb3BlIGZvciBpbXBy
b3ZlbWVudCBpbiB0aGUgY2xhcml0eSBvZiBkZWZpbml0aW9uIG9mIGhvdyB0aGVzZQ0KPj4gbWV0
cmljcyBhcmUgdXNlZC4NCj4+DQo+PiBbUWluXTogQWdyZWUuDQo+PiAgICANCj4+IEIuIEFwcGxp
Y2FiaWxpdHkgU2VjdGlvbg0KPj4gICAgDQo+PiAxLjQgQXBwbGljYWJpbGl0eQ0KPj4gTWV0cmlj
cyBvbmx5IG1lYXN1cmUgdHJhbnNwb3J0IHN0cmVhbSBxdWFsaXR5IG5vdCBjb250ZW50IHN0cmVh
bSBxdWFsaXR5Lg0KPj4gQWxzbyB0aGUgbWV0cmljcyBhcmUgbm90IGRlZmluZWQgaW4gdGhpcyBk
cmFmdCBidXQgYXJlIGVuY29kaW5ncyBvZiB0aGUNCj4+IG1ldHJpY3MgZGVmaW5lZCBpbiBFVFNJ
IFRTIDEwMTI5MC4NCj4+ICAgIA0KPj4gU3VnZ2VzdA0KPj4gICAgDQo+PiDCs1RoaXMgYmxvY2sg
dHlwZSBhbGxvd3MgYSBjb3VudHMgb2YgTVBFRyBUcmFuc3BvcnQgU3RyZWFtIHF1YWxpdHkgbWV0
cmljcw0KPj4gdGhhdCBhcmUgbWVhc3VyZWQgaW4gYWNjb3JkYW5jZSB3aXRoIEVUU0kgVFIgMTAx
MjkwIFtFVFNJXSB0byBiZSByZXBvcnRlZCBieQ0KPj4gYW4gZW5kcG9pbnQuICBUaGVzZSBtZXRy
aWNzIGFyZSB1c2VmdWwgZm9yIGlkZW50aWZ5aW5nIGJpdHN0cmVhbQ0KPj4gcGFja2V0aXphdGlv
biBhbmQgdHJhbnNwb3J0IHN0cmVhbSBlbmNvZGluZyBwcm9ibGVtcyB0aGF0IG1heSBhZmZlY3Qg
dGhlDQo+PiB1c2VywrlzIHBlcmNlcHRpb24gb2YgYSB2aWRlbyBzZXJ2aWNlIGRlbGl2ZXJlZCBv
dmVyIFJUUC7Csg0KPj4NCj4+IFtRaW5dOiBPa2F5LiBZb3VyIHByb3Bvc2VkIHRleHQgaGF2ZSBi
ZWVuIGluY29ycG9yYXRlZCBpbiAoLXYxMSkuDQo+PiAgICANCj4+IEMuIE1ldHJpY3MgRGVmaW5p
dGlvbnMNCj4+ICAgIA0KPj4gQy4xIEdlbmVyYWwNCj4+ICAgIA0KPj4gRm9yIGNsYXJpdHkgdGhl
IGRyYWZ0IHNob3VsZCBwcmVmYWNlIHRoZSBtZXRyaWNzIGRlZmluaXRpb25zIHdpdGggYSBnZW5l
cmFsDQo+PiBleHBsYW5hdGlvbiBvZiBob3cgdGhlc2UgbWV0cmljcyByZWxhdGUgdG8gRVRTSSBU
UjEwMTI5MC4gVFIxMDEyOTAgZ2VuZXJhbGx5DQo+PiBkZWZpbmVzIGVycm9yIGV2ZW50cyBhbmQg
dGhpcyBkcmFmdCBjb250YWlucyBjb3VudHMgb2YgdGhvc2UgbWV0cmljcy4NCj4+DQo+PiAgICAN
Cj4+IElmIHRoZXJlIGFyZSBhbnkgwrNlZGdlwrIgY2FzZXMgd2hlcmUgYSBwcm9ibGVtIGluIG9u
ZSBtZWFzdXJlbWVudCBpbnRlcnZhbA0KPj4gd291bGQgYmUgcmVmbGVjdGVkIGluIHRoZSBjb3Vu
dCBpbiB0aGUgbmV4dCBtZWFzdXJlbWVudCBpbnRlcnZhbCB0aGVuIHRoaXMNCj4+IHNob3VsZCBi
ZSBhcnRpY3VsYXRlZCBpbiB0aGUgZ2VuZXJhbCBkZXNjcmlwdGlvbiBhbmQgYWxzbyBpbiB0aGUg
c3BlY2lmaWMNCj4+IG1ldHJpYy4gIEZvciBleGFtcGxlLCBhIHN5bmMgYnl0ZSBlcnJvciBpcyBk
ZWZpbmVkIGFzIG11bHRpcGxlIGNvbnNlY3V0aXZlDQo+PiBlcnJvcmVkIHN5bmMgYnl0ZXMgYW5k
IGlmIHRoaXMgd2FzIHJlcG9ydGVkIGluIGFuIGludGVydmFsIGl0IG1heSBoYXZlDQo+PiBvY2N1
cnJlZCBhdCB0aGUgZW5kIG9mIHRoZSBwcmVjZWRpbmcgaW50ZXJ2YWwgb3IgYXQgc29tZSB0aW1l
IGR1cmluZyB0aGUNCj4+IHByZXNlbnQgaW50ZXJ2YWwgLSBoZW5jZSB0aGUgZGVzY3JpcHRpb24g
c2hvdWxkIHN0YXRlIHRoYXQgdGhlIGNvdW50IG1heQ0KPj4gcmVmbGVjdCBhIHByb2JsZW0gaW4g
dGhlIGN1cnJlbnQgb3IgcHJldmlvdXMgaW50ZXJ2YWwuIFRoaXMgd291bGQgYWxzbyBiZQ0KPj4g
dGhlIGNhc2UgZm9yIFBDUiBlcnJvcnMgYW5kIGV2ZW4gY29udGludWl0eSBjb3VudCBlcnJvcnMu
DQo+Pg0KPj4gW1Fpbl06IE9rYXksIEkgaGF2ZSBhZGRlZCBzb21lIHRleHQgaW4gdGhlIDJuZCBw
YXJhZ3JhcGggb2Ygc2VjdGlvbiAzDQo+PiBhbmQgaW5jb3Jwb3JhdGVkIHlvdXIgc3VnZ2VzdGVk
IHRleHQgaW4gKHYtMTEpLg0KPj4gICAgDQo+PiBDLjIgIFNlcXVlbmNlIG51bWJlcnMNCj4+ICAg
IA0KPj4gYmVnaW5fc2VxIGFuZCBlbmRfc2VxDQo+PiAgICANCj4+IFRoZXNlIGRlZmluaXRpb25z
IHNpbXBseSBzYXkgwrNBcyBkZWZpbmVkIGluU8KyIHdoaWNoIHJlcXVpcmVzIHRoZSByZWFkZXIg
dG8NCj4+IHJlZmVyIHRvIGFub3RoZXIgZG9jdW1lbnQuIEl0IGlzIGdvb2QgcHJhY3RpY2UgdG8g
YXQgbGVhc3QgbWVudGlvbiB3aGF0IHRoZQ0KPj4gZGVmaW5pdGlvbiByZWZlcnMgdG8gYW5kIHRo
ZW4gdG8gaW5jbHVkZSBhIHJlZmVyZW5jZSB0aGF0IGNvbnRhaW5zIHRoZQ0KPj4gbm9ybWF0aXZl
IGRlZmluaXRpb24uDQo+PiAgICANCj4+IFNvUy4uDQo+PiAgICANCj4+IMKzYmVnaW5fc2VxOiAx
NiBiaXRzDQo+Pg0KPj4gVGhlIFJUUCBzZXF1ZW5jZSBudW1iZXIgY29ycmVzcG9uZGluZyB0byB0
aGUgc3RhcnQgb2YgdGhlIG1lYXN1cmVtZW50DQo+PiBwZXJpb2QsIGFzIGRlZmluZWQgaW4gU2Vj
dGlvbiA0LjEgb2YgUkZDIDM2MTHCsg0KPj4NCj4+IFtRaW5dOiBGaXhlZCBpbiAoLXYxMSkuDQo+
PiAgICANCj4+IEMuMyBNZXRyaWNzIGRlZmluaXRpb25zDQo+PiBUaGUgbWV0cmljcyBkZWZpbml0
aW9ucyBzaG91bGQgY29udGFpbiBhIGZpcm1lciBzdGF0ZW1lbnQgb2Ygd2hhdCBpcyBiZWluZw0K
Pj4gbWVhc3VyZWQgYW5kLCBpZiB0aGUgbm9ybWF0aXZlIGRlZmluaXRpb24gaXMgaW4gYW5vdGhl
ciBzdGFuZGFyZCwgdGhlbg0KPj4gY2xlYXJseSBzdGF0ZSDCs2FzIGRlZmluZWQgaW4gU2VjdGlv
biBYLlkgb2YgTk5OTk7Csi4gVGhpcyBhcHBsaWVzIHRvIGFsbCB0aGUNCj4+IG1ldHJpY3MgZGVm
aW5pdGlvbnMgYW5kIHRoZSBleGFtcGxlIGJlbG93IGNhbiBiZSB1c2VkIGFzIGEgdGVtcGxhdGUg
Zm9yDQo+PiAgICANCj4+IEZvciBleGFtcGxlDQo+PiAgICANCj4+IEV4aXN0aW5nIGxhbmd1YWdl
IFMuLg0KPj4gICAgDQo+PiBUU19zeW5jX2xvc3NfY291bnQ6IDMyIGJpdHMNCj4+ICAgIA0KPj4g
TnVtYmVyIG9mIFRTX3N5bmNfbG9zcyBlcnJvcnMgaW4gdGhlIGFib3ZlIHNlcXVlbmNlIG51bWJl
ciBpbnRlcnZhbC4gIEl0IGlzDQo+PiBjYWxjdWxhdGVkIGJhc2VkIG9uIHRoZSBvY2N1cnJlbmNl
IG9mIGVycm9ycyBmb3IgIlRTX3N5bmNfbG9zcyJwYXJhbWV0ZXINCj4+IGRlZmluZWQgaW4gdGhl
IHNlY3Rpb24gNS4yLjEgb2YgW0VUU0ldIChBbHNvIHNlZSBzZWN0aW9uIDUuNS4xIG9mIFtFVFNJ
XSkuDQo+PiAgICANCj4+IFRoaXMgaXMgdmVyeSB2YWd1ZSBsYW5ndWFnZSBhbmQgaXQgaXMgdW5j
bGVhciB3aHkgdGhlIMKzQWxzbyBzZWXCsiByZWZlcmVuY2UNCj4+IGlzIHRoZXJlLiAgQSBiZXR0
ZXIgYXBwcm9hY2ggaXM6DQo+PiAgICANCj4+IFJlcGxhY2VtZW50IGxhbmd1YWdlICh1c2UgdGhp
cyBmb3JtYXQgZm9yIGVhY2ggb2YgdGhlIG1ldHJpY3MpDQo+PiAgICANCj4+IFRTX3N5bmNfbG9z
c19jb3VudDogMzIgYml0cw0KPj4gICAgDQo+PiBBIGNvdW50IG9mIHRoZSBudW1iZXIgb2YgVFNf
c3luY19sb3NzIGVycm9ycyB0aGF0IG9jY3VycmVkIGluIHRoZSBhYm92ZQ0KPj4gc2VxdWVuY2Ug
bnVtYmVyIGludGVydmFsLiAgQSBUU19zeW5jX2xvc3MgZXJyb3Igb2NjdXJzIHdoZW4gdGhlcmUg
YXJlIHR3byBvcg0KPj4gbW9yZSBjb25zZWN1dGl2ZSBpbmNvcnJlY3Qgc3luYyBieXRlcyB3aXRo
aW4gdGhlIE1QRUcgVFMgc3RyZWFtLCBhcyBkZWZpbmVkDQo+PiBpbiBzZWN0aW9uIDUuMi4xIG9m
IFtFVFNJXS4gVGhpcyBwYXJhbWV0ZXIgbWF5IGJlIHVzZWQgYXMgcGFydCBvZiBhIFNlcnZpY2UN
Cj4+IEF2YWlsYWJpbGl0eSBjYWxjdWxhdGlvbiwgYXMgZGVmaW5lZCBpbiBzZWN0aW9uIDUuNS4x
IG9mIFtFVFNJXS4NCj4+DQo+PiBbUWluXTogRml4ZWQgaW4gKC12MTEpLg0KPj4gICAgDQo+PiBD
LjQgU2VydmljZSBBdmFpbGFiaWxpdHkNCj4+ICAgIA0KPj4gRm9sbG93aW5nIG9uIGZyb20gdGhl
IHByZXZpb3VzIGNvbW1lbnQsICBzZWN0aW9uIDUuNS4xIG9mIFRSMTAxMjkwIGRlc2NyaWJlcw0K
Pj4gYSBzZXJ2aWNlIGF2YWlsYWJpbGl0eSBlcnJvciBhcyBhIGNvbWJpbmF0aW9uIG9mIFRTX3N5
bmNfbG9zcywgUEFUX2Vycm9yIGFuZA0KPj4gUE1UX2Vycm9yIHdoZXJlYXMgZHJhZnQtaWV0Zi14
cmJsb2NrLXJ0Y3AteHItZGVjb2RhYmlsaXR5LTEwIGRvZXMgbm90DQo+PiBjb250YWluIHRoZSBQ
QVQgYW5kIFBNVCBlcnJvciBtZXRyaWNzLiAgVGhlIHJlc29sdXRpb24gZm9yIHRoaXMgd291bGQg
ZWl0aGVyDQo+PiBiZSB0byByZW1vdmUgdGhlIHJlZmVyZW5jZSB0byA1LjUuMSBvciB0byBhZGQg
dGhlIG1ldHJpY3MgcmVxdWlyZWQgdG8NCj4+IGNhbGN1bGF0ZSB0aGUgc2VydmljZSBhdmFpbGFi
aWxpdHkuDQo+PiAgICANCj4+IFtRaW5dOiBBZ3JlZS4gSSBwcmVmZXIgdG8gcmVtb3ZlIHRoZSBy
ZWZlcmVuY2UgdG8gNS41LjEgc2luY2UgdGhlcmUgd2FzIGNvbnNlbnN1cyBpbiB0aGUgcGFzdCBX
R0xDIHRvIHRoaXMgZHJhZnQNCj4+IHRoYXQgaGF2aW5nIGEgc2Vjb25kIHJlcG9ydCBibG9jayBs
YXRlciB0byBjb3ZlciB0aGUgb3RoZXIgcGFyYW1ldGVycyBhbmQgZ2V0IGlubGluZSB3aXRoIGNv
bmNlcHQgb2YgUkZDNjc5Mg0KPj4gYW5kIGxldHRpbmcgdGhpcyBkcmFmdCBmb2N1cyBvbiBQU0kg
aW5kcGVuZGVudCBwYXJhbWV0ZXIgcmVwb3J0aW5nLg0KPj4gU2VlIGRldGFpbHMgZm9yIHRoZSBX
R0xDIGRpc2N1c3Npb24gaW4gdGhlIGZvbGxvd2luZyBsaW5rOg0KPj4gaHR0cDovL3d3dy5pZXRm
Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL3hyYmxvY2svY3VycmVudC9tc2cwMTAzMi5odG1sDQo+Pg0K
Pj4gSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBQQVRfZXJyb3IgLCBQQVRfZXJyb3JfMiwgIFBNVF9l
cnJvciBhbmQgUE1UX2Vycm9yXzINCj4+IGJlIGluY2x1ZGVkIGFzIG1ldHJpY3MgYXMgdGhlc2Ug
wrNhcmXCsiBnZW5lcmFsbHkgcHJlc2VudCBpbiBNUEVHIFRyYW5zcG9ydA0KPj4gc3RyZWFtcyBh
bmQgZXJyb3JzIHdpdGhpbiB0aGVzZSBjYW4gcHJldmVudCBjb3JyZWN0IGRlY29kaW5nIG9mIHRo
ZSBzdHJlYW0uDQo+PiAgICANCj4+IEMuNSBQQ1JfZXJyb3JfY291bnQNCj4+ICAgIA0KPj4gUENS
X2Vycm9yX2NvdW50IGlzIGRlZmluZWQgdHdpY2UgLSB0aGUgc2Vjb25kIG9mIHRoZXNlIHNob3Vs
ZCBiZQ0KPj4gUENSX2FjY3VyYWN5X2Vycm9yX2NvdW50DQo+PiAgICANCj4+ICAgIFtRaW5dOiBH
b29kIGNhdGNoIGFuZCBoYXZlIGZpeGVkIGluICgtdjExKS4NCj4+DQo+Pg0KPj4NCj4NCj4NCg0K

From bill.wu@huawei.com  Mon May 27 02:52:28 2013
Return-Path: <bill.wu@huawei.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0234821F8CA5 for <pm-dir@ietfa.amsl.com>; Mon, 27 May 2013 02:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMywJc6zh1LG for <pm-dir@ietfa.amsl.com>; Mon, 27 May 2013 02:52:22 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ECB7921F8E12 for <pm-dir@ietf.org>; Mon, 27 May 2013 02:52:21 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATF13969; Mon, 27 May 2013 09:52:18 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 27 May 2013 10:51:47 +0100
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 27 May 2013 10:52:11 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Mon, 27 May 2013 17:52:00 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Vinayak Hegde <vinayakh@gmail.com>
Thread-Topic: Review of xrblock rtcp xr synchronization Version 5
Thread-Index: AQHOWZEjxsbaEAHhEEyWVl4fyINwvpkV6m+AgALLtsCAAAIaIA==
Date: Mon, 27 May 2013 09:51:59 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA43B3BE07@nkgeml501-mbs.china.huawei.com>
References: <51E6A56BD6A85142B9D172C87FC3ABBB458165FF@nkgeml501-mbs.china.huawei.com>
In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB458165FF@nkgeml501-mbs.china.huawei.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.149]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43B3BE07nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Tue, 28 May 2013 04:32:32 -0700
Cc: "pm-dir@ietf.org" <pm-dir@ietf.org>, "Huangyihong \(Rachel\)" <rachel.huang@huawei.com>, "asaeda@nict.go.jp" <asaeda@nict.go.jp>
Subject: Re: [pm-dir] Review of xrblock rtcp xr synchronization Version 5
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 May 2013 09:52:28 -0000

--_000_B8F9A780D330094D99AF023C5877DABA43B3BE07nkgeml501mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi, Vinayak:
Thank for your confirmation for RFC6390 requirements.
Please see my reply inline.

Regards!
-Qin

From: Vinayak Hegde [mailto:vinayakh@gmail.com]
Sent: Sunday, May 26, 2013 5:50 AM
To: pm-dir@ietf.org<mailto:pm-dir@ietf.org>; asaeda@nict.go.jp<mailto:asaed=
a@nict.go.jp>; Huangyihong (Rachel); Qin Wu
Subject: Re: Review of xrblock rtcp xr synchronization Version 5

Hi,

Used the wrong alias in the initial mail. Please reply to this mail as I ha=
ve fixedc the mail address.

-- Vinayak
On Sun, May 26, 2013 at 3:15 AM, Vinayak Hegde <vinayakh@gmail.com<mailto:v=
inayakh@gmail.com>> wrote:
Hi,

I reveiewd the  xrblock rtcp xr synchronization Version 5 draft at

The draft does specify and fulfill all the requirements of RFC 6390

Comments are below:

Section 3.2
Initial Synchronization Delay: 32 bits

The selection of units in 1/65536 seconds seems arbitrary (inspite of the f=
act that it could make bit arithmetic easier). I would suggest to use may b=
e denote each bit as 1/10000 or 1/100000 (too granualr ?) units. This could=
 be much more useful for interaction with humans such as in reading debug o=
utput (which is likely since this is a synchronization delay).

[Qin]: The choice of 1/65536 of a second is not arbitrary, it's based on th=
e properties of the NTP format time stamp, and to match the rest of the RTP=
 protocol. This is the reason why the draft was switched to use 1/65536 of =
a second. Using the other units is appropriate for this report block.

Section 4.2
For the offset constant <RFSO> it is not clear what the 8-bit is. Either yo=
u can note it here or reference it.

[Qin]: Okay, we can add a sentence to say:
"
      [Note to RFC Editor: please replace RFSO with the IANA provided
      RTCP XR block type for this block.]
"


-- Vinayak


--_000_B8F9A780D330094D99AF023C5877DABA43B3BE07nkgeml501mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML \9884\8BBE\683C\5F0F Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"\6279\6CE8\6846\6587\672C Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:9.0pt;
	font-family:SimSun;}
span.HTMLChar
	{mso-style-name:"HTML \9884\8BBE\683C\5F0F Char";
	mso-style-priority:99;
	mso-style-link:"HTML \9884\8BBE\683C\5F0F";
	font-family:"Courier New";}
span.hoenzb
	{mso-style-name:hoenzb;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.Char
	{mso-style-name:"\6279\6CE8\6846\6587\672C Char";
	mso-style-priority:99;
	mso-style-link:\6279\6CE8\6846\6587\672C;
	font-family:SimSun;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi,
</span>Vinayak:<o:p></o:p></p>
<p class=3D"MsoNormal">Thank for your confirmation for RFC6390 requirements=
. <o:p></o:p></p>
<p class=3D"MsoNormal">Please see my reply inline.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Regards!<o:p></o:p></p>
<p class=3D"MsoNormal">-Qin<span style=3D"font-size:11.0pt;font-family:&quo=
t;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Vinayak =
Hegde [<a href=3D"mailto:vinayakh@gmail.com">mailto:vinayakh@gmail.com</a>]
<br>
<b>Sent:</b> Sunday, May 26, 2013 5:50 AM<br>
<b>To:</b> <a href=3D"mailto:pm-dir@ietf.org">pm-dir@ietf.org</a>; <a href=
=3D"mailto:asaeda@nict.go.jp">
asaeda@nict.go.jp</a>; Huangyihong (Rachel); Qin Wu<br>
<b>Subject:</b> Re: Review of xrblock rtcp xr synchronization Version 5<o:p=
></o:p></span></p>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi,<br>
<br>
Used the wrong alias in the initial mail. Please reply to this mail as I ha=
ve fixedc the mail address.<br>
<br>
-- Vinayak<o:p></o:p></p>
<div>
<p class=3D"MsoNormal">On Sun, May 26, 2013 at 3:15 AM, Vinayak Hegde &lt;<=
a href=3D"mailto:vinayakh@gmail.com" target=3D"_blank">vinayakh@gmail.com</=
a>&gt; wrote:<o:p></o:p></p>
<p class=3D"MsoNormal">Hi,<br>
<br>
I reveiewd the&nbsp; xrblock rtcp xr synchronization Version 5 draft at <br=
>
<br>
The draft does specify and fulfill all the requirements of RFC 6390<br>
<br>
Comments are below:<br>
<br>
Section 3.2<br>
Initial Synchronization Delay: 32 bits<br>
<br>
The selection of units in 1/65536 seconds seems arbitrary (inspite of the f=
act that it could make bit arithmetic easier). I would suggest to use may b=
e denote each bit as 1/10000 or 1/100000 (too granualr ?) units. This could=
 be much more useful for interaction
 with humans such as in reading debug output (which is likely since this is=
 a synchronization delay).<br>
<br>
<span style=3D"color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Qin]:
</span>The choice of 1/65536 of a second is not arbitrary, it's based on th=
e properties of the NTP format time stamp, and to match the rest of the RTP=
 protocol. This is the reason why the draft was switched to use 1/65536 of =
a second. Using the other units
 is appropriate for this report block.<span style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p=
></span></p>
<p class=3D"MsoNormal"><br>
Section 4.2 <br>
For the offset constant &lt;RFSO&gt; it is not clear what the 8-bit is. Eit=
her you can note it here or reference it.<span style=3D"color:#1F497D"><o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Qin]: Okay, we can add a=
 sentence to say:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&#8220;<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal" style=3D"page-break-before:always"><span lang=3D"EN"=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; [Note to RFC Editor: please replace
</span><span lang=3D"EN" style=3D"font-size:10.0pt;font-family:&quot;Courie=
r New&quot;">RFSO</span><span lang=3D"EN" style=3D"font-size:10.0pt;font-fa=
mily:&quot;Courier New&quot;"> with the IANA provided<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"page-break-before:always"><span lang=3D"EN"=
 style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; RTCP XR block type for this block.]</span><span lang=3D=
"EN" style=3D"font-size:10.0pt;font-family:&quot;Courier New&quot;"><o:p></=
o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">&#8221;<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"color:#888888"><br>
<br>
<span class=3D"hoenzb">-- Vinayak</span></span><o:p></o:p></p>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_B8F9A780D330094D99AF023C5877DABA43B3BE07nkgeml501mbschi_--

From vinayakh@gmail.com  Fri May 31 19:41:26 2013
Return-Path: <vinayakh@gmail.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CE221F8EAD for <pm-dir@ietfa.amsl.com>; Fri, 31 May 2013 19:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzwvBGljDT3R for <pm-dir@ietfa.amsl.com>; Fri, 31 May 2013 19:41:22 -0700 (PDT)
Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4132721F8E37 for <pm-dir@ietf.org>; Fri, 31 May 2013 19:41:19 -0700 (PDT)
Received: by mail-pd0-f176.google.com with SMTP id r11so3089544pdi.35 for <pm-dir@ietf.org>; Fri, 31 May 2013 19:41:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=j1msec5E4h3bpSTFOz3FUOYnFqDsC901dguUy2gotPY=; b=ghkuGFRR0JS5Q4nACWQgHX1DEZWzMtbUapKUbPImdpthh16/ng4rg2UF/M0JjRlzNP +Q1qeONUt7ozFlrlaPIf2Oa6HmHjvUrXlrWZSiz40eBy7QkkufOlUJE+1TYriNb1EK3y RfzqXHr+5gO8pU1cApsZbYMYi0tmwq6MWV6GjzjHmFxqlJJNhpO41AMs5MT+9BHKNAm9 dd67nZydc0p17PXqjy/XZvdfBUstpxY+1ALpSM+RpRfAsevpSiOGk4EABGrW+aayXn/r ZzJUCOtNj0e5WJvnDJs+6542AkewDk4jLHhg+sbnXhxrS9OzM192z/55o7anpJXDuAMC 8Fug==
MIME-Version: 1.0
X-Received: by 10.66.150.168 with SMTP id uj8mr16254312pab.34.1370054478657; Fri, 31 May 2013 19:41:18 -0700 (PDT)
Received: by 10.66.232.233 with HTTP; Fri, 31 May 2013 19:41:18 -0700 (PDT)
Date: Sat, 1 Jun 2013 08:11:18 +0530
Message-ID: <CAKe6YvMinkX--5MksKtBAyvsNWJbEusBjQ33CJ_7TgpAA3HmUQ@mail.gmail.com>
From: Vinayak Hegde <vinayakh@gmail.com>
To: pm-dir@ietf.org, gwz@net-zen.net, alan.d.clark@telchemy.com,  bijy@sttri.com.cn, sunseawq@huawei.com
Content-Type: multipart/alternative; boundary=047d7b677dea86051a04de0eaa08
Subject: [pm-dir] PM dir - Review of RTCP XR Report Block for Concealment metrics Reporting on Audio Applications
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Jun 2013 02:41:26 -0000

--047d7b677dea86051a04de0eaa08
Content-Type: text/plain; charset=ISO-8859-1

Hi draft authors / PM-dir,

I did a review of the  RTCP XR Report Block for Concealment metrics
Reporting on Audio Applications (version 5)
Link - http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-loss-conceal-05

The draft is well written and conforms to RFC 6390 template for performance
metric definition. I have only some small nitpicks to improve clarity and
comprehension. Comments follow:
===
1.1
SCS threshold fixed (constant) - how is it communicated to the receiver ?
Please add a reference to the definition later in the draft.

3.2. Definition of Fields in Loss Concealment Report Block

VAD acronym is not defined at first use though it is defined and referenced
further down in the draft. Please reference it here to improve clarity.

-- Vinayak

--047d7b677dea86051a04de0eaa08
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi draft authors / PM-dir,<br><br>I did a review of the=A0 RTCP XR Report B=
lock for Concealment metrics Reporting on Audio Applications (version 5)<br=
>Link - <a href=3D"http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-lo=
ss-conceal-05">http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-loss-c=
onceal-05</a><br>
<br>The draft is well written and conforms to RFC 6390 template for perform=
ance metric definition. I have only some small nitpicks to improve clarity =
and comprehension. Comments follow:<br>=3D=3D=3D<br>1.1<br>SCS threshold fi=
xed (constant) - how is it communicated to the receiver ? Please add a refe=
rence to the definition later in the draft.<br>
<br>3.2. Definition of Fields in Loss Concealment Report Block<br><br>VAD a=
cronym is not defined at first use though it is defined and referenced furt=
her down in the draft. Please reference it here to improve clarity.<br>
<br>-- Vinayak<br>

--047d7b677dea86051a04de0eaa08--