Re: [payload] New version of draft-ietf-payload-vp8

"Ben Campbell" <ben@nostrum.com> Wed, 09 September 2015 22:18 UTC

Return-Path: <ben@nostrum.com>
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 9FCEC1B2BE1 for <payload@ietfa.amsl.com>; Wed, 9 Sep 2015 15:18:17 -0700 (PDT)
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 k7jhvsf9OqPA for <payload@ietfa.amsl.com>; Wed, 9 Sep 2015 15:18:16 -0700 (PDT)
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 3878F1B2ABD for <payload@ietf.org>; Wed, 9 Sep 2015 15:18:16 -0700 (PDT)
Received: from [10.0.1.23] (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 t89MI1HZ006905 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 9 Sep 2015 17:18:11 -0500 (CDT) (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.23]
From: Ben Campbell <ben@nostrum.com>
To: Henrik Lundin <hlundin@google.com>
Date: Wed, 09 Sep 2015 17:18:00 -0500
Message-ID: <61C9844E-0751-4319-9F06-8303EA9B1318@nostrum.com>
In-Reply-To: <CAOhzyf=qB9MNQO6=AjC8OArrxcC8zDwsOa_RdF2aV-3jwmHLCw@mail.gmail.com>
References: <CAOhzyf=qB9MNQO6=AjC8OArrxcC8zDwsOa_RdF2aV-3jwmHLCw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.2r5107)
Archived-At: <http://mailarchive.ietf.org/arch/msg/payload/RYUNBcGCv5-v6is20h54CfXDBOA>
Cc: draft-ietf-payload-vp8@tools.ietf.org, payload@ietf.org
Subject: Re: [payload] New version of draft-ietf-payload-vp8
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, 09 Sep 2015 22:18:17 -0000

Hi,

Thanks for submitting this. I plan to put it on the agenda for the 
September 17 telechat.

In the interim, I had a few comments when you sent me the diff a while 
back that I think still apply (copied below for reference) I sent a 
separate email to the payload list point out the changes to 2119 
language.

Thanks!

Ben.

>
> This revision makes changes to normative language. Please make sure 
> those changes are mentioned on the working group list with enough time 
> for anyone to object prior to final approval. (This doesn't 
> necessarily need a WGLC unless the chairs wish it, but people should 
> at least see the changes and have a few days to complain if they don't 
> like it.)
>
>
> -- section 3, Payload Type: "... the VP8 RTP payload profile MUST 
> assign a dynamic payload type number ..."
>
> If I read correctly, Colin Perkins objected to this change. Did you 
> consider his objection?
>
> -- 4.2
>
> I didn't see anything addressing Elwyn's Gen-ART review question 
> about: “What happens if L=1 but both T=0 and K=0 so that there is no 
> TID value present? Or indeed if T=0 but K=1 so that the TID field is 
> there but 'MUST be ignored by the receiver'  (definition of TID 
> field)?” Did I miss something?
>



On 9 Sep 2015, at 16:01, Henrik Lundin wrote:

> Payload WG:
>
> After the second Last Call, we have done a review of the document 
> against
> the comments that were pointed out to us on this document and on 
> previous
> versions of the document.
>
> We have made no technical changes to the document, but have added a 
> number
> of grammar updates and clarifications. Some of the important 
> clarifications
> are as follows:
>
> We have added a number of definitions that were previously only in
> referenced documents.
>
> With regard to indexes that start at random numbers and wrap, we’ve
> switched to consistently using “wrap”. The text about not starting 
> at zero
> is just to say that starting at zero is not required; there is no 
> security
> benefit that we know of.
>
> We have removed some material that was repeated from RFC 6386; it was 
> clear
> that the explanation copied up was not sufficient for understanding, 
> and we
> found it better to refer to the more complete specification in RFC 
> 6386 for
> that material.
>
> The definition of the Y-bit and structure of temporal layers has been
> strengthened.
>
> SLI and RPSI have been explained with more links back to RFC 4585.
>
> We note that the text about pathological data noted in the sec-dir 
> review
> comes from the RTP HOWTO - we have updated the copied text to be 
> consistent
> with version -14 of the RTP HOWTO draft.
>
> The Gen-ART review suggested to add a definition of temporal base 
> layer. We
> added an informal reference to an article on scalable video coding, 
> and
> think that the general definitions of scalability found therein apply 
> to
> this draft too.
>
> The Gen-ART review also suggested that the VER field in the VP8 
> Payload
> Header should be validated by the depacketizer. We disagree with this, 
> and
> argue that the VER field should be verified by the VP8 decoder.
>
> For minor updates, please refer to the diff at
> https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-17.
>
> With this update, we believe the document is ready for publication.
>
> Sincerely,
> /Henrik
>
> -- 
> Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 
> 13 41