Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-21.txt

Colin Perkins <csp@csperkins.org> Fri, 21 September 2012 09:38 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6968521F8720 for <avt@ietfa.amsl.com>; Fri, 21 Sep 2012 02:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQyKlSjCs54G for <avt@ietfa.amsl.com>; Fri, 21 Sep 2012 02:38:57 -0700 (PDT)
Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id 890C421F8723 for <avt@ietf.org>; Fri, 21 Sep 2012 02:38:57 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1TEzhI-0002vQ-an for avt@ietf.org; Fri, 21 Sep 2012 09:38:56 +0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1283)
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <20120921033311.2019.17521.idtracker@ietfa.amsl.com>
Date: Fri, 21 Sep 2012 10:38:55 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <94BFF0B8-B69E-41C7-8C73-9CD38EF5F938@csperkins.org>
References: <20120921033311.2019.17521.idtracker@ietfa.amsl.com>
To: "avt@ietf.org WG" <avt@ietf.org>
X-Mailer: Apple Mail (2.1283)
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-21.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Sep 2012 09:38:58 -0000

On 21 Sep 2012, at 04:33, Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF.
> 
> 	Title           : Guidelines for Use of the RTP Monitoring Framework
> 	Author(s)       : Qin Wu
>                          Geoff Hunt
>                          Philip Arden
> 	Filename        : draft-ietf-avtcore-monarch-21.txt
> 	Pages           : 29
> 	Date            : 2012-09-20
> 
> Abstract:
>   This memo proposes an extensible Real-Time Protocol (RTP) monitoring
>   framework for extending RTP Control Protocol (RTCP) with a new RTCP
>   Extended Reports (XR) block type to report new metrics regarding
>   media transmission or reception quality.  In this framework, a new XR
>   block should contain a single metric or a small number of metrics
>   relevant to a single parameter of interest or concern, rather than
>   containing a number of metrics which attempt to provide full coverage
>   of all those parameters of concern to a specific application.
>   Applications may then "mix and match" to create a set of blocks which
>   covers their set of concerns.  Where possible, a specific block
>   should be designed to be re-usable across more than one application,
>   for example, for all of voice, streaming audio and video.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch


I'm a little confused by the changes to this draft. The last paragraph of the Introduction now has a strong focus on definition of new metrics, and explicitly refers to the RFC 6390 guidelines for defining new metrics. However, we've been pretty consistent that new RTCP XR report blocks don't define new metrics, but rather explicitly convey metrics that have been defined elsewhere. 

I'd suggest changing:

   In the Performance Metrics Framework [RFC6390], guidelines for
   Considering New Performance Metric Development are provided.  The
   objective of this document is to describe an extensible RTP
   monitoring framework to provide a small number of re-usable Quality
   of Service (QoS) / QoE metrics which facilitate reduced
   implementation costs and help maximize inter-operability.  The
   "Guidelines for Extending the RTP Control Protocol (RTCP)" [RFC5968]
   has stated that, where RTCP is to be extended with a new metric, the
   preferred mechanism is by the addition of a new RTCP XR [RFC3611]
   block.  This memo assumes that all the guidelines from RFC 5968 must
   apply on top of the guidelines in this document.  In the Performance
   Metrics Framework [RFC6390], guidelines for Considering New
   Performance Metric Development are provided.  When new performance
   metrics are specified, they must follow the RFC 6390 rules:
   specifically, the performance metric definition template (see section
   5.4.4, RFC 6390) must be used.

to:

   The objective of this document is to describe an extensible RTP
   monitoring framework to provide a small number of re-usable Quality
   of Service (QoS) / QoE metrics which facilitate reduced
   implementation costs and help maximize inter-operability.  The
   "Guidelines for Extending the RTP Control Protocol (RTCP)" [RFC5968]
   has stated that, where RTCP is to be extended with a new metric, the
   preferred mechanism is by the addition of a new RTCP XR [RFC3611]
   block.  This memo assumes that all the guidelines from RFC 5968 must
   apply on top of the guidelines in this document. Guidelines for 
   developing new performance metrics are specified in [RFC6390]. New
   RTCP XR report block definitions should not define new performance
   metrics, but should rather refer to metrics defined elsewhere. It
   is expected that the referenced metrics will conform to [RFC6390].

Colin 


-- 
Colin Perkins
http://csperkins.org/