Re: [avtext] Alia Atlas' Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS)

["Huangyihong (Rachel)" <[e-mail]>]

Hi Alia,

Thank you for raising the concerns. Please see my replies inline.

Rachel, as one of the author.

-----邮件原件-----
发件人: Alia Atlas [mailto:[e-mail]] 
发送时间: 2016年6月15日 6:00
收件人: The IESG
抄送: [e-mail]; [e-mail]; [e-mail]; [e-mail]
主题: Alia Atlas' Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS)

Alia Atlas has entered the following ballot position for
draft-ietf-avtext-splicing-notification-07: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I believe this is more  a discussion for the IESG.

First, this is way out of my area and I'm not particularly commenting on the details - but I do agree with Mirja's discuss about
"- The following action does not seem to be appropriate for a specification of an end-to-end protocol:
"And if the splicer wishes to prevent the downstream receivers from detecting splicing, it MUST
   NOT forward the message.""

[Rachel]: This is not a end-to-end protocol. These extended messages are intended to send to the splicer, which is the middle box expected to be able to modify RTCP messages. Discarding or modifying RTCP packets that don’t make sense for some participants is normal behaviour for RTP middle boxes. I understand the mormative language is kind of confusing here. We'll remove the normative language.

The full paragraph at the end of Sec 3.2 is: "When the splicer intercepts the RTCP splicing notification message,
   it SHOULD NOT forward the message to the down-stream receivers in
   order to reduce RTCP bandwidth consumption. And if the splicer wishes
   to prevent the downstream receivers from detecting splicing, it MUST
   NOT forward the message."

Even more specifically to me, superficially this seems to me to be a way to change what is in the stream that a receiver has requested or subscribed to without permission
or notification.   In that light,
the idea that the splicer is able to prevent downstream receivers from detecting the splicing does not sound good.

[Rachel]: As I said, this message is supposed to send to the splicer, not the receivers of the end user. When the splicer receives such messages, it'll do the splicing activity, which is to use the substitutive content replace the original content. When splicing interval ends, the splicer will change it back. It's usually used for advertisement insertion.  I do find the word "intercepts" here is improper and confusing. How about using "receives"?

Similarly, the end of Sec 3.1 says "After the splicer intercepts the RTP header extension and derives the
   Splicing Interval, it will generate its own stream and SHOULD NOT
   include the RTP header extension in outgoing packets to reduce header
   overhead."

This looks like another example of making the choice to hide information from the receiver.

[Rachel]: Please see above.

I realize that there is probably an technical arms-race going on - of inserting advertisements and building receivers to block undesired advertisements.  I am  not seeing a balanced solution that considers the receivers as well as the senders.

[Rachel]: On the contrary, it's a method used in IPTV services, that service provider inserts different advertisements to different users. It's totally not blocking or hiding something. Sometime the service provider don't want the end users to detect the advertisement inserting. That's why the splicing interval are not forwarded to the receivers.

I am startled that there is no consideration of the impact of this extension on the receivers in the security considerations.

The only reference I see in the Security Considerations further assumes that it is appropriate to have an undetectable splicing.

" A malicious endpoint may also break an undetectable splicing. To
   mitigate this effect, the splicer SHOULD NOT forward the splicing
   time information RTP header extension defined in Section 4.1 to the
   receivers. And it MUST NOT forward this header extension when
   considering an undetectable splicing. "

At a minimum, I feel like there should be a very clear consideration of the pros and cons - including from the viewpoint of a receiver. 

If we end up with this biased technology, then it should be clearly stated
- not hidden in assumptions.