Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-03.txt

From: "Ben Campbell" <[email-masked]>
Date: Mon, 14 Dec 2015 20:12:59 -0600

Hi Rachel,

Apologies, I missed your email about the update until this afternoon.

In general, I don't think you have completely succeeded in removing the 
need for a normative dependency on RFC 6828. There is text that says a 
splicer can be a 6828 mixer, but there's no provision for cases where it 
is not. That text needs clarification to say that 6828 is an example of 
how one might do splicing, but other approaches would still need the 
splicing interval information, and can still use this draft.

1.1:

This section still depends on 6828 for terminology.  If that terminology 
is required to understand this draft, then you still need a normative 
dependency. If you wish to avoid that, you will need to define the terms 
in this draft.

- section 2:

-- general:  I'm still not entirely comfortable with the assumption of 
the existence of a way to get the interval to the substitutive source. 
Yes, there may be proprietary interfaces, or the substitutive source 
could be integrated with either the main source or the splicer. But do 
such interfaces already exist? Are we expecting people to do something 
they aren't already doing? It comes down to the question, do you think 
people will deploy this solution if we don't define the other part?

I assume the answer is yes, in which case it would be useful to have 
some text about _why_ we think this is useful without a standardized 
"source to substitutive source" interface. It might also be worth 
considering why, if such things already exist, they can't also be used 
for the "source-to-splicer" interface.

-- paragraph 3: I see the new sentence about the clock depending on the 
codec. Does this mean the requirements for clock resolution and skew 
limits depend on the codec?

- 3.2:

Does "in-band NTP formatted timestamps" mean intervals sent in the RTP 
header extension?

- 5:
-- 3rd paragraph: The text "If a mixer works as the splicer [RFC6828] 
still seems to depend on RFC 6828 to define what a splicer is.

-- 4th paragraph: Am I correct to assume any such translation or 
reporting would be the responsibility of the mixer? Is the mixer 
expected to know if the senders want to detect problems?

-- 5th paragraph: This talks about the splicer detecting a failure. The 
previous paragraph talked about senders detecting failures. Is that an 
intentional shift in perspective? Do you really expect out-of-band 
signaling here, or is falling back to payload specific mechanisms or 
abandonment not more likely?

- 7:

-- 1st paragraph: This still depends on 6828 for security 
considerations. And now that we have the possibility that 6828 is _not_ 
used, what are there not similar considerations for whatever other 
mechanism is used? Since those are not documented elsewhere, they will 
need to be documented here.

-- 2nd paragraph: The text says that SRTP does not encrypt header 
extensions. But it can, as mentioned in paragraph 3.

-- 3rd paragraph: The phrase "To avoid invalid substitutive contents are 
inserted..." still does not make sense. Consider  "To avoid the 
insertion of invalid substitutive content..."

On 26 Nov 2015, at 21:10, Huangyihong (Rachel) wrote:

> Dear all,
>
> This new version aims to solve the comments during the AD review.
>
> BR,
> Rachel
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, November 27, 2015 11:00 AM
> To: Deng Lingli; Roni Even; Xiajinwei; Huangyihong (Rachel); Lingli 
> Deng
> Subject: New Version Notification for 
> draft-ietf-avtext-splicing-notification-03.txt
>
>
> A new version of I-D, draft-ietf-avtext-splicing-notification-03.txt
> has been successfully submitted by Rachel Huang and posted to the IETF 
> repository.
>
> Name:		draft-ietf-avtext-splicing-notification
> Revision:	03
> Title:		RTP/RTCP extension for RTP Splicing Notification
> Document date:	2015-11-27
> Group:		avtext
> Pages:		18
> URL:            
> https://www.ietf.org/internet-drafts/draft-ietf-avtext-splicing-notification-03.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/
> Htmlized:       
> https://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-03
> Diff:           
> https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-splicing-notification-03
>
> Abstract:
> Content splicing is a process that replaces the content of a main
> multimedia stream with other multimedia content, and delivers the
> substitutive multimedia content to the receivers for a period of
> time. The splicer is designed to handle RTP splicing and needs to
> know when to start and end the splicing.
>
> This memo defines two RTP/RTCP extensions to indicate the splicing
> related information to the splicer: an RTP header extension that
> conveys the information in-band and an RTCP packet that conveys the
> information out-of-band.
>
>
>
>
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 15 Dec 2015 11:48:47 +0000

Hi Ben,

Please see my replies inline.

BR,
Rachel

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, December 15, 2015 10:13 AM
> To: Huangyihong (Rachel)
> Cc: [email-masked]
> Subject: Re: [avtext] New Version Notification for
> In general, I don't think you have completely succeeded in removing the need
> for a normative dependency on RFC 6828. There is text that says a splicer can
> be a 6828 mixer, but there's no provision for cases where it is not. That text
> needs clarification to say that 6828 is an example of how one might do splicing,
> but other approaches would still need the splicing interval information, and can
> still use this draft.

[Rachel]: Ok. Here are my proposal changes to address this issue:

  1. In section 1, 2nd paragraph. I'll remove the reference, and give some descriptions of the splicing scenario.
  2. Section 1.1 , I will define some necessary terms and remove the reference of 6828.
  3. I'll leave the references in section 2, 1st paragraph and section 5, 3rd paragraph as they are, because they are just described as examples.
  4. Section 7, I'll remove the reference. See the reply to the 7th comments.

What do you think?

> dependency. If you wish to avoid that, you will need to define the terms

[Rachel]: Ok. I will define some necessary terms and remove the reference of 6828 from section 1.1.

> for the "source-to-splicer" interface.

[Rachel]: In implementations, both substitutive RTP sender and RTP sender are all ISP servers and controlled by the same ISP. There's no business model that substitutive source will be provided by a 3rd-party due to security issues. That's why we think it could be a proprietary interface between 2 servers. However, for a splicer, it could be a network node, e.g., a mixer, implemented near end users, which may be provided by a different access network provider, and can forward different advertisements to different users. Standardizing this part will easily for operators to interact with these network nodes without complex proprietary negotiation between different parties.

Does it make sense to you? I can propose some texts if you think it's useful.

> limits depend on the codec?

[Rachel]: Yes. They depend on the encoder the application is using.
> Does "in-band NTP formatted timestamps" mean intervals sent in the RTP

[Rachel]: Yes.

> still seems to depend on RFC 6828 to define what a splicer is.

[Rachel]: How about the following changing:

" If a mixer works as the splicer as described in [RFC6828] and it follows [RFC3550], "

> expected to know if the senders want to detect problems?

[Rachel]: It's the responsibility of the splicer to detect a splicing failure. And if the senders want to detect problems is an implementation issue. When a mixer works as a splicer, it's easy because failure can be detected anyway as specified in [RFC6828]. When other middle boxes like translator work as splicer, they should consider such translation if the implementation requires the failure should be reported to the server. However, no such translations will not break the whole system. So we will specify it in this document.

> abandonment not more likely?

[Rachel]: It's always the splicer detecting a failure. The previous paragraph talks about how to make the senders learn the failure. This paragraph talks about when learning the failure, what they should do.
When learning the failure, there are 3 options here: one is to leave as it is. Two, the sender stops inserting any splicing intervals. Three, the sender negotiates with the splicer to fall back to payload specific mechanism. This negotiation is expected to be out-of-band signaling.

> need to be documented here.

[Rachel]: Good point. Actually, I think the splicer will be either a mixer of a translator. 

How about the following texts adding to Section 7 as the 2nd paragraph?

OLD
"
   The security considerations of the RTP specification [RFC3550] and
   the general mechanism for RTP header extensions [RFC5285] apply. If
   the RTP splicing mechanism described in [RFC6828] is in use, its
   security considerations also apply.
"

NEW
"
The security considerations of the RTP specification [RFC3550] and
   the general mechanism for RTP header extensions [RFC5285] apply. The splicer MUST either be a mixer or a translator, and has all the security considerations on these two standard RTP intermediaries. 
"
> extensions. But it can, as mentioned in paragraph 3.

[Rachel]: How about the following change:

OLD
"
   In Secure Real-time Transport Protocol (SRTP)[RFC3711], RTP header
   extensions are authenticated but not encrypted. For a malicious
   endpoint without the key, it can observe the splicing time in the RTP
   header, and it can intercept the substitutive content and even
   replace it with a different one if the substitutive stream does not
   use any security like SRTP and the splicer does not authenticate the
   main and substitutive content sources.
"

NEW
" 
Since the mechanism introduced in this document is not dependent on any RTP payload-level hints for finding the splicing in and out points, Secure Real-Time Transport Protocol (SRTP) [3711] can be used to provide confidentiality of the RTP payload while leaving the RTP header in the clear so that the splicer can still carry out splicing without keying materials. However, for a malicious endpoint without the key, it can observe the splicing time in the RTP header, and it can intercept the substitutive content and even replace it with a different one if the substitutive stream does not use any security like SRTP and the splicer does not authenticate the main and substitutive content sources. "

> insertion of invalid substitutive content..."

[Rachel]: Will change it.

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Mon, 21 Dec 2015 06:25:34 +0000

Hi Ben,

After some further considerations, some of the following proposals are updated. Please see inline.
I'll submit a new version if you agree with the changes.

BR,
Rachel

> From: Huangyihong (Rachel)
> Sent: Tuesday, December 15, 2015 7:49 PM
> To: 'Ben Campbell'
> Cc: [email-masked]
> Subject: RE: [avtext] New Version Notification for
> > In general, I don't think you have completely succeeded in removing
> > the need for a normative dependency on RFC 6828. There is text that
> > says a splicer can be a 6828 mixer, but there's no provision for cases
> > where it is not. That text needs clarification to say that 6828 is an
> > example of how one might do splicing, but other approaches would still
> > need the splicing interval information, and can still use this draft.
> 

[Rachel]: Maybe rephrasing it as RF6828 gives an example of how to do this for RTP, rather than just removing the reference entirely.
OLD:
"
   [SCTE35] provides a method that encapsulates the Splicing Interval
   inside the MPEG2-TS layer in cable TV systems. But in the RTP
   splicing scenario described in [RFC6828], the mixer designed as the
   splicer has to decode the RTP packets and search for the Splicing
   Interval inside the payloads. The need for such processing increases
   the workload of the mixer and limits the number of RTP sessions the
   mixer can support.
"

NEW:
"
   [SCTE35] provides a method that encapsulates the Splicing Interval
   inside the MPEG2-TS layer in cable TV systems. When transported in RTP, an middle box designed as the splicer to decode the RTP packets and search for the Splicing Interval inside the payloads is required. The middle box is either a translator or a mixer as described in [RFC6828]. The need for such processing increases the workload of the middle box and limits the number of RTP sessions the middle box can support.
"

>   3. I'll leave the references in section 2, 1st paragraph and section 5, 3rd
> paragraph as they are, because they are just described as examples.
> > This section still depends on 6828 for terminology.  If that
> > terminology is required to understand this draft, then you still need
> > a normative dependency. If you wish to avoid that, you will need to
> > define the terms in this draft.
> >
> 
> [Rachel]: In implementations, both substitutive RTP sender and RTP sender are
> all ISP servers and controlled by the same ISP. There's no business model that
> substitutive source will be provided by a 3rd-party due to security issues. That's
> why we think it could be a proprietary interface between 2 servers. However,
> for a splicer, it could be a network node, e.g., a mixer, implemented near end
> users, which may be provided by a different access network provider, and can
> forward different advertisements to different users. Standardizing this part will
> easily for operators to interact with these network nodes without complex
> proprietary negotiation between different parties.
> 

[Rachel]: After some discussions, we think it is still possible that substitutive RTP sender and main RTP sender are from different companies. These two companies may have some business relationship. So maybe a standard protocol for this interface would be good. However, it's okay not to have a standard one because this interface might convey extra information rather than just Splicing Interval. For example, some metadata about the stream of which the content is being substituted, or the end users information. This kind of information is proprietary and not something people want to standardize.

> 
> >
> >
> > -- paragraph 3: I see the new sentence about the clock depending on
> > the codec. Does this mean the requirements for clock resolution and
> > skew limits depend on the codec?
> 
> [Rachel]: It's the responsibility of the splicer to detect a splicing failure. And if
> the senders want to detect problems is an implementation issue. When a mixer
> works as a splicer, it's easy because failure can be detected anyway as
> specified in [RFC6828]. When other middle boxes like translator work as splicer,
> they should consider such translation if the implementation requires the failure
> should be reported to the server. However, no such translations will not break
> the whole system. So we will specify it in this document.
> 
> >
> > -- 5th paragraph: This talks about the splicer detecting a failure.
> > The previous paragraph talked about senders detecting failures. Is
> > that an intentional shift in perspective? Do you really expect
> > out-of-band signaling here, or is falling back to payload specific
> > mechanisms or abandonment not more likely?
> 
> [Rachel]: It's always the splicer detecting a failure. The previous paragraph
> talks about how to make the senders learn the failure. This paragraph talks
> about when learning the failure, what they should do.
> When learning the failure, there are 3 options here: one is to leave as it is. Two,
> the sender stops inserting any splicing intervals. Three, the sender negotiates
> with the splicer to fall back to payload specific mechanism. This negotiation is
> expected to be out-of-band signaling.
> 
> >
> > - 7:
> >
> > considerations. And now that we have the possibility that 6828 is
> > _not_ used, what are there not similar considerations for whatever
> > other mechanism is used? Since those are not documented elsewhere,
> > they will need to be documented here.
> 
>    the general mechanism for RTP header extensions [RFC5285] apply. The
> splicer MUST either be a mixer or a translator, and has all the security
> considerations on these two standard RTP intermediaries.
> "

[Rachel]: We think the previous proposal is not good enough. Please see following proposal

NEW
"
The security considerations of the RTP specification [RFC3550] and the general mechanism for RTP header extensions [RFC5285] apply. The splicer MUST either be a mixer or a translator, and has all the security considerations on these two standard RTP intermediaries. However, the splicer replaces some content with other content in RTP packet, thus breaking any RTP-level end-to-end security, such as source authentication and integrity protection.

Security goals to have source authentication all the way from the RTP main sender to the receiver through the splicer is not possible with splicing and any existing solutions. A new solution can theoretically be developed that enables indentifying the participating entities and what each provides, i.e., the different media sources, man and substituting, and the splicer providing the RTP-level integration of the media payloads in a common timeline and synchronization context.
"
And integrity protection is discussed in the text I proposed in previous mail for the next comment, plus the last 2 paragraphs of Section 6 in the draft.

> Since the mechanism introduced in this document is not dependent on any RTP
> payload-level hints for finding the splicing in and out points, Secure Real-Time
> Transport Protocol (SRTP) [3711] can be used to provide confidentiality of the
> RTP payload while leaving the RTP header in the clear so that the splicer can
> still carry out splicing without keying materials. However, for a malicious
> endpoint without the key, it can observe the splicing time in the RTP header,
> and it can intercept the substitutive content and even replace it with a different
> one if the substitutive stream does not use any security like SRTP and the
> splicer does not authenticate the main and substitutive content sources. "
> 

[Rachel]: This proposal will be the discussion for integrity protection issue.

> >
> > -- 3rd paragraph: The phrase "To avoid invalid substitutive contents
> > are inserted..." still does not make sense. Consider  "To avoid the
> > > has been successfully submitted by Rachel Huang and posted to the
> > > IETF repository.
> > >
> > https://www.ietf.org/internet-drafts/draft-ietf-avtext-splicing-notifi
> > cation-03.t
> > xt
> > > Status:

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 21 Dec 2015 18:51:17 -0600

Hi Rachel,

More comments inline:

Thanks!

Ben.

On 21 Dec 2015, at 0:25, Huangyihong (Rachel) wrote:

>> 1. In section 1, 2nd paragraph. I'll remove the reference, and give 
>> some
>> descriptions of the splicing scenario.
>
> [Rachel]: Maybe rephrasing it as RF6828 gives an example of how to do 
> this for RTP, rather than just removing the reference entirely.
> OLD:
> "
> inside the MPEG2-TS layer in cable TV systems. When transported in 
> RTP, an middle box designed as the splicer to decode the RTP packets 
> and search for the Splicing Interval inside the payloads is required. 
> The middle box is either a translator or a mixer as described in 
> [RFC6828]. The need for such processing increases the workload of the 
> middle box and limits the number of RTP sessions the middle box can 
> support.
> "
>

I don't see how this change addresses the issue. But this particular 
citation is not the main problem. By itself, it could be read as and 
informational. The bigger problems are in 1.1, where this draft says the 
terminology in 6828 applies to this document. Maybe you removed the use 
of that terminoligy, but 1.1 still says it applies. The Splicing 
Interval is still defined in terms of 6828.

The security considerations section removed the normative dependency by 
saying "If the...mechanisms applies...". But without the normative 
reference, I don't think the security considerations are complete. That 
is, the idea of splicing _in_general_ has security considerations 
documented in 6828. If you don't normatively depend on 6828, then they 
need to be normatively referenced from somewhere else, or they need to 
be described here.

>> 2. Section 1.1 , I will define some necessary terms and remove the 
>> reference
>> of 6828.
>> [Rachel]: Ok. I will define some necessary terms and remove the 
>> reference of
>> 6828 from section 1.1.
>>
>>> - section 2:
>>>
> [Rachel]: After some discussions, we think it is still possible that 
> substitutive RTP sender and main RTP sender are from different 
> companies. These two companies may have some business relationship. So 
> maybe a standard protocol for this interface would be good. However, 
> it's okay not to have a standard one because this interface might 
> convey extra information rather than just Splicing Interval. For 
> example, some metadata about the stream of which the content is being 
> substituted, or the end users information. This kind of information is 
> proprietary and not something people want to standardize.

Okay. Let's leave it that way for IETF last call, and see if anyone else 
comments on it.

>> [Rachel]: Yes. They depend on the encoder the application is using.

Then I suggest the following:
OLD:
The common reference clock depends on the codec the media content using.
NEW:
The requirements for the common reference clock (e.g. resolution, skew) 
depend on the codec used by the media content.

>>> Does "in-band NTP formatted timestamps" mean intervals sent in the 

I suggest:
OLD:
Whether the in-band NTP-format timestamps are included or not, the main 
RTP sender MUST send the RTCP splicing notification message to provide 
robustness in case of any splicing-unaware middlebox that might strip 
RTP header extensions.
NEW:
Whether or not the timestamps are included in the RTP header extension, 
the main RTP sender MUST send the RTCP splicing notification message. 
This provide robustness in the case where a middlebox strips RTP header 
extensions.

>> " If a mixer works as the splicer as described in [RFC6828] and it 
>> follows
>> [RFC3550], "

Let's back up on this a bit. A reference needs to be normative if a 
reader needs to read that reference to understand and/or implement the 
protocol. If a reader doesn't read 6828, they will probably not 
understand this paragraph. Is that important for understanding and 
implementing the draft in general? (I think it probably is at least 
somewhat important.) Can you restate the paragraph in a way that 
describes the concept even if the reader doesn't read 6828? (It's okay 
to use it as an example, as long as the reader can likely understand 
things without the example.)

>> the whole system. So we will specify it in this document.

Okay. Also, I suspect most splicers will not care whether the sender 
needs the reports; they will either translate this or not (maybe as a 
configurable option). I suggest removing "if the senders want to detect 
splicing problems."

>> expected to be out-of-band signaling.

Okay.

>> [Rachel]: Good point. Actually, I think the splicer will be either a 
>> mixer of a
>> translator.
>>
> The security considerations of the RTP specification [RFC3550] and the 
> general mechanism for RTP header extensions [RFC5285] apply. The 
> splicer MUST either be a mixer or a translator, and has all the 
> security considerations on these two standard RTP intermediaries. 
> However, the splicer replaces some content with other content in RTP 
> packet, thus breaking any RTP-level end-to-end security, such as 
> source authentication and integrity protection.

This paragraph is helpful. Can you include a reference for "mixer" and 
"translator"? (I think this will be the first mention of "translator", 
and I'm not sure "mixer" has a reference or definition elsewhere in the 
draft.)
>
> Security goals to have source authentication all the way from the RTP 
> main sender to the receiver through the splicer is not possible with 
> splicing and any existing solutions. A new solution can theoretically 
> be developed that enables indentifying the participating entities and 
> what each provides, i.e., the different media sources, man and 
> substituting, and the splicer providing the RTP-level integration of 
> the media payloads in a common timeline and synchronization context.

This is on the right track. For the first sentence, I suggest:
"End to end source authentication is not possible with any known 
existing splicing solution."

I'm not quite sure what properties you have in mind for the theoretical 
new solution. Also, does the work in PERC offer any value here?

> "
> And integrity protection is discussed in the text I proposed in 
> previous mail for the next comment, plus the last 2 paragraphs of 
> Section 6 in the draft.
>
>>>
>> header,

Does this assume both sources use the same SRTP key, or that the 
receiving endpoint is aware which key to use for any given packet? Are 
either ever likely to be the case?

Doesn't the part about a malicious endpoint (should that be middlebox?) 
viewing the splicing time in the RTP header depend on the header 
extension that contains the splicing interval _not_ being encrypted?

> [Rachel]: This proposal will be the discussion for integrity 

[...]

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 23 Dec 2015 02:02:28 +0000

Hi Ben,

Inline, please.

BR,
Rachel

> Sent: Tuesday, December 22, 2015 8:51 AM
> To: Huangyihong (Rachel)
> Cc: [email-masked]
> >>> says a splicer can be a 6828 mixer, but there's no provision for
> >>> cases where it is not. That text needs clarification to say that
> >>> 6828 is an example of how one might do splicing, but other
> >>> approaches would still need the splicing interval information, and
> >>> can still use this draft.
> >>
> >> some descriptions of the splicing scenario.
> >
> > inside the MPEG2-TS layer in cable TV systems. But in the RTP splicing
> > scenario described in [RFC6828], the mixer designed as the splicer has
> > to decode the RTP packets and search for the Splicing Interval inside
> > the payloads. The need for such processing increases the workload of
> > the mixer and limits the number of RTP sessions the mixer can support.
> > "
> >
> > NEW:
> > "
> I don't see how this change addresses the issue. But this particular citation is
> not the main problem. By itself, it could be read as and informational. The
> bigger problems are in 1.1, where this draft says the terminology in 6828
> applies to this document. Maybe you removed the use of that terminoligy, but
> 1.1 still says it applies. The Splicing Interval is still defined in terms of 6828.

[Rachel]: Will removing the use of terminology in Section 1.1, and adding some necessary terms like "Splicing-In Point, Splicing-Out Point, Splicer, Main RTP sender, substitutive RTP sender" in this document.

> saying "If the...mechanisms applies...". But without the normative reference, I
> don't think the security considerations are complete. That is, the idea of
> splicing _in_general_ has security considerations documented in 6828. If you
> don't normatively depend on 6828, then they need to be normatively
> referenced from somewhere else, or they need to be described here.

[Rachel]: I have described some security considerations explicitly in this document due to the splicing in general mechanisms, which I already proposed in the last mail. Actually 6828 introduce a solution on how to splice, and this document specifies a mechanism on when to splice. The security consideration for them are different. So it is possible for the security consideration of when to splice to independent on the security consideration of how to splice, provided it is normatively stated that there will be some security considerations of how to splice that need to be taken into account.

> >> reference of 6828.
> >> 3. I'll leave the references in section 2, 1st paragraph and section
> >> 5, 3rd paragraph as they are, because they are just described as
> >> examples.
> >>> terminology is required to understand this draft, then you still
> >>> need a normative dependency. If you wish to avoid that, you will
> >>> need to define the terms in this draft.
> >>>
> >>
> >>> -- general:  I'm still not entirely comfortable with the assumption
> >>> of the existence of a way to get the interval to the substitutive
> >>> source.
> >>> could be integrated with either the main source or the splicer. But
> >>> do such interfaces already exist? Are we expecting people to do
> >>> something they aren't already doing? It comes down to the question,
> >>> do you think people will deploy this solution if we don't define the
> >>> other part?
> >>>
> >>> considering why, if such things already exist, they can't also be
> >>> used for the "source-to-splicer" interface.
> >>
> >> [Rachel]: In implementations, both substitutive RTP sender and RTP
> >> sender are all ISP servers and controlled by the same ISP. There's no
> >> business model that substitutive source will be provided by a
> >> 3rd-party due to security issues. That's why we think it could be a
> >> proprietary interface between 2 servers.
> >> However,
> >> for a splicer, it could be a network node, e.g., a mixer, implemented
> >> near end users, which may be provided by a different access network
> >> provider, and can forward different advertisements to different
> >> users. Standardizing this part will easily for operators to interact
> >> with these network nodes without complex proprietary negotiation
> >> between different parties.
> >>
> Okay. Let's leave it that way for IETF last call, and see if anyone else comments
> on it.
>

[Rachel]: Okay.

> depend on the codec used by the media content.

[Rachel]: Okay.

> This provide robustness in the case where a middlebox strips RTP header

[Rachel]: Okay. Thanks for the suggestion.

> things without the example.)

[Rachel]: How about following proposed rephrasing?
OLD
"
   If a mixer works as the splicer [RFC6828] and it follows [RFC3550],
   the RTP sender whose content is being passed to a downstream receiver
   will see the reception quality of its stream as received by the mixer
   and the reception quality of the processed stream as received by the
   receiver; The RTP sender whose content is not being passed to a
   downstream receiver will only see the reception quality of its stream
   as received by the mixer. In such a case, the main RTP sender can
   learn that splicing failed if it still sees the RTCP RR packets sent
   from downstream receivers when the splicing starts; In a similar
   manner, the substitutive sender can also learn that splicing failed
   if it does not receive any RTCP RR packets from downstream receivers
   when the splicing starts.

   Other cases where senders and receivers are in different RTCP domains
   may require translation of RTCP reports, or additional reporting, if
   the senders want to detect splicing problems.
"

NEW
"
The splicer can be implemented to have its own SSRC, and send RTCP reception reports to the senders of the main and substitutive RTP streams. This allows the senders to detect problems on the path to the splicer. Alternatively, it is possible to implement the splicer such that it has no SSRC, and does not send RTCP reports; this prevents the senders from being able to monitor the quality to the path to the splicer. 

If the splicer has an SSRC and sends its own RTCP reports, it can choose not to pass RTCP reports it receives from the receivers to the senders. This will stop the senders from being able to monitor the quality of the paths from the splicer to the receivers. 

A splicer that has an SSRC can choose to pass RTCP reception reports from the receivers back to the senders, after modifications to account for the splicing. This will allow the senders the monitor the quality of the paths from the splicer to the receivers. A splicer that does not have its own SSRC has to forward and translation RTCP reports from the receiver, otherwise the senders will not see any receivers in the RTP session. 

If the splicer is implemented following [RFC6828], it will have its own SSRC and will send its own RTCP reports, and will forward translated RTCP reports from the receivers.
"

> configurable option). I suggest removing "if the senders want to detect

[Rachel]: Make sense to me.

> >> security

[Rachel]: Mixer and translator are specified in RFC3550, it's already a normative reference. I'll reference RFC3550 section 7 for clarity.

> > what each provides, i.e., the different media sources, main and

[Rachel]: Good suggestion.
> new solution. Also, does the work in PERC offer any value here?

[Rachel]: No, PERC is about protection from against stream modification and impersonation by RTP middleboxes. A splicer is supposed to be a trusted middle box which can modify and impersonate the stream. 
> either ever likely to be the case?

[Rachel]: Either both sources use the same SRTP key, or the splicer decrypts and re-encrypts with a single key.

> extension that contains the splicing interval _not_ being encrypted?

[Rachel]: Yes. Header extensions are not encrypted by default in SRTP. So this paragraph talks the case header extensions are not encrypted. And 3rd paragraph of section 7 talks about header extension encryption [RFC6904].