[Ballot comment]
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.

[Ballot discuss]
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.

[Ballot discuss]
(This is a two part discuss.  Part 1 was previously submitted as a preliminary discuss.  Part 2 specifies a new set of concerns.)

Part 1:

Kurt Zeilenga's secdir review, and Eric Rescorla's follow-up, identified a number of issues
in the security considerations section.  Specific issues include insertion of text concerning
denial of service in section 10, clarification of the authentication/authorization text in
10.1, and refining the discussion of randomness in passwords and PINs (also in 10.1). 
This discuss is a placeholder for resolution of those issues.

Part 2:

The complexity and high level of abstraction of the xcon framework introduces a number of
security problems that should be highlighted in this document.  To get my head around this,
I had to fall back and review RFC 4353, "Conferencing Framework With SIP". While RFC 4353
includes SIP and non-SIP protocols (e.g., to communicate with the conference policy server)
all participants share the SIP namespace and common authentication mechanisms.  This
simplifies specification of policies and helps ensure that authorization mechanisms are
applied to the correct participants.

The xcon framework is not SIP specific, so the first problem is the lack of a shared
namespace.  The membership specified in a conference object may need to be mapped from
one namespace to another by the focus, since a variety of signaling protocols are possible.
This mapping becomes a security-sensitive operation, so the mapping database has to have
integrity when it is established, the integrity has to be protected, and the database has
to be maintained to ensure changes in namespaces are accurately reflected.

Different conferencing protocols will support different types of authentication mechanisms.
To ensure that policies are adequately enforced, mechanisms are needed to specify the
acceptable range of authentication mechanisms when users assume a particular role.  Users
may use different authentication mechanisms (and different namespaces!) when assuming different
roles.  It is unclear if xcon-common-data-model supports the necessary features to ensure
appropriate security is achieved.

I believe that these issues need to be highlighted in both the body of the document and the
security considerations section.

[Ballot discuss]
I will fill this in in more detail as the telechat approaches two
weeks from now.

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 permission things to be in scope.  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 permissions etc.

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

This part definitely seems very over-complex.

Finally, I'm concerned about the complexity and interoperability of
the spec as a whole.  I am having difficulty articulating my concerns,
but section 9 definitely makes me worried.

[Ballot discuss]
(This is a preliminary discuss.  I am still trying to get my head around this work, so I
may be adding additional issues.)

Kurt Zeilenga's secdir review, and Eric Rescorla's follow-up, identified a number of issues
in the security considerations section.  Specific issues include insertion of text concerning
denial of service in section 10, clarification of the authentication/authorization text in
10.1, and refining the discussion of randomness in passwords and PINs (also in 10.1). 
This discuss is a placeholder for resolution of those issues.

[Ballot comment]
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.

[Ballot discuss]
DISCUSS: Why is this going for PS? There is nothing in here that
  people can build interoperable implementations from. IMO, it should be
  published as Informational, which is what we usually do for framework
  documents. I also note that the document has no normative references,
  which is very unusual for a standards track document.

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Adam Roach <adam@nostrum.com> has personally reviewed this version
of the  document, and beleives it is ready to be forwarded to the
IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The only concerns with review coverage relate to the relatively low
level of participation in the XCON working group in contrast to the
level of participation in working groups dealing with related
technologies (cf. SIPPING, SIP, SIMPLE). In comparision to working
groups operating in other areas, participation in discussions and
review appears to have been within the norm.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

The shepherd does not beleive that review outside the context of the
XCON working group is warranted.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

The document shepherd has no concerns with the document contents or
purpose.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

The document has been the primary focus of both mailing-list discussions
and face-to-face dicsussions for several years. It represents the most
fundamental points of agreement within the XCON working group, with
buy-in from the overwhelming preponderance of the active working
group participants.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

If applicable, the responsible area director has been notified of
any such issues.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

The document satisfies all ID Nits, in both content and formatting.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The document contains no normative references. All references are
clearly indicated as being informative.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

The document does not require any IANA actions, and contains a section
indicating this fact.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

The document does not make use of any formal language.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary

    This document defines the framework for Centralized
    Conferencing.  The framework allows participants using
    various call signaling protocols, such as SIP, H.323,
    Jabber and various protocols used in the PSTN, to
    exchange media in a centralized unicast conference.
    The Centralized Conferencing Framework defines logical
    entities and naming conventions, along with a high
    level conferencing data model.  The framework also
    outlines a set of conferencing protocols, which are
    complementary to the call signaling protocols, for
    building advanced conferencing applications.  The
    framework binds all the defined components together
    for the benefit of builders of conferencing systems.

          Working Group Summary

            This document is a product of the XCON working group.
            It captures some of the most important consensus decisions
            in the working group's history, and forms the foundation
            of the conference control protocol that XCON will ultimately
            publish.

          Document Quality

            The document has been reviewed for technical quality
            by Adam Roach.

            The document specifies a framework and important
            concepts, but does not define an implementable protocol
            (which is a separate deliverable of the XCON working
            group). A group of students at Universita' di Napoli
            Federico II (Naples University) have implemented their
            own protocol based on the concepts in the XCON framework;
            however, because no protocol has been formally defined
            by XCON yet, interoperability isn't possible.  See
            https://sourceforge.net/projects/confiance/ for details.

            The document itself underwent a detailed review by assigned
            reviewers in September of 2005. Detailed reviewers included
            David Morgan, Oscar Novo, Roni Even, and Umesh Chandra.