Content Splicing for RTP Sessions
draft-ietf-avtext-splicing-for-rtp-13

Note: This ballot was opened for revision 07 and is now closed.

(Gonzalo Camarillo) Yes

(Ron Bonica) No Objection

(Stewart Bryant) (was Discuss) No Objection

Comment (2012-11-09 for -11)
No email
send info
It is a pity that this design does not allow the content security domain to be separated from the content insertion trigger domain, since it exposes the content to an additional interception point. However the restriction is clearly described.

(Benoît Claise) No Objection

Comment (2012-05-10 for -07)
No email
send info
Much has been said already with the multiple DISCUSS feedback on this draft. So, no need to repeat the information: I'll trust the other ADs will take care of this one.

(Ralph Droms) No Objection

(Wesley Eddy) (was Abstain) No Objection

(Adrian Farrel) No Objection

Comment (2012-10-08 for -09)
No email
send info
I am ballotting No Objection on this document although I am not convinced by the Security thoughts. It doesn't seem to me to be impossible to construct a three-way security arrangement for source, splicer, and destination. But maybe the point here is that the very act of splicing *is* a violaiton of the source-destination relationship. Thus the destination correctly only has a relationship with the splicer.

(Stephen Farrell) (was Discuss) No Objection

Comment (2012-08-27 for -09)
No email
send info
Thanks for addressing my discuss points. I think the current
version's truth-in-advertising approach to the fact that it 
breaks e2e security is much better. (Though it'd be even better 
if you could figure a way to do this that would not break e2e
security. I'd encourage folks wanting to insert advertisements
to try think about that.)

(Brian Haberman) No Objection

(Russ Housley) No Objection

Barry Leiba No Objection

Comment (2012-10-09 for -09)
No email
send info
Thank you for the extensive work on this document since the -07 version.  This is *much* clearer, and addresses all my significant concerns.

Only one, small, non-blocking point: I suggest expanding "SSRC" and "CSRC" on first use.

For the record, I have no issue with Section 4.3 -- I see nothing wrong with a non-normative section that calls out an issue (including a user-experience issue) that's likely to come up in implementations, and warns them about it.  If it tried to be normative, or if it went into a lot of detail about user interface design, I might agree that it's a problem... but it doesn't, and I don't.

(Robert Sparks) (was Discuss) No Objection

Comment (2012-10-09 for -09)
No email
send info
Thanks for addressing my concerns.

Please consider adding (or pointing to) a discussion of what the impact of having a loop is.

(Martin Stiemerling) (was Discuss) No Objection

Comment (2012-10-10 for -09)
No email
send info
Thank you for addressing my concerns!

(Sean Turner) No Objection

Comment (2012-05-10 for -07)
No email
send info
I support the discuss positions from the other ADs.

(Pete Resnick) (was Discuss) Abstain

Comment (2012-11-12 for -12)
No email
send info
At base, I disagree with the WG and some of the ADs that this document should include anything about user experience; that is not a requirement for the protocol. But the author and WG have done a good job of addressing all of my other concerns and the user experience discussion in the document is very limited, so I am clearly "in the rough" and it is only right that I not hold up the document.