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