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

From: "Ben Campbell" <[email-masked]>
Date: Fri, 12 Feb 2016 15:34:10 -0600

I believe this version is ready to go to IETF last call. I will kick 
that off shortly.

I do have a couple of remaining comments for section 7, but you can 
treat these along with any other IETF last call comments:

-7, first paragraph: "The splicer MUST either be a mixer or a 
translator..."

Is the MUST really a requirement, or a statement of fact?

-- third paragraph:

Can you clarify the assumptions about the SRTP security association(s)? 
I assume it's not end to end between the original source and the 
receiver, since splicing would seem to violate integrity protection. In 
particular, what assumptions allow the insertion to occur without 
violating integrity protection, and do not assume the splicer has access 
to the keys?

Thanks!

Ben.

On 26 Jan 2016, at 2:27, Huangyihong (Rachel) wrote:

> Dear all,
>
> This version tries to address the AD's comments. Please feel free to 
> raise any other suggestions. Thanks.
>
> BR,
> Rachel
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 26, 2016 4:25 PM
> To: Deng Lingli; Roni Even; Xiajinwei; Huangyihong (Rachel); Lingli 
> Deng
> Subject: New Version Notification for 
> draft-ietf-avtext-splicing-notification-04.txt
>
>
> A new version of I-D, draft-ietf-avtext-splicing-notification-04.txt
> has been successfully submitted by Rachel Huang and posted to the IETF 
> repository.
>
> Name:		draft-ietf-avtext-splicing-notification
> Revision:	04
> Title:		RTP/RTCP extension for RTP Splicing Notification
> Document date:	2016-01-26
> Group:		avtext
> Pages:		19
> URL:            
> https://www.ietf.org/internet-drafts/draft-ietf-avtext-splicing-notification-04.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/
> Htmlized:       
> https://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-04
> Diff:           
> https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-splicing-notification-04
>
> 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: Wed, 17 Feb 2016 03:30:37 +0000

Hi Ben,

Thanks for moving this work forward.

Please see my replies for the further comments.

BR,
Rachel

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Saturday, February 13, 2016 5:34 AM
> To: Huangyihong (Rachel)
> Cc: [email-masked]
> Subject: Re: [avtext] New Version Notification for
> I believe this version is ready to go to IETF last call. I will kick that off shortly.
> 
> I do have a couple of remaining comments for section 7, but you can treat
> these along with any other IETF last call comments:
> 
> -7, first paragraph: "The splicer MUST either be a mixer or a translator..."
> 

[Rachel]: RTP protocol considers intermediate boxes at the RTP level either as mixers or translators. So here it's a statement of fact. But I think that we may not need such a RFC2119 terminology in this case. Maybe change to "can"?
> I assume it's not end to end between the original source and the receiver, since
> splicing would seem to violate integrity protection. In particular, what
> assumptions allow the insertion to occur without violating integrity protection,
> and do not assume the splicer has access to the keys?

[Rachel]: When splicer works as a translator, it doesn't have a SSRC, so it just switches the RTP packets between main stream and substitutive stream when splicing time comes and ends. In that a case, the splicer does not have to access to the keys, it just works like a transport translator. But when splicer works as a mixer like RFC FC6828 suggests, to have the splicer SSRC so it will prevent to take out the ads based on SSRC. It need to have the keying information and decrypt and encrypt the payload. 

Does the clarification makes sense to you?

> > 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.
> >

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 16 Feb 2016 21:41:34 -0600

On 16 Feb 2016, at 21:30, Huangyihong (Rachel) wrote:

> [Rachel]: RTP protocol considers intermediate boxes at the RTP level 
> either as mixers or translators. So here it's a statement of fact. But 
> I think that we may not need such a RFC2119 terminology in this case. 
> Maybe change to "can"?

"can" works for me.

>> receiver, since
> [Rachel]: When splicer works as a translator, it doesn't have a SSRC, 
> so it just switches the RTP packets between main stream and 
> substitutive stream when splicing time comes and ends. In that a case, 
> the splicer does not have to access to the keys, it just works like a 
> transport translator. But when splicer works as a mixer like RFC 
> FC6828 suggests, to have the splicer SSRC so it will prevent to take 
> out the ads based on SSRC. It need to have the keying information and 
> decrypt and encrypt the payload.
>

In the translator case, the receiver starts out receiving packets from 
the original source. It has the key for those packets through some 
mechanism (e.g. dtls-srtp or security descriptions). Then the splicer 
switches to the substitutive source. Presumably, these packets use 
different keys, since they come from a different source. How does the 
receiver learn of this? Or do we assume the original source and the 
substitutive source share keys?

Thanks!

Ben.

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 17 Feb 2016 03:50:05 +0000

Inline, please.

BR,
Rachel

> Sent: Wednesday, February 17, 2016 11:42 AM
> To: Huangyihong (Rachel)
> Cc: [email-masked]
> >> receiver, since splicing would seem to violate integrity protection.
> >> In particular, what assumptions allow the insertion to occur without
> >> violating integrity protection, and do not assume the splicer has
> >> access to the keys?
> >
> >
> In the translator case, the receiver starts out receiving packets from the
> original source. It has the key for those packets through some mechanism (e.g.
> dtls-srtp or security descriptions). Then the splicer switches to the substitutive
> source. Presumably, these packets use different keys, since they come from a
> different source. How does the receiver learn of this? Or do we assume the
> original source and the substitutive source share keys?

[Rachel]: Yes, they share the keys. I answered it once in the previous comments. I copy it here:

"
   > 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?

[Rachel]: Either both sources use the same SRTP key, or the splicer decrypts and re-encrypts with a single key.
"
So maybe I should clarify it in the draft?

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 16 Feb 2016 22:18:02 -0600

> comments. I copy it here:

Yes, you did :-)

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

Given I keep asking the same question, others may do so also. So it's 
probably a good idea to clarify it.

Thanks!

Ben.

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 17 Feb 2016 04:27:05 +0000

All right. I'll do it together with other comments that may be produced in the IETF last call.

BR,
Rachel

> Sent: Wednesday, February 17, 2016 12:18 PM
> To: Huangyihong (Rachel)
> Cc: [email-masked]
> >>>> In particular, what assumptions allow the insertion to occur
> >>>> without violating integrity protection, and do not assume the
> >>>> splicer has access to the keys?
> >>>
> >>>
> >>> [Rachel]: When splicer works as a translator, it doesn't have a
> >>> SSRC, so it just switches the RTP packets between main stream and
> >>> substitutive stream when splicing time comes and ends. In that a
> >>> case, the splicer does not have to access to the keys, it just works
> >>> like a transport translator. But when splicer works as a mixer like
> >>> RFC
> >>> out the ads based on SSRC. It need to have the keying information
> >>> and decrypt and encrypt the payload.
> >>>
> >> In the translator case, the receiver starts out receiving packets
> >> from the original source. It has the key for those packets through
> >> some mechanism (e.g.
> >> dtls-srtp or security descriptions). Then the splicer switches to the
> >> substitutive source. Presumably, these packets use different keys,
> >> since they come from a different source. How does the receiver learn
> >> of this? Or do we assume the original source and the substitutive
> >> source share keys?
> >
> Given I keep asking the same question, others may do so also. So it's probably a
> good idea to clarify it.
> 
> Thanks!
> 
> Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 29 Feb 2016 20:09:07 -0600

Hi,

The last call is complete. The only feedback I saw (I might have missed 
something) was from the IANA review. Have the authors responded to that? 
Do you plan an update before the IESG evaluation?

Thanks!

Ben.

On 16 Feb 2016, at 22:27, Huangyihong (Rachel) wrote:

>>> [Rachel]: Yes, they share the keys. I answered it once in the 
>>> previous
>>> comments. I copy it here:
>>
>> Yes, you did :-)
>>
>>>
>>> "

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 1 Mar 2016 02:27:34 +0000

Hi Ben,

We author did receive IANA review. But there's no comments in that review. It was just to confirm the actions that need IANA to complete. And I think it requires us to respond only when any action they are going to take is not accurate. 

They also said these actions need to be evaluated by experts reviews via a separate request. However, we haven't seen any expert review comments from then on. Maybe they forgot to copy us or maybe there's no comments at all. We're not sure about it.

It's okay for us to bring an update one before the IESG evaluation to address the further issues you raised before. What do you think?

BR,
Rachel

> Sent: Tuesday, March 01, 2016 10:09 AM
> To: Huangyihong (Rachel)
> Cc: [email-masked]
> >>>>> [Rachel]: RTP protocol considers intermediate boxes at the RTP
> >>>>> level either as mixers or translators. So here it's a statement of
> >>>>> fact.
> >>>>> But
> >>>>> case, the splicer does not have to access to the keys, it just
> >>>>> works like a transport translator. But when splicer works as a
> >>>>> mixer like RFC
> >>>>> FC6828 suggests, to have the splicer SSRC so it will prevent to
> >>>>> take out the ads based on SSRC. It need to have the keying
> >>>>> information and decrypt and encrypt the payload.
> >>>>>
> >>>> dtls-srtp or security descriptions). Then the splicer switches to
> >>>> the substitutive source. Presumably, these packets use different
> >>>> keys, since they come from a different source. How does the
> >>> previous comments. I copy it here:
> >>
> >> Yes, you did :-)
> >>
> >>>
> >>> "