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

"Ben Campbell" <ben@nostrum.com> Wed, 23 September 2015 12:31 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 C5C901B29C6 for <payload@ietfa.amsl.com>; Wed, 23 Sep 2015 05:31: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 FalFjMk5n_-E for <payload@ietfa.amsl.com>; Wed, 23 Sep 2015 05:31: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 2B4B51B29CF for <payload@ietf.org>; Wed, 23 Sep 2015 05:31: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 t8NCUt4i004681 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 23 Sep 2015 07:31:06 -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: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 23 Sep 2015 07:30:55 -0500
Message-ID: <F08D19CF-6C0A-4B4C-A396-038660244981@nostrum.com>
In-Reply-To: <56025428.4030106@alvestrand.no>
References: <CAOhzyf=qB9MNQO6=AjC8OArrxcC8zDwsOa_RdF2aV-3jwmHLCw@mail.gmail.com> <05DD07CB-26A5-4D07-9605-86C7D321B093@nostrum.com> <658F1EF8-8933-43E7-ADDF-173904FE60A2@csperkins.org> <55F1AEC9.6050408@alvestrand.no> <4D9392D8-4790-41EB-9FC6-B7CC98895E10@nostrum.com> <560190B1.3040400@alvestrand.no> <88518539-9321-4616-A84F-736A1C9D2256@csperkins.org> <71734E21-F414-42AD-995F-384A8A719D4C@alvestrand.no> <23B4B22E-DC89-4BC0-9F9D-404379C8CA28@csperkins.org> <56023B71.8080309@alvestrand.no> <6841FC81-0D81-479F-ACBC-4C56D1C55247@csperkins.org> <56025428.4030106@alvestrand.no>
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/cbsbwrY_Aki5Mh0bK7b7hn8oqfI>
Cc: Colin Perkins <csp@csperkins.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, 23 Sep 2015 12:31:17 -0000

On 23 Sep 2015, at 2:26, Harald Alvestrand wrote:

> On 09/23/2015 09:14 AM, Colin Perkins wrote:
>>> On 23 Sep 2015, at 06:41, Harald Alvestrand <harald@alvestrand.no> 
>>> wrote:
>>>
>>> On 09/22/2015 11:00 PM, Colin Perkins wrote:
>>>> Remind me?
>>> Suggested text (suggested in a way that was a bit hard to follow):
>>>
>>> "Payload Type (PT): The assignment of an RTP payload type for this 
>>> packet format is outside the scope of this document and will not be 
>>> specified here."
>>> I’m all for separation of concerns.
>> Yes, that works for me.
>>
>> Colin
>>
> Ben, based on the set of threads until now - can we publish an updated
> draft with this single change without revisiting the IESG, or would 
> you
> prefer to handle this by an RFC Editor note?
>
> I don't think there are any other changes that we all agree on are
> improvements that matter.

Let's do the RFC Editor note.

Do I understand correctly that this replaces the "Payload Type" 
definition in section 4.1 in it's entirety? That is:

OLD:
Payload type (PT):  In line with the policy in Section 3 of
       [RFC3551], applications using the VP8 RTP payload profile MUST
       assign a dynamic payload type number to be used in each RTP
       session and provide a mechanism to indicate the mapping.  See
       Section 6.2 for the mechanism to be used with the Session
       Description Protocol (SDP) [RFC4566].
NEW:
Payload Type (PT): The assignment of an RTP payload type for this packet
       format is outside the scope of this document and will not be
       specified here."
END:


Ben.