Subject: [AVTCORE] WG last call on Monitoring Architecture for RTP (draft-ietf-avtcore-monarch-11)

From: Magnus Westerlund <[email-masked]>
Date: Mon, 5 Mar 2012 08:44:31 +0100

WG,

This initiates the Working group last call on Monitoring Architecture
for RTP (draft-ietf-avtcore-monarch-11) to be published as Informational
RFC. The WG last call will run for three weeks and end Monday the 26th.

The draft can be retrieved from here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch/

Please provide feedback if you have read it, even if you have no
comments or think it is good enough, this is important information in
judging the support and readiness for publication.

Thanks

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 14 Mar 2012 15:46:33 -0700

I have read this draft and think it is in good shape.
I have the following editorial recommendations.

1) Section 1, reads as follows:
   However the proliferation of RTP/RTCP specific metrics for transport
   and application quality monitoring has been identified as a potential
   problem for RTP/RTCP interoperability, which attempt to provide full
   coverage of all those parameters of concern to a specific
   application.
I suggest rewording this as follows:
   The proliferation of RTP/RTCP specific metrics for transport
   and application quality monitoring has been identified as a potential
   problem for interoperability when using RTP/RTCP to communicate all 
   the parameters of concern to a specific application.

2) Section 2, Application level metric definition
r/the service level and is/the service level and are

3) Section 2, Direct metrics definition
r/other metric/other metrics

4) Section 2, Composed metrics definition, reads as follows:
      Metrics that are not directly measured and derived from other
      metrics.  One example of such metrics is the ones calculated based
      on Direct metric that have been measured.
I suggest rewording as follows:
      Metrics that are not measured directly but rather are derived from one or 
      more other metrics. An example is a metric calculated based on derived metrics
      that have been measured.

5) Section 2, Sampled metrics definition
r/measured or calculated that/measure or calculated metric that

6) Section 3, last word
r/mechanism/mechanisms

7) Section 3.1
r/RTP is used/RTP may be used,
Also, expand ASM and SSM.

8) Section 4, first bullet
r/Design compound/Designing compound

9) Section 4, second bullet, reads as follows:
   o  Correlating RTCP XR with the non-RTP data.  Canonical End-Point
      Identifier SDES Item (CNAME) defined in the RTP Protocol [RFC3550]
      is an example of existing tool that allows to bind an
      Synchronization source (SSRC) that may change to a fixed source
      name in one RTP session.  It may be also fixed across multiple RTP
      sessions from the same source.
I suggest rewording as follows:
   o  Correlating RTCP XR with the non-RTP data.  Canonical End-Point
      Identifier SDES Item (CNAME), defined in the RTP Protocol [RFC3550],
      is an example of an existing tool that allows binding a
      Synchronization source (SSRC) that may change to a name that is
      fixed within one RTP session.  CNAME may be also fixed across multiple RTP
      sessions from the same source.
Also
r/should be concerned/should be provided

10) Section 4, third bullet
r/"metric interval. In such case"/"metric intervals. In such cases"

11) Section 5.1, second paragraph
r/this memo proposes the use of single metrics block each containing/this memo recommends the definition of metrics blocks containing

12) Section 5.2,
r/There may be situation/There may be situations
r/one media transport protocols are used/one media transport protocol is used
r/"in a VOIP session one"/"in a VOIP session. One"

13) Section 5.3,
r/even if though/even though

Cheers,
Charles
 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Magnus Westerlund
> Sent: Sunday, March 04, 2012 11:45 PM
> To: IETF AVTCore WG
> Subject: [AVTCORE] WG last call on Monitoring Architecture for
> RTP(draft-ietf-avtcore-monarch-11)
> 
> WG,
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Qin Wu <[email-masked]>
Date: Fri, 16 Mar 2012 15:19:07 +0800

Hi, Charles:
I accept all your comments and will issue new version to address upon LC is done.
Thanks for your valuable review. 

Regards!
-Qin
----- Original Message ----- 
>From: "Charles Eckel (eckelcu)" <[email-masked]>
>To: "Magnus Westerlund" <[email-masked]>; "IETF AVTCore WG" <[email-masked]>
>Sent: Thursday, March 15, 2012 6:46 AM
>Subject: Re: [AVTCORE] WG last call on Monitoring Architecture forRTP(draft-ietf-avtcore-monarch-11)

>   the parameters of concern to a specific application.

[Qin]: The new wording looks better to me. Thanks. 

>r/the service level and is/the service level and are

[Qin]: Okay.

>r/other metric/other metrics

[Qin]: Okay.

>      more other metrics. An example is a metric calculated based on derived metrics

[Qin]: Good wording, thanks.

>r/measured or calculated that/measure or calculated metric that

[Qin]: Okay.

>r/mechanism/mechanisms

[Qin]: Okay.

>Also, expand ASM and SSM.

[Qin]: Okay.

>r/Design compound/Designing compound

[Qin]: Okay.

>r/should be concerned/should be provided

[Qin]: Okay.

>r/"metric interval. In such case"/"metric intervals. In such cases"

[Qin]: Okay.

>r/this memo proposes the use of single metrics block each containing/this memo recommends the definition of metrics blocks containing

[Qin]: Okay.

>r/"in a VOIP session one"/"in a VOIP session. One"

[Qin]: Okay.

>r/even if though/even though

[Qin]: Okay.