IETF Logo Mail Archive

Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT)

Adam Roach <adam@nostrum.com> Tue, 10 October 2017 22:01 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAF6124B17; Tue, 10 Oct 2017 15:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 o-S4GxwvzCsB; Tue, 10 Oct 2017 15:01:11 -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 4E9211241F3; Tue, 10 Oct 2017 15:01:11 -0700 (PDT)
Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v9AM14Sf033541 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Oct 2017 17:01:06 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at
To: Ben Campbell <ben@nostrum.com>, "Ali C. Begen" <ali.begen@networked.media>
Cc: Thomas Edwards <Thomas.Edwards@fox.com>, "payload-chairs@ietf.org" <payload-chairs@ietf.org>, "payload@ietf.org" <payload@ietf.org>, "draft-ietf-payload-rtp-ancillary@ietf.org" <draft-ietf-payload-rtp-ancillary@ietf.org>, The IESG <iesg@ietf.org>, Colin Perkins <csp@csperkins.org>
References: <150285025423.12514.106587665039751833.idtracker@ietfa.amsl.com> <863974D7-E112-4794-AD4D-C39C99BD40C9@foxeg.com> <b601dc36-8aee-75db-7159-6d4d5b6e684e@nostrum.com> <0C6F1364-DAB5-4AA3-8450-84771EF0ED1E@foxeg.com> <deb11f6f-3e21-df5d-1391-fc20bad88ce4@nostrum.com> <AD92A1F3-5B6F-4D49-BC47-3E662B6673F7@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810BB8@DGGEMM506-MBX.china.huawei.com> <37F6B554-530B-4A30-B66F-A70D026DD2B8@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810CC5@DGGEMM506-MBX.china.huawei.com> <04D71781-0E87-461C-BDA0-D44F94FED1A0@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD810D79@DGGEMM506-MBX.china.huawei.com> <7574DE41-96BB-45C1-8279-F9E2460E0452@csperkins.org> <6E58094ECC8D8344914996DAD28F1CCD81103C@DGGEMM506-MBX.china.huawei.com> <7D009531-3DB3-4923-80B2-38BC3F9FB020@foxeg.com> <D5102BCB-1AF9-4568-B416-443400226A9B@nostrum.com> <CAA4Mczu=REes--g_5BNBdSQg4as-b-99V9qeZTcp8fuR_66Dig@mail.gmail.com> <D8C20B8D-281E-4571-A230-F6D103241553@nostrum.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <805546c9-c059-20ad-57ac-55767ffb5fc5@nostrum.com>
Date: Tue, 10 Oct 2017 17:01:04 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <D8C20B8D-281E-4571-A230-F6D103241553@nostrum.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/c3DzccN-1073zP3jwpqF7a0F5mI>
Subject: Re: [payload] Adam Roach's Discuss on draft-ietf-payload-rtp-ancillary-10: (with DISCUSS and COMMENT)
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 10 Oct 2017 22:01:14 -0000

On 10/10/17 4:56 PM, Ben Campbell wrote:
>
>> On Oct 10, 2017, at 4:40 PM, Ali C. Begen <ali.begen@networked.media> wrote:
>>
>> Hi Ben
>>
>> On Tue, Oct 10, 2017 at 11:59 PM, Ben Campbell <ben@nostrum.com> wrote:
>> My takeaways from the discussion so far:
>>
>> 1)  LS doesn’t work, at least not cleanly.
>> 2)  FID would work, but there are philosophical objections.
>> 3)  People don’t want to create a new grouping semantic.
>>
>> So unless people want to argue that LS really does work, even in the case of Adam’s multi-stream example, I think we are left choosing between FID or creating something new. If people don’t like FID, is creating something new (maybe a “metadata” semantic) that hard?
>>
>> Yes, this is where we are. LS does not work, I agree. I believe FID works as the language in the RFC does not bother me because whoever needs to work with ANC data knows how to deal with it anyway. So bottomline is I am ready to ship this with FID. If that is absolutely not acceptable to Thomas or others, the only option is to define a new grouping semantics, which is not a significant work but needs blessing from MMUSIC.
> The IANA registration policy for the group semantics table is “standards action”. It needs a standards track RFC, but I am not aware of a requirement for that to come from MMUSIC. The most recent one came from AVTEXT. I agree that we would want a new semantic to be at least reviewed in MMUSIC. But I don’t think we are talking about all that much text to add.
>
> FID would still be easier, though.  :-)

To be clear, I absolutely agree that FID would be cleaner.

/a

v2.23.0 | Report a Bug | By Email