Re: [payload] Questions on draft-ietf-payload-vp8-16

Harald Alvestrand <harald@alvestrand.no> Wed, 15 July 2015 14:20 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E881A914F; Wed, 15 Jul 2015 07:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 wBgOCPe1A8XE; Wed, 15 Jul 2015 07:20:53 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0231A914E; Wed, 15 Jul 2015 07:20:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 42CE37C3AAA; Wed, 15 Jul 2015 16:20:52 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcHK7CBRRQ_i; Wed, 15 Jul 2015 16:20:50 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:3da7:4293:4c8b:1565] (unknown [IPv6:2001:470:de0a:27:3da7:4293:4c8b:1565]) by mork.alvestrand.no (Postfix) with ESMTPSA id 840A17C3A97; Wed, 15 Jul 2015 16:20:50 +0200 (CEST)
Message-ID: <55A66C41.1030902@alvestrand.no>
Date: Wed, 15 Jul 2015 16:20:49 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>, draft-ietf-payload-vp8.all@ietf.org, payload-chairs@ietf.org, payload@ietf.org
References: <8163A1DE-531A-4CDA-AA6F-61ADCDAE784B@nostrum.com>
In-Reply-To: <8163A1DE-531A-4CDA-AA6F-61ADCDAE784B@nostrum.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/payload/xxukDHWtbF43w6DTfx44ftW_MI8>
Subject: Re: [payload] Questions on draft-ietf-payload-vp8-16
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2015 14:20:55 -0000

Den 29. juni 2015 23:50, skrev Ben Campbell:
> Hi,
> 
> I'm doing a quick re-look at draft-ietf-payload-vp8-16 before starting a
> repeat IETF Last Call. I have a few comments. I don't think any of these
> need delay the last call, so please address them along with any last
> call comments.
> 
> Please bear in mind that I am reconstructing a lot of history here, so I
> apologize in advance if I bring up things that have already been discussed.
> 
> Thanks!
> 
> Ben.
> 
> ------------
> 
> General:
> 
> Ted Lemon and Pete Resnick made some AD comments when they were still
> ADs. Even though they are no longer on the IESG, their comments look
> reasonable. I don't see evidence that they have been addressed--please
> consider addressing them.
> 
> It looks like you have addressed some, but not all, of Stephen Farrell's
> comments. Has there been discussion on why the ones not addressed were
> not addressed?

I'm afraid we missed some :-(

We'll consider these for the next update round - as far as I remember,
they were all of an editorial nature ("this can be stated more clearly"
or "this needs some more justification").

It wasn't immediately clear to us where responses to those comments
should go either, given that they were never posted to the mailing list,
and we can't respond in the tool that was used to keep them.

> (Note that in both of the paragraphs above, I don't mean by "addressed"
> that the draft necessarily needs to change--just that the authors
> respond to the input--even if only to say why they don't agree with a
> comment.)
> 
> -- 4.5 and 4.5.1: It would be helpful to explain why these are listed as
> examples. I assume it's one of those cases where this algorithm gives
> the right results, but others could also do so. If so, some words to
> that effect would be helpful. It might also be helpful to include a few
> words indicating why 4.5.1 is a child of 4.5 rather than a peer. (I
> assume because partition reconstruction is a subset of frame
> reconstruction?)

A tidier format would be to have

4.5 Reconstruction algorithms
4.5.1 Frame reconstruction
4.5.2 Partition reconstruction

The sections were added in version -09 (July 2013), in response to
Richard Barnes' AD review (where he pointed out that it was "mostly
clear", but that it would be nice to make it explicit).

I guess nobody looked hard at the table of content for the next 2 years.


> 
> -- 7:
> 
> I don't see a response to the secdir review ( Secdir review of
> draft-ietf-payload-vp8-08 ). For the SRTP question, please consider
> using the boilerplate in the appendix of draft-ietf-payload-rtp-howto-14
> (section A.13).
> 

The secdir review was another one that we spent considerable time
finding, and then did not address explicitly...

The text about pathological data refers to the fact that some codecs
have algorithms that allow very high complexity operations to be
triggered by a suitably crafted data stream (10x or more beyond the
decoding of an ordinary stream); VP8 does not contain such algorithms,
so people shouldn't be too worried about this threat. It is in fact a
direct quote from draft-ietf-payload-rtp-howto, so it seems a bit
strange that the reviewer hadn't seen that one before.

The security section seems mostly to be a direct copy from
draft-ietf-payload-rtp-howto-00, including the lowercase "recommended".
I like the text in -14 better, so I'll suggest replacing the -00
boilerplate with the -14 boilerplate for the next version. (Any objections?)

We'll get there sooner or later...