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

From: "Alissa Cooper" <[email-masked]>
Date: Tue, 14 Jun 2016 12:24:11 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-avtext-splicing-notification-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

= Section 4 =

"Either the main RTP sender or the
   substitutive sender SHOULD send the synchronization metadata early
   enough so that the receivers can play out the multimedia in a
   synchronized fashion."

In Section 2 you gave a guideline for how to figure out how far in
advance to send the splicing information. I think a similar guideline
would be useful here.

s/e.g., choosing media sender/e.g., choosing main RTP sender/

= Section 7 =

What is undetectable splicing?

= Section 8.3 =

In the past when we've registered these there was no contact I don't
think. Not sure what IANA would do with one here.

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 15 Jun 2016 19:45:31 +0000

Hi Alissa,

Thank you for the comments. Please see my replies inline.

BR,
Rachel, as one of the authors.

-----邮件原件-----
发件人: Alissa Cooper [mailto:[email-masked]] 
发送时间: 2016年6月15日 3:24
收件人: The IESG
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Alissa Cooper's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

= Section 4 =

In Section 2 you gave a guideline for how to figure out how far in advance to send the splicing information. I think a similar guideline would be useful here. 

[Rachel]: Good point. I agree. So I suggest to add following sentences after the words you quoted.

"The main RTP sender or the substitutive sender can estimate when to send the synchronization metadata based on, for example, the round-trip time (RTT) following the
 mechanisms in section 6.4.1 of [RFC3550] when the splicer sends RTCP RR to the main sender or the substitutive sender.
"

[Rachel]: Okay.

= Section 7 =

[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.

= Section 8.3 =

In the past when we've registered these there was no contact I don't think. Not sure what IANA would do with one here.

[Rachel]: We'll remove the contact.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 15 Jun 2016 19:25:19 -0500

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

> [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.

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 16 Jun 2016 06:40:34 +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:[email-masked]] 
发送时间: 2016年6月16日 8:25
收件人: Huangyihong (Rachel)
抄送: Alissa Cooper; The IESG; [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: Alissa Cooper's No Objection on draft-ietf-avtext-splicing-notification-07: (with COMMENT)

> 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.