Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio
draft-ietf-avt-rtp-eac3-01

Brian provided: I just heard from Richard Nicholls that he got the deadline for 102 005
publication pushed back to September, for both the ETSI publication and
the DVB blue book. This happened at this week's DVB meetings.

1.a) Have the chairs personally reviewed this version of the ID and
do they believe this ID is sufficiently baked to forward to the
IESG for publication?

Yes.

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

The draft has had adequate review.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

I have no concerns. MIME review completed with no objections.

1.d) Do you have any specific concerns/issues with this document
that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of
the
document, or have concerns whether there really is a need for
it, etc. If your issues have been discussed in the WG and the
WG has indicated it wishes to advance the document anyway, note
if you continue to have concerns.

I have no concerns.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is solid consensus (indeed, this is very similar to the audio/
ac3 format, which the group has previous published).

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise what are they upset about.

No.

1.g) Have the chairs verified that the document adheres to _all_ of
the ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes.

1.h) Does the document a) split references into normative/
informative, and b) are there normative references to IDs,
where
the IDs are not also ready for advancement or are otherwise in
an unclear state? (Note: the RFC editor will not publish an RFC
with normative references to IDs, it will delay publication
until all such IDs are also ready for publication as RFCs.)

References are split; no normative reference to I-Ds.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following
sections:


* Technical Summary

This document describes an RTP payload format for transporting
Enhanced AC-3 (E-AC-3) encoded audio data. E-AC-3 is a high
quality,
multichannel audio coding format and is an extension of the AC-3
audio coding format, which is used in US HDTV, DVD, cable and
satellite television and other media. E-AC-3 is an optional audio
format in US and world-wide digital television and high definition
DVD formats. The RTP payload format as presented in this document
includes support for data fragmentation.


* Working Group Summary

This is a straight forward RTP payload format, similar to previous
formats. It has been reviewed by the AVT working group, and is not
controversial.

* Protocol Quality

This document was reviewed in detail by Colin Perkins and Magnus
Westerlund.


1.j) Please provide such a writeup. (We will hopefully use it as
is,
but may make some changes.) For recent examples, have a look at
the "protocol action" announcements for approved documents.



1.k) Note:

* When doing the technical summary, one would expect that
the
relevant information is in the abstract and/or
introduction
of the document. It turns out that the step of producing
the writeup sometimes points out deficiencies in the
introduction/abstract that are also worthy of rectifying.


* For the Working Group Summary, was there anything in WG
process that is worth noting? (E.g., controversy about
particular points, decisions where consensus was
particularly rough, etc.)


* For the protocol quality, useful information could
include:


+ is the protocol already being implemented?


+ have a significant number of vendors indicated they
plan to implement the spec?


+ are there any reviewers (during the end stages) that
merit explicit mention as having done a thorough
review that resulted in important changes or a
conclusion that the document was fine (except for
maybe some nits?)