RE: [OPS-AREA] BOF: Applications Performance Management (APM) BOF

Al Morton <acmorton@att.com> Sun, 15 July 2007 03:42 UTC

Return-path: <ops-area-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9uzg-0006du-Un; Sat, 14 Jul 2007 23:42:00 -0400
Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1I9uze-0006cZ-Qd for ops-area-confirm+ok@megatron.ietf.org; Sat, 14 Jul 2007 23:41:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9uze-0006cR-Et for ops-area@ietf.org; Sat, 14 Jul 2007 23:41:58 -0400
Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9uzX-0003pw-3U for ops-area@ietf.org; Sat, 14 Jul 2007 23:41:58 -0400
X-VirusChecked: Checked
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-12.tower-121.messagelabs.com!1184470909!18434447!1
X-StarScan-Version: 5.5.12.11; banners=-,-,-
X-Originating-IP: [144.160.20.53]
Received: (qmail 25311 invoked from network); 15 Jul 2007 03:41:50 -0000
Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-12.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 15 Jul 2007 03:41:50 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6F3fnXJ021402 for <ops-area@ietf.org>; Sat, 14 Jul 2007 23:41:49 -0400
Received: from mlph070.sfdc.sbc.com (mlph070.sfdc.sbc.com [144.155.224.139]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6F3fgiM021375 for <ops-area@ietf.org>; Sat, 14 Jul 2007 23:41:46 -0400
Received: from sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph070.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6F3fgCf026937 for <ops-area@ietf.org>; Sat, 14 Jul 2007 23:41:42 -0400
Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by mlph070.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6F3fZO2026876 for <ops-area@ietf.org>; Sat, 14 Jul 2007 23:41:37 -0400
Message-Id: <200707150341.l6F3fZO2026876@mlph070.sfdc.sbc.com>
Received: from acmt.att.com (unknown[135.210.128.46](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20070715034134gw10010g2ee>; Sun, 15 Jul 2007 03:41:34 +0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sat, 14 Jul 2007 23:38:40 -0400
To: Daryl Malas <daryl@level3.net>, ops-area@ietf.org
From: Al Morton <acmorton@att.com>
Subject: RE: [OPS-AREA] BOF: Applications Performance Management (APM) BOF
In-Reply-To: <1182352980.16393.14.camel@montag.eng.level3.com>
References: <662C3EB2067DD64FBB2CDA77CD2B1A5601C82429@MCHP7R6A.ww002.siemens.net> <1182352980.16393.14.camel@montag.eng.level3.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc:
X-BeenThere: ops-area@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: OPS Area e-mail list <ops-area.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ops-area>, <mailto:ops-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ops-area>
List-Post: <mailto:ops-area@ietf.org>
List-Help: <mailto:ops-area-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ops-area>, <mailto:ops-area-request@ietf.org?subject=subscribe>
Errors-To: ops-area-bounces@ietf.org

Hi Daryl,

Thanks for your comments, here's the on-list response.
(Now that the drafts are out-there, it can be more complete.
We've exchanged some messages off list, so you knew this was coming.)

At 11:23 AM 6/20/2007, Daryl Malas wrote:
>IMO, I completely agree there is a gap in the IETF for this type of
>work, and I absolutely think an APM Directorate is the right approach.
>There are only two drafts associated with this BOF at this point.  It
>does not appear there are a lot of other drafts in the pipeline for this
>work.  Since this is the case, I don't see a need to create a new
>working group for 1 or 2 drafts.

The APM agenda lists more than two now:
http://www3.ietf.org/proceedings/07jul/agenda/apm.txt


- draft-malas-performance-metrics-07.txt
- draft-venna-ippm-app-loss-metrics-00.txt
- draft-ietf-avt-rtcpxr-video-01.txt
- draft-ietf-avt-rtcpxr-audio-00.txt
- draft-ietf-avt-rtcphr-01.txt
- draft-xie-ccamp-lsp-dppm-01.txt
- draft-kikuchi-passive-measure-00.txt

IDR Stability Performance (draft?)
(There is a Liaison statement on this topic, at least:
https://datatracker.ietf.org/liaison/237/ )


>Unfortunately, I don't think this type
>of work is "sexy" from an IETF perspective.  I am concerned if a working
>group is created, this type of work will not receive the necessary
>visibility to be successful and truly valuable.

It's a valid concern.  Performance metric definition has never
been "sexy".  The work in IPPM and BMWG is carried out by
small but dedicated core groups, and a healthy influx of new people
with work proposals.  Can this "performance community" sustain a
third chartered activity?  That's what we hope to learn in the BOF.
However, it seems to me that forming a working group would tend to
increase the visibility (more so than an APM Directorate),
if this move is warranted.

>On the flip side, I
>also know that it will take up time within the existing working groups,
>but I think those are the right locations to get a temperature reading
>on their value.

In either case (WG or directorate), it would be a necessary step
to have the proposal reviewed by the associated protocol development
WG, and then develop the draft(s) in partnership with the protocol
experts.

Al



_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www1.ietf.org/mailman/listinfo/ops-area