Re: [avtext] Alissa Cooper's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT)

"Ben Campbell" <ben@nostrum.com> Thu, 16 June 2016 00:25 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: avtext@ietfa.amsl.com
Delivered-To: avtext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E711C12DB7C; Wed, 15 Jun 2016 17:25:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=unavailable 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 ivZT8MQecFB3; Wed, 15 Jun 2016 17:25:22 -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 AAFF812DA3C; Wed, 15 Jun 2016 17:25:22 -0700 (PDT)
Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5G0PCWp033087 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 15 Jun 2016 19:25:13 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4]
From: Ben Campbell <ben@nostrum.com>
To: Huangyihong <rachel.huang@huawei.com>
Date: Wed, 15 Jun 2016 19:25:19 -0500
Message-ID: <61F2E237-E6D9-472A-84FB-49EBA6EDC7A8@nostrum.com>
In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86ED6597@nkgeml513-mbx.china.huawei.com>
References: <20160614192411.19187.22192.idtracker@ietfa.amsl.com> <51E6A56BD6A85142B9D172C87FC3ABBB86ED6597@nkgeml513-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <https://mailarchive.ietf.org/arch/msg/avtext/hUFe1Ss0tnIdF5oWmfxmH2yYcJQ>
Cc: "jonathan@vidyo.com" <jonathan@vidyo.com>, "avtext@ietf.org" <avtext@ietf.org>, "avtext-chairs@ietf.org" <avtext-chairs@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-avtext-splicing-notification@ietf.org" <draft-ietf-avtext-splicing-notification@ietf.org>
Subject: Re: [avtext] Alissa Cooper's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT)
X-BeenThere: avtext@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Extensions working group discussion list <avtext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avtext>, <mailto:avtext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avtext/>
List-Post: <mailto:avtext@ietf.org>
List-Help: <mailto:avtext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avtext>, <mailto:avtext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jun 2016 00:25:24 -0000

On 15 Jun 2016, at 14:45, Huangyihong (Rachel) wrote:

> What is undetectable splicing?
>
> [Rachel]: Undetectable splicing means that the RTP receivers should 
> not be able to detect any splicing points in the RTP layer. It is 
> required in some cases, for example, an IPTV advertisement user case, 
> the service provider may want to make it difficult for the RTP 
> receiver to detect where an advertisement insertion is starting or 
> ending from the RTP packets, and thus avoiding the RTP receiver from 
> filtering out the advertisement content.

Since several people have expressed concerns here, I wonder if it would 
be helpful to have some text about trust and content models. I _think_ 
that the typical use case will be one where the splicer is operating on 
behalf of the content provider. In that case, one could think of the 
post-splicing RTP stream as the the final content being provided. One 
could reasonably argue that the knowledge of how that stream was 
composed is private to the provider, and not the business of the final 
recipient.

On the other hand, a splicer that does not operate on behalf or (or at 
least with the permission of) of the content provider or recipient would 
be egregious, even if it did not hide the splicing interval data.