Re: [pm-dir] FW: draft-ietf-xrblock-rtcp-xr-discard-rle-metrics PM-D= IR review

Subject:	[IESG-AGENDA-DIST] Summarized Agenda for the 2013-07-11 IESG Teleconference
Date:	Thu, 04 Jul 2013 14:58:58 -0700
From:	IESG Secretary <iesg-secretary@ietf.org>
To:	iesg-agenda-dist@ietf.org

= PM-DIR,

Would someone please volunteer to review

https://datatracker.ietf.org/doc/draft-ietf= -xrblock-rtcp-xr-discard-rle-metrics/

Note that the d= raft is about 10 pages long, and appears on the telechat agenda<= /span>

10 days hence (when Benoit would need the r= eview).

thanks,

pm-dir admin

From: Benoit Claise= [mailto:bclaise@cisco.com]
Sent: Monday, July 08, 2013 11:47 AM=
To: MORTON JR., ALFRED C (AL)
Subject: draft-ietf-xrbl= ock-rtcp-xr-discard-rle-metrics PM-DIR review

Hi Al,
Can you please assign someone for the PM-DIR review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics

Regards, Beno= it

= --_000_F1312FAF1A1E624DA0972D1C9A91379A1CA22DE362njfpsrvexg7re_-- From alan.d.clark@telchemy.com Mon Jul 8 09:05:46 2013 Return-Path: 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 8D78D21F9AC5 for ; Mon, 8 Jul 2013 09:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7P4cKmFe-QOD for ; Mon, 8 Jul 2013 09:05:42 -0700 (PDT) Received: from omx.cbeyond.com (omx.cbeyond.com [50.20.30.10]) by ietfa.amsl.com (Postfix) with ESMTP id CCD5E21F86D5 for ; Mon, 8 Jul 2013 09:05:10 -0700 (PDT) X-SBRS: None X-HAT: Sender Group ONNET_RELAY, Policy $ACCEPTED applied. X-Hostname: omx03bay.sys.cbeyond.net X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoDAB/i2lFFD9PB/2dsb2JhbAANTYJFdsEtAwEggQiDFwEBAQMBAQEBOjEQDQEIBAkBAwQBASguHwgBCAEBBAESiAkSpmeSBASPDFsKAYNwA54Zji8 X-IronPort-AV: E=Sophos;i="4.87,1021,1363147200"; d="scan'208,217";a="53081282" Received: from unknown (HELO [192.168.1.117]) ([69.15.211.193]) by omx.cbeyond.com with ESMTP/TLS/DES-CBC3-SHA; 08 Jul 2013 12:05:07 -0400 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 08 Jul 2013 12:05:03 -0400 From: Alan Clark To: Al Morton , "pm-dir@ietf.org" Message-ID: Thread-Topic: [pm-dir] FW: draft-ietf-xrblock-rtcp-xr-discard-rle-metrics PM-DIR review Thread-Index: Ac578nGbZ0Z2CghJTWWTgRpr9KRRHwAAN7XQAABl0S8= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3456129907_1680384" Subject: Re: [pm-dir] FW: draft-ietf-xrblock-rtcp-xr-discard-rle-metrics PM-DIR review X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 16:05:46 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3456129907_1680384 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Al I can review this draft Regards Alan On 7/8/13 11:58 AM, "Al Morton" wrote: > PM-DIR, > > Would someone please volunteer to review > > https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-discard-rle-metric > s/ > > Note that the draft is about 10 pages long, and appears on the telechat agenda > 10 days hence (when Benoit would need the review). > > thanks, > Al > pm-dir admin > > > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Monday, July 08, 2013 11:47 AM > To: MORTON JR., ALFRED C (AL) > Subject: draft-ietf-xrblock-rtcp-xr-discard-rle-metrics PM-DIR review > > Hi Al, > > Can you please assign someone for the PM-DIR review of > draft-ietf-xrblock-rtcp-xr-discard-rle-metrics > cs/> > > Regards, Benoit > > > _______________________________________________ > pm-dir mailing list > pm-dir@ietf.org > https://www.ietf.org/mailman/listinfo/pm-dir --B_3456129907_1680384 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [pm-dir] FW: draft-ietf-xrblock-rtcp-xr-discard-rle-metrics PM-D= IR review Al

I can review this draft

Regards

Alan

On 7/8/13 11:58 AM, "Al Morton" <ac= morton@att.com> wrote:

<= FONT SIZE=3D"2">PM-DIR,

Would someone please volunteer to review

https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-= discard-rle-metrics/

Note that the draft is about 10 pages long, and appears on the telechat age= nda
10 days hence (when Benoit would need the review).

thanks,
Al
pm-dir admin

From: Benoit Clai= se [mailto:bclaise@cisco.com]
Sent: Monday, July 08, 2013 11:47 AM
To: MORTON JR., ALFRED C (AL)
Subject: draft-ietf-xrblock-rtcp-xr-discard-rle-metrics PM-DIR revie= w

Hi Al,

Can you please assign someone for the PM-DIR review of draft-ietf-xrblock-r= tcp-xr-discard-rle-metrics <https://datatracker.ietf.org/d= oc/draft-ietf-xrblock-rtcp-xr-discard-rle-metrics/>

Regards, Benoit

___________= ____________________________________
pm-dir mailing list
pm-dir@ietf.org
https://www.ietf.org= /mailman/listinfo/pm-dir

--B_3456129907_1680384-- From bclaise@cisco.com Sun Jul 14 14:06:20 2013 Return-Path: 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 D9A2221F9AC1 for ; Sun, 14 Jul 2013 14:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 x7M5R14QGU-3 for ; Sun, 14 Jul 2013 14:06:15 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 049C921F91CE for ; Sun, 14 Jul 2013 14:06:14 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6EL6E4a015878 for ; Sun, 14 Jul 2013 17:06:14 -0400 (EDT) Received: from sweet-brew-5.cisco.com (sweet-brew-5.cisco.com [144.254.10.206]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6EL6DG0004221 for ; Sun, 14 Jul 2013 17:06:14 -0400 (EDT) Received: (from bclaise@localhost) by sweet-brew-5.cisco.com (8.13.8+Sun/8.13.6/Submit) id r6EL68xH011672 for pm-dir@ietf.org; Sun, 14 Jul 2013 23:06:08 +0200 (CEST) Date: Sun, 14 Jul 2013 23:06:08 +0200 From: Benoit Claise To: pm-dir@ietf.org Message-ID: <20130714210608.GA11670@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 21:06:21 -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-ippm-testplan-rfc2680-03 Active draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 In IESG processing - ID Tracker state Informative References ---------------------- draft-ietf-ippm-testplan-rfc2680-03 Active draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-decodability-12 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-discard-15 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-jb-14 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-loss-conceal-08 Active draft-ietf-xrblock-rtcp-xr-qoe-10 Active draft-ietf-xrblock-rtcp-xr-summary-stat-11 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-synchronization-06 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-2330-update-00 Active draft-ietf-ippm-lmap-path-00 Active draft-ietf-ippm-model-based-metrics-00 Active draft-ietf-ippm-rate-problem-03 Active draft-ietf-ippm-testplan-rfc2680-03 Active draft-ietf-manet-smf-mib-07 In IESG processing - ID Tracker state draft-ietf-nvo3-framework-03 Active draft-ietf-opsawg-oam-overview-09 In IESG processing - ID Tracker state draft-ietf-ppsp-base-tracker-protocol-01 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 draft-ietf-xrblock-rtcp-xr-decodability-12 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-discard-15 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-jb-14 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-loss-conceal-08 Active draft-ietf-xrblock-rtcp-xr-qoe-10 Active draft-ietf-xrblock-rtcp-xr-summary-stat-11 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-synchronization-06 Active From alan.d.clark@telchemy.com Tue Jul 16 08:58:26 2013 Return-Path: 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 8142421F9B5D for ; Tue, 16 Jul 2013 08:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ZfPDh2SezAPU for ; Tue, 16 Jul 2013 08:58:21 -0700 (PDT) Received: from omx.cbeyond.com (omx.cbeyond.com [50.20.30.10]) by ietfa.amsl.com (Postfix) with ESMTP id 201F121F9B07 for ; Tue, 16 Jul 2013 08:58:19 -0700 (PDT) X-SBRS: None X-HAT: Sender Group ONNET_RELAY, Policy $ACCEPTED applied. X-Hostname: omx04bay.sys.cbeyond.net X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwDAOhs5VFFD9PB/2dsb2JhbAANTYJCwx8DIYEFgx49TgEVAYEQAQQBq1OSRI8AhF8DiG+LFoodjjU X-IronPort-AV: E=Sophos;i="4.89,677,1367985600"; d="scan'208,217";a="55260809" Received: from unknown (HELO [192.168.1.117]) ([69.15.211.193]) by omx.cbeyond.com with ESMTP/TLS/DES-CBC3-SHA; 16 Jul 2013 11:58:12 -0400 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 16 Jul 2013 11:58:03 -0400 From: Alan Clark To: Al Morton , Benoit Claise , , , , , "Dan (Dan)" , Shida Schubert Message-ID: Thread-Topic: RFC6390 review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 Thread-Index: Ac6CPUCs5Rlgpyx0NEyYCUiOrwxpvw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3456820694_18335901" Subject: [pm-dir] RFC6390 review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:58:29 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3456820694_18335901 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Alan Clark=B9s Comments on Discard RLE block draft The draft is entitled Run Length Encoding of Discarded Packets however includes a block that is not a run length encoded and which does not contai= n a count of discarded packets. =20 Section 3 =20 This draft has a strong dependency on the definitions of RFC3611 Section 4.= 1 and has a weak reference to a discard definition. draft-ietf-xrblock-xr-discard draft has a definition of Discard and I recommend that we refer to this. =20 =B3The XR Discard RLE report block uses exactly the same format, parameter an= d chunk definitions as the Loss RLE Report Block defined in RFC3611 Section 4.1 with the sole change that Chunks represent counts of discarded packets rather than lost packets. A definition of a discarded packet is given in draft-ietf-xrblock-xr-discard.=B2 =20 Figure 1 should be titled =B3XR Discard RLE Report Block=B2 =20 Last but one paragraph states that Discard RLE report blocks should not contain conflicting indications of packets being early and late - however does not state what a receiver should do if it receives conflicting blocks. State whether the blocks should be ignored or only the conflicting packets ignored. Other than a normative reference to =B3discard=B2 the definition of this block does not require an RFC6390 metric template as it refers to a sufficiently detailed definition in RFC3611. =20 Section 4 =20 The XR Bytes Discarded report block is much closer in intent and form to th= e Discard Count block contained in draft-ietf-xrblock-xr-discard, and is not run length encoded or a count of packets which places it in conflict with the =B3Run Length Encoding of Discarded Packets=B2 draft=B9s title. In order to comply with RFC6390 this block definition should follow the metric template and describe: =20 (i) How to determine if a packet or a byte is discarded. Presumably this would be that the packet was received but was too early or late to be useful. What if a duplicate packet was received - would the discard of a duplicate packet be regarded as a =B3discard=B2? =20 (ii) How to count how many bytes are discarded - is this RTP payload bytes, UDP/TCP payload bytes or IP packet bytes? Presumably the intent is RTP payload bytes however this should be explicitly stated and reference made t= o the treatment of RTP header extensions and padding. =20 (iii) What edge cases may exist and how to handle these. For example if a late packet is received at the start of an interval then the resulting discarded packet and bytes would technically apply to the previous interval= . >From a practical perspective it may be simpler just to say that if a packet is discarded during an interval then it is counted as a discard for that interval, however this should be explicitly stated. In summary - I would recommend the following: =20 Either =20 (a) Rename the draft to ensure that the title represents both blocks (as it currently only describes one block) AND include a metrics definition according to the template given in RFC6390 for both blocks. =20 Or - Preferred but with one complication =20 (b) Move the Bytes Discarded block to the draft-ietf-xrblock-xr-discard draft. The RLE Discard block draft can rely on the description in RFC3611, which does not follow the template but is fairly detailed and can be slightly augmented to refer to the definition of =B3discard=B2 in draft-ietf-xrblock-xr-discard. The main problem with this is that the draft-ietf-xrblock-xr-discard draft is in the RFC Editor=B9s Edit queue - I=B9m not sure whether this would be too much of an Edit? Regards Alan Clark --B_3456820694_18335901 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable RFC6390 review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06<= /TITLE> </HEAD> <BODY> Alan Clark’= s Comments on Discard RLE block draft The draft is entitled Run Length Encoding of Discarded Packets however incl= udes a block that is not a run length encoded and which does not contain a c= ount of discarded packets. Section 3 This draft has a strong dependency on the definitions of RFC3611 Section 4.= 1 and has a weak reference to a discard definition. draft-ietf-xrblock= -xr-discard draft has a definition of Discard and I recommend that we refer = to this. “The XR Discard RLE report block uses exactly the same format, parame= ter and chunk definitions as the Loss RLE Report Block defined in RFC3611 Se= ction 4.1 with the sole change that Chunks represent counts of discarded pac= kets rather than lost packets. A definition of a discarded packet is given i= n draft-ietf-xrblock-xr-discard.” Figure 1 should be titled “XR Discard RLE Report Block” Last but one paragraph states that Discard RLE report blocks should not con= tain conflicting indications of packets being early and late - however does = not state what a receiver should do if it receives conflicting blocks. State= whether the blocks should be ignored or only the conflicting packets ignore= d. Other than a normative reference to “discard” the definition of= this block does not require an RFC6390 metric template as it refers to a su= fficiently detailed definition in RFC3611. Section 4 The XR Bytes Discarded report block is much closer in intent and form to th= e Discard Count block contained in draft-ietf-xrblock-xr-discard, and = is not run length encoded or a count of packets which places it in conflict = with the “Run Length Encoding of Discarded Packets” draft’= s title. In order to comply with RFC6390 this block definition should follow the met= ric template and describe: (i) How to determine if a packet or a byte is discarded. Presumably this wo= uld be that the packet was received but was too early or late to be useful. = What if a duplicate packet was received - would the discard of a dupli= cate packet be regarded as a “discard”? (ii) How to count how many bytes are discarded - is this RTP payload bytes,= UDP/TCP payload bytes or IP packet bytes? Presumably the intent is RT= P payload bytes however this should be explicitly stated and reference made = to the treatment of RTP header extensions and padding. (iii) What edge cases may exist and how to handle these. For example = if a late packet is received at the start of an interval then the resulting = discarded packet and bytes would technically apply to the previous interval.= From a practical perspective it may be simpler just to say that if a = packet is discarded during an interval then it is counted as a discard for t= hat interval, however this should be explicitly stated. In summary - I would recommend the following: Either (a) Rename the draft to ensure that the title represents both blocks (as it= currently only describes one block) AND include a metrics definition accord= ing to the template given in RFC6390 for both blocks. Or - Preferred but with one complication (b) Move the Bytes Discarded block to the draft-ietf-xrblock-xr-discard dra= ft. The RLE Discard block draft can rely on the description in RFC3611, whic= h does not follow the template but is fairly detailed and can be slightly au= gmented to refer to the definition of “discard” in draft-ietf-xr= block-xr-discard. The main problem with this is that the draft-ietf-xrblock-= xr-discard draft is in the RFC Editor’s Edit queue - I’m not sur= e whether this would be too much of an Edit? Regards Alan Clark </BODY> </HTML> --B_3456820694_18335901-- From alan.d.clark@telchemy.com Tue Jul 16 12:10:24 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 4680A21E809D for <pm-dir@ietfa.amsl.com>; Tue, 16 Jul 2013 12:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 5W4Gxl1de2oF for <pm-dir@ietfa.amsl.com>; Tue, 16 Jul 2013 12:10:19 -0700 (PDT) Received: from omx.cbeyond.com (omx.cbeyond.com [50.20.30.10]) by ietfa.amsl.com (Postfix) with ESMTP id D4B6821E8056 for <pm-dir@ietf.org>; Tue, 16 Jul 2013 12:09:58 -0700 (PDT) X-SBRS: None X-HAT: Sender Group ONNET_RELAY, Policy $ACCEPTED applied. X-Hostname: omx03bay.sys.cbeyond.net X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0DALCY5VFFD9PB/2dsb2JhbAANTYJCwzkDASCBB4MePTwSAQwBCAGBEAEEAQ2rT5I7jwBfhAADniKONQ X-IronPort-AV: E=Sophos;i="4.89,678,1367985600"; d="scan'208,217";a="55409020" Received: from unknown (HELO [192.168.1.117]) ([69.15.211.193]) by omx.cbeyond.com with ESMTP/TLS/DES-CBC3-SHA; 16 Jul 2013 15:09:47 -0400 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 16 Jul 2013 15:09:47 -0400 From: Alan Clark <alan.d.clark@telchemy.com> To: Colin Perkins <csp@csperkins.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>, <jorg.ott@aalto.fi>, <pm-dir@ietf.org> Message-ID: <CE0B12BB.52C13%alan.d.clark@telchemy.com> Thread-Topic: RFC6390 Review of draft-ietf-rtcweb-rtp-usage-07 Thread-Index: Ac6CWAmXBvEnHnSSFUa/FuAi+PqVrg== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3456832187_19029823" Cc: Benoit Claise <bclaise@cisco.com>, rib@ipv.sx, ted.ietf@gmail.com, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, fluffy@iii.ca Subject: [pm-dir] RFC6390 Review of draft-ietf-rtcweb-rtp-usage-07 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: Tue, 16 Jul 2013 19:10:24 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3456832187_19029823 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Comments from Alan Clark This review was requested (some months ago) from the Performance Management Directorate and is focused on whether the -07 draft of rtcweb-rtp-usage contains any metrics that should be defined in accordance with RFC6390, and if so then to recommend what the definition should contain. This review does not consider what metrics could or should be incorporated into the draft. draft-ietf-rtcweb-rtp-usage-07 describes how RTP is used in the context of WebRTC. The sections of this draft to which RFC6390 could apply are the definitions of Picture/Slice Loss Indication and the section on Performance Monitoring. 1. Sections 5.1.2 and 5.1.3 refer to Picture and Slice Loss Indication. These terms are normatively and sufficiently defined in RFC4585. 2. Section 8 mandates the use of RTCP SR/RR and refers to the use of XR for performance reporting and does not contain any metric definitions. draft-ietf-rtcweb-rtp-usage-07 does not require any changes resulting from this review. If any metrics are added to subsequent versions of this draft they should be defined in accordance with RFC6390. Regards Alan Clark --B_3456832187_19029823 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>RFC6390 Review of draft-ietf-rtcweb-rtp-usage-07 Comments from Alan Clark

This review was requested (some months ago) from the Performance Management= Directorate and is focused on whether the -07 draft of rtcweb-rtp-usage con= tains any metrics that should be defined in accordance with RFC6390, and if = so then to recommend what the definition should contain. This review d= oes not consider what metrics could or should be incorporated into the draft= .

draft-ietf-rtcweb-rtp-usage-07 describes how RTP is used in the context of = WebRTC. The sections of this draft to which RFC6390 could apply are the defi= nitions of Picture/Slice Loss Indication and the section on Performance Moni= toring.

1. Sections 5.1.2 and 5.1.3 refer to Picture and Slice Loss Indication. The= se terms are normatively and sufficiently defined in RFC4585.

2. Section 8 mandates the use of RTCP SR/RR and refers to the use of XR for= performance reporting and does not contain any metric definitions.

draft-ietf-rtcweb-rtp-usage-07 does not require any changes resulting from = this review. If any metrics are added to subsequent versions of this draft t= hey should be defined in accordance with RFC6390.

Regards

Alan Clark
--B_3456832187_19029823-- From bclaise@cisco.com Wed Jul 17 00:34:38 2013 Return-Path: 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 CB6A821F8956; Wed, 17 Jul 2013 00:34:38 -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.042, 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 lWMHh--6Puxv; Wed, 17 Jul 2013 00:34:33 -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 54BFA21F9A18; Wed, 17 Jul 2013 00:34:33 -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 r6H7YWrv016366; Wed, 17 Jul 2013 09:34:32 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6H7YGkE007829; Wed, 17 Jul 2013 09:34:26 +0200 (CEST) Message-ID: <51E648F8.7020107@cisco.com> Date: Wed, 17 Jul 2013 09:34:16 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors o , "ops-dir@ietf.org" , "pm-dir@ietf.org" , IETF DNS Directorate References: <20130715221930.5235.34434.idtracker@ietfa.amsl.com> In-Reply-To: <20130715221930.5235.34434.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130715221930.5235.34434.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010807020206070902040808" Subject: [pm-dir] IESG telechat: Agenda and Package for the July 18, 2013 Teleconference X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 07:34:39 -0000 This is a multi-part message in MIME format. --------------010807020206070902040808 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, We have back to back formal telechat. Please find below the agenda of the July 18th IESG telechat. Please send your questions, comments and concerns before July 17th COB. Sorry for the short notice. Thanks and Regards, Benoit. -------- Original Message -------- Subject: UPDATED Agenda and Package for the July 18, 2013 Teleconference Date: Mon, 15 Jul 2013 15:19:30 -0700 From: IESG Secretary To: The IESG CC: avezza@amsl.com, cmorgan@amsl.com, iesg-scribes@ietf.org, rse@rfc-editor.org 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-payload-vp8-09 - IETF stream RTP Payload Format for VP8 Video (Proposed Standard) Note: Ali Begen (abegen@cisco.com) is the document shepherd. Token: Richard Barnes IANA Review: Version Changed - Review Needed Consensus: Unknown o draft-ietf-abfab-eapapplicability-05 - IETF stream Update to the EAP Applicability Statement for ABFAB (Proposed Standard) Note: Klaas Wierenga (kwiereng@cisco.com) is the doc shepherd. Token: Stephen Farrell IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 - IETF stream RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length Encoding (RLE) of Discarded Packets (Proposed Standard) Note: Shida Schubert (shida@ntt-at.com) is the document shepherd. Token: Gonzalo Camarillo IANA Review: IANA OK - Actions Needed Consensus: Unknown o draft-ietf-jcardcal-jcard-05 - IETF stream jCard: The JSON format for vCard (Proposed Standard) Token: Pete Resnick IANA Review: IANA - Review Needed Consensus: Yes Last call expires: 2013-07-18 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items NONE 2.3 Status Changes 2.3.1 New Items NONE 2.3.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-multimob-pmipv6-ropt-07 - IETF stream Multicast Mobility Routing Optimizations for Proxy Mobile IPv6 (Experimental) Note: The document went through IETF Last Call as Informational, but has since been re-classified as Experimental. Token: Brian Haberman IANA Review: IANA OK - Actions Needed Consensus: Unknown o draft-ietf-dhc-dhcpv6-failover-requirements-06 - IETF stream DHCPv6 Failover Requirements (Informational) Note: Bernie Volz (volz@cisco.com) is the document shepherd. Token: Ted Lemon IANA Review: IANA OK - No Actions Needed Consensus: Yes Last call expires: 2013-07-17 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items NONE 3.2.2 Returning Items NONE 3.3 Status Changes 3.3.1 New Items NONE 3.3.2 Returning Items NONE 3.4 IRTF and Independent Submission Stream Documents 3.4.1 New Items NONE 3.4.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o Transparent Interconnection of Lots of Links (trill) 4.2.2 Proposed for Approval NONE --------------010807020206070902040808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear all,

We have back to back formal telechat.
Please find below the agenda of the July 18th IESG telechat.
Please send your questions, comments and concerns before July 17th COB.
Sorry for the short notice.

Thanks and Regards, Benoit.

-------- Original Message --------

Subject:	UPDATED Agenda and Package for the July 18, 2013 Teleconference
Date:	Mon, 15 Jul 2013 15:19:30 -0700
From:	IESG Secretary <iesg-secretary@ietf.org>
To:	The IESG <iesg@ietf.org>
CC:	avezza@amsl.com, cmorgan@amsl.com, iesg-scribes@ietf.org, rse@rfc-editor.org


2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items

  o draft-ietf-payload-vp8-09  - IETF stream
    RTP Payload Format for VP8 Video (Proposed Standard)
    Note: Ali Begen (abegen@cisco.com) is the document shepherd.
    Token: Richard Barnes
    IANA Review: Version Changed - Review Needed
    Consensus: Unknown

  o draft-ietf-abfab-eapapplicability-05  - IETF stream
    Update to the EAP Applicability Statement for ABFAB (Proposed
    Standard)
    Note: Klaas Wierenga (kwiereng@cisco.com) is the doc shepherd.
    Token: Stephen Farrell
    IANA Review: IANA OK - No Actions Needed
    Consensus: Yes

  o draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06  - IETF stream
    RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length
    Encoding (RLE) of Discarded Packets (Proposed Standard)
    Note: Shida Schubert (shida@ntt-at.com) is the document shepherd.
    Token: Gonzalo Camarillo
    IANA Review: IANA OK - Actions Needed
    Consensus: Unknown

  o draft-ietf-jcardcal-jcard-05  - IETF stream
    jCard: The JSON format for vCard (Proposed Standard)
    Token: Pete Resnick
    IANA Review: IANA - Review Needed
    Consensus: Yes
    Last call expires: 2013-07-18

2.1.2 Returning Items

  NONE

2.2 Individual Submissions
2.2.1 New Items

  NONE

2.2.2 Returning Items

  NONE

2.3 Status Changes
2.3.1 New Items

  NONE

2.3.2 Returning Items

  NONE

3. Document Actions
3.1 WG Submissions
3.1.1 New Items

  o draft-ietf-multimob-pmipv6-ropt-07  - IETF stream
    Multicast Mobility Routing Optimizations for Proxy Mobile IPv6
    (Experimental)
    Note: The document went through IETF Last Call as Informational, but
    has since been re-classified as Experimental.
    Token: Brian Haberman
    IANA Review: IANA OK - Actions Needed
    Consensus: Unknown

  o draft-ietf-dhc-dhcpv6-failover-requirements-06  - IETF stream
    DHCPv6 Failover Requirements (Informational)
    Note: Bernie Volz (volz@cisco.com) is the document shepherd.
    Token: Ted Lemon
    IANA Review: IANA OK - No Actions Needed
    Consensus: Yes
    Last call expires: 2013-07-17

3.1.2 Returning Items

  NONE

3.2 Individual Submissions Via AD
3.2.1 New Items

  NONE

3.2.2 Returning Items

  NONE

3.3 Status Changes
3.3.1 New Items

  NONE

3.3.2 Returning Items

  NONE

3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items

  NONE

3.4.2 Returning Items

  NONE

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review

  NONE

4.1.2 Proposed for Approval

  NONE

4.2 WG Rechartering
4.2.1 Under Evaluation for IETF Review

  o Transparent Interconnection of Lots of Links (trill)

4.2.2 Proposed for Approval

  NONE

--------------010807020206070902040808-- From alan.d.clark@telchemy.com Wed Jul 17 04:27:09 2013 Return-Path: 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 B2F3521F9DFB for ; Wed, 17 Jul 2013 04:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.298 X-Spam-Level: * X-Spam-Status: No, score=1.298 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, 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 FruXJmTzVFU3 for ; Wed, 17 Jul 2013 04:27:05 -0700 (PDT) Received: from omx.cbeyond.com (omx.cbeyond.com [50.20.30.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD0C21F9C86 for ; Wed, 17 Jul 2013 04:27:05 -0700 (PDT) X-SBRS: -4.0 X-HAT: Sender Group POORREP_BLACKLIST, Policy $SBRSPOOR applied. X-Hostname: omx08bay.sys.cbeyond.net X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoqAId95lFi+2EaPGdsb2JhbAANTYJCiQe7DgMBIIEGAwEBAQE4glgBAQEDAT08EgEIgQkUAQEEDgWICqMhkjOPD18Hg3oDiG+LFphS X-IronPort-AV: E=Sophos;i="4.89,684,1367985600"; d="scan'208,217";a="27567644" Received: from c-98-251-97-26.hsd1.ga.comcast.net (HELO [192.168.1.11]) ([98.251.97.26]) by omx.cbeyond.com with ESMTP/TLS/DES-CBC3-SHA; 17 Jul 2013 07:27:01 -0400 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 17 Jul 2013 07:26:53 -0400 From: Alan Clark To: Varun Singh Message-ID: Thread-Topic: RFC6390 review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 Thread-Index: Ac6C4IlpEA0s6CaGdk+D3jQdIEgB5g== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3456890822_20501100" Cc: jo@comnet.tkk.fi, Al Morton , Shida Schubert , "Dan $Dan$" , igor.curcio@nokia.com, Benoit Claise , pm-dir@ietf.org Subject: Re: [pm-dir] RFC6390 review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 11:27:09 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3456890822_20501100 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Varun On 7/17/13 5:44 AM, "Varun Singh" wrote: >=20 > Okay >=20 >> Last but one paragraph states that Discard RLE report blocks should not >> contain conflicting indications of packets being early and late - howeve= r >> does not state what a receiver should do if it receives conflicting bloc= ks. >> State whether the blocks should be ignored or only the conflicting packe= ts >> ignored. >=20 > How about adding the following line at the appropriate place: > "If packets appear in both report blocks, the conflicting packets are > ignored." >=20 >> [Alan] That would be ok >>=20 >> Other than a normative reference to =B3discard=B2 the definition of this blo= ck >> does not require an RFC6390 metric template as it refers to a sufficient= ly >> detailed definition in RFC3611. >> =20 >=20 > I'll move the reference of ietf-xrblock-rtcp-xr-discard from Informative = to > Normative. > Should that suffice? >=20 > [Alan] Change from Informative to Normative and also make the text cl= early > refer to the definition of =B3discard=B2 in the ietf-xrblock-rtcp-xr-discard = draft >=20 >> Section 4 >> =20 >> The XR Bytes Discarded report block is much closer in intent and form to= the >> Discard Count block contained in draft-ietf-xrblock-xr-discard, and is = not >> run length encoded or a count of packets which places it in conflict wit= h the >> =B3Run Length Encoding of Discarded Packets=B2 draft=B9s title. >>=20 >=20 > Proposal for new title: > RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length Encodin= g > (RLE) of Discarded Packets and Bytes Discarded. >=20 > [Alan] This does not work as it reads as if the Bytes Discarded are also = RLE. > You would have to change to something like =B3RTP Control Protocol (RTCP) > Extended Reports (XR) for Bytes Discarded and Run Length Encoding (RLE) o= f > Sequences of Discarded Packets=B2 to make it clear that the byte discard co= unts > are not run length encoded. I suggest that you discuss this with Dan and > Shida. >=20 >> In order to comply with RFC6390 this block definition should follow the >> metric template and describe: >> =20 >> (i) How to determine if a packet or a byte is discarded. Presumably this >> would be that the packet was received but was too early or late to be us= eful. >> What if a duplicate packet was received - would the discard of a duplica= te >> packet be regarded as a =B3discard=B2? >> =20 >=20 > Duplicate packets are ignored, I can make that explicit. >=20 > [Alan] Ok. >=20 >> (ii) How to count how many bytes are discarded - is this RTP payload byt= es, >> UDP/TCP payload bytes or IP packet bytes? Presumably the intent is RTP >> payload bytes however this should be explicitly stated and reference mad= e to >> the treatment of RTP header extensions and padding. >> =20 >=20 > I don't have a strong opinion here, but my proposal would be to report th= e > size of the whole RTP packet, > including RTP header and payload. However, just reporting the sum of the = RTP > payloads is also fine. >=20 > Any comments >=20 > [Alan] My suggestion would be to report the number of payload bytes disca= rded. >=20 >> (iii) What edge cases may exist and how to handle these. For example if= a >> late packet is received at the start of an interval then the resulting >> discarded packet and bytes would technically apply to the previous inter= val. >> From a practical perspective it may be simpler just to say that if a pac= ket >> is discarded during an interval then it is counted as a discard for that >> interval, however this should be explicitly stated. >>=20 >=20 > I will clarify it should be counted in the interval that it was discarded= in. >=20 > [Alan] Ok >=20 >> In summary - I would recommend the following: >> =20 >> Either >> =20 >> (a) Rename the draft to ensure that the title represents both blocks (as= it >> currently only describes one block) AND include a metrics definition >> according to the template given in RFC6390 for both blocks. >> =20 >=20 > See above for title proposal. >=20 >=20 >> Or - Preferred but with one complication >> =20 >> (b) Move the Bytes Discarded block to the draft-ietf-xrblock-xr-discard >> draft. The RLE Discard block draft can rely on the description in RFC361= 1, >> which does not follow the template but is fairly detailed and can be sli= ghtly >> augmented to refer to the definition of =B3discard=B2 in >> draft-ietf-xrblock-xr-discard. The main problem with this is that the >> draft-ietf-xrblock-xr-discard draft is in the RFC Editor=B9s Edit queue - = I=B9m >> not sure whether this would be too much of an Edit? >>=20 > I would not want to hold up the drafts longer or reset the process. > But I am open to whatever is the best course of action. >=20 > [Alan] It is a conundrum - the bytes discarded block would be a much bett= er > fit in draft-ietf-xrblock-xr-discard >=20 >>=20 >=20 >=20 --B_3456890822_20501100 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: RFC6390 review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics= -06 Hi Varun

On 7/17/13 5:44 AM, "Varun Singh" <varun@comnet.tkk.fi> wrote:

<= SPAN STYLE=3D'font-size:12pt'>
Okay

Last but one paragraph states that Discard RLE report blocks should= not contain conflicting indications of packets being early and late - howev= er does not state what a receiver should do if it receives conflicting block= s. State whether the blocks should be ignored or only the conflicting packet= s ignored.

How about adding the following line at the appropriate place:
"If packets appear in both report blocks, the conflicting packets are = ignored."

[Alan] That would be ok

Other than a normative reference to “discard” the definition of= this block does not require an RFC6390 metric template as it refers to a su= fficiently detailed definition in RFC3611.

I'll move the reference of ietf-xrblock-rtcp-xr-discard from Informative to= Normative.
Should that suffice?

[Alan] Change from Informative to Normative and als= o make the text clearly refer to the definition of “discard” in = the ietf-xrblock-rtcp-xr-discard draft

Section 4

The XR Bytes Discarded report block is much closer in intent and form to th= e Discard Count block contained in draft-ietf-xrblock-xr-discard, and = is not run length encoded or a count of packets which places it in conflict = with the “Run Length Encoding of Discarded Packets” draft’= s title.

Proposal for new title:
RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length Enco= ding (RLE) of Discarded Packets and Bytes Discarded.

[Alan] This does not work as it reads as if the Bytes Discarded are also RL= E. You would have to change to something like “RTP Control Proto= col (RTCP) Extended Reports (XR) for Bytes Discarded and Run Length Encoding= (RLE) of Sequences of Discarded Packets” to make it clear that the by= te discard counts are not run length encoded. I suggest that you discu= ss this with Dan and Shida.

In order to comply with RFC6390 this block definition should follow= the metric template and describe:

(i) How to determine if a packet or a byte is discarded. Presumably this wo= uld be that the packet was received but was too early or late to be useful. = What if a duplicate packet was received - would the discard of a dupli= cate packet be regarded as a “discard”?

Duplicate packets are ignored, I can make that explicit.

[Alan] Ok.

(ii) How to count how many bytes are discarded - is this RTP payloa= d bytes, UDP/TCP payload bytes or IP packet bytes? Presumably the inte= nt is RTP payload bytes however this should be explicitly stated and referen= ce made to the treatment of RTP header extensions and padding.

I don't have a strong opinion here, but my proposal would be to report the = size of the whole RTP packet,
including RTP header and payload. However, just reporting the sum of the RT= P payloads is also fine.

Any comments

[Alan] My suggestion would be to report the number of payload bytes discard= ed.

(iii) What edge cases may exist and how to handle these. For = example if a late packet is received at the start of an interval then the re= sulting discarded packet and bytes would technically apply to the previous i= nterval. From a practical perspective it may be simpler just to say th= at if a packet is discarded during an interval then it is counted as a disca= rd for that interval, however this should be explicitly stated.

I will clarify it should be counted in the interval that it was discarded i= n.

[Alan] Ok

In summary - I would recommend the following:

Either

(a) Rename the draft to ensure that the title represents both blocks (as it= currently only describes one block) AND include a metrics definition accord= ing to the template given in RFC6390 for both blocks.

See above for title proposal.

Or - Preferred but with one complication

(b) Move the Bytes Discarded block to the draft-ietf-xrblock-xr-discard dra= ft. The RLE Discard block draft can rely on the description in RFC3611, whic= h does not follow the template but is fairly detailed and can be slightly au= gmented to refer to the definition of “discard” in draft-ietf-xr= block-xr-discard. The main problem with this is that the draft-ietf-xrblock-= xr-discard draft is in the RFC Editor’s Edit queue - I’m not sur= e whether this would be too much of an Edit?

I would not want to hold up the drafts longer o= r reset the process.
But I am open to whatever is the best course of action.

[Alan] It is a conundrum - the bytes discarded block would be a much better= fit in draft-ietf-xrblock-xr-discard

--B_3456890822_20501100-- From varun@comnet.tkk.fi Wed Jul 17 02:44:35 2013 Return-Path: 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 8676421F9970 for ; Wed, 17 Jul 2013 02:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-2.501, BAYES_00=-2.599, GB_SUMOF=5, 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 V0at+1UK7-j9 for ; Wed, 17 Jul 2013 02:44:29 -0700 (PDT) Received: from smtp-out-02.aalto.fi (smtp-out-02.aalto.fi [130.233.228.121]) by ietfa.amsl.com (Postfix) with ESMTP id BB87B21F9963 for ; Wed, 17 Jul 2013 02:44:28 -0700 (PDT) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id DD42B27191D_1E6677AB; Wed, 17 Jul 2013 09:44:26 +0000 (GMT) Received: from smtp.netlab.hut.fi (sx2.tct.hut.fi [130.233.154.177]) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTP id 8333D2718B9_1E6677AF; Wed, 17 Jul 2013 09:44:26 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 701221E147; Wed, 17 Jul 2013 12:44:26 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id S+wBJp6oSQrK; Wed, 17 Jul 2013 12:44:20 +0300 (EEST) Received: from [192.168.0.10] (cs181253247.pp.htv.fi [82.181.253.247]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id B02731E13F; Wed, 17 Jul 2013 12:44:20 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_7BB6182E-9746-4D7C-B051-EAD15D8A614D" From: Varun Singh In-Reply-To: Date: Wed, 17 Jul 2013 12:44:19 +0300 Message-Id: References: To: Alan Clark X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Wed, 17 Jul 2013 05:23:02 -0700 Cc: jo@comnet.tkk.fi, Al Morton , Shida Schubert , "Dan $Dan$" , igor.curcio@nokia.com, Benoit Claise , pm-dir@ietf.org Subject: Re: [pm-dir] RFC6390 review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 09:44:35 -0000 --Apple-Mail=_7BB6182E-9746-4D7C-B051-EAD15D8A614D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Alan, On Jul 16, 2013, at 6:58 PM, Alan Clark wrote: > Alan Clark=92s Comments on Discard RLE block draft >=20 > The draft is entitled Run Length Encoding of Discarded Packets however = includes a block that is not a run length encoded and which does not = contain a count of discarded packets.=20 > =20 > Section 3 > =20 > This draft has a strong dependency on the definitions of RFC3611 = Section 4.1 and has a weak reference to a discard definition. = draft-ietf-xrblock-xr-discard draft has a definition of Discard and I = recommend that we refer to this. > =20 > =93The XR Discard RLE report block uses exactly the same format, = parameter and chunk definitions as the Loss RLE Report Block defined in = RFC3611 Section 4.1 with the sole change that Chunks represent counts of = discarded packets rather than lost packets. A definition of a discarded = packet is given in draft-ietf-xrblock-xr-discard.=94 > =20 I will make an explicit reference to Discards.=20 > Figure 1 should be titled =93XR Discard RLE Report Block=94 > =20 Okay > Last but one paragraph states that Discard RLE report blocks should = not contain conflicting indications of packets being early and late - = however does not state what a receiver should do if it receives = conflicting blocks. State whether the blocks should be ignored or only = the conflicting packets ignored. How about adding the following line at the appropriate place: "If packets appear in both report blocks, the conflicting packets are = ignored." >=20 > Other than a normative reference to =93discard=94 the definition of = this block does not require an RFC6390 metric template as it refers to a = sufficiently detailed definition in RFC3611. > =20 I'll move the reference of ietf-xrblock-rtcp-xr-discard from Informative = to Normative. Should that suffice? > Section 4 > =20 > The XR Bytes Discarded report block is much closer in intent and form = to the Discard Count block contained in draft-ietf-xrblock-xr-discard, = and is not run length encoded or a count of packets which places it in = conflict with the =93Run Length Encoding of Discarded Packets=94 draft=92s= title.=20 >=20 Proposal for new title: RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length = Encoding (RLE) of Discarded Packets and Bytes Discarded. > In order to comply with RFC6390 this block definition should follow = the metric template and describe: > =20 > (i) How to determine if a packet or a byte is discarded. Presumably = this would be that the packet was received but was too early or late to = be useful. What if a duplicate packet was received - would the discard = of a duplicate packet be regarded as a =93discard=94? > =20 Duplicate packets are ignored, I can make that explicit. > (ii) How to count how many bytes are discarded - is this RTP payload = bytes, UDP/TCP payload bytes or IP packet bytes? Presumably the intent = is RTP payload bytes however this should be explicitly stated and = reference made to the treatment of RTP header extensions and padding. > =20 I don't have a strong opinion here, but my proposal would be to report = the size of the whole RTP packet,=20 including RTP header and payload. However, just reporting the sum of the = RTP payloads is also fine. Any comments > (iii) What edge cases may exist and how to handle these. For example = if a late packet is received at the start of an interval then the = resulting discarded packet and bytes would technically apply to the = previous interval. =46rom a practical perspective it may be simpler = just to say that if a packet is discarded during an interval then it is = counted as a discard for that interval, however this should be = explicitly stated. >=20 I will clarify it should be counted in the interval that it was = discarded in.=20 > In summary - I would recommend the following: > =20 > Either > =20 > (a) Rename the draft to ensure that the title represents both blocks = (as it currently only describes one block) AND include a metrics = definition according to the template given in RFC6390 for both blocks.=20= > =20 See above for title proposal.=20 > Or - Preferred but with one complication > =20 > (b) Move the Bytes Discarded block to the = draft-ietf-xrblock-xr-discard draft. The RLE Discard block draft can = rely on the description in RFC3611, which does not follow the template = but is fairly detailed and can be slightly augmented to refer to the = definition of =93discard=94 in draft-ietf-xrblock-xr-discard. The main = problem with this is that the draft-ietf-xrblock-xr-discard draft is in = the RFC Editor=92s Edit queue - I=92m not sure whether this would be too = much of an Edit? >=20 I would not want to hold up the drafts longer or reset the process.=20 But I am open to whatever is the best course of action. Cheers, Varun > Regards >=20 > Alan Clark >=20 --Apple-Mail=_7BB6182E-9746-4D7C-B051-EAD15D8A614D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Alan,

On Jul 16, 2013, at 6:58 PM, Alan = Clark wrote:

RFC6390 review of = draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06
Alan = Clark=92s Comments on Discard RLE block draft

The draft is entitled Run Length Encoding of Discarded Packets however = includes a block that is not a run length encoded and which does not = contain a count of discarded packets.

Section 3

This draft has a strong dependency on the definitions of RFC3611 Section = 4.1 and has a weak reference to a discard definition. = draft-ietf-xrblock-xr-discard draft has a definition of Discard = and I recommend that we refer to this.

=93The XR Discard RLE report block uses exactly the same format, = parameter and chunk definitions as the Loss RLE Report Block defined in = RFC3611 Section 4.1 with the sole change that Chunks represent counts of = discarded packets rather than lost packets. A definition of a discarded = packet is given in draft-ietf-xrblock-xr-discard.=94

I will = make an explicit reference to Discards.

Figure 1 should be titled =93XR Discard RLE Report Block=94
=

Okay

<= br>

Last but one paragraph states that Discard RLE report blocks should not = contain conflicting indications of packets being early and late - = however does not state what a receiver should do if it receives = conflicting blocks. State whether the blocks should be ignored or only = the conflicting packets = ignored.

How = about adding the following line at the appropriate = place:

"If packets appear in both report blocks, the = conflicting packets are ignored."

Other than a normative reference to =93discard=94 the definition of this = block does not require an RFC6390 metric template as it refers to a = sufficiently detailed definition in RFC3611.
=

I'll = move the reference of ietf-xrblock-rtcp-xr-discard from Informative to = Normative.

Should that suffice?

Section 4

The XR Bytes Discarded report block is much closer in intent and form to = the Discard Count block contained in = draft-ietf-xrblock-xr-discard, and is not run length encoded or a = count of packets which places it in conflict with the =93Run Length = Encoding of Discarded Packets=94 draft=92s title.

Proposal for = new title:

RTP Control Protocol (RTCP) Extended = Reports (XR) for Run Length Encoding (RLE) of Discarded Packets and = Bytes Discarded.

In order to comply with RFC6390 this block definition should follow the = metric template and describe:

(i) How to determine if a packet or a byte is discarded. Presumably this = would be that the packet was received but was too early or late to be = useful. What if a duplicate packet was received - would the = discard of a duplicate packet be regarded as a =93discard=94?

Duplicate = packets are ignored, I can make that explicit.

(ii) How to count how many bytes are discarded - is this RTP payload = bytes, UDP/TCP payload bytes or IP packet bytes? Presumably the = intent is RTP payload bytes however this should be explicitly stated and = reference made to the treatment of RTP header extensions and = padding.

I don't = have a strong opinion here, but my proposal would be to report the size = of the whole RTP packet,

including RTP header and = payload. However, just reporting the sum of the RTP payloads is also = fine.

Any = comments

(iii) What edge cases may exist and how to handle these. For = example if a late packet is received at the start of an interval then = the resulting discarded packet and bytes would technically apply to the = previous interval. =46rom a practical perspective it may be = simpler just to say that if a packet is discarded during an interval = then it is counted as a discard for that interval, however this should = be explicitly stated.

I will clarify = it should be counted in the interval that it was discarded = in.

In summary - I would recommend the following:

Either

(a) Rename the draft to ensure that the title represents both blocks (as = it currently only describes one block) AND include a metrics definition = according to the template given in RFC6390 for both blocks.

See above = for title proposal.

Or - Preferred but with one complication

(b) Move the Bytes Discarded block to the draft-ietf-xrblock-xr-discard = draft. The RLE Discard block draft can rely on the description in = RFC3611, which does not follow the template but is fairly detailed and = can be slightly augmented to refer to the definition of =93discard=94 in = draft-ietf-xrblock-xr-discard. The main problem with this is that the = draft-ietf-xrblock-xr-discard draft is in the RFC Editor=92s Edit queue = - I=92m not sure whether this would be too much of an Edit?
=

I = would not want to hold up the drafts longer or reset the = process.

But I am open to whatever is the best course of = action.

Cheers,

Varun

Regards

Alan Clark

= --Apple-Mail=_7BB6182E-9746-4D7C-B051-EAD15D8A614D-- From varun@comnet.tkk.fi Wed Jul 17 04:44:49 2013 Return-Path: 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 50EB921F9C19 for ; Wed, 17 Jul 2013 04:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.433 X-Spam-Level: * X-Spam-Status: No, score=1.433 tagged_above=-999 required=5 tests=[AWL=-2.365, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, 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 1IYUF9QLBm7C for ; Wed, 17 Jul 2013 04:44:44 -0700 (PDT) Received: from smtp-out-01.aalto.fi (smtp-out-01.aalto.fi [130.233.228.120]) by ietfa.amsl.com (Postfix) with ESMTP id C25CF21F9D4A for ; Wed, 17 Jul 2013 04:44:42 -0700 (PDT) Received: from smtp-out-01.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0DC58115D0A_1E683A9B; Wed, 17 Jul 2013 11:44:41 +0000 (GMT) Received: from smtp.netlab.hut.fi (cinema.netlab.hut.fi [130.233.154.177]) by smtp-out-01.aalto.fi (Sophos Email Appliance) with ESMTP id 63580115CF0_1E683A8F; Wed, 17 Jul 2013 11:44:40 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 4DB501E147; Wed, 17 Jul 2013 14:44:40 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BLR83fKSUvNN; Wed, 17 Jul 2013 14:44:34 +0300 (EEST) Received: from [192.168.0.11] (cs181253247.pp.htv.fi [82.181.253.247]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 0CEF81E13F; Wed, 17 Jul 2013 14:44:34 +0300 (EEST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-6B53697E-679D-4406-9386-B808A7D9FFC3 Content-Transfer-Encoding: 7bit Message-Id: <08475E57-8516-43AC-A2B8-D846D345F379@comnet.tkk.fi> X-Mailer: iPhone Mail (11A4414e) From: Varun Singh Date: Wed, 17 Jul 2013 14:44:30 +0300 To: Alan Clark X-Mailman-Approved-At: Wed, 17 Jul 2013 05:23:02 -0700 Cc: "" , Al Morton , Shida Schubert , "Dan $Dan$" , "" , Benoit Claise , "" Subject: Re: [pm-dir] RFC6390 review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 11:44:49 -0000 --Apple-Mail-6B53697E-679D-4406-9386-B808A7D9FFC3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Alan, Thanks for the input. Comments inline and snipping away text that we agree w= ith.=20 Regards, Varun ---- http://www.netlab.tkk.fi/~varun > On 17.7.2013, at 14.26, Alan Clark wrote: >=20 > Hi Varun >=20 >=20 > On 7/17/13 5:44 AM, "Varun Singh" wrote: >=20 >=20 >=20 > Section 4 > =20 > The XR Bytes Discarded report block is much closer in intent and form to t= he Discard Count block contained in draft-ietf-xrblock-xr-discard, and is n= ot run length encoded or a count of packets which places it in conflict with= the =E2=80=9CRun Length Encoding of Discarded Packets=E2=80=9D draft=E2=80=99= s title.=20 >=20 >=20 > Proposal for new title: > RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length Encoding= (RLE) of Discarded Packets and Bytes Discarded. >=20 > [Alan] This does not work as it reads as if the Bytes Discarded are also R= LE. You would have to change to something like =E2=80=9CRTP Control Protoco= l (RTCP) Extended Reports (XR) for Bytes Discarded and Run Length Encoding (= RLE) of Sequences of Discarded Packets=E2=80=9D to make it clear that the by= te discard counts are not run length encoded. I suggest that you discuss th= is with Dan and Shida. >=20 Agree with reordering the title, if it is the way forward.=20 >=20 > (ii) How to count how many bytes are discarded - is this RTP payload bytes= , UDP/TCP payload bytes or IP packet bytes? Presumably the intent is RTP pa= yload bytes however this should be explicitly stated and reference made to t= he treatment of RTP header extensions and padding. > =20 >=20 > I don't have a strong opinion here, but my proposal would be to report the= size of the whole RTP packet,=20 > including RTP header and payload. However, just reporting the sum of the R= TP payloads is also fine. >=20 > Any comments >=20 > [Alan] My suggestion would be to report the number of payload bytes discar= ded. >=20 I am fine with that too and will add text to explicitly state it.=20 >=20 > In summary - I would recommend the following: > =20 > Either > =20 > (a) Rename the draft to ensure that the title represents both blocks (as i= t currently only describes one block) AND include a metrics definition accor= ding to the template given in RFC6390 for both blocks.=20 > =20 >=20 > See above for title proposal.=20 >=20 >=20 > Or - Preferred but with one complication > =20 > (b) Move the Bytes Discarded block to the draft-ietf-xrblock-xr-discard dr= aft. The RLE Discard block draft can rely on the description in RFC3611, whi= ch does not follow the template but is fairly detailed and can be slightly a= ugmented to refer to the definition of =E2=80=9Cdiscard=E2=80=9D in draft-ie= tf-xrblock-xr-discard. The main problem with this is that the draft-ietf-xrb= lock-xr-discard draft is in the RFC Editor=E2=80=99s Edit queue - I=E2=80=99= m not sure whether this would be too much of an Edit? >=20 > I would not want to hold up the drafts longer or reset the process.=20 > But I am open to whatever is the best course of action. >=20 > [Alan] It is a conundrum - the bytes discarded block would be a much bette= r fit in draft-ietf-xrblock-xr-discard >=20 >=20 I agree it is a better fit, I'll wait for Shida and/or Dan's input before pr= oceeding.=20 >=20 >=20 --Apple-Mail-6B53697E-679D-4406-9386-B808A7D9FFC3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Alan,

Than= ks for the input. Comments inline and snipping away text that we agree with.=

Regards,

Varun

----

http://www.netlab.tkk.fi= /~varun

On 17.7.2013, at 14.26, Alan Clark <alan.d.clark@telchemy.com> wr= ote:

Re: RFC6390 review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-= 06 Hi Varun

On 7/17/13 5:44 AM, "Varun Singh" <varun@= comnet.tkk.fi> wrote:

=

Section 4

The XR Bytes Discarded report block is much closer in intent and form to the= Discard Count block contained in draft-ietf-xrblock-xr-discard, and i= s not run length encoded or a count of packets which places it in conflict w= ith the =E2=80=9CRun Length Encoding of Discarded Packets=E2=80=9D draft=E2=80= =99s title.

Proposal for new title:
RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length Encod= ing (RLE) of Discarded Packets and Bytes Discarded.

[Alan] This does not work as it reads as if the Bytes Discarded are also RLE= . You would have to change to something like =E2=80=9CRTP Control Prot= ocol (RTCP) Extended Reports (XR) for Bytes Discarded and Run Length Encodin= g (RLE) of Sequences of Discarded Packets=E2=80=9D to make it clear that the= byte discard counts are not run length encoded. I suggest that you di= scuss this with Dan and Shida.

Agree w= ith reordering the title, if it is the way forward.

(ii) How to count how many bytes ar= e discarded - is this RTP payload bytes, UDP/TCP payload bytes or IP packet b= ytes? Presumably the intent is RTP payload bytes however this should b= e explicitly stated and reference made to the treatment of RTP header extens= ions and padding.

I don't have a strong opinion here, but my proposal would be to report the s= ize of the whole RTP packet,
including RTP header and payload. However, just reporting the sum of the RTP= payloads is also fine.

Any comments

[Alan] My suggestion would be to report the number of payload bytes discarde= d.

I am f= ine with that too and will add text to explicitly state it.

<= blockquote type=3D"cite">

In summary - I would recommend the f= ollowing:

Either

(a) Rename the draft to ensure that the title represents both blocks (as it c= urrently only describes one block) AND include a metrics definition accordin= g to the template given in RFC6390 for both blocks.

See above for title proposal.

Or - Preferred but with one complication

(b) Move the Bytes Discarded block to the draft-ietf-xrblock-xr-discard draf= t. The RLE Discard block draft can rely on the description in RFC3611, which= does not follow the template but is fairly detailed and can be slightly aug= mented to refer to the definition of =E2=80=9Cdiscard=E2=80=9D in draft-ietf= -xrblock-xr-discard. The main problem with this is that the draft-ietf-xrblo= ck-xr-discard draft is in the RFC Editor=E2=80=99s Edit queue - I=E2=80=99m n= ot sure whether this would be too much of an Edit?

I would not want to hold up the drafts longe= r or reset the process.
But I am open to whatever is the best course of action.

[Alan] It is a conundrum - the bytes discarded block would be a much better f= it in draft-ietf-xrblock-xr-discard

<= div>

I agree it is a better fit, I'll wait for Shida and/or Da= n's input before proceeding.

<= blockquote>

= --Apple-Mail-6B53697E-679D-4406-9386-B808A7D9FFC3-- From bclaise@cisco.com Wed Jul 17 08:41:47 2013 Return-Path: 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 4FEF311E8111 for ; Wed, 17 Jul 2013 08:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.037, 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 FBrWS+Lbqov8 for ; Wed, 17 Jul 2013 08:41:43 -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 D0A0011E80F4 for ; Wed, 17 Jul 2013 08:41:42 -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 r6HFfSnH019785; Wed, 17 Jul 2013 17:41:29 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6HFe6Rk024942; Wed, 17 Jul 2013 17:40:21 +0200 (CEST) Message-ID: <51E6BAD5.4060101@cisco.com> Date: Wed, 17 Jul 2013 17:40:05 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Alan Clark , draft-ietf-xrblock-rtcp-xr-discard-rle-metrics.all@tools.ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020505080007070001030201" Cc: jo@comnet.tkk.fi, Al Morton , "Dan $Dan$" , varun@comnet.tkk.fi, Shida Schubert , igor.curcio@nokia.com, pm-dir@ietf.org Subject: Re: [pm-dir] RFC6390 review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 15:41:47 -0000 This is a multi-part message in MIME format. --------------020505080007070001030201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Thanks Alan for your feedback. Forwarding to draft-ietf-xrblock-rtcp-xr-discard-rle-metrics.all@tools.ietf.org, as mentioned at http://www.ietf.org/iesg/directorate/performance-metrics.html, so that everybody is in the loop. Regards, Benoit > RFC6390 review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 > Alan Clark's Comments on Discard RLE block draft > > The draft is entitled Run Length Encoding of Discarded Packets however > includes a block that is not a run length encoded and which does not > contain a count of discarded packets. > > Section 3 > > This draft has a strong dependency on the definitions of RFC3611 > Section 4.1 and has a weak reference to a discard definition. > draft-ietf-xrblock-xr-discard draft has a definition of Discard and I > recommend that we refer to this. > > "The XR Discard RLE report block uses exactly the same format, > parameter and chunk definitions as the Loss RLE Report Block defined > in RFC3611 Section 4.1 with the sole change that Chunks represent > counts of discarded packets rather than lost packets. A definition of > a discarded packet is given in draft-ietf-xrblock-xr-discard." > > Figure 1 should be titled "XR Discard RLE Report Block" > > Last but one paragraph states that Discard RLE report blocks should > not contain conflicting indications of packets being early and late - > however does not state what a receiver should do if it receives > conflicting blocks. State whether the blocks should be ignored or only > the conflicting packets ignored. > > Other than a normative reference to "discard" the definition of this > block does not require an RFC6390 metric template as it refers to a > sufficiently detailed definition in RFC3611. > > Section 4 > > The XR Bytes Discarded report block is much closer in intent and form > to the Discard Count block contained in > draft-ietf-xrblock-xr-discard, and is not run length encoded or a > count of packets which places it in conflict with the "Run Length > Encoding of Discarded Packets" draft's title. > > In order to comply with RFC6390 this block definition should follow > the metric template and describe: > > (i) How to determine if a packet or a byte is discarded. Presumably > this would be that the packet was received but was too early or late > to be useful. What if a duplicate packet was received - would the > discard of a duplicate packet be regarded as a "discard"? > > (ii) How to count how many bytes are discarded - is this RTP payload > bytes, UDP/TCP payload bytes or IP packet bytes? Presumably the > intent is RTP payload bytes however this should be explicitly stated > and reference made to the treatment of RTP header extensions and padding. > > (iii) What edge cases may exist and how to handle these. For example > if a late packet is received at the start of an interval then the > resulting discarded packet and bytes would technically apply to the > previous interval. From a practical perspective it may be simpler > just to say that if a packet is discarded during an interval then it > is counted as a discard for that interval, however this should be > explicitly stated. > > In summary - I would recommend the following: > > Either > > (a) Rename the draft to ensure that the title represents both blocks > (as it currently only describes one block) AND include a metrics > definition according to the template given in RFC6390 for both blocks. > > Or - Preferred but with one complication > > (b) Move the Bytes Discarded block to the > draft-ietf-xrblock-xr-discard draft. The RLE Discard block draft can > rely on the description in RFC3611, which does not follow the template > but is fairly detailed and can be slightly augmented to refer to the > definition of "discard" in draft-ietf-xrblock-xr-discard. The main > problem with this is that the draft-ietf-xrblock-xr-discard draft is > in the RFC Editor's Edit queue - I'm not sure whether this would be > too much of an Edit? > > Regards > > Alan Clark > --------------020505080007070001030201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Dear all,

Thanks Alan for your feedback.
Forwarding to draft-ietf-xrblock-rtcp-xr-discard-rle-metrics.all@tools.ietf.org, as mentioned at http://www.ietf.org/iesg/directorate/performance-metrics.html, so that everybody is in the loop.

Regards, Benoit

RFC6390 review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 Alan Clark’s Comments on Discard RLE block draft

The draft is entitled Run Length Encoding of Discarded Packets however includes a block that is not a run length encoded and which does not contain a count of discarded packets.

Section 3

This draft has a strong dependency on the definitions of RFC3611 Section 4.1 and has a weak reference to a discard definition. draft-ietf-xrblock-xr-discard draft has a definition of Discard and I recommend that we refer to this.

“The XR Discard RLE report block uses exactly the same format, parameter and chunk definitions as the Loss RLE Report Block defined in RFC3611 Section 4.1 with the sole change that Chunks represent counts of discarded packets rather than lost packets. A definition of a discarded packet is given in draft-ietf-xrblock-xr-discard.”

Figure 1 should be titled “XR Discard RLE Report Block”

Last but one paragraph states that Discard RLE report blocks should not contain conflicting indications of packets being early and late - however does not state what a receiver should do if it receives conflicting blocks. State whether the blocks should be ignored or only the conflicting packets ignored.

Other than a normative reference to “discard” the definition of this block does not require an RFC6390 metric template as it refers to a sufficiently detailed definition in RFC3611.

Section 4

The XR Bytes Discarded report block is much closer in intent and form to the Discard Count block contained in draft-ietf-xrblock-xr-discard, and is not run length encoded or a count of packets which places it in conflict with the “Run Length Encoding of Discarded Packets” draft’s title.

In order to comply with RFC6390 this block definition should follow the metric template and describe:

(i) How to determine if a packet or a byte is discarded. Presumably this would be that the packet was received but was too early or late to be useful. What if a duplicate packet was received - would the discard of a duplicate packet be regarded as a “discard”?

(ii) How to count how many bytes are discarded - is this RTP payload bytes, UDP/TCP payload bytes or IP packet bytes? Presumably the intent is RTP payload bytes however this should be explicitly stated and reference made to the treatment of RTP header extensions and padding.

(iii) What edge cases may exist and how to handle these. For example if a late packet is received at the start of an interval then the resulting discarded packet and bytes would technically apply to the previous interval. From a practical perspective it may be simpler just to say that if a packet is discarded during an interval then it is counted as a discard for that interval, however this should be explicitly stated.

In summary - I would recommend the following:

Either

(a) Rename the draft to ensure that the title represents both blocks (as it currently only describes one block) AND include a metrics definition according to the template given in RFC6390 for both blocks.

Or - Preferred but with one complication

(b) Move the Bytes Discarded block to the draft-ietf-xrblock-xr-discard draft. The RLE Discard block draft can rely on the description in RFC3611, which does not follow the template but is fairly detailed and can be slightly augmented to refer to the definition of “discard” in draft-ietf-xrblock-xr-discard. The main problem with this is that the draft-ietf-xrblock-xr-discard draft is in the RFC Editor’s Edit queue - I’m not sure whether this would be too much of an Edit?

Regards

Alan Clark

--------------020505080007070001030201-- From bclaise@cisco.com Wed Jul 17 08:45:56 2013 Return-Path: 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 487B021F9D7E for ; Wed, 17 Jul 2013 08:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.619 X-Spam-Level: X-Spam-Status: No, score=-7.619 tagged_above=-999 required=5 tests=[AWL=-2.905, BAYES_00=-2.599, GB_SUMOF=5, HTML_FONT_FACE_BAD=0.884, 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 4UHqfNuLSLwu for ; Wed, 17 Jul 2013 08:45:52 -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 BBB7621F9D75 for ; Wed, 17 Jul 2013 08:45:51 -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 r6HFjfMM020284; Wed, 17 Jul 2013 17:45:41 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6HFi6Gm000076; Wed, 17 Jul 2013 17:44:21 +0200 (CEST) Message-ID: <51E6BBC6.3080000@cisco.com> Date: Wed, 17 Jul 2013 17:44:06 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Varun Singh References: <08475E57-8516-43AC-A2B8-D846D345F379@comnet.tkk.fi> In-Reply-To: <08475E57-8516-43AC-A2B8-D846D345F379@comnet.tkk.fi> Content-Type: multipart/alternative; boundary="------------050906080409030704050700" Cc: "" , Al Morton , "Dan $Dan$" , "" , Alan Clark , Shida Schubert , "" , draft-ietf-xrblock-rtcp-xr-discard-rle-metrics.all@tools.ietf.org Subject: Re: [pm-dir] RFC6390 review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 15:45:56 -0000 This is a multi-part message in MIME format. --------------050906080409030704050700 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit including draft-ietf-xrblock-rtcp-xr-discard-rle-metrics.all@tools.ietf.org for the latest email in the email thread. Regards, Benoit > Hi Alan, > > Thanks for the input. Comments inline and snipping away text that we > agree with. > > Regards, > Varun > > ---- > http://www.netlab.tkk.fi/~varun > > On 17.7.2013, at 14.26, Alan Clark > wrote: > >> Re: RFC6390 review of >> draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 Hi Varun >> >> >> On 7/17/13 5:44 AM, "Varun Singh" wrote: >> >> >> >> Section 4 >> >> The XR Bytes Discarded report block is much closer in intent >> and form to the Discard Count block contained in >> draft-ietf-xrblock-xr-discard, and is not run length encoded >> or a count of packets which places it in conflict with the >> “Run Length Encoding of Discarded Packets” draft’s title. >> >> >> Proposal for new title: >> RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length >> Encoding (RLE) of Discarded Packets and Bytes Discarded. >> >> [Alan] This does not work as it reads as if the Bytes Discarded >> are also RLE. You would have to change to something like “RTP >> Control Protocol (RTCP) Extended Reports (XR) for Bytes Discarded >> and Run Length Encoding (RLE) of Sequences of Discarded Packets” >> to make it clear that the byte discard counts are not run length >> encoded. I suggest that you discuss this with Dan and Shida. >> > > Agree with reordering the title, if it is the way forward. > >> >> (ii) How to count how many bytes are discarded - is this RTP >> payload bytes, UDP/TCP payload bytes or IP packet bytes? >> Presumably the intent is RTP payload bytes however this >> should be explicitly stated and reference made to the >> treatment of RTP header extensions and padding. >> >> >> I don't have a strong opinion here, but my proposal would be to >> report the size of the whole RTP packet, >> including RTP header and payload. However, just reporting the sum >> of the RTP payloads is also fine. >> >> Any comments >> >> [Alan] My suggestion would be to report the number of payload >> bytes discarded. >> > > I am fine with that too and will add text to explicitly state it. > >> >> In summary - I would recommend the following: >> >> Either >> >> (a) Rename the draft to ensure that the title represents both >> blocks (as it currently only describes one block) AND include >> a metrics definition according to the template given in >> RFC6390 for both blocks. >> >> >> See above for title proposal. >> >> >> Or - Preferred but with one complication >> >> (b) Move the Bytes Discarded block to the >> draft-ietf-xrblock-xr-discard draft. The RLE Discard block >> draft can rely on the description in RFC3611, which does not >> follow the template but is fairly detailed and can be >> slightly augmented to refer to the definition of “discard” in >> draft-ietf-xrblock-xr-discard. The main problem with this is >> that the draft-ietf-xrblock-xr-discard draft is in the RFC >> Editor’s Edit queue - I’m not sure whether this would be too >> much of an Edit? >> >> I would not want to hold up the drafts longer or reset the process. >> But I am open to whatever is the best course of action. >> >> [Alan] It is a conundrum - the bytes discarded block would be a >> much better fit in draft-ietf-xrblock-xr-discard >> >> > > I agree it is a better fit, I'll wait for Shida and/or Dan's input > before proceeding. > >> >> --------------050906080409030704050700 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

including draft-ietf-xrblock-rtcp-xr-discard-rle-metrics.all@tools.ietf.org for the latest email in the email thread.

Regards, Benoit

Hi Alan,

Thanks for the input. Comments inline and snipping away text that we agree with.

Regards,

Varun

----

http://www.netlab.tkk.fi/~varun

On 17.7.2013, at 14.26, Alan Clark <alan.d.clark@telchemy.com> wrote:

Re: RFC6390 review of draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 Hi Varun

On 7/17/13 5:44 AM, "Varun Singh" <varun@comnet.tkk.fi> wrote:

Section 4

The XR Bytes Discarded report block is much closer in intent and form to the Discard Count block contained in draft-ietf-xrblock-xr-discard, and is not run length encoded or a count of packets which places it in conflict with the “Run Length Encoding of Discarded Packets” draft’s title.

Proposal for new title:
RTP Control Protocol (RTCP) Extended Reports (XR) for Run Length Encoding (RLE) of Discarded Packets and Bytes Discarded.

[Alan] This does not work as it reads as if the Bytes Discarded are also RLE. You would have to change to something like “RTP Control Protocol (RTCP) Extended Reports (XR) for Bytes Discarded and Run Length Encoding (RLE) of Sequences of Discarded Packets” to make it clear that the byte discard counts are not run length encoded. I suggest that you discuss this with Dan and Shida.

Agree with reordering the title, if it is the way forward.

(ii) How to count how many bytes are discarded - is this RTP payload bytes, UDP/TCP payload bytes or IP packet bytes? Presumably the intent is RTP payload bytes however this should be explicitly stated and reference made to the treatment of RTP header extensions and padding.

I don't have a strong opinion here, but my proposal would be to report the size of the whole RTP packet,
including RTP header and payload. However, just reporting the sum of the RTP payloads is also fine.

Any comments

[Alan] My suggestion would be to report the number of payload bytes discarded.

I am fine with that too and will add text to explicitly state it.

In summary - I would recommend the following:

Either

(a) Rename the draft to ensure that the title represents both blocks (as it currently only describes one block) AND include a metrics definition according to the template given in RFC6390 for both blocks.

See above for title proposal.

Or - Preferred but with one complication

(b) Move the Bytes Discarded block to the draft-ietf-xrblock-xr-discard draft. The RLE Discard block draft can rely on the description in RFC3611, which does not follow the template but is fairly detailed and can be slightly augmented to refer to the definition of “discard” in draft-ietf-xrblock-xr-discard. The main problem with this is that the draft-ietf-xrblock-xr-discard draft is in the RFC Editor’s Edit queue - I’m not sure whether this would be too much of an Edit?

I would not want to hold up the drafts longer or reset the process.
But I am open to whatever is the best course of action.

[Alan] It is a conundrum - the bytes discarded block would be a much better fit in draft-ietf-xrblock-xr-discard

I agree it is a better fit, I'll wait for Shida and/or Dan's input before proceeding.

--------------050906080409030704050700-- From acmorton@att.com Fri Jul 19 06:40:59 2013 Return-Path: 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 989C111E8131 for ; Fri, 19 Jul 2013 06:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.229 X-Spam-Level: X-Spam-Status: No, score=-105.229 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_00=-2.599, MANGLED_SAVELE=2.3, 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 slvAo74M2uqI for ; Fri, 19 Jul 2013 06:40:44 -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 4474311E812C for ; Fri, 19 Jul 2013 06:40:44 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 1FF451205AE; Fri, 19 Jul 2013 09:40:42 -0400 (EDT) Received: from njfpsrvexg1.research.att.com (njfpsrvexg1.research.att.com [135.207.177.20]) by mail-green.research.att.com (Postfix) with ESMTP id 60023E018F; Fri, 19 Jul 2013 09:40:30 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg1.research.att.com ([fe80::58ce:ca01:5d18:db01%13]) with mapi; Fri, 19 Jul 2013 09:40:43 -0400 From: "MORTON JR., ALFRED C (AL)" To: Benoit Claise , "pm-dir@ietf.org" Date: Fri, 19 Jul 2013 09:40:43 -0400 Thread-Topic: [pm-dir] Performance metrics doctors generated email Thread-Index: Ac6A1gRoardDE6ByRderzvnOjSmoMADrJq1w Message-ID: References: <20130714210608.GA11670@sweet-brew-5.cisco.com> In-Reply-To: <20130714210608.GA11670@sweet-brew-5.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_F1312FAF1A1E624DA0972D1C9A91379A1CA4D677FBnjfpsrvexg7re_" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 13:40:59 -0000 --_002_F1312FAF1A1E624DA0972D1C9A91379A1CA4D677FBnjfpsrvexg7re_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have updated the tracking spread sheet: https://docs.google.com/spreadsheet/ccc?key=3D0AmKrqWIOBsprdGZqMnB6dmx5bFJv= VUhta3VLSjl3SkE&usp=3Dsharing and the diff on performance-related drafts is attached. You'll note there are now 2 worksheets, one for in-progress reviews where I have added the following drafts (needing review volunteers): draft-ietf-alto-deployments- draft-ietf-cdni-footprint-capabilities-semantics- draft-ietf-nvo3-framework- draft-ietf-ppsp-base-tracker-protocol- draft-ietf-ppsp-peer-protocol- If you don't see your name on the "Completed" sheet, let me suggest that it's time to participate (or retire from the pm-dir to pursue other activities that keep you busy). This way, we can keep the reviews voluntary and avoid random or round-robin review assignments. For those attending IETF-87, we will likely have a short pm-dir organizational meeting. Let me know (off-list) if you will be=20 in Berlin and are willing to attend if we can find an available time. Directorate membership will be discussed. regards, Al pm-dir admin > -----Original Message----- > From: pm-dir-bounces@ietf.org [mailto:pm-dir-bounces@ietf.org] On Behalf > Of Benoit Claise > Sent: Sunday, July 14, 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-ippm-testplan-rfc2680-03 Active > draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 In IESG processing - ID > Tracker state >=20 > Informative References > ---------------------- > draft-ietf-ippm-testplan-rfc2680-03 Active > draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14 In IESG processing - ID > Tracker state > draft-ietf-xrblock-rtcp-xr-decodability-12 In IESG processing - ID > Tracker state > draft-ietf-xrblock-rtcp-xr-discard-15 In IESG processing - ID > Tracker state > draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 In IESG processing - ID > Tracker state > draft-ietf-xrblock-rtcp-xr-jb-14 In IESG processing - ID > Tracker state > draft-ietf-xrblock-rtcp-xr-loss-conceal-08 Active > draft-ietf-xrblock-rtcp-xr-qoe-10 Active > draft-ietf-xrblock-rtcp-xr-summary-stat-11 In IESG processing - ID > Tracker state > draft-ietf-xrblock-rtcp-xr-synchronization-06 Active >=20 > 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-2330-update-00 Active > draft-ietf-ippm-lmap-path-00 Active > draft-ietf-ippm-model-based-metrics-00 Active > draft-ietf-ippm-rate-problem-03 Active > draft-ietf-ippm-testplan-rfc2680-03 Active > draft-ietf-manet-smf-mib-07 In IESG processing - ID > Tracker state > draft-ietf-nvo3-framework-03 Active > draft-ietf-opsawg-oam-overview-09 In IESG processing - ID > Tracker state > draft-ietf-ppsp-base-tracker-protocol-01 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 > draft-ietf-xrblock-rtcp-xr-decodability-12 In IESG processing - ID > Tracker state > draft-ietf-xrblock-rtcp-xr-discard-15 In IESG processing - ID > Tracker state > draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 In IESG processing - ID > Tracker state > draft-ietf-xrblock-rtcp-xr-jb-14 In IESG processing - ID > Tracker state > draft-ietf-xrblock-rtcp-xr-loss-conceal-08 Active > draft-ietf-xrblock-rtcp-xr-qoe-10 Active > draft-ietf-xrblock-rtcp-xr-summary-stat-11 In IESG processing - ID > Tracker state > draft-ietf-xrblock-rtcp-xr-synchronization-06 Active > _______________________________________________ > pm-dir mailing list > pm-dir@ietf.org > https://www.ietf.org/mailman/listinfo/pm-dir --_002_F1312FAF1A1E624DA0972D1C9A91379A1CA4D677FBnjfpsrvexg7re_ Content-Type: text/plain; name="pm-dir_diffs.txt" Content-Description: pm-dir_diffs.txt Content-Disposition: attachment; filename="pm-dir_diffs.txt"; size=2799; creation-date="Fri, 19 Jul 2013 13:10:45 GMT"; modification-date="Fri, 19 Jul 2013 13:38:04 GMT" Content-Transfer-Encoding: base64 W3N5c3RlbUBkZWxsNC00IHBtLWRpcl0kIGNhdCBkaWZmLnR4dA0KRGlmZnMgZnJvbSBMYXN0IFRp bWUgLT1vbGQsICs9bmV3DQotLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tIHBtb2wtb2xkLWNvbnRl bnQudHh0CTIwMTMtMDYtMDMgMTY6NTQ6MTMuMDI5MDY5MTA0IC0wNDAwDQorKysgcG1vbC11bmlx LWNvbnRlbnQudHh0CTIwMTMtMDctMTkgMDg6NTA6MjguMDU0NDc5NDA1IC0wNDAwDQpAQCAtMSwy ICsxIEBADQotZHJhZnQtaWV0Zi1hbHRvLWRlcGxveW1lbnRzLTA2ICAgICAgICAgICAgICAgICAg ICBBY3RpdmUJDQotZHJhZnQtaWV0Zi1hbHRvLXByb3RvY29sLTE2ICAgICAgICAgICAgICAgICAg ICAgICBBY3RpdmUJDQorZHJhZnQtaWV0Zi1hbHRvLWRlcGxveW1lbnRzLTA3ICAgICAgICAgICAg ICAgICAgICBBY3RpdmUJDQpAQCAtMywwICszLDQgQEANCitkcmFmdC1pZXRmLWNkbmktZm9vdHBy aW50LWNhcGFiaWxpdGllcy1zZW1hbnRpY3MtMDBBY3RpdmUJDQorZHJhZnQtaWV0Zi1pcHBtLTIz MzAtdXBkYXRlLTAwICAgICAgICAgICAgICAgICAgICBBY3RpdmUJDQorZHJhZnQtaWV0Zi1pcHBt LWxtYXAtcGF0aC0wMCAgICAgICAgICAgICAgICAgICAgICBBY3RpdmUJDQorZHJhZnQtaWV0Zi1p cHBtLW1vZGVsLWJhc2VkLW1ldHJpY3MtMDAgICAgICAgICAgICBBY3RpdmUJDQpAQCAtNSArOCBA QA0KLWRyYWZ0LWlldGYtaXBwbS10ZXN0cGxhbi1yZmMyNjgwLTAyICAgICAgICAgICAgICAgQWN0 aXZlCQ0KK2RyYWZ0LWlldGYtaXBwbS10ZXN0cGxhbi1yZmMyNjgwLTAzICAgICAgICAgICAgICAg QWN0aXZlCQ0KQEAgLTcsNSArMTAsNSBAQA0KLWRyYWZ0LWlldGYtbnZvMy1mcmFtZXdvcmstMDIg ICAgICAgICAgICAgICAgICAgICAgQWN0aXZlCQ0KLWRyYWZ0LWlldGYtb3BzYXdnLW9hbS1vdmVy dmlldy0wOCAgICAgICAgICAgICAgICAgSW4gSUVTRyBwcm9jZXNzaW5nIC0gSUQNClRyYWNrZXIg c3RhdGUgPFdhaXRpbmcgZm9yIEFEIEdvLUFoZWFkOjpSZXZpc2VkIEktRCBOZWVkZWQ+CQ0KLWRy YWZ0LWlldGYtcGNlLXBjZXAtc2VydmljZS1hd2FyZS0wMCAgICAgICAgICAgICAgQWN0aXZlCQ0K LWRyYWZ0LWlldGYtcHBzcC1wZWVyLXByb3RvY29sLTA2ICAgICAgICAgICAgICAgICAgQWN0aXZl CQ0KLWRyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0wNiAgICAgICAgICAgICAgICAgICAgQWN0 aXZlCQ0KK2RyYWZ0LWlldGYtbnZvMy1mcmFtZXdvcmstMDMgICAgICAgICAgICAgICAgICAgICAg QWN0aXZlCQ0KK2RyYWZ0LWlldGYtb3BzYXdnLW9hbS1vdmVydmlldy0wOSAgICAgICAgICAgICAg ICAgSW4gSUVTRyBwcm9jZXNzaW5nIC0gSUQNClRyYWNrZXIgc3RhdGUgPEFEIEV2YWx1YXRpb24+ CQ0KK2RyYWZ0LWlldGYtcHBzcC1iYXNlLXRyYWNrZXItcHJvdG9jb2wtMDEgICAgICAgICAgQWN0 aXZlCQ0KK2RyYWZ0LWlldGYtcHBzcC1wZWVyLXByb3RvY29sLTA3ICAgICAgICAgICAgICAgICAg QWN0aXZlCQ0KK2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0wNyAgICAgICAgICAgICAgICAg ICAgQWN0aXZlCQ0KQEAgLTEzLDYgKzE2LDYgQEANCi1kcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14 ci1kZWNvZGFiaWxpdHktMTIgICAgICAgIEluIElFU0cgcHJvY2Vzc2luZyAtIElEDQpUcmFja2Vy IHN0YXRlIDxBcHByb3ZlZC1hbm5vdW5jZW1lbnQgdG8gYmUgc2VudDo6UG9pbnQgUmFpc2VkIC0g d3JpdGV1cA0KbmVlZGVkPgkNCi1kcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1kaXNjYXJkLTE0 ICAgICAgICAgICAgIEluIElFU0cgcHJvY2Vzc2luZyAtIElEDQpUcmFja2VyIHN0YXRlIDxXYWl0 aW5nIGZvciBBRCBHby1BaGVhZD4JDQotZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItZGlzY2Fy ZC1ybGUtbWV0cmljcy0wNSBJbiBJRVNHIHByb2Nlc3NpbmcgLSBJRA0KVHJhY2tlciBzdGF0ZSA8 UHVibGljYXRpb24gUmVxdWVzdGVkPgkNCi1kcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1qYi0x MSAgICAgICAgICAgICAgICAgIEluIElFU0cgcHJvY2Vzc2luZyAtIElEDQpUcmFja2VyIHN0YXRl IDxXYWl0aW5nIGZvciBBRCBHby1BaGVhZD4JDQotZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHIt bG9zcy1jb25jZWFsLTA1ICAgICAgICBBY3RpdmUJDQotZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3At eHItcW9lLTA4ICAgICAgICAgICAgICAgICBBY3RpdmUJDQorZHJhZnQtaWV0Zi14cmJsb2NrLXJ0 Y3AteHItZGVjb2RhYmlsaXR5LTEyICAgICAgICBJbiBJRVNHIHByb2Nlc3NpbmcgLSBJRA0KVHJh Y2tlciBzdGF0ZSA8UkZDIEVkIFF1ZXVlPgkNCitkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1k aXNjYXJkLTE1ICAgICAgICAgICAgIEluIElFU0cgcHJvY2Vzc2luZyAtIElEDQpUcmFja2VyIHN0 YXRlIDxSRkMgRWQgUXVldWU+CQ0KK2RyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLWRpc2NhcmQt cmxlLW1ldHJpY3MtMDYgSW4gSUVTRyBwcm9jZXNzaW5nIC0gSUQNClRyYWNrZXIgc3RhdGUgPElF U0cgRXZhbHVhdGlvbjo6UmV2aXNlZCBJLUQgTmVlZGVkPgkNCitkcmFmdC1pZXRmLXhyYmxvY2st cnRjcC14ci1qYi0xNCAgICAgICAgICAgICAgICAgIEluIElFU0cgcHJvY2Vzc2luZyAtIElEDQpU cmFja2VyIHN0YXRlIDxSRkMgRWQgUXVldWU+CQ0KK2RyYWZ0LWlldGYteHJibG9jay1ydGNwLXhy LWxvc3MtY29uY2VhbC0wOCAgICAgICAgQWN0aXZlCQ0KK2RyYWZ0LWlldGYteHJibG9jay1ydGNw LXhyLXFvZS0xMCAgICAgICAgICAgICAgICAgQWN0aXZlCQ0KW3N5c3RlbUBkZWxsNC00IHBtLWRp cl0kIA0K --_002_F1312FAF1A1E624DA0972D1C9A91379A1CA4D677FBnjfpsrvexg7re_-- From vinayakh@gmail.com Fri Jul 19 06:56:04 2013 Return-Path: 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 6354911E81E6 for ; Fri, 19 Jul 2013 06:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 7Azpu8HMEqAP for ; Fri, 19 Jul 2013 06:56:03 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD6811E8139 for ; Fri, 19 Jul 2013 06:56:03 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id wz7so4472922pbc.9 for ; Fri, 19 Jul 2013 06:56:03 -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 :cc:content-type; bh=Z/ru8wWx43rxeHHH8FsFnlVI8ybA+dXdOzOrwloeXno=; b=ZXwq7JMPhTBqhTUUXxPDamQvHLG7mqb5/S/Y3IkJz0Jyi1s3nwKznpw+rOPE3hgIvZ sjMWFiVihbWCFJeWyE79pb/ayAt9AwpRigIpd819HspPWvd4qg6L4qBs5TaB3v+HCs6P fgHeRFAogjH+5uM3v2NVnUm1vopolNfez/WCpbhdgLuICbmWtLIiNwNs1Q5A9ZKfnsjv 7V2nGnmYI4rrqLiayyRo/fh5oE4VZYaDcR6dohwl72qgyubRv5Di3eAELasErl1BYU53 eKBIeEsOlgr0OePWzkGf/6w0ZLxlwmYY7sByWsGev74LX3fcVpMF09+bUdp032CloWrl KHBQ== MIME-Version: 1.0 X-Received: by 10.68.234.33 with SMTP id ub1mr17208778pbc.98.1374242163153; Fri, 19 Jul 2013 06:56:03 -0700 (PDT) Received: by 10.66.85.167 with HTTP; Fri, 19 Jul 2013 06:56:03 -0700 (PDT) In-Reply-To: References: <20130714210608.GA11670@sweet-brew-5.cisco.com> Date: Fri, 19 Jul 2013 19:26:03 +0530 Message-ID: From: Vinayak Hegde To: "MORTON JR., ALFRED C (AL)" Content-Type: multipart/alternative; boundary=047d7b33d876f861bb04e1ddafbc Cc: Benoit Claise , "pm-dir@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 13:56:04 -0000 --047d7b33d876f861bb04e1ddafbc Content-Type: text/plain; charset=ISO-8859-1 Hi Al, I will pick up two drafts as I have been following CDNI and ALTO groups. draft-ietf-alto-deployments- draft-ietf-cdni-footprint-capabilities-semantics- I will send in the reviews before the Berlin meeting. I am not able to update the tracking spreading spreadsheet. -- Vinayak On Fri, Jul 19, 2013 at 7:10 PM, MORTON JR., ALFRED C (AL) wrote: > I have updated the tracking spread sheet: > > https://docs.google.com/spreadsheet/ccc?key=0AmKrqWIOBsprdGZqMnB6dmx5bFJvVUhta3VLSjl3SkE&usp=sharing > and the diff on performance-related drafts is attached. > > You'll note there are now 2 worksheets, one for in-progress reviews > where I have added the following drafts (needing review volunteers): > > draft-ietf-alto-deployments- > draft-ietf-cdni-footprint-capabilities-semantics- > draft-ietf-nvo3-framework- > draft-ietf-ppsp-base-tracker-protocol- > draft-ietf-ppsp-peer-protocol- > > If you don't see your name on the "Completed" sheet, > let me suggest that it's time to participate (or retire > from the pm-dir to pursue other activities that keep you busy). > This way, we can keep the reviews voluntary and avoid > random or round-robin review assignments. > > For those attending IETF-87, we will likely have a short pm-dir > organizational meeting. Let me know (off-list) if you will be > in Berlin and are willing to attend if we can find an available time. > Directorate membership will be discussed. > > regards, > Al > pm-dir admin > > > > -----Original Message----- > > From: pm-dir-bounces@ietf.org [mailto:pm-dir-bounces@ietf.org] On Behalf > > Of Benoit Claise > > Sent: Sunday, July 14, 2013 5:06 PM > > To: pm-dir@ietf.org > > Subject: [pm-dir] Performance metrics doctors generated email > > > > 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-ippm-testplan-rfc2680-03 Active > > draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 In IESG processing - ID > > Tracker state > > > > Informative References > > ---------------------- > > draft-ietf-ippm-testplan-rfc2680-03 Active > > draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14 In IESG processing - ID > > Tracker state > > draft-ietf-xrblock-rtcp-xr-decodability-12 In IESG processing - ID > > Tracker state > > draft-ietf-xrblock-rtcp-xr-discard-15 In IESG processing - ID > > Tracker state > > draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 In IESG processing - ID > > Tracker state > > draft-ietf-xrblock-rtcp-xr-jb-14 In IESG processing - ID > > Tracker state > > draft-ietf-xrblock-rtcp-xr-loss-conceal-08 Active > > draft-ietf-xrblock-rtcp-xr-qoe-10 Active > > draft-ietf-xrblock-rtcp-xr-summary-stat-11 In IESG processing - ID > > Tracker state > > draft-ietf-xrblock-rtcp-xr-synchronization-06 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-2330-update-00 Active > > draft-ietf-ippm-lmap-path-00 Active > > draft-ietf-ippm-model-based-metrics-00 Active > > draft-ietf-ippm-rate-problem-03 Active > > draft-ietf-ippm-testplan-rfc2680-03 Active > > draft-ietf-manet-smf-mib-07 In IESG processing - ID > > Tracker state > > draft-ietf-nvo3-framework-03 Active > > draft-ietf-opsawg-oam-overview-09 In IESG processing - ID > > Tracker state > > draft-ietf-ppsp-base-tracker-protocol-01 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 > > draft-ietf-xrblock-rtcp-xr-decodability-12 In IESG processing - ID > > Tracker state > > draft-ietf-xrblock-rtcp-xr-discard-15 In IESG processing - ID > > Tracker state > > draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 In IESG processing - ID > > Tracker state > > draft-ietf-xrblock-rtcp-xr-jb-14 In IESG processing - ID > > Tracker state > > draft-ietf-xrblock-rtcp-xr-loss-conceal-08 Active > > draft-ietf-xrblock-rtcp-xr-qoe-10 Active > > draft-ietf-xrblock-rtcp-xr-summary-stat-11 In IESG processing - ID > > Tracker state > > draft-ietf-xrblock-rtcp-xr-synchronization-06 Active > > _______________________________________________ > > pm-dir mailing list > > pm-dir@ietf.org > > https://www.ietf.org/mailman/listinfo/pm-dir > > _______________________________________________ > pm-dir mailing list > pm-dir@ietf.org > https://www.ietf.org/mailman/listinfo/pm-dir > > --047d7b33d876f861bb04e1ddafbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Al,

I will pick up two drafts as I have been following CDNI and A= LTO groups.

draft-ietf-alto-deployments-
draft-ietf-cdni-footprint-capabilities-semantics-

I will send in the= reviews before the Berlin meeting.

I am not able to update the trac= king spreading spreadsheet.

-- Vinayak

On Fri, Jul 19, 2013 at 7:10 PM, MORTON JR., ALFRED C (AL) <acmorton@att.co= m> wrote:

I have updated the tracking spread sheet:
https://doc= s.google.com/spreadsheet/ccc?key=3D0AmKrqWIOBsprdGZqMnB6dmx5bFJvVUhta3VLSjl= 3SkE&usp=3Dsharing
and the diff on performance-related drafts is attached.

You'll note there are now 2 worksheets, one for in-progress reviews
where I have added the following drafts (needing review volunteers):

draft-ietf-alto-deployments-
draft-ietf-cdni-footprint-capabilities-semantics-
draft-ietf-nvo3-framework-
draft-ietf-ppsp-base-tracker-protocol-
draft-ietf-ppsp-peer-protocol-

If you don't see your name on the "Completed" sheet,
let me suggest that it's time to participate (or retire
from the pm-dir to pursue other activities that keep you busy).
This way, we can keep the reviews voluntary and avoid
random or round-robin review assignments.

For those attending IETF-87, we will likely have a short pm-dir
organizational meeting. Let me know (off-list) if you will be
in Berlin and are willing to attend if we can find an available time.
Directorate membership will be discussed.

regards,
Al
pm-dir admin

> -----Original Message-----
> From: pm-dir-bounces@ietf.o= rg [mailto:pm-dir-bounces@ie= tf.org] On Behalf
> Of Benoit Claise
> Sent: Sunday, July 14, 2013 5:06 PM
> To: pm-dir@ietf.org
> Subject: [pm-dir] Performance metrics doctors generated email
>
> 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 "performa= nce
> metric".
>
> Regards, Benoit
>
> =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
>
> Normative References
> --------------------
> draft-ietf-ippm-testplan-rfc2680-03 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Active=
> draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 In IESG processing -= ID
> Tracker state <IESG Evaluation>
>
> Informative References
> ----------------------
> draft-ietf-ippm-testplan-rfc2680-03 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Active=
> draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14 =A0 In IESG processing= - ID
> Tracker state <RFC Ed Queue>
> draft-ietf-xrblock-rtcp-xr-decodability-12 =A0 =A0 =A0 =A0In IESG proc= essing - ID
> Tracker state <RFC Ed Queue>
> draft-ietf-xrblock-rtcp-xr-discard-15 =A0 =A0 =A0 =A0 =A0 =A0 In IESG = processing - ID
> Tracker state <RFC Ed Queue>
> draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 In IESG processing -= ID
> Tracker state <IESG Evaluation>
> draft-ietf-xrblock-rtcp-xr-jb-14 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In= IESG processing - ID
> Tracker state <RFC Ed Queue>
> draft-ietf-xrblock-rtcp-xr-loss-conceal-08 =A0 =A0 =A0 =A0Active
> draft-ietf-xrblock-rtcp-xr-qoe-10 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Acti= ve
> draft-ietf-xrblock-rtcp-xr-summary-stat-11 =A0 =A0 =A0 =A0In IESG proc= essing - ID
> Tracker state <RFC Ed Queue>
> draft-ietf-xrblock-rtcp-xr-synchronization-06 =A0 =A0 Active
>
> drafts containing performance metric
> ------------------------------------
> draft-ietf-alto-deployments-06 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Active
> draft-ietf-alto-protocol-16 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 Active
> draft-ietf-bmwg-ca-bench-meth-04 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ac= tive
> draft-ietf-ippm-2330-update-00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Active
> draft-ietf-ippm-lmap-path-00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Active
> draft-ietf-ippm-model-based-metrics-00 =A0 =A0 =A0 =A0 =A0 =A0Active > draft-ietf-ippm-rate-problem-03 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ac= tive
> draft-ietf-ippm-testplan-rfc2680-03 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Active=
> draft-ietf-manet-smf-mib-07 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 In IESG processing - ID
> Tracker state <AD Evaluation::Revised I-D Needed>
> draft-ietf-nvo3-framework-03 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Active
> draft-ietf-opsawg-oam-overview-09 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 In I= ESG processing - ID
> Tracker state <AD Evaluation>
> draft-ietf-ppsp-base-tracker-protocol-01 =A0 =A0 =A0 =A0 =A0Active
> draft-ietf-ppsp-peer-protocol-06 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ac= tive
> draft-ietf-rtcweb-rtp-usage-06 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Active
> draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14 =A0 In IESG processing= - ID
> Tracker state <RFC Ed Queue>
> draft-ietf-xrblock-rtcp-xr-decodability-12 =A0 =A0 =A0 =A0In IESG proc= essing - ID
> Tracker state <RFC Ed Queue>
> draft-ietf-xrblock-rtcp-xr-discard-15 =A0 =A0 =A0 =A0 =A0 =A0 In IESG = processing - ID
> Tracker state <RFC Ed Queue>
> draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 In IESG processing -= ID
> Tracker state <IESG Evaluation>
> draft-ietf-xrblock-rtcp-xr-jb-14 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In= IESG processing - ID
> Tracker state <RFC Ed Queue>
> draft-ietf-xrblock-rtcp-xr-loss-conceal-08 =A0 =A0 =A0 =A0Active
> draft-ietf-xrblock-rtcp-xr-qoe-10 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Acti= ve
> draft-ietf-xrblock-rtcp-xr-summary-stat-11 =A0 =A0 =A0 =A0In IESG proc= essing - ID
> Tracker state <RFC Ed Queue>
> draft-ietf-xrblock-rtcp-xr-synchronization-06 =A0 =A0 Active
> _______________________________________________
> pm-dir mailing list
> pm-dir@ietf.org
> https://www.ietf.org/mailman/listinfo/pm-dir

_______________________________________________
pm-dir mailing list
pm-dir@ietf.org
= https://www.ietf.org/mailman/listinfo/pm-dir

--047d7b33d876f861bb04e1ddafbc-- From bclaise@cisco.com Sun Jul 21 14:06:38 2013 Return-Path: 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 BF5D921F9FDE for ; Sun, 21 Jul 2013 14:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 J6Cz3l7Z3xUa for ; Sun, 21 Jul 2013 14:06:33 -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 9BFB621F9FCC for ; Sun, 21 Jul 2013 14:06: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 r6LL6UP9026356 for ; Sun, 21 Jul 2013 23:06:30 +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 r6LL6D89006098 for ; Sun, 21 Jul 2013 23:06:23 +0200 (CEST) Received: (from bclaise@localhost) by sweet-brew-5.cisco.com (8.13.8+Sun/8.13.6/Submit) id r6LL6ASb018396 for pm-dir@ietf.org; Sun, 21 Jul 2013 23:06:10 +0200 (CEST) Date: Sun, 21 Jul 2013 23:06:10 +0200 From: Benoit Claise To: pm-dir@ietf.org Message-ID: <20130721210610.GA18394@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 21:06:39 -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-ippm-testplan-rfc2680-03 Active draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 In IESG processing - ID Tracker state Informative References ---------------------- draft-ietf-ippm-testplan-rfc2680-03 Active draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-decodability-12 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-discard-15 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-jb-14 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-loss-conceal-08 Active draft-ietf-xrblock-rtcp-xr-qoe-10 Active draft-ietf-xrblock-rtcp-xr-summary-stat-11 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-synchronization-06 Active drafts containing performance metric ------------------------------------ draft-ietf-alto-deployments-07 Active draft-ietf-bmwg-ca-bench-meth-04 Active draft-ietf-cdni-footprint-capabilities-semantics-00Active draft-ietf-ippm-2330-update-00 Active draft-ietf-ippm-lmap-path-00 Active draft-ietf-ippm-model-based-metrics-00 Active draft-ietf-ippm-rate-problem-03 Active draft-ietf-ippm-testplan-rfc2680-03 Active draft-ietf-manet-smf-mib-07 In IESG processing - ID Tracker state draft-ietf-nvo3-framework-03 Active draft-ietf-opsawg-oam-overview-09 In IESG processing - ID Tracker state draft-ietf-ppsp-base-tracker-protocol-01 Active draft-ietf-ppsp-peer-protocol-07 Active draft-ietf-rtcweb-rtp-usage-07 Active draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-decodability-12 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-discard-15 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-jb-14 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-loss-conceal-08 Active draft-ietf-xrblock-rtcp-xr-qoe-10 Active draft-ietf-xrblock-rtcp-xr-summary-stat-11 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-synchronization-06 Active From bclaise@cisco.com Sat Jul 27 03:14:14 2013 Return-Path: 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 1619721F9DA8 for ; Sat, 27 Jul 2013 03:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.55 X-Spam-Level: X-Spam-Status: No, score=-10.55 tagged_above=-999 required=5 tests=[AWL=0.048, 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 co4V7MpR+-yO for ; Sat, 27 Jul 2013 03:14:09 -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 D43AB21F9BF3 for ; Sat, 27 Jul 2013 03:14:06 -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 r6RAE1xL013105; Sat, 27 Jul 2013 12:14:02 +0200 (CEST) Received: from [10.61.214.14] ([10.61.214.14]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6RADReh023134; Sat, 27 Jul 2013 12:13:37 +0200 (CEST) Message-ID: <51F39D2C.7050501@cisco.com> Date: Sat, 27 Jul 2013 12:13:00 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Al Morton Content-Type: multipart/alternative; boundary="------------040900010307010904090906" Cc: "pm-dir@ietf.org" Subject: [pm-dir] Review of http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680-03 -> W RFC 6390 Template X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 10:14:14 -0000 This is a multi-part message in MIME format. --------------040900010307010904090906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Al, I reviewed http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680-03 A discussion among the pm-dir first, before mentioning this on the IPPM mailing list I don't believe that the following statement is correct We recognize the existence ofBCP 170 [RFC6390 ] providing guidelines for development of drafts describing new performance metrics. However, the advancement of [RFC2680 ] represents fine-tuning of long- standing specifications based on experience that helped to formulate BCP 170 , and material that satisfies some of the requirements of [RFC6390 ] can be found in other RFCs, such as the IPPM Framework [RFC2330 ]. Thus, no specific changes to addressBCP 170 guidelines are recommended for RFC 2680bis. The IPPM charter mentions: Metric definitions will follow the template given in RFC 6390. The RFC 6390 template should be applied. This is required to have a RFC 6390-based template registry, as I will show during the IPPM WG. Regards, Benoit --------------040900010307010904090906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Al,

I reviewed http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680-03
A discussion among the pm-dir first, before mentioning this on the IPPM mailing list
I don't believe that the following statement is correct

   We recognize the existence of BCP 170 [RFC6390] providing guidelines
   for development of drafts describing new performance metrics.
   However, the advancement of [RFC2680] represents fine-tuning of long-
   standing specifications based on experience that helped to formulate
   BCP 170, and material that satisfies some of the requirements of
   [RFC6390] can be found in other RFCs, such as the IPPM Framework
   [RFC2330].  Thus, no specific changes to address BCP 170 guidelines
   are recommended for RFC 2680bis.

The IPPM charter mentions: Metric definitions will follow the template given in RFC
6390.
The RFC 6390 template should be applied. This is required to have a RFC 6390-based template registry, as I will show during the IPPM WG.

Regards, Benoit
--------------040900010307010904090906-- From alan.d.clark@telchemy.com Sat Jul 27 04:25:29 2013 Return-Path: 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 24B7721F9CC7 for ; Sat, 27 Jul 2013 04:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 iDSxEbbl93P7 for ; Sat, 27 Jul 2013 04:25:25 -0700 (PDT) Received: from omx.cbeyond.com (omx.cbeyond.com [50.20.30.10]) by ietfa.amsl.com (Postfix) with ESMTP id E88B221F9C2D for ; Sat, 27 Jul 2013 04:25:24 -0700 (PDT) X-SBRS: -4.0 X-HAT: Sender Group POORREP_BLACKLIST, Policy $SBRSPOOR applied. X-Hostname: omx09bay.sys.cbeyond.net X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMRAKCt81Fi+2EaPGdsb2JhbAANToJCeYZArzKGXYFdIIEMAwEBAQE4glkBAQEDAQEBASQWMQsFDQEIDi0yHBQBAQQBDQWIChKmF5Ifj3kEB4QFA4hyixaFAJFZJYFV X-IronPort-AV: E=Sophos;i="4.89,757,1367985600"; d="scan'208,217";a="56120543" Received: from c-98-251-97-26.hsd1.ga.comcast.net (HELO [192.168.1.7]) ([98.251.97.26]) by omx.cbeyond.com with ESMTP/TLS/DES-CBC3-SHA; 27 Jul 2013 07:25:23 -0400 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Sat, 27 Jul 2013 07:25:18 -0400 From: Alan Clark To: Benoit Claise , Al Morton Message-ID: Thread-Topic: [pm-dir] Review of http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680-03 -> W RFC 6390 Template Thread-Index: Ac6Ku/jruVvO/gb0QUa3exPiOiRETA== In-Reply-To: <51F39D2C.7050501@cisco.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3457754723_2331973" Cc: "pm-dir@ietf.org" Subject: Re: [pm-dir] Review of http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680-03 -> W RFC 6390 Template X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 11:25:29 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3457754723_2331973 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Benoit The motivation behind RFC6390 was to ensure that metrics were properly defined, and this goal is not in conflict with the desire of authors or WG=B9= s to rapidly develop or evolve drafts or associated metrics. IMHO the order of importance of application of RFC6390 (highest to lowest) is=20 (i) Properly define metric and make sure the definition includes everything required by RFC6390 (ii) Define the metric using the template (iii) Put the definition into a registry Regards Alan Clark On 7/27/13 6:13 AM, "Benoit Claise" wrote: > Dear Al, > =20 > I reviewed http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680-0= 3 > A discussion among the pm-dir first, before mentioning this on the IPPM > mailing list > I don't believe that the following statement is correct > =20 > We recognize the existence of BCP 170 > [RFC6390 ] providing guidelines > for development of drafts describing new performance metrics. > However, the advancement of [RFC2680 ] > represents fine-tuning of long- > standing specifications based on experience that helped to formulate > BCP 170 , and material that satisf= ies > some of the requirements of > [RFC6390 ] can be found in other = RFCs, > such as the IPPM Framework > [RFC2330 ]. Thus, no specific ch= anges > to address BCP 170 guidelines > are recommended for RFC 2680bis. > The IPPM charter mentions: Metric definitions will follow the template g= iven > in RFC > 6390. > The RFC 6390 template should be applied. This is required to have a RFC > 6390-based template registry, as I will show during the IPPM WG. > =20 > Regards, Benoit > =20 >=20 > _______________________________________________ > pm-dir mailing list > pm-dir@ietf.org > https://www.ietf.org/mailman/listinfo/pm-dir --B_3457754723_2331973 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [pm-dir] Review of http://tools.ietf.org/html/draft-ietf-ippm-te= stplan-rfc2680-03 -> W RFC 6390 Template Benoit

The motivation behind RFC6390 was to ensure that metrics were properly defi= ned, and this goal is not in conflict with the desire of authors or WG’= ;s to rapidly develop or evolve drafts or associated metrics.

IMHO the order of importance of application of RFC6390 (highest to lowest) = is

(i) Properly define metric and make sure the definition includes everything= required by RFC6390

(ii) Define the metric using the template

(iii) Put the definition into a registry

Regards

Alan Clark

On 7/27/13 6:13 AM, "Benoit Claise" <bclaise@cisco.com> wrote:

<= SPAN STYLE=3D'font-size:12pt'> Dear Al,

I reviewed http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680-0= 3
A discussion among the pm-dir first, before mentioning this on the IP= PM mailing list
I don't believe that the following statement is correct

 We recognize the existence of BCP 170 <http://tools.ietf.org/html/bcp170> = ;[RFC6390 <http://tools.ietf= .org/html/rfc6390> ] providing guidelines
 for development of drafts describing new performance metr= ics.
 However, the advancement of [RFC2680 <http://tools.ietf.org/html/rfc2680> ] re= presents fine-tuning of long-
 standing specifications based on experience that helped t= o formulate
 BCP 170 <h= ttp://tools.ietf.org/html/bcp170> , and material that satisfies some = of the requirements of
 [RFC6390 <http://tools.ietf.org/html/rfc6390> ] can be found in other RFCs, su= ch as the IPPM Framework
 [RFC2330 <http://tools.ietf.org/html/rfc2330> ]. Thus, no specific chang= es to address BCP 170 <http:/= /tools.ietf.org/html/bcp170> guidelines
 are recommended for RFC 2680bis.
The IPPM charter mentions: Metric definitions will follow the templat= e given in RFC
6390.
The RFC 6390 template should be applied. This is required to have a R= FC 6390-based template registry, as I will show during the IPPM WG.

Regards, Benoit

_____________________________________= __________
pm-dir mailing list
pm-dir@ietf.org
https://www.ietf.org= /mailman/listinfo/pm-dir

--B_3457754723_2331973-- From acmorton@att.com Sat Jul 27 06:48:25 2013 Return-Path: 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 AA99021F991E for ; Sat, 27 Jul 2013 06:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.319 X-Spam-Level: X-Spam-Status: No, score=-106.319 tagged_above=-999 required=5 tests=[AWL=0.280, 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 Xfw0dLdr4rQF for ; Sat, 27 Jul 2013 06:48:20 -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 E067D21F9974 for ; Sat, 27 Jul 2013 06:48:19 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id AAF57120622; Sat, 27 Jul 2013 09:48:16 -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 7EEA0E01B3; Sat, 27 Jul 2013 09:47:51 -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; Sat, 27 Jul 2013 09:48:18 -0400 From: "MORTON JR., ALFRED C (AL)" To: Alan Clark , Benoit Claise Date: Sat, 27 Jul 2013 09:48:17 -0400 Thread-Topic: [pm-dir] Review of http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680-03 -> W RFC 6390 Template Thread-Index: Ac6Ku/jruVvO/gb0QUa3exPiOiRETAAEmi3h Message-ID: References: <51F39D2C.7050501@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pm-dir@ietf.org" Subject: Re: [pm-dir] Review of http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680-03 -> W RFC 6390 Template X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 13:48:25 -0000 Hi Benoit, Thanks for initiating this discussion. I tend to agree with Alan's hierarchy, but observe that the template is a v= ery small part of the large body of useful guidance contained in RFC 6390.=20 Putting the registry aside (because the 6390 guidance is about the metric s= pecifications themselves) what is the benefit of one template over another when the needed informatio= n is conveyed=20 effectively? =20 regards, Al ________________________________________ From: Alan Clark [alan.d.clark@telchemy.com] Sent: Saturday, July 27, 2013 7:25 AM To: Benoit Claise; MORTON JR., ALFRED C (AL) Cc: pm-dir@ietf.org Subject: Re: [pm-dir] Review of http://tools.ietf.org/html/draft-ietf-ippm-= testplan-rfc2680-03 -> W RFC 6390 Template Benoit The motivation behind RFC6390 was to ensure that metrics were properly defi= ned, and this goal is not in conflict with the desire of authors or WG=92s = to rapidly develop or evolve drafts or associated metrics. IMHO the order of importance of application of RFC6390 (highest to lowest) = is (i) Properly define metric and make sure the definition includes everything= required by RFC6390 (ii) Define the metric using the template (iii) Put the definition into a registry Regards Alan Clark On 7/27/13 6:13 AM, "Benoit Claise" wrote: Dear Al, I reviewed http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680-03 A discussion among the pm-dir first, before mentioning this on the IPPM ma= iling list I don't believe that the following statement is correct We recognize the existence of BCP 170 [RFC6390 ] providing guidelines for development of drafts describing new performance metrics. However, the advancement of [RFC2680 ] represents fine-tuning of long- standing specifications based on experience that helped to formulate BCP 170 , and material that satisfie= s some of the requirements of [RFC6390 ] can be found in other RF= Cs, such as the IPPM Framework [RFC2330 ]. Thus, no specific chan= ges to address BCP 170 guidelines are recommended for RFC 2680bis. The IPPM charter mentions: Metric definitions will follow the template giv= en in RFC 6390. The RFC 6390 template should be applied. This is required to have a RFC 63= 90-based template registry, as I will show during the IPPM WG. Regards, Benoit ________________________________ _______________________________________________ pm-dir mailing list pm-dir@ietf.org https://www.ietf.org/mailman/listinfo/pm-dir From bclaise@cisco.com Sat Jul 27 09:44:02 2013 Return-Path: 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 46F8E21F9BB4 for ; Sat, 27 Jul 2013 09:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.514 X-Spam-Level: X-Spam-Status: No, score=-10.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 Bq7WH+A-U68o for ; Sat, 27 Jul 2013 09:43: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 CFABC21F9BAB for ; Sat, 27 Jul 2013 09:43: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 r6RGhsYV017417; Sat, 27 Jul 2013 18:43:54 +0200 (CEST) Received: from [10.61.214.14] ([10.61.214.14]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6RGh93P025848; Sat, 27 Jul 2013 18:43:19 +0200 (CEST) Message-ID: <51F3F881.4090901@cisco.com> Date: Sat, 27 Jul 2013 18:42:41 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "MORTON JR., ALFRED C (AL)" References: <51F39D2C.7050501@cisco.com>, In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "pm-dir@ietf.org" , Alan Clark Subject: Re: [pm-dir] Review of http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680-03 -> W RFC 6390 Template X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 16:44:02 -0000 On 27/07/2013 15:48, MORTON JR., ALFRED C (AL) wrote: > Hi Benoit, > > Thanks for initiating this discussion. > > I tend to agree with Alan's hierarchy, but observe that the template is a very small > part of the large body of useful guidance contained in RFC 6390. > > Putting the registry aside (because the 6390 guidance is about the metric specifications themselves) > what is the benefit of one template over another when the needed information is conveyed > effectively? I believe that the template definition is required for correctly populating the registry. I will present on this in the IPPM WG. Regards, Benoit > > regards, > Al > ________________________________________ > From: Alan Clark [alan.d.clark@telchemy.com] > Sent: Saturday, July 27, 2013 7:25 AM > To: Benoit Claise; MORTON JR., ALFRED C (AL) > Cc: pm-dir@ietf.org > Subject: Re: [pm-dir] Review of http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680-03 -> W RFC 6390 Template > > Benoit > > The motivation behind RFC6390 was to ensure that metrics were properly defined, and this goal is not in conflict with the desire of authors or WG�s to rapidly develop or evolve drafts or associated metrics. > > IMHO the order of importance of application of RFC6390 (highest to lowest) is > > (i) Properly define metric and make sure the definition includes everything required by RFC6390 > > (ii) Define the metric using the template > > (iii) Put the definition into a registry > > Regards > > Alan Clark > > > On 7/27/13 6:13 AM, "Benoit Claise" wrote: > > Dear Al, > > I reviewed http://tools.ietf.org/html/draft-ietf-ippm-testplan-rfc2680-03 > A discussion among the pm-dir first, before mentioning this on the IPPM mailing list > I don't believe that the following statement is correct > > We recognize the existence of BCP 170 [RFC6390 ] providing guidelines > for development of drafts describing new performance metrics. > However, the advancement of [RFC2680 ] represents fine-tuning of long- > standing specifications based on experience that helped to formulate > BCP 170 , and material that satisfies some of the requirements of > [RFC6390 ] can be found in other RFCs, such as the IPPM Framework > [RFC2330 ]. Thus, no specific changes to address BCP 170 guidelines > are recommended for RFC 2680bis. > The IPPM charter mentions: Metric definitions will follow the template given in RFC > 6390. > The RFC 6390 template should be applied. This is required to have a RFC 6390-based template registry, as I will show during the IPPM WG. > > Regards, Benoit > > ________________________________ > _______________________________________________ > pm-dir mailing list > pm-dir@ietf.org > https://www.ietf.org/mailman/listinfo/pm-dir > > From alan.d.clark@telchemy.com Sun Jul 28 07:01:42 2013 Return-Path: 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 C9AF721F9C33 for ; Sun, 28 Jul 2013 07:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599] 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 FTCZCgMwxan2 for ; Sun, 28 Jul 2013 07:01:38 -0700 (PDT) Received: from omx.cbeyond.com (omx.cbeyond.com [50.20.30.10]) by ietfa.amsl.com (Postfix) with ESMTP id 610D921F9CF5 for ; Sun, 28 Jul 2013 07:01:29 -0700 (PDT) X-SBRS: -4.0 X-HAT: Sender Group POORREP_BLACKLIST, Policy $SBRSPOOR applied. X-Hostname: omx05bay.sys.cbeyond.net X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMbAL0i9VEYf+AcPGdsb2JhbAANToM7tyGHAYEtAwEBAQE4glkBAQEDAQEBATcCATEQBwYBCA4DBAEBKC4cAwkIAQEEARKIAggSpXqNQIQTBI4+gQwIMgaDfwOoI4Q4gVU X-IronPort-AV: E=Sophos;i="4.89,763,1367985600"; d="scan'208";a="56946197" Received: from c-24-127-224-28.hsd1.fl.comcast.net (HELO [192.168.1.3]) ([24.127.224.28]) by omx.cbeyond.com with ESMTP/TLS/DES-CBC3-SHA; 28 Jul 2013 10:01:25 -0400 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Sun, 28 Jul 2013 10:01:21 -0400 From: Alan Clark To: Al Morton , Benoit Claise , "pm-dir@ietf.org" Message-ID: Thread-Topic: [pm-dir] Performance metrics doctors generated email Thread-Index: Ac6A1gRoardDE6ByRderzvnOjSmoMADrJq1wAcYUQPg= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 14:01:42 -0000 Al I volunteer to review the two ppsp drafts Regards Alan On 7/19/13 9:40 AM, "Al Morton" wrote: > I have updated the tracking spread sheet: > https://docs.google.com/spreadsheet/ccc?key=0AmKrqWIOBsprdGZqMnB6dmx5bFJvVUhta > 3VLSjl3SkE&usp=sharing > and the diff on performance-related drafts is attached. > > You'll note there are now 2 worksheets, one for in-progress reviews > where I have added the following drafts (needing review volunteers): > > draft-ietf-alto-deployments- > draft-ietf-cdni-footprint-capabilities-semantics- > draft-ietf-nvo3-framework- > draft-ietf-ppsp-base-tracker-protocol- > draft-ietf-ppsp-peer-protocol- > > If you don't see your name on the "Completed" sheet, > let me suggest that it's time to participate (or retire > from the pm-dir to pursue other activities that keep you busy). > This way, we can keep the reviews voluntary and avoid > random or round-robin review assignments. > > For those attending IETF-87, we will likely have a short pm-dir > organizational meeting. Let me know (off-list) if you will be > in Berlin and are willing to attend if we can find an available time. > Directorate membership will be discussed. > > regards, > Al > pm-dir admin > > >> -----Original Message----- >> From: pm-dir-bounces@ietf.org [mailto:pm-dir-bounces@ietf.org] On Behalf >> Of Benoit Claise >> Sent: Sunday, July 14, 2013 5:06 PM >> To: pm-dir@ietf.org >> Subject: [pm-dir] Performance metrics doctors generated email >> >> 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-ippm-testplan-rfc2680-03 Active >> draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 In IESG processing - ID >> Tracker state >> >> Informative References >> ---------------------- >> draft-ietf-ippm-testplan-rfc2680-03 Active >> draft-ietf-xrblock-rtcp-xr-burst-gap-discard-14 In IESG processing - ID >> Tracker state >> draft-ietf-xrblock-rtcp-xr-decodability-12 In IESG processing - ID >> Tracker state >> draft-ietf-xrblock-rtcp-xr-discard-15 In IESG processing - ID >> Tracker state >> draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06 In IESG processing - ID >> Tracker state