A Framework for Conferencing with the Session Initiation Protocol (SIP)
draft-ietf-sipping-conferencing-framework-05

[Note]: 'Restored to RFC Editor Queue as requested by the RFC Editor and Dean Willis.  This document draft-ietf-sipping-conferencing-framework is still in the RFC Editor Queue.' added by Amy Vezza

[Ballot discuss]
I'm concerned that the discussion of ejection in section 4.1 and the
discussion of media in 4.3 and 6.3 through 6.5 doesn't consider the
security implications of badly behaved clients.  It's not enough to
eject someone with a bye; you may (depending on how important it is
they be ejected) want to guarantee they are no longer receiving the
media stream.  For the unicast case all talking to one central
server, this is probably close enough to existing practice that you
may be able to point to something in another document.  I'm
concerned that new text needs to be written for the multicast case
(to the extent it is in scope) and the other more complicated mixing
cases covered in this document.

I would like the document to point out that the mixers need to be
involved in a forced ejection and discuss how this could be
accomplished and what the tradeoffs are.  For cases where things
are being mixed it seems like you just need to describe (or point to
a description of) how to inform the right parties that they should
stop sending  media to the ejected participant.  For the multicast
case it seems like you have three options: ignore the problem and
accept there is some risk the participant is still listening, change
the multicast group you are using or update your multicast key.