Protocol Action: 'Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)' to Proposed Standard (draft-ietf-avtext-multicast-acq-rtcp-xr-06.txt)

The IESG <iesg-secretary@ietf.org> Wed, 08 June 2011 15:36 UTC

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)' to Proposed Standard (draft-ietf-avtext-multicast-acq-rtcp-xr-06.txt)
Message-ID: <20110608153621.23408.6943.idtracker@ietfa.amsl.com>
Date: Wed, 08 Jun 2011 08:36:21 -0700
Cc: avtext mailing list <avtext@ietf.org>, avtext chair <avtext-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Precedence: list

The IESG has approved the following document:
- 'Multicast Acquisition Report Block Type for RTP Control Protocol
   (RTCP) Extended Reports (XRs)'
  (draft-ietf-avtext-multicast-acq-rtcp-xr-06.txt) as a Proposed Standard

This document is the product of the Audio/Video Transport Extensions
Working Group.

The IESG contact persons are Gonzalo Camarillo and Robert Sparks.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-avtext-multicast-acq-rtcp-xr/




Technical Summary

   In most RTP-based multicast applications, the RTP source sends inter-
   related data.  Due to this interdependency, randomly joining RTP
   receivers usually cannot start consuming the multicast data right
   after they join the session.  Thus, they often experience a random
   acquisition delay.  An RTP receiver can use one ore more different
   approaches to achieve rapid acquisition.  Yet, due to various
   factors, performance of the rapid acquisition methods usually varies.
   Furthermore, in some cases the RTP receiver can do a simple multicast
   join (in other cases it is compelled to do so).  For quality
   reporting, monitoring and diagnostics purposes, it is important to
   collect detailed information from the RTP receivers about their
   acquisition and presentation experiences.  This document addresses
   this issue by defining a new report block type, called Multicast
   Acquisition (MA) Report Block, within the framework of RTP Control
   Protocol (RTCP) Extended Reports (XR) (RFC 3611).  This document also
   defines the necessary signaling of the new MA report block type in
   the Session Description Protocol (SDP).

Working Group Summary

  There was nothing contentious about this document.

Document Quality

   Are there existing implementations of the protocol?  Have a 
   significant number of vendors indicated their plan to
   implement the specification?  Are there any reviewers that
   merit special mention as having done a thorough review,
   e.g., one that resulted in important changes or a
   conclusion that the document had no substantive issues?  If
   there was a MIB Doctor, Media Type, or other Expert Review,
   what was its course (briefly)?  In the case of a Media Type
   Review, on what date was the request posted?

At the moment the shepherd is not aware of any protocol implementations, 
and no vendors have directly indicated they plan to implement, although he 
assumes that all RAMs implementations will ultimately include this, as it is 
essentially a mandatory part of RAMs. The reviewers are listed elsewhere 
in the PROTO writeup. There were no external reviews of the types mentioned, 
because there is no material requiring such review.

Personnel

Keith Drage is the document shepherd
Gonzalo Camarillo is the responsible area director.

Protocol Action: 'Multicast Acquisition Report Bl… The IESG