[codec] AD Evaluation of draft-ietf-codec-oggopus-09
"Ben Campbell" <ben@nostrum.com> Wed, 09 December 2015 01:43 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4DC1A6FDF; Tue, 8 Dec 2015 17:43:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJmJx47sT4YO; Tue, 8 Dec 2015 17:43:28 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07D01A6FC8; Tue, 8 Dec 2015 17:43:21 -0800 (PST)
Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tB91hKQm086672 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 8 Dec 2015 19:43:21 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10]
From: Ben Campbell <ben@nostrum.com>
To: draft-ietf-codec-oggopus.all@ietf.org, codec@ietf.org
Date: Tue, 08 Dec 2015 19:43:21 -0600
Message-ID: <86ACD2D0-02B6-473E-9E35-B9980166D9A0@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.3r5187)
Archived-At: <http://mailarchive.ietf.org/arch/msg/codec/HTfg54dvnDG_LJV9Tt0TNsw-FN4>
Subject: [codec] AD Evaluation of draft-ietf-codec-oggopus-09
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Wed, 09 Dec 2015 01:43:30 -0000
(oops, sent from wrong address, and got bounced from a lot of lists. Apologies for the repeat. Please send replies to this address.) Hi, Here is my AD evaluation of draft-ietf-codec-oggopus-09. Codec encapsulation is not my strong suit, so I suspect many of my comments can be answered with "this is the way we normally do this thing". But I'd still like to discuss these before going to IETF last call. Thanks! Ben. ---------------- Substantive: ============ - section 2, last paragraph: Is this paragraph necessary or useful? (And is it really impossible to create a non-compliant implementation that meets all the MUSTs?) I suggest removing it. - section 3: This section seems to use 2119 keywords to describe what I _think_ are existing Ogg requirements. If so, they should use descriptive text, unless they are in the form of attributed quotes. - 3, last paragraph: -- "implementations need to be prepared": maybe that should be a MUST or SHOULD? -- "last page SHOULD NOT be a continued packet": Why not MUST NOT? Can you describe reasons someone might reasonably violate this? - 4.2, 2nd paragraph: -- "samples which SHOULD be skipped": Why not MUST? (also, s/which/that) -- "SHOULD NOT be played": Is this redundant with SHOULD be skipped? - 4.3: Should the reference to [vorbis-trim] be normative? Can the feature be implemented without understanding the referenced doc? - 4.6: Should the reference to [seeking] be normative? Can the section be implemented without understanding it? - 5.1, list entry 5: What is the unit for "Input Sample Rate"? - 5.1, entry 6, sentence starting with "Virtually all players..." Is this a normative statement, or a statement of fact? If the former, consider dropping “Virtually all” - 5.1, entry 6, last paragraph: -- "which MUST be omitted when the channel mapping family is 0": That seems redundant to the previous paragraph. -- "Implementations SHOULD reject ID headers" What does it mean, in context, to "reject" headers? - 5.1.1.4: Why not MUST? - 5.2, last two paragraph: Why are the two SHOULDs not MUSTs? - 5.2.1, 2nd to last paragraph, last sentence: I don’t think muxers assume things—what is the required concrete behavior? - 5.2.1, last paragraph: Why is the SHOULD NOT not MUST NOT? -6, first paragraph: Why are the two SHOULDs not MUSTs? What does it mean to reject a packet? -7: "reference implementation" could use a citation. Should [linear-predection] be normative? Can this be implemented without understanding that? If it does need to be normative, can you find a more stable reference? - 9, first paragraph: This seems to defer at least some security considerations to 4732. If so, this should be a normative reference. If, on the other hand, 4732 just provides additional information that is not necessary to understand this section, then the wording should be adjusted. - 13: Is this needed? Are the IETF BCP 78 and 79 provisions incorrect for this? Editorial ========= - Section 1: Consider spelling out multiplexer (muxer) and demultiplexer (demuxer) on first mention. - 3: Please expand TOC, SILK, and CELT on first mention. - 5, steps 2 and 3: These steps in combination seem to say “ decode at the highest available supported rate that the hardware can handle.” If so, the wording could be simplified. - 7, 2nd paragraph: I don’t think that’s literally true, you’ve defined 0, 1, and 255. The rest are reserved. (I guess one could argue the guidance to treat reserved values as 255 supports this statement, but I think that’s a stretch. -5.1.1.2: Do you expect the reader to know what Vorbis channel order is? Also, please expand FLAC on first mention. - 5.2.1, paragraph starting with " An Ogg Opus stream MUST NOT have more than one of each tag, and if present their values MUST be an integer" each of these two new tags, or all tags? (I assume the former from the numeric values) Also, singular/plural mismatch in "their values MUST be an integer" -10, last paragraph: Updates, or extends? If the former, the draft needs an “Updates RFC 5334” field in the initial heading.
- [codec] AD Evaluation of draft-ietf-codec-oggopus… Ben Campbell
- Re: [codec] AD Evaluation of draft-ietf-codec-ogg… Timothy B. Terriberry
- Re: [codec] AD Evaluation of draft-ietf-codec-ogg… Ron
- Re: [codec] AD Evaluation of draft-ietf-codec-ogg… Timothy B. Terriberry
- Re: [codec] AD Evaluation of draft-ietf-codec-ogg… Ben Campbell
- Re: [codec] AD Evaluation of draft-ietf-codec-ogg… Ben Campbell
- Re: [codec] AD Evaluation of draft-ietf-codec-ogg… Timothy B. Terriberry
- Re: [codec] AD Evaluation of draft-ietf-codec-ogg… Ben Campbell
- Re: [codec] AD Evaluation of draft-ietf-codec-ogg… Ben Campbell
- Re: [codec] AD Evaluation of draft-ietf-codec-ogg… Timothy B. Terriberry
- Re: [codec] AD Evaluation of draft-ietf-codec-ogg… Ron
- Re: [codec] AD Evaluation of draft-ietf-codec-ogg… Timothy B. Terriberry
- Re: [codec] AD Evaluation of draft-ietf-codec-ogg… Ben Campbell
- Re: [codec] AD Evaluation of draft-ietf-codec-ogg… Ben Campbell
- Re: [codec] AD Evaluation of draft-ietf-codec-ogg… Ron
- Re: [codec] AD Evaluation of draft-ietf-codec-ogg… Timothy B. Terriberry
- Re: [codec] AD Evaluation of draft-ietf-codec-ogg… Ben Campbell
- Re: [codec] AD Evaluation of draft-ietf-codec-ogg… Timothy B. Terriberry