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

["Roni Even" <[e-mail]>]

Hi Alia,
I am not sure what you mean by "the receiver has agreed" agreed to what.
The receiver asked for content and he receives the content. Part of it is advertisements that are spliced in the stream.
The only consent I can think of may be in the application layer that may tell that this content include advertisements.  
What is hidden from the receiver is that some content is spliced in.
BTW: changing the content midstream without notifying the receiver can be done by any RFC3550 RTP mixer and this is why we have the reference to RFC7557.
Roni Even

> -----Original Message-----
> From: Alia Atlas [mailto:[e-mail]]
> Sent: Wednesday, June 22, 2016 12:36 AM
> To: Ben Campbell
> Cc: Huangyihong; [e-mail]; Mirja Kuehlewind;
> Alissa Cooper; Colin Perkins; [e-mail]; draft-ietf-avtext-
> [e-mail]; [e-mail]; The IESG;
> [e-mail]
> Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS
> 
> 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-notif
> >>>>>> ica
> >>>>>> 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 concern