Re: [avtext] Proposed text for Alia and other AD's DISCUSS

[Alia Atlas <[e-mail]>]

This is useful clarification, but it still contains no hint that the
receiver has agreed.  It doesn't
alter the SHOULD or MUSTs associated with hiding this from receivers.

I am looking for a balanced explanation - the motivations here give me more
than heartburn.
It's clearly deciding for the content provider.

Regards,
Alia

On Tue, Jun 21, 2016 at 3:32 PM, Ben Campbell <[e-mail]> wrote:

> Hi, some comments inline:
>
> On 21 Jun 2016, at 7:58, Huangyihong (Rachel) wrote:
>
> Hi All,
>>
>> Here's my proposal for addressing Alia's and other AD's similar DISCUSS.
>> The main idea is to add a new subsection in Section 2, which is showed as
>> following:
>>
>> "
>> 2.1 Overview of RTP Splicing
>>
>>    RTP Splicing is to replace some multimedia content with certain
>>    substitutive multimedia content, and then forward it to the receivers
>>    for a period of time. This process is authorized by the service
>>    provider who sends the multimedia content to these receivers. A
>>    typical usage is that IPTV service providers use their own regional
>>    advertising content to replace national advertising content provided
>>    by the content providers.
>>
>
> I think this could be strengthened a bit. IIUC, this mechanism assumes the
> splicing interval is sent _by_ the main content provider. That is, this
> mechanism only works with the permission of the content provider. If they
> don't consent, they simply won't send the splicing interval.
>
> This relationship might be more clear if the example talked about the main
> content provider offering a time window for the regional advertising
> insert, rather than about replacing national advertising. While that might
> in fact replace national content, it should be clear that the main provider
> _intends_ for the insert to happen.
>
>
>>    The splicer is a middlebox handling RTP splicing. It receives main
>>    content and substitutive content simultaneously but only chooses to
>>    send one of them to the receiver at any point of time. When RTP
>>    splicing begins, the splicer sends the substitutive content to the
>>    receivers instead of the main content. When RTP splicing ends, the
>>    splicer switches back to sending the main content to the receivers.
>>
>>    The middle box working as the splicer is either a translator or a
>>    mixer. [RFC6828] specifies a splicer implemented as a mixer that uses
>>    its own SSRC, sequence number space, and timing model when generating
>>    the output stream to receivers. The mixer must not insert the SSRC of
>>    the main RTP stream or the SSRC of the substitutive RTP stream into
>>    the contributing source (CSRC) list in the output media stream when
>>    implementing undetectable splicing.
>>
>
> I suggest promoting that last sentence a bit, and removing any hint of
> 2119 language. For example:
>
> "The splicer, operating on behalf of the content provider, may not wish to
> reveal that splicing has occurred. In this case, the splicer does not
> insert the SSRCs from either the main or substitutive RTP streams into the
> CSRC list in the resulting output media stream.."
>
> Since it works as the mixer, it
>>    splits the RTCP flow between the sender and receiver into two
>>    separate RTCP loops. This implies additional considerations should be
>>    taken into account when handling congestion control, see Section 4.4
>>    of [RFC6828].
>>
>>    A translator [RFC3550] can also be a splicer by forwarding the RTP
>> packets with
>>    their SSRCs intact, where the congestion control runs between
>>    original sender and receiver, or between substitutive sender and
>>    receiver. In such a case, the RTCP feedback message must be passed to
>>    the right sender to let the congestion control work. And undetectable
>>    splicing will not be fulfilled when the translator works as the
>>    splicer.
>> "
>>
>> Besides that, a new terminology is defined in section 1.1 to define
>> "Undetectable Splicing", see below:
>>
>> "
>> Undetectable Splicing:
>>
>> The RTP receivers are not able to detect any splicing points in the RTP
>> layer. Sometimes, service providers may require an undetectable splicing to
>> avoid the RTP receivers from filtering out the advertisement content.
>>
>
> That particular motivation gives me a bit of heartburn. But I think the
> reality is that the content provider wants to provide an apparently
> continuous stream, and they don't think the the splicing details are the
> business of the recipient (any more than the splices that occur in the
> original media stream incident to the normal editing of the content.)
>
>
>
>> "
>>
>> Your further thoughts or comments are welcomed. We'll bring a new version
>> as soon as consensus is achieved.
>>
>> BR,
>> Rachel
>>
>>
>> -----Original Message-----
>>> From: [e-mail]
>>> [mailto:[e-mail]]
>>> Sent: Monday, June 20, 2016 9:14 PM
>>> To: Mirja Kuehlewind (IETF)
>>> Cc: Colin Perkins; [e-mail];
>>> [e-mail]; [e-mail]; The
>>> IESG;
>>> [e-mail]
>>> Subject: Re: [avtext] Kathleen Moriarty's No Objection on
>>> draft-ietf-avtext-splicing-notification-07: (with COMMENT)
>>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On Jun 20, 2016, at 5:29 AM, Mirja Kuehlewind (IETF) <
>>>> [e-mail]>
>>>>
>>> wrote:
>>>
>>>>
>>>> Hi Colin,
>>>>
>>>> see below.
>>>>
>>>> Am 16.06.2016 um 00:34 schrieb Colin Perkins <[e-mail]>:
>>>>>>
>>>>>> On 15 Jun 2016, at 19:37, Kathleen Moriarty
>>>>>>
>>>>> <[e-mail]> wrote:
>>>
>>>>
>>>>>> Kathleen Moriarty 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-notifica
>>>>>> tion/
>>>>>>
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>> --
>>>>>> COMMENT:
>>>>>> --------------------------------------------------------------------
>>>>>> --
>>>>>>
>>>>>> I strongly support Mirja's and Alia's discuss points and would like
>>>>>> to see more of a discussion of the capability to hide splicing in
>>>>>> the security considerations text.  My ballot would be discuss, but
>>>>>> they pulled out the relevant sections and that would be duplication.
>>>>>> I'd like to review agreed upon text though to address these concerns.
>>>>>>
>>>>>> I don't like the idea of enabling a MiTM, but do see the draft talks
>>>>>> about how to protect headers when this happens and confidentiality
>>>>>> is needed as well as session protection between the endpoints and
>>>>>> the splicer (which I don't like either, but you do call out the
>>>>>> security considerations of this and that's what is needed).
>>>>>>
>>>>>
>>>>> The mechanism described doesn’t work unless the receiver explicitly
>>>>>
>>>> chooses to receive media content delivered via the splicer. I agree
>>> that the
>>> draft could be more clearly written, but it doesn’t seem to be “enabling
>>> a
>>> MiTM” attack, since the receiver opts in.
>>>
>>>>
>>>> This definitely need from clarification in the draft!
>>>>
>>>
>>> Yes, can we see some proposed text?
>>>
>>> Thank you,
>>> Kathleen
>>>
>>>>
>>>> Mirja
>>>>
>>>>
>>>>
>>>>> --
>>>>> Colin Perkins
>>>>> https://csperkins.org/
>>>>>
>>>>
>>>>