A Framework for Centralized Conferencing
RFC 5239
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14 |
11 | (System) | Notify list changed from adam@nostrum.com, alan.johnston@mci.com, draft-ietf-xcon-framework@ietf.org to adam@nostrum.com |
2012-08-22 |
11 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22 |
11 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
2008-06-10 |
11 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
2008-06-10 |
11 | Cindy Morgan | [Note]: 'RFC 5239 Adam Roach is proto shepherd' added by Cindy Morgan |
2008-06-09 |
11 | (System) | RFC published |
2008-05-15 |
11 | (System) | IANA Action state changed to No IC from In Progress |
2008-05-08 |
11 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2008-05-08 |
11 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2008-05-08 |
11 | Cindy Morgan | IESG has approved the document |
2008-05-07 |
11 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2008-05-07 |
11 | (System) | IANA Action state changed to In Progress |
2008-05-07 |
11 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2008-05-07 |
11 | Cindy Morgan | IESG has approved the document |
2008-05-07 |
11 | Cindy Morgan | Closed "Approve" ballot |
2008-05-02 |
11 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2008-05-02 |
11 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
2008-04-11 |
11 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-04-11 |
11 | (System) | New version available: draft-ietf-xcon-framework-11.txt |
2007-11-15 |
11 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2007-11-15 |
11 | Lisa Dusseault | [Ballot Position Update] Position for Lisa Dusseault has been changed to Undefined from No Objection by Lisa Dusseault |
2007-11-15 |
11 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
2007-11-15 |
11 | Ron Bonica | [Ballot Position Update] Position for Ron Bonica has been changed to No Objection from Discuss by Ron Bonica |
2007-11-15 |
11 | (System) | [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by IESG Secretary |
2007-11-15 |
11 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2007-11-15 |
11 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2007-11-15 |
11 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2007-11-15 |
11 | Jon Peterson | [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 ... [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. |
2007-11-14 |
11 | David Ward | [Ballot Position Update] Position for David Ward has been changed to No Objection from Undefined by David Ward |
2007-11-14 |
11 | David Ward | [Ballot Position Update] Position for David Ward has been changed to Undefined from No Objection by David Ward |
2007-11-14 |
11 | David Ward | [Ballot comment] As with others, this should be INFO and cleaned up. |
2007-11-14 |
11 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2007-11-14 |
11 | Sam Hartman | [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 ... [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. |
2007-11-14 |
11 | Tim Polk | [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.) ... [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. |
2007-11-14 |
11 | (System) | State Changes to IESG Evaluation from IESG Evaluation - Defer by system |
2007-11-09 |
10 | (System) | New version available: draft-ietf-xcon-framework-10.txt |
2007-11-02 |
11 | (System) | Removed from agenda for telechat - 2007-11-01 |
2007-11-01 |
11 | Sam Hartman | [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 ... [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. |
2007-11-01 |
11 | Sam Hartman | [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman |
2007-11-01 |
11 | Jon Peterson | State Changes to IESG Evaluation - Defer from IESG Evaluation by Jon Peterson |
2007-10-31 |
11 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2007-10-31 |
11 | Ron Bonica | [Ballot comment] Ths is a very useful framework document, but framework documents are generally INFORMATIONAL |
2007-10-31 |
11 | Ron Bonica | [Ballot Position Update] New position, Discuss, has been recorded by Ron Bonica |
2007-10-31 |
11 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2007-10-30 |
11 | Tim Polk | [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.) ... [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. |
2007-10-30 |
11 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2007-10-30 |
11 | Dan Romascanu | [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 ... [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. |
2007-10-30 |
11 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2007-10-29 |
11 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2007-10-27 |
11 | Cullen Jennings | [Note]: 'Adam Roach is proto shepherd' added by Cullen Jennings |
2007-10-27 |
11 | Lars Eggert | [Ballot comment] This architecture is really, really complex. Are people really implementing the pieces to build this whole framework? |
2007-10-27 |
11 | Lars Eggert | [Ballot discuss] DISCUSS: Why is this going for PS? There is nothing in here that people can build interoperable implementations from. IMO, it should ... [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. |
2007-10-27 |
11 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
2007-10-24 |
11 | Cullen Jennings | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Cullen Jennings |
2007-10-24 |
11 | Cullen Jennings | Placed on agenda for telechat - 2007-11-01 by Cullen Jennings |
2007-10-24 |
11 | Cullen Jennings | [Ballot Position Update] New position, Yes, has been recorded for Cullen Jennings |
2007-10-24 |
11 | Cullen Jennings | Ballot has been issued by Cullen Jennings |
2007-10-24 |
11 | Cullen Jennings | Created "Approve" ballot |
2007-10-22 |
11 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2007-10-18 |
11 | Amanda Baber | As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2007-10-09 |
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Kurt Zeilenga |
2007-10-09 |
11 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Kurt Zeilenga |
2007-10-08 |
11 | Amy Vezza | Last call sent |
2007-10-08 |
11 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2007-10-05 |
11 | Cullen Jennings | Last Call was requested by Cullen Jennings |
2007-10-05 |
11 | Cullen Jennings | State Changes to Last Call Requested from AD Evaluation by Cullen Jennings |
2007-10-05 |
11 | (System) | Ballot writeup text was added |
2007-10-05 |
11 | (System) | Last call text was added |
2007-10-05 |
11 | (System) | Ballot approval text was added |
2007-10-05 |
11 | Cullen Jennings | State Changes to AD Evaluation from Publication Requested by Cullen Jennings |
2007-08-24 |
11 | Cullen Jennings | [Note]: 'Adam Roach is proto shepherd and holder of the AD Cattle prod ' added by Cullen Jennings |
2007-08-24 |
11 | Cullen Jennings | State Changes to Publication Requested from AD is watching by Cullen Jennings |
2007-08-24 |
11 | Cullen Jennings | State Change Notice email list have been change to adam@nostrum.com, alan.johnston@mci.com, draft-ietf-xcon-framework@tools.ietf.org from adam@nostrum.com, alan.johnston@mci.com |
2007-08-24 |
11 | Cullen Jennings | Intended Status has been changed to Proposed Standard from Informational |
2007-08-24 |
11 | Cullen Jennings | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the ... (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. |
2007-08-06 |
09 | (System) | New version available: draft-ietf-xcon-framework-09.txt |
2007-05-15 |
08 | (System) | New version available: draft-ietf-xcon-framework-08.txt |
2007-01-23 |
07 | (System) | New version available: draft-ietf-xcon-framework-07.txt |
2006-12-05 |
06 | (System) | New version available: draft-ietf-xcon-framework-06.txt |
2006-09-12 |
05 | (System) | New version available: draft-ietf-xcon-framework-05.txt |
2006-06-23 |
04 | (System) | New version available: draft-ietf-xcon-framework-04.txt |
2006-03-28 |
11 | Cullen Jennings | Shepherding AD has been changed to Cullen Jennings from Allison Mankin |
2006-03-09 |
03 | (System) | New version available: draft-ietf-xcon-framework-03.txt |
2005-10-27 |
02 | (System) | New version available: draft-ietf-xcon-framework-02.txt |
2005-10-12 |
11 | Allison Mankin | Draft Added by Allison Mankin in state AD is watching |
2005-07-18 |
01 | (System) | New version available: draft-ietf-xcon-framework-01.txt |
2005-05-02 |
00 | (System) | New version available: draft-ietf-xcon-framework-00.txt |