Re: [codec] Eric Rescorla's No Objection on draft-ietf-codec-ambisonics-07: (with COMMENT)

Ben Campbell <> Fri, 24 August 2018 20:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A5BB130DC0; Fri, 24 Aug 2018 13:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MAdhihIug468; Fri, 24 Aug 2018 13:52:12 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C974D130DDF; Fri, 24 Aug 2018 13:52:12 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id w7OKq6rS079009 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 24 Aug 2018 15:52:11 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_AC410CAA-ED0E-4782-AF95-8060AB0377B2"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 24 Aug 2018 15:51:55 -0500
In-Reply-To: <>
Cc: Jan Skoglund <>, Tim Terriberry <>,,,, The IESG <>
To: Eric Rescorla <>
References: <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [codec] Eric Rescorla's No Objection on draft-ietf-codec-ambisonics-07: (with COMMENT)
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Aug 2018 20:52:15 -0000

> On Aug 10, 2018, at 2:33 PM, Eric Rescorla <> wrote:
> S 5.2.
> >         The remaining channel mapping families (2...254) are reserved.  A
> >         demuxer implementation encountering a 'channel mapping family'
> >         value that it does not recognize SHOULD NOT attempt to decode the
> >         packets and SHOULD NOT use any information except for the first 19
> >         octets of the ID header packet (Fig. 2) and the comment header
> >         (Fig. 10).
> What is the rationale for this change? Also, why are you doing it in
> this document? This seems like it's going to be extremely hard for
> implementors to find in future.
> These paragraphs are updates to RFC 7845, which needed to be revised to accommodate the proposed channel mapping families in this draft.
> Sorry, I don't understand. Why did they need to be revised to have this change?
> The authors of RFC 7845 and RFC 6716 suggested that the necessary updates to RFC 7845 should be included in this draft.
> I understand, but my point is that people are likely to ignore this draft if they don't care about ambisonics and thereby miss out on a relevant information. In any case, I'll defer to the WG and AD.

Closing the loop on this point:

We have commonly put updates to RFCs in the documents that create the need for the updates, even if the update is generally applicable. We have the “Updates/Updated by” relationships to track this sort of thing.

I am sympathetic to Ekr’s argument, in that I agree it would be more convenient for the reader to find the update in a smaller, dedicated draft. But at this point in the process, I highly doubt the wg has the energy to do that sort of restructuring. Therefore I am inclined to leave this the way it is.