RTP Payload Format for BroadVoice Speech Codecs
draft-ietf-avt-rtp-bv-04

[Ballot comment]
This document is not limited to the vendor tree
because multiple vendors and an industry
consortium have agreed to it.  That justifies
this as a COMMON registration.  The document
reads, though, as if it were for a vendor specific
registration, and the registrants may wish to remove
some of the more marketing-literature appropriate
phrases to highlight that this codec will be valid
beyond Broadcom's wares.

[Ballot discuss]
Section 7 says:
  >
  > Because the data compression used with this payload
  > format is applied end-to-end, encryption may be performed after
  > compression so there is no conflict between the two operations.
  >
  Yes, compression needs to be performed prior to encryption for it
  to be useful.  However, this is awkward wording.  I think a bit of
  tutorial information is desirable.  Three points should be made:
 
  1.  Compression aids encryption by reducing the redundancy in the
  plaintext.  Since all encryption algorithms have an upper limit
  to the amount of data that can be encrypted under a single key,
  this increases the amount of encoded speech that can be
  encrypted under a particular key.

  2.  Compression shortens the input, and thus reducing the amount
  of processing required to perform encryption.

  3.  Compression after encryption is silly.  An good encryption
  algorithm will produce output which is statistically indistinguishable
  from random numbers, and no compression algorithm will successfully
  compress random numbers.

IANA Last Call Comments:
Upon approval of this document the IANA will register 2 MIME Media Types:
audio/BV16 and audio/BV32
We understand these 2 registrations to be the only IANA Actions for this document.

[Note]: 'About to send to ietf-types and then speed to IESG - this version has payloads only and
will be updated by a later draft with the storage formats' added by Allison Mankin

will get a separate i-d for the file format so we not gate on mime file discussion later (J-F Mule
verbal communication today, confirming chair discussion Sunday) - cablelabs needs basic
registration published asap

Received email from J-F Mule about CableLabs timetable for need for this spec (sent to Chairs/AD and another copy sent to several ADs and Jonathan Rosenberg as IAB advocate for CableLabs liaison) - timing is either by mid-Feb for a Mar deadline or before a July deadline.  Keeping this information within tracker at J-F's request.

AD Review email with Chairs/Authors

> > Please define separate media types for the file formats; this is
> > a new recommendation by the Applications area, not to be applied
> > to existing types such amr, but for new media types.
>
> Since when? This is extremely problematic, goes against explicit advice
> from the applications area when RTP changed to using MIME types,
> contradicts many existing types, and has not been discussed with the
> working group.
>

Sorry, I elided the discussion - "this is a new recommendation"
is a shorthand for "new recommendation-in-the-making".  I do know that
the AVT Chairs have not completely signed on, especially not you, Colin.
But the Applications ADs are very sure this is a technically sound, and
you Chairs and I have discussed this, and it has been discussed on the
AVT list.  I am remiss in a plan to have a conference call of AVT Chairs
and Apps ADs to work on the revision of the media types registration
document and drive to the Last Call of this policy so the clear
guidance is there for the long run.  Many existing types have* used
the same registration for RTP and file types in the past, though,
and another piece of guidance is that these and their updates will
be left alone.

My elision was that BV should not have a good technical reason to
cling to the old way, at the cost of delays.  Why wait to get the
media type document all squared away, which could take a while, before
getting BV settled?

From Colin Perkins, WG Chair, this is the WG Chair Write-up (inclusion in the datatracker approved by Allison Mankin):

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?

Yes. The document is a straight-forward RTP payload format, which has
been discussed on the mailing list and at a number of working group
meetings.

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.)?

No.

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.

No. I am happy with the draft.

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?

This is an RTP payload format for a proprietary codec and has been
driven primarily by the makers of that codec. The working group has
reviewed the draft, and there is consensus that it is an appropriate
solution.

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 have been split. There is one normative reference to an
internet-draft, but that draft is in working group last call in MMUSIC
at this time.