[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Laugh Test: xcon BOF



Mark,

The limit was placed that the media be unicast because of
security, because this group emphasizes that the conference
should be capable of strong security, and it isn't clear that
multicast media can get there yet.

Allison

> 
> >BOF NAME & ACRONYM: Centralized Conferencing (xcon)
> 
> ...
> 
> >The deliverables for the group will be:
> >- A mechanism for membership and authorization control
> >- A mechanism to manipulate and describe media "layout" or "topology" for 
> >multiple media types (audio, video, text)
> >- A mechanism for notification of conference related events/changes (for 
> >example a roster)
> >- A basic floor control protocol
> >- Peer-to-peer cascading of conferences (one conference is a participant in 
> >another and vice versa)
> >
> >The following items are specifically out-of-scope:
> >- Voting
> >- Multicast media (due to security concerns)
> >- Fully distributed conferences
> >- Loosely-coupled conferences (no central point of control)
> >- Far-end device control
> >- Protocol used between the conference controller and the mixer(s)
> >- Capabilities negotiation of the mixer(s)
> >- Master-slave cascaded conferences
> 
> 
> I have no problem with narrowly defining the focus of such a proposed
> WG, but this seems to go a little too far.  In particular, I don't see
> any reason to prohibit the use of multicast for media distribution.
> 
> What they need to do is not get held up on hard problems that are
> peripheral to their focus.  So, if some of their deliverables can work
> just fine with multicast media, and some can't, that's OK.  If there's
> a demand, then someone can come along later and solve the remaining
> issues related to mulicast.  But ruling it completely out of scope
> will ensure that it isn't even considered, even if there's no reason
> not to support it for a particular deliverable.
> 
> Multicast isn't the only issue here.  Ruling peer-to-peer cascading
> in-scope and master-slave cascading out-of-scope seems very arbitrary.
> 
> Mechanisms for floor control and mechanisms for voting may be quite
> similar.  It seems like something slightly more general may solve both
> these two problems and other unforeseen problems, whereas narrowly
> defining the scope prevents such solutions being discussed.
> 
> In general though, I think this should be a good BOF and likely WG.
> Just don't push quite so hard on the narrowness of scope.
> 
> Cheers,
> 	Mark