IETF Logo Mail Archive

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

"Huangyihong (Rachel)" <rachel.huang@huawei.com> Thu, 16 June 2016 06:40 UTC

Return-Path: <rachel.huang@huawei.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 4818F12D548; Wed, 15 Jun 2016 23:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.647
X-Spam-Level:
X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 Mbod_XNfc9aD; Wed, 15 Jun 2016 23:40:46 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818D612B026; Wed, 15 Jun 2016 23:40:45 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMA84764; Thu, 16 Jun 2016 06:40:43 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 16 Jun 2016 07:40:42 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 16 Jun 2016 14:40:34 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: Ben Campbell <ben@nostrum.com>
Thread-Topic: Alissa Cooper's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT)
Thread-Index: AQHRxnJX1qlwdj/5d0ytJlTWc1T4HZ/q6rcQ///NZ4CAAOp7kA==
Date: Thu, 16 Jun 2016 06:40:34 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86ED6715@nkgeml513-mbx.china.huawei.com>
References: <20160614192411.19187.22192.idtracker@ietfa.amsl.com> <51E6A56BD6A85142B9D172C87FC3ABBB86ED6597@nkgeml513-mbx.china.huawei.com> <61F2E237-E6D9-472A-84FB-49EBA6EDC7A8@nostrum.com>
In-Reply-To: <61F2E237-E6D9-472A-84FB-49EBA6EDC7A8@nostrum.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.93.84]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.576249EC.002B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 6bfd8513bdc373fe85f13b3a52e0b4dd
Archived-At: <https://mailarchive.ietf.org/arch/msg/avtext/OFfO2toUu_R2tSIINtpeD_mrcyg>
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 06:40:48 -0000

Hi Ben,

It seems we do lack such clarifications in the draft, which may lead to some misunderstanding. We'll address this in the updated version. Thanks.

BR,
Rachel

-----邮件原件-----
发件人: Ben Campbell [mailto:ben@nostrum.com] 
发送时间: 2016年6月16日 8:25
收件人: Huangyihong (Rachel)
抄送: Alissa Cooper; The IESG; draft-ietf-avtext-splicing-notification@ietf.org; avtext@ietf.org; jonathan@vidyo.com; avtext-chairs@ietf.org
主题: Re: Alissa Cooper's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT)

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.

v2.23.0 | Report a Bug | By Email