[codec] Benjamin Kaduk's No Objection on draft-ietf-codec-ambisonics-07: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Mon, 30 July 2018 19:35 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: codec@ietf.org
Delivered-To: codec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5962130ECF; Mon, 30 Jul 2018 12:35:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-codec-ambisonics@ietf.org, Tim Terriberry <tterriberry@mozilla.com>, codec-chairs@ietf.org, tterriberry@mozilla.com, codec@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153297931466.7637.15045953147147693291.idtracker@ietfa.amsl.com>
Date: Mon, 30 Jul 2018 12:35:14 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/codec/iPrEbtr1W1YsNm8ZRpeICv3l_qI>
Subject: [codec] Benjamin Kaduk's No Objection on draft-ietf-codec-ambisonics-07: (with COMMENT)
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/codec/>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jul 2018 19:35:15 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-codec-ambisonics-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I see that Section 5.2 attempts to Update RFC 7845 to allow for the larger
channel mapping information used by family 3, but I'm still a little
unclear about what behavior I should expect from a pure RFC 7845
implementation that receives a family 3 stream.  The actual mapping table
would be "too long", but would the implementation detect that, or just note
that it's an unrecognized family and generate silence?

Section 1

I think we want to say "by adding itesm with values 2 and 3" to the
registry, since we add two entries and not a single superposed entry.

Section 3.1

While I can deduce this from the list of allowed numbers of channels,
noting that both ends of the range (0 and 14) are allowed values probably
would add clarity.

Section 3.2

Figure 3 could perhaps make it more clear that C and K are not necessarily

The term "side information" is used without definition (and is not used in
RFC 7845).  Does this clause really add anything in comparison to if we
just say "The matrix MUST be provided in the channel mapping table portion
of the identification header, in place of a normal channel mapping table"?

Section 5.1

Family 255 is specified in Section of RFC 7845, not
(Also, the unqualified Section references should probably all be of the
form Section N of RFC 7845, for the benefift of the HTML linkification

Section 8

Sometimes I see a "Description" column that allows for in-registry
visibility that a range is for experimental usage.  I suppose it would not
be too hard to also modify the registry structure to add such a thing, if
you want.