RTP/RTCP Extension for RTP Splicing Notification
draft-ietf-avtext-splicing-notification-09

Thank you very much for addressing my discuss.
I particularly found Sec 2.1 helped to clarify the architecture.

= Section 4 =

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

In Section 2 you gave a guideline for how to figure out how far in advance to send the splicing information. I think a similar guideline would be useful here.

s/e.g., choosing media sender/e.g., choosing main RTP sender/

= Section 7 =

What is undetectable splicing?

= Section 8.3 =

In the past when we've registered these there was no contact I don't think. Not sure what IANA would do with one here.

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

I moved my discuss points into the comment now assuming that the discussed changes will be applied in the next version. I still support Alia's discuss, as this point must be addressed carefully, and I would like to review the next before final publications.

- The following action does not seem to be appropriate for a specification of an end-to-end protocol:
"And if the splicer wishes to prevent the downstream receivers from detecting splicing, it MUST
   NOT forward the message."
I guess if a middlebox decides to drop the message, there is not much we can do. But I definitely would prefer to not see this specified in an RFC.

- Why is just having the RTCP message not sufficient? Why are the RTP extensions needed as well?

- And is the RTCP message send only once or multiple time? This is not specified.

- There is some discussion about the implementation of the slicer in section 5 (where btw. the title "Failure Cases" seems inappropriate), while there is one sentence saying: "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."
Why are alternatives discussed here, if there is already a recommendation given in RFC6828? And how would proper congestion handling be ensure in the other setups not described in RFC6828?

- As a general comment, I found it quite hard to read this doc without reading RFC6828 which is only listed as a informative reference as it is informational only. I think it is wrong. Further, RFC6828 describes some action that a slicers has to perform. However, all language in RFC6828 is non normative. This is slightly confusing to me as well. I would further recommend to briefly give an overview of the assumed scenario is this document.

- Minor comment: The definition of the new SDP grouping semantic should be mentioned in the abstract and RFC4566 should be referenced. And I don't think the SDP grouping registry requires a contact.

- Quick question: Maybe I'm missing something here but why do you need a splicer in a scenario where "the
   substitutive sender is implemented together with the main RTP sender inside a single device" (as written in section 2)?

I do share the question about the definition of "undetectable splicing".

Thanks for handling my discuss points. 

Old comments below, I didn't check those.

-----

- I agree with Alia's discuss, but suspect the ship has sailed.
(Sadly IMO, but sailed nonetheless.)

- The security considerations here are similar to but not quite
the same as those in RFC6828 which I think was the last time a
similar document was before the IESG. I wondered if those
differences were significant or not, it might be no harm to
commpare the two (if that's not already been done) since they
really ought be pretty much the same.