[Gen-art] Review: draft-ietf-codec-oggopus-10

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 15 January 2016 22:27 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 1F29E1B333A; Fri, 15 Jan 2016 14:27:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id o1J8BXUkYxK0; Fri, 15 Jan 2016 14:27:41 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF78B1B3339; Fri, 15 Jan 2016 14:27:41 -0800 (PST)
Received: from localhost (localhost []) by mailb2.tigertech.net (Postfix) with ESMTP id 6B3211C0D95; Fri, 15 Jan 2016 14:27:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1452896861; bh=hf3f0FK1Y3CfH5I/ISuYPq2Zks7M04Gm/NnZuSt65Qk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=MeTyQ+pWgoczK0LF2D/44OH55RYwfpnIAd2EwMuVK/FcpOk4JEuwTbICv5M32hfEo GKeJo+EbjHZ5AN/cgzjfPEQg02RQl5ovx+s2J28GK2j5BxeKOj1XEsR4ij3DzyzSdK YXABNmCgBg7gkr61NYS4qOIAjd2WZetoJ/Q8ks/I=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E5E4B1C013E; Fri, 15 Jan 2016 14:27:40 -0800 (PST)
To: "A. Jean Mahoney" <mahoney@nostrum.com>, General Area Review Team <gen-art@ietf.org>, IETF discussion list <ietf@ietf.org>, draft-ietf-codec-oggopus.all@ietf.org
References: <569820FC.7050309@nostrum.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <56997225.9000405@joelhalpern.com>
Date: Fri, 15 Jan 2016 17:26:45 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <569820FC.7050309@nostrum.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/4NCRb5lKDwlGx3JoRTALAYz1hf0>
Subject: [Gen-art] Review: draft-ietf-codec-oggopus-10
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jan 2016 22:27:43 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-codec-oggopus-10
     Ogg Encapsulation for the Opus Audio Codec
Reviewer: Joel M. Halpern
Review Date:
IETF LC End Date: 27-January-2016
IESG Telechat date: N/A

     This document is nearly ready for publication as a Proposed Standard.
     The reviewer believes the status issues needs to be addressed, and 
would like the minor issue identified below discussed.

Major issues:
     I do not see how we can have a standards track document for using 
an Informational format.  RFC 3533 is Informational.  At the very least, 
the last call needed to identify the downref to RFC 3533.  (It is not 
clear whether the reference to RFC 4732 needs to be normative or could 
be informative.)

Minor issues:
     While I do not completely understand ogg lacing values, there 
appears to be an internal inconsistency in the text in section 3:
1) "if the previous page with packet data does not end in a continued 
packet (i.e., did not end with a lacing value of 255)"
2) "a packet that continues onto a subsequent page (i.e., when the page 
ends with a lacing value of 255)"
     The first quote says that continued packets end with a lacing value 
of 255, and the second quote says that continued packets end with a 
lacing value of less than 255.  At the very least, these need to be 

Nits/editorial comments:
     is there some way to indicate that the ogg encoding constraints 
(e.g. 48kHz granule and 2.5 ms timing) are sufficiently broad to cover 
all needed cases?

Joel Halpern