Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Tue, 08 October 2019 19:30 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA1512013B; Tue, 8 Oct 2019 12:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 IHme0tA1l6kr; Tue, 8 Oct 2019 12:30:47 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D701120100; Tue, 8 Oct 2019 12:30:45 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x98JUYdj002945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 8 Oct 2019 15:30:37 -0400
Date: Tue, 08 Oct 2019 12:30:34 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Roni Even (A)" <roni.even@huawei.com>
Cc: "victor.demjanenko@vocal.com" <victor.demjanenko@vocal.com>, 'The IESG' <iesg@ietf.org>, "draft-ietf-payload-tsvcis@ietf.org" <draft-ietf-payload-tsvcis@ietf.org>, 'Ali Begen' <ali.begen@networked.media>, "avtcore-chairs@ietf.org" <avtcore-chairs@ietf.org>, "avt@ietf.org" <avt@ietf.org>, "'Dave Satterlee (Vocal)'" <Dave.Satterlee@vocal.com>
Message-ID: <20191008193034.GJ76545@kduck.mit.edu>
References: <157007038502.8860.1558861534319247512.idtracker@ietfa.amsl.com> <001601d57af9$405efcf0$c11cf6d0$@vocal.com> <6E58094ECC8D8344914996DAD28F1CCD23D79BC0@DGGEMM506-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD23D79BC0@DGGEMM506-MBX.china.huawei.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/EBVUZsagbwTkKoZoDBfFHqLy3Ho>
Subject: Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Oct 2019 19:30:50 -0000
On Sun, Oct 06, 2019 at 06:08:51AM +0000, Roni Even (A) wrote: > Hi, > About the reference to TSVCIS. > The RTP payload is about how to encapsulate the payload in an RTP packet. The objective is to define how an RTP stack can insert the tsvcis frames and extract the tsvcis frames from the RTP packet. Typically it is not required to understand the payload structure in order to be able to perform the encapsulation. > This is why the reference to the payload is Informational and we did not require to have it publically available. If there is a need to understand the payload itself for the encapsulating than we need more information in the RTP payload specification and a publically available normative reference. I think this is not the case here I for the most part agree with you, but the current draft is saying that TSVCIS is going to give the encoder "some parameters" and the draft specifies a way to pack those parameters into a byte encoding. We don't have enough information to decode that encoding without some canonical ordered list of parmeters that gives a mapping from encoded bytestream length to which parameters are to be extracted. It feels like something best done as "TSVCIS gives us an opaque octet string that we blindly transport", but that doesn't seem to be the case. -Ben
- [AVTCORE] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk via Datatracker
- Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-i… victor.demjanenko
- Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-i… Roni Even (A)
- Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-i… victor.demjanenko
- Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-i… victor.demjanenko
- Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-i… Barry Leiba
- Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-i… victor.demjanenko
- Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-i… Barry Leiba
- Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-i… victor.demjanenko
- Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk
- Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-i… Barry Leiba
- Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-i… victor.demjanenko
- Re: [AVTCORE] Benjamin Kaduk's Discuss on draft-i… Benjamin Kaduk