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

Good point, thank for clarification and proposed change.

Regards!
-Qin
----- Original Message ----- 
From: "Colin Perkins" <csp@csperkins.org>
To: <avt@ietf.org>
Sent: Friday, September 21, 2012 5:38 PM
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-21.txt

> 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/
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>