A Framework for Centralized Conferencing
RFC 5239

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

(Sam Hartman) Discuss

Discuss (2007-11-14 for -)
Currently, the framework document attempts to rule issues of security
policy and in particular access permissions out of scope.  I don't
think the policy and permissions for this can be out of scope.  It
seems that there are authorization issues that need to be handled that
require manipulation of permissions for floors and participants  to be in scope.  Also, issues of permissions and security policy will affect what blueprint a client wants to choose.  If these are not in scope, then clients cannot interoperate for important aspects of conference configuration.  I think you should look at
use cases from a security standpoint and I think that if you do that
you'll find that more authorization work needs to be done.  One use
case is a conference with a moderator, speakers and listeners.  How
are roles assigned to participants in an interoperable manner without
examining permissions to control floors, etc.  Another example is a
conference to discuss a sensitive issue where all participants must be
authenticated individually and authenticated identities made available
to all participants.  Again access control for the conference along
with permissions for seeing authenticated identities will be
important.  I don't understand how clients can interoperably choose
between the blueprints for these very different conferences unless
they understand  what permissions participants have and what security policy is applied.  

Another concern I have is that there are a large number of protocols
and a large number of ways to identify conferences and users.  We need
to look at the authentication, authorization and naming aspects of
each protocol and make sure they all fit together.  We need to make
sure that as we add authentication mechanisms to protocols, we will
not run into problems where for example you can use a given
infrastructure to sign into a conference with a signaling protocol but
you cannot use that infrastructure to control the conference.  There
 needs to be an analysis of each protocol's naming and authentication
and of how names flow from one protocol to another making sure that
they are properly authenticated.  One way to do this analysis would be
to go through each identified object--including conference participants, floors, conferences, mixers, media streams--any object that can be manipulated by any of the related protocols.  For each such object describe what protocols that object appears in, what names are used for the object in each protocol and how the names in one protocol are mapped to the names in another protocol.  For each mapping, consider the security implications and discuss the binding of the authentication.
Yes, this is a huge undertaking.  The xcon framework is very complex and securing it will be hard.

This section compliments and supports much of Tim's discuss.  Tim's discuss requires analysis; I'd also like to require that the provided security be adequate.  In other words, documenting weak security should not be sufficient for this document to go forward.

Finally, I'm concerned about the complexity and interoperability of
the spec as a whole and how it fits together with other IETF
conferencing efforts.  Section 9 particularly concerns me.  I'm
skeptical that we need both this and the SIP conferencing framework.
Section 9 makes an assertion that the two frameworks are compatible.  What has been done to make sure that is true.

More generally though, there is not enough mandatory behavior to make
sure that all implementations of this framework can work together.  I
understand that an audio-only device will not be able to work with a
text conference.  However at least at the level of this framework we
need to specify what the interoperability requirements are.  I'd
expect roughly that we'd have one mandatory to implement signaling protocol and that we'd expect that participants sharing codecs and the same type of media would be able to work together.  However this document doesn't specify what level of interoperability is expected nor does it place enough requirements to achieve that.  I could easily see situations where the way one conference focus modeled conferences in its blueprints was incompatible with some client.
The document needs to state clear requirements  for what types of blueprints are required.

(Cullen Jennings) Yes

(Jari Arkko) No Objection

(Ron Bonica) (was Discuss) No Objection

Comment (2007-10-31 for -)
No email
send info
Ths is a very useful framework document, but framework documents are generally INFORMATIONAL

(Ross Callon) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2007-10-27)
No email
send info
  This architecture is really, really complex. Are people really
  implementing the pieces to build this whole framework?

(Russ Housley) No Objection

(Jon Peterson) No Objection

Comment (2007-11-15 for -)
No email
send info
10.2 discusses at a high level a fairly complicated mechanism for balancing degrees of anonymity in the system ("hidden", etc). It would be nice if there were a pointer here to a document where that story is further elaborated.

(Tim Polk) (was No Record, Discuss) No Objection

(Dan Romascanu) No Objection

Comment (2007-10-30 for -)
No email
send info
I like the document which does provide useful and complete information on centralized conferencing. However I join Lars DISCUSS questioning whether this needs to be Proposed Standard. I am curious to hear the shepherd and WG justification of why this is a PS and what is normative text.

Also, I think that the following part in the anstract is mis-leading: 'The Centralized Conferencing Framework defines logical entities and naming conventions, along with a high level conferencing data model.'. There is no data model definition in this document, terminology and functional decomposition diagrams do not qualify for data models.

(Mark Townsley) No Objection

(David Ward) (was No Record, No Objection) No Objection

Comment (2007-11-14 for -)
No email
send info
As with others, this should be INFO and cleaned up.

Magnus Westerlund No Objection

(Lisa Dusseault) (was No Objection) No Record