[codec] Barry Leiba's No Objection on draft-ietf-codec-oggopus-13: (with COMMENT)
"Barry Leiba" <barryleiba@computer.org> Wed, 17 February 2016 17:14 UTC
Return-Path: <barryleiba@computer.org>
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 E88081ACE99; Wed, 17 Feb 2016 09:14:53 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Barry Leiba <barryleiba@computer.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160217171453.30561.96304.idtracker@ietfa.amsl.com>
Date: Wed, 17 Feb 2016 09:14:53 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/codec/lj-F5rl11L8I6JEpHBE6mSgEHfA>
Cc: codec-chairs@ietf.org, codec@ietf.org, draft-ietf-codec-oggopus@ietf.org
Subject: [codec] Barry Leiba's No Objection on draft-ietf-codec-oggopus-13: (with COMMENT)
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.15
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, 17 Feb 2016 17:14:54 -0000
Barry Leiba has entered the following ballot position for draft-ietf-codec-oggopus-13: 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: https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 3 -- A demuxer SHOULD NOT attempt to decode the data for the first packet on a page with the 'continued packet' flag set 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) or if the page sequence numbers are not consecutive, unless the demuxer has some special knowledge that would allow it to interpret this data despite the missing pieces. This "SHOULD NOT" requirement is in a very long sentence with a few "ifs" and "buts", which make it hard to see what's really being required. Rewording to put the conditions up front might help. It'd also be good to explain why it's SHOULD NOT, rather than, say, MUST NOT. Under what conditions might I want to decode the first packet anyway, and what are the consequences of my doing that? It looks like the "unless" clause is there to explain that, in which case "MUST NOT ... unless" seems right. For the rewording, maybe this?: NEW If a page has the "continued packet" flag set and one of the following conditions is also true: - the previous page with packet data does not end in a continued packet (a lacing value of 255) OR - the page sequence numbers are not consecutive, then the demuxer SHOULD NOT attempt to decode the data for the first packet on the page unless the demuxer has some special knowledge that would allow it to interpret this data despite the missing pieces. END ...and then consider whether it really should be "MUST NOT ... unless". You should take similar action with the "SHOULD NOT" sentence in the next paragraph as well, as it has the same convolution problem. -- Section 5.2 -- In bullet 4, might it not be clearer to call it "User Comment List Count", rather than "Length"? In the list in general, I think it'd be clearer and more accurate to group all the "MUST NOT indicate that there are so many..." sorts of things into one one-sentence pargraph that says that the Vendor String and all the User Comments, together, MUST fit into the packet. No? -- Section 9 -- Malicious payloads MUST NOT cause an implementation to overrun its allocated memory or to take an excessive amount of resources to decode. ... Malicious audio input streams MUST NOT cause an implementation to overrun its allocated memory or consume excessive resources It's a small thing, rather at the nit level, but it doesn't make much sense to levy normative requirements on malicious actors. These would be much better if worded as requirements on the implementation, somewhat like this: NEW Malicious payloads and/or input streams can be used to attack codec implementations. Implementations MUST NOT overrun their allocated memory nor take an excessive amount of resources when decoding payloads or processing input streams. END -- Section 11 -- Modifications to this registry follow the "Specification Required with Expert Review" registration policy as defined in [RFC5226]. RFC 5226 does not define a policy with that name. The name is just "Specification Required"; please change this. And thanks for the paragraph giving guidance to the designated expert.
- [codec] Barry Leiba's No Objection on draft-ietf-… Barry Leiba
- Re: [codec] Barry Leiba's No Objection on draft-i… Timothy B. Terriberry