Subject: [avtext] AD Evaluation of draft-ietf-avtext-splicing-notification-02

From: "Ben Campbell" <[email-masked]>
Date: Tue, 10 Nov 2015 21:57:38 -0600

Hi,

Here is my AD Evaluation of draft-ietf-avtext-splicing-notification-02. 
I think a number of these issues need to be handled prior to the IETF 
last call, so I'm holding off on that until we've at least had a chance 
to discuss them.

Thanks!

Ben.

-----------

Substantive Comments:
=====================

- RFC 6828 informational. This draft depends heavily on behavior from 
that RFC (which needs to be a normative reference as things are 
currently written). I suspect this draft needs to be PS due to  the SDP 
group semantics registration,  but I think it really should be 
informational, or it should be written in a way to not depend on or 
assume behaviors from RFC 6828. (Especially for the security 
considerations)

- section 1, first paragraph: "the splicing duration MUST be inside of 
the specific, pre-designated time slot"

That sounds more like a statement of fact than a 2119 MUST.

- 2, 2nd paragraph: "When a new splicing is forthcoming, the main RTP 
sender MUST send the
    Splicing Interval to the mixer."

I don't think that needs to be a 2119 MUST. The sender does this, or it 
doesn't. In the latter case, this draft does not come into play.

-2, paragraph 3:

If I understand correctly, this mechanisms doesn't work unless the 
substitutive source knows the splice interval. Furthermore, it needs to 
know it in time to act on it. I'm not sure this mechanism is useful 
without at least some mechanism to share the SI. Do you assume they have 
a proprietary mechanism (i.e. they are from the same vendor) or perhaps 
the substitutive source is colocated with the main source or the mixer? 
If so, please mention that.

Is there a minimum required resolution and skew for the shared reference 
clock?

-2, paragraph 5:

Any guidance on how much ahead the substitutive packets should be sent?

-2, paragraph 6:

How. By selecting the correct packet? By adjusting the time stamp? Do we 
assume a main stream packet exists that starts at that exact timestamp?

-3.1, paragraph after figure 1:

This is at least partially redundant with previous guidance.

- 3.2, last paragraph:

Are there receivers that are not down-stream receivers? If so, there the 
SHOULD and MUST seem to conflict. Or does the MUST only apply if you 
want undetectable splicing?

- 4, last paragraph: "Either the main RTP sender or the substitutive 
sender SHOULD send..."

Assuming "either" means that exactly one SHOULD send, how do they 
coordinate? Or does it matter if both do it?

-5, 3rd paragraph:

What if the mixer uses a separate closed RCTP loop for senders and 
receivers? I think 6828 can be interpreted to allow that. (And see 
previous comment about assuming 6828 behavior.)

Also, please describe the process by which the RTP sender infers that 
splicing failed from the downstream sender reports. ( I think I know, 
but don't assume everyone will.)

-5, last paragraph:

What do you mean by "check the path"? Wouldn't it be up to the mixer to 
fall back to a payload specific mechanism?

-7, first paragraph:

If you depend on the security considerations in RFC 6828, that reference 
needs to be normative.

-7, 2nd paragraph: "authenticate the main and substitutive content 
sources?

I thought the paragraph was talking about SRTP on the main source but 
not on the substitutive source? If neither are protected, there’s a 
lot easier attacks than the one described.

-7, last paragraph:

The last two sentences conflict with slightly different normative 
statements earlier in the draft.

- 10.2:

The references for RFCs 3711, 5506, 6904, and 6828 need to be normative 
the way the draft is currently formulated. (See previous comments about 
6828).

Editorial Comments:
===================

- 1, first paragraph: "refers to this information as Splicing Interval."

Missing article ("... the Splicing Interval")

- 1, last paragraph:

Do you mean to say you designed it in a complementary fashion, or it 
carries the SI in a complementary fashion?

- 2, 2nd paragraph: "Usually, the Splicing Interval SHOULD
    be sent more than once"

"Usually" is redundant to the SHOULD, and only serves to weaken it. If 
there are known circumstances where it does not make sense to send more 
than once, please mention them.

- 3.1, paragraph 2:

I think this would be easier to understand if you described how to 
calculate the absolute (64bit NTP) splicing out time by concatenating 
the first octet of the splice-in time with the 7 octets of the 
splice-out time.

also, s/referred/infer

- 3.1, 2nd to last paragraph:

Consider stating this in the positive, i.e. SHOULD strip the RTP 
extension from forwarded packets.

- 3.1, last paragraph:

This seems to belong with the following section. It needs a "the" before 
"RTCP splicing notification message". Also, please consider restating 
"MUST be sent to provide robustness " in the active voice. (That is, 
what MUST send it?)

-3.2, 2nd paragraph:

s/fix/fixed

- 3.2, definition of Timestamp:

s/"RTCP Sender Report" / "the RTCP Sender Report

- 4, 1st paragraph:

I don't understand the phrase "... provide the Reference Information 
align with its multimedia content ...".

- 5, 1st paragraph: "... other failure case..."

"... other failure cases..." or "... the other failure case..."

- 5, 2nd paragraph: "... splicing un-aware middlebox ..."

"... a splicing un-aware middlebox ..." or "... splicing un-aware 
middleboxes ..."

"one heuristics" -> "one heuristic"

What uses the heuristic? (consider active voice).

- 6, paragraph 2:

Please expand SDP on first mention in the body text.

-6, paragraph 3:

"multiple media": Does that mean multiple media streams? Multiple 
m-lines?

s / "This semantics" / "This semantic"  ; or "These semantics"

-7, 3rd paragraph: "To protect from different substitutive contents are 
inserted,
    the splicer MUST have some mechanisms to authenticate the
    substitutive stream source."

I don't understand the sentence.

-9: Acknowledgement section says "TBD" Also, 
s/Acknowledges/Acknowledgement

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Fri, 13 Nov 2015 13:17:50 +0000

Hi Ben,

Sorry for my late response. I'm on my business trip this week. Please see my replies inline. I'll modify the draft according to your comments and proposals that you agree.

BR,
Rachel

-----邮件原件-----
发件人: Ben Campbell [mailto:[email-masked]] 
发送时间: 2015年11月11日 11:58
收件人: [email-masked]; [email-masked]
主题: AD Evaluation of draft-ietf-avtext-splicing-notification-02

Hi,

Here is my AD Evaluation of draft-ietf-avtext-splicing-notification-02. 
I think a number of these issues need to be handled prior to the IETF last call, so I'm holding off on that until we've at least had a chance to discuss them.

Thanks!

Ben.

-----------

Substantive Comments:
=====================

- RFC 6828 informational. This draft depends heavily on behavior from that RFC (which needs to be a normative reference as things are currently written). I suspect this draft needs to be PS due to  the SDP group semantics registration,  but I think it really should be informational, or it should be written in a way to not depend on or assume behaviors from RFC 6828. (Especially for the security
considerations)
 
[Rachel]: Make sense to me. Since we expect this draft goes for a standards track, I'll modify the draft to just use RFC6828 as an example of splicing mechanisms. What do you think?

- section 1, first paragraph: "the splicing duration MUST be inside of the specific, pre-designated time slot"

[Rachel]: How about changing to "needs to"?

- 2, 2nd paragraph: "When a new splicing is forthcoming, the main RTP sender MUST send the
    Splicing Interval to the mixer."

I don't think that needs to be a 2119 MUST. The sender does this, or it doesn't. In the latter case, this draft does not come into play.

[Rachel]: Agree. Also can be changed to "needs to".

-2, paragraph 3:

If I understand correctly, this mechanisms doesn't work unless the substitutive source knows the splice interval. Furthermore, it needs to know it in time to act on it. I'm not sure this mechanism is useful without at least some mechanism to share the SI. Do you assume they have a proprietary mechanism (i.e. they are from the same vendor) or perhaps the substitutive source is colocated with the main source or the mixer? 
If so, please mention that.

[Rachel]: Yes. Both assumptions are possible in deployments. So I'll add some text in Section 3 to clarify this.

Is there a minimum required resolution and skew for the shared reference clock?

[Rachel]: It depends on the codec that's used. I can clarify it in the draft.

-2, paragraph 5:

[Rachel]: We have some suggestions in 2rd paragraph of section 3. It is copied as following:

"
When a new splicing is forthcoming, the main RTP sender MUST send the
   Splicing Interval to the mixer. Usually, the Splicing Interval SHOULD
   be sent more than once to mitigate the possible packet loss. To
   enable the mixer to get the substitutive content before the splicing
   starts, the main RTP sender MUST send the Splicing Interval far
   ahead. For example, the main RTP sender can estimate when to send the
   Splicing Interval based on the round-trip time (RTT) following the
   mechanisms in section 6.4.1 of [RFC3550] when the mixer sends RTCP RR
   to the main sender.
"

-2, paragraph 6:

How. By selecting the correct packet? By adjusting the time stamp? Do we assume a main stream packet exists that starts at that exact timestamp?

[Rachel]: The mixer cannot ensure the exact same time instance. So how about fixing it like this?

"
When the splicing will end, the mixer MUST ensure the Splicing Out NTP timestamp in the Splicing Interval is in the between of the time instance of the last substitutive RTP packet's timestamp and the time instance of the first main RTP packet's timestamp that would be presented on the receivers.
"

[Rachel]: Okay. Will be fixed.

- 3.2, last paragraph:

Are there receivers that are not down-stream receivers?

[Rachel]: I'll change "receivers" in the first sentence into "down-stream receivers" to avoid any confusions.
 
 If so, there the SHOULD and MUST seem to conflict. Or does the MUST only apply if you want undetectable splicing?

[Rachel]: The second sentence should be changed from

"
And it MUST NOT forward the message to
   the downstream receivers to avoid them from detecting splicing
   defined in Section 4.5 in [RFC6828].
"
To

"
And if the mixer wishes to prevent the downstream receivers from detecting splicing, it MUST NOT forward the message.
"

- 4, last paragraph: "Either the main RTP sender or the substitutive sender SHOULD send..."

Assuming "either" means that exactly one SHOULD send, how do they coordinate? Or does it matter if both do it?

[Rachel]: Yes. They can be coordinated by some proprietary out-of-band mechanisms. I'll clarify it in the draft.

-5, 3rd paragraph:

What if the mixer uses a separate closed RCTP loop for senders and receivers? I think 6828 can be interpreted to allow that. (And see previous comment about assuming 6828 behavior.)

[Rachel]: In other topologies where senders and receivers are in different RTCP domains, we assume that splicing failure is notified by out-of-band mechanisms.

Also, please describe the process by which the RTP sender infers that splicing failed from the downstream sender reports. ( I think I know, but don't assume everyone will.)

[Rachel]: Ok.

-5, last paragraph:

What do you mean by "check the path"? Wouldn't it be up to the mixer to fall back to a payload specific mechanism?

[Rachel]: If a failure is detected, it is possible that there's a splicing un-aware middlebox in the path between the sender and mixer, and RTCP messages haven't arrived in time. So the best way is to use [SCTE35] instead, which encapsulates the splicing interval inside the payload. But you're right. The mixer in this case must support detecting the payload and agree to fall back to this method. Thus, can I change the last paragraph as following?

OLD
"
Upon the detection of a failure, the main RTP sender or the
   substitutive sender SHOULD check the path to the failed mixer, or
   fallback to the payload specific mechanisms, e.g., MPEG-TS splicing
   solution defined in [SCTE35].
"

NEW
"
Upon the detection of a failure, the mixer can communicate with the main sender and the substitutive sender in some out of band signaling to fall back to the payload specific mechanisms it supports, e.g., MPEG-TS splicing solution defined in [SCTE35].
"

-7, first paragraph:

If you depend on the security considerations in RFC 6828, that reference needs to be normative.

[Rachel]: Agree. Will delete the reference and rephrase some texts.

-7, 2nd paragraph: "authenticate the main and substitutive content sources?

I thought the paragraph was talking about SRTP on the main source but not on the substitutive source? If neither are protected, there’s a lot easier attacks than the one described.

[Rachel]: Yes. You're right. SRTP should be also used on the substitutive source. 

-7, last paragraph:

The last two sentences conflict with slightly different normative statements earlier in the draft.

[Rachel]: Are you referring to the last paragraph of Section 3.2. They don't conflict. Section 3.2 is talking about RTCP message. Here is talking about RTP header extensions.

- 10.2:

The references for RFCs 3711, 5506, 6904, and 6828 need to be normative the way the draft is currently formulated. (See previous comments about 6828).

[Rachel]: Agree. Will be fixed.

Editorial Comments:
===================

[Rachel]: Ok.

- 1, last paragraph:

Do you mean to say you designed it in a complementary fashion, or it carries the SI in a complementary fashion?

[Rachel]: I'm not quite sure I understand the difference. The reason we want to have a RTCP message here is to have another way to convey SI information in case the RTP header information is stripped by some splicing unaware middlebox. The RTCP messages can be sent in parallel with RTP header information to improve robustness.

"Usually" is redundant to the SHOULD, and only serves to weaken it. If there are known circumstances where it does not make sense to send more than once, please mention them.

[Rachel]: Will delete usually.

- 3.1, paragraph 2:

I think this would be easier to understand if you described how to calculate the absolute (64bit NTP) splicing out time by concatenating the first octet of the splice-in time with the 7 octets of the splice-out time.

[Rachel]: Ok.

also, s/referred/infer

[Rachel]: Ok.

Consider stating this in the positive, i.e. SHOULD strip the RTP extension from forwarded packets.

[Rachel]: Ok.

- 3.1, last paragraph:

This seems to belong with the following section. It needs a "the" before "RTCP splicing notification message". Also, please consider restating "MUST be sent to provide robustness " in the active voice. (That is, what MUST send it?)

[Rachel]: Ok.

-3.2, 2nd paragraph:

s/fix/fixed

[Rachel]: Agree.

- 4, 1st paragraph:

I don't understand the phrase "... provide the Reference Information align with its multimedia content ...".

[Rachel]: "align" can be changed to "together".

"... a splicing un-aware middlebox ..." or "... splicing un-aware middleboxes ..."

[Rachel]: Agree.

[Rachel]: The main RTP sender and the substitutive sender.

- 6, paragraph 2:

[Rachel]: Right.

-6, paragraph 3:

"multiple media": Does that mean multiple media streams? Multiple m-lines?

[Rachel]: Here is multiple m-lines.

-7, 3rd paragraph: "To protect from different substitutive contents are inserted,
    the splicer MUST have some mechanisms to authenticate the
    substitutive stream source."

[Rachel]: I think it could be reworded like this

"
To avoid invalid substitutive contents are inserted, the splicer MUST have some mechanisms to authenticate the substitutive stream source.
"

-9: Acknowledgement section says "TBD" Also, s/Acknowledges/Acknowledgement

[Rachel]: Will change it.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 23 Nov 2015 15:15:53 -0600

Hi,

Thanks for the response. Please see comments below. I removed sections 
that don't seem to need further discussion.

Thanks!

Ben.

On 13 Nov 2015, at 7:17, Huangyihong (Rachel) wrote:

[...]

> currently written). I suspect this draft needs to be PS due to  the 
> SDP group semantics registration,  but I think it really should be 
> [Rachel]: Make sense to me. Since we expect this draft goes for a 
> standards track, I'll modify the draft to just use RFC6828 as an 
> example of splicing mechanisms. What do you think?

That would help. But keep in mind that would mean this draft could not 
depend on 6828. That is, it could not assume 6828 behaviors, security 
considerations, etc.

The other option would be to make this draft informational, but that 
would mean either removing the group semantic registration, or 
convincing people to relax the group semantic registration policy.

> [Rachel]: How about changing to "needs to"?

That would work for me .

> I don't think that needs to be a 2119 MUST. The sender does this, or 
> it doesn't. In the latter case, this draft does not come into play.
>

Works for me.

> substitutive source knows the splice interval. Furthermore, it needs 
> to know it in time to act on it. I'm not sure this mechanism is useful 
> without at least some mechanism to share the SI. Do you assume they 
> have a proprietary mechanism (i.e. they are from the same vendor) or 
> perhaps the substitutive source is colocated with the main source or 
> the mixer?
> [Rachel]: Yes. Both assumptions are possible in deployments. So I'll 
> add some text in Section 3 to clarify this.
>

Okay. That likely works for me--depending on the text. :-) But I'm a 
little bit nervous that too many dependencies on proprietary or 
otherwise unspecified mechanisms will make it very hard to create 
interoperable implementations.

[...]

> mechanisms in section 6.4.1 of [RFC3550] when the mixer sends RTCP RR

Ah, right. Nevermind.

> "
>
> -2, paragraph 6:
>
> How. By selecting the correct packet? By adjusting the time stamp? Do 
> we assume a main stream packet exists that starts at that exact 
> timestamp?
>
> When the splicing will end, the mixer MUST ensure the Splicing Out NTP 
> timestamp in the Splicing Interval is in the between of the time 
> instance of the last substitutive RTP packet's timestamp and the time 
> instance of the first main RTP packet's timestamp that would be 
> presented on the receivers.
> "
>

Works for me, thanks.

[...]

> [Rachel]: I'll change "receivers" in the first sentence into 
> "down-stream receivers" to avoid any confusions.
>
> If so, there the SHOULD and MUST seem to conflict. Or does the MUST 
> only apply if you want undetectable splicing?
>
> And if the mixer wishes to prevent the downstream receivers from 
> detecting splicing, it MUST NOT forward the message.
> "
>

Okay, all taken together that helps.

> [Rachel]: Yes. They can be coordinated by some proprietary out-of-band 
> mechanisms. I'll clarify it in the draft.

Okay (depending on the clarification text. In particular, does it do 
harm if both do it?)

> [Rachel]: In other topologies where senders and receivers are in 
> different RTCP domains, we assume that splicing failure is notified by 
> out-of-band mechanisms.

It would help to mention that (unless you already did and I missed it.)

[...]

> -5, last paragraph:
>
> What do you mean by "check the path"? Wouldn't it be up to the mixer 
> to fall back to a payload specific mechanism?
>
> [Rachel]: If a failure is detected, it is possible that there's a 
> splicing un-aware middlebox in the path between the sender and mixer, 
> and RTCP messages haven't arrived in time. So the best way is to use 
> [SCTE35] instead, which encapsulates the splicing interval inside the 
> payload. But you're right. The mixer in this case must support 
> detecting the payload and agree to fall back to this method. Thus, can 
> I change the last paragraph as following?
>
> OLD
> "
> Upon the detection of a failure, the mixer can communicate with the 
> main sender and the substitutive sender in some out of band signaling 
> to fall back to the payload specific mechanisms it supports, e.g., 
> MPEG-TS splicing solution defined in [SCTE35].

We seem to be creating a lot of dependencies on unspecified mechanisms. 
In this case, what happens if no such mechanism is available? Do things 
just fail?

[...]

> [Rachel]: Are you referring to the last paragraph of Section 3.2. They 
> don't conflict. Section 3.2 is talking about RTCP message. Here is 
> talking about RTP header extensions.

Oops, you are correct that I missed the distinction.

[...]

> Editorial Comments:

[...]

> [Rachel]: I'm not quite sure I understand the difference. The reason 
> we want to have a RTCP message here is to have another way to convey 
> SI information in case the RTP header information is stripped by some 
> splicing unaware middlebox. The RTCP messages can be sent in parallel 
> with RTP header information to improve robustness.

As written, it says "defined in a complementary fashion" which describes 
the act of defining, not the thing being defined. I think you mean 
something like "... defines a complementary RTCP packet type ..." (so 
that "complementary" refers to the RTCP packet type".

[...]
> To avoid invalid substitutive contents are inserted, the splicer MUST 
> have some mechanisms to authenticate the substitutive stream source.
>
> "

That helps, but consider "To avoid the insertion of invalid..."

[...]

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 24 Nov 2015 06:50:37 +0000

Dear Ben,

Please see further replies inline.

BR,
Rachel

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, November 24, 2015 5:16 AM
> To: Huangyihong (Rachel)
> Cc: [email-masked]; [email-masked]
> Subject: Re: AD Evaluation of draft-ietf-avtext-splicing-notification-02
> 
> Hi,
> 
> Thanks for the response. Please see comments below. I removed sections that
> don't seem to need further discussion.
> 
> Thanks!
> 
> Ben.
> 
> 
> That would help. But keep in mind that would mean this draft could not depend
> on 6828. That is, it could not assume 6828 behaviors, security considerations,
> etc.

[Rachel]: Yes. That's what I'm going to do. Because this draft just specifies 2 timing extension on the splicing. It doesn't have to require any RFC6828 method. To do that, I'll rephrase the texts referring to RFC6828, and modify anything that depends on splicing being implemented as an RTP mixer. 

> The other option would be to make this draft informational, but that would
> mean either removing the group semantic registration, or convincing people to
> relax the group semantic registration policy.

[Rachel]: Thanks for the suggestion. But I'll try option 1.

> Okay. That likely works for me--depending on the text. :-) But I'm a little bit
> nervous that too many dependencies on proprietary or otherwise unspecified
> mechanisms will make it very hard to create interoperable implementations.

[Rachel]: I think it is common that substitutive source and media sender are provided by the same operators so that security risks can be reduced.  The propriety mechanisms between the main media sender and the substitutive source sender don't affect interoperability between media source and middlebox (splicer), and end users. 

Here's the suggested text:

OLD
"
   The Splicing Interval
   could be transmitted from the main RTP sender to the substitutive
   content using some out-of-band mechanisms, the details how to achieve
   that are beyond the scope of this memo. 

"
NEW

"
   The Splicing Interval could be transmitted from the main RTP sender to the substitutive content using some out-of-band mechanisms, for example, a proprietary mechanism to exchange the Splicing Interval, or the substitutive sender is implemented together with the main RTP sender in a single device. However, the details how to achieve that are beyond the scope of this memo.
"
> Okay (depending on the clarification text. In particular, does it do harm if both
> do it?)
> 

[Rachel]: How about the following suggested text?

OLD
"
   Another latency element is synchronization caused delay. The
   receivers must receive enough synchronization metadata prior to
   synchronizing the separate components of the multimedia streams when
   splicing starts or ends. 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. The mechanisms defined in [RFC6051] are
   RECOMMENDED to be adopted to reduce the possible synchronization
   delay.
"

NEW

"
   Another latency element is synchronization caused delay. The 
   receivers must receive enough synchronization metadata prior to 
   synchronizing the separate components of the multimedia streams when
   splicing starts or ends. 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. The main RTP sender
   and the substitutive sender can be coordinated by some proprietary out-of-band mechanisms to decide when and whom to send the metadata. If both send the information, the splicer SHOULD pick one based on the current situation, e.g., choosing media sender when synchronizing the main media content while choosing the information from the substitutive sender when synchronizing the spliced content. The mechanisms defined in [RFC6051] are
   RECOMMENDED to be adopted to reduce the possible synchronization
   delay.
"

> It would help to mention that (unless you already did and I missed it.)

[Rachel]: Please see following suggested modifications:

OLD

"
   If the mixer does not get the Splicing Interval when the splicing
   starts, it will still output the main content to the downstream
   receivers and forward the RTCP RR packets sent from downstream
   receivers to the main RTP sender (see section 4.2 of [RFC6828]). In
   such case, the main RTP sender can learn that splicing failed.
"

NEW

"
If a mixer works as the splicer and it follows [RFC3550], the main RTP sender can learn that splicing failed: The splicer will still output the main content to the downstream receivers and forward the RTCP RR packets sent from downstream receivers to the main RTP sender (see section 4.2 of [RFC6828]), if it does not get the Splicing Interval 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.
"

> In this case, what happens if no such mechanism is available? Do things just
> fail?

[Rachel]: If no such mechanism, splicing will never happen. I think it does no harm to the original RTP session. So how about following suggestion?

NEW

"
Upon the detection of a failure, the mixer can communicate with the
main sender and the substitutive sender in some out of band signaling
to fall back to the payload specific mechanisms it supports, e.g.,
MPEG-TS splicing solution defined in [SCTE35], or just abandon the splicing.
"

> As written, it says "defined in a complementary fashion" which describes the
> act of defining, not the thing being defined. I think you mean something like "...
> defines a complementary RTCP packet type ..." (so that "complementary"
> refers to the RTCP packet type".

[Rachel]: Oh, I get it. Will modify it as you suggested.

> > -7, 3rd paragraph: "To protect from different substitutive contents
> > are inserted,  the splicer MUST have some mechanisms to authenticate
> > the  substitutive stream source."
> >

[Rachel]: Right. Good suggestion.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 24 Nov 2015 16:00:49 -0600

Thanks Rachel,

Do you plan to submit a new version? I think doing so might give us a 
smoother IETF last call.

Thanks!

Ben.

On 24 Nov 2015, at 0:50, Huangyihong (Rachel) wrote:

>> Subject: Re: AD Evaluation of 
>> draft-ietf-avtext-splicing-notification-02
>>
>> Hi,
>>
> [Rachel]: Yes. That's what I'm going to do. Because this draft just 
> specifies 2 timing extension on the splicing. It doesn't have to 
> require any RFC6828 method. To do that, I'll rephrase the texts 
> referring to RFC6828, and modify anything that depends on splicing 
> being implemented as an RTP mixer.
>
>> would
>> little bit
>> mechanisms will make it very hard to create interoperable 
>> implementations

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 25 Nov 2015 03:39:34 +0000

Hi Ben,

I'll submit a new version in these two days to reflect all the comments we discussed.

BR,
Rachel

> Sent: Wednesday, November 25, 2015 6:01 AM
> To: Huangyihong (Rachel)
> Do you plan to submit a new version? I think doing so might give us a smoother
> IETF last call.
> 
> Thanks!
> 
> Ben.
> 
> 
> >> Thanks for the response. Please see comments below. I removed
> >> sections that don't seem to need further discussion.
> >>
> >> Thanks!
> >>
> >> Ben.
> >>
> >>
> >>> - RFC 6828 informational. This draft depends heavily on behavior
> >>> from that RFC (which needs to be a normative reference as things are
> >> That would help. But keep in mind that would mean this draft could
> >> not depend on 6828. That is, it could not assume 6828 behaviors,
> >> security considerations, etc.
> >
> >>> to know it in time to act on it. I'm not sure this mechanism is
> >>> useful without at least some mechanism to share the SI. Do you
> >>> assume they have a proprietary mechanism (i.e. they are from the
> >>> same vendor) or perhaps the substitutive source is colocated with
> >>> the main source or the mixer?
> >> interoperable implementations