From xcon-bounces@ietf.org Wed Oct 03 08:37:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3Tj-0006Bg-Tx; Wed, 03 Oct 2007 08:37:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id3Ti-0006B1-19; Wed, 03 Oct 2007 08:37:26 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Id3Th-0007Qm-CO; Wed, 03 Oct 2007 08:37:25 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7D508204E3; Wed, 3 Oct 2007 14:37:24 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-fb-47038d04dd94 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 62F91203EE; Wed, 3 Oct 2007 14:37:24 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 14:37:24 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 14:37:23 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B89512442; Wed, 3 Oct 2007 15:37:23 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6CB884DC26; Wed, 3 Oct 2007 15:37:23 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 04CB64DB21; Wed, 3 Oct 2007 15:37:22 +0300 (EEST) From: Salvatore Loreto To: Adam Roach In-Reply-To: <46C6334B.2030806@nostrum.com> References: <46C6334B.2030806@nostrum.com> Content-Type: text/plain Date: Wed, 03 Oct 2007 15:37:22 +0300 Message-Id: <1191415042.13681.119.camel@n85.nomadiclab.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 03 Oct 2007 12:37:24.0073 (UTC) FILETIME=[26107D90:01C805BA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: XCON-IETF , "'simple@ietf.org'" Subject: [XCON] Re: [Simple] Chatroom Gap Analysis X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Adam, I have read the draft and I really like it, it is a good and useful overview. I have just a couple of questions: 1)in section 2.1.9 "Sending Files and Images to a Chatroom" Even if it is true that MSRP inherently support sending of arbitrary content, I thinks should more correct provide a mechanism that let the user to decide if to accept or not a particular File. Something like the mechanism designed in the mmusic-file-transfer-mech 2)in section 2.4.2 "Discovery of Client Chatroom Support" you claim the necessity of two new feature tags for MSRP and CPIM support. Why do you think 'message' media type it is not enough? This media feature tag already indicate that a particular device supports 'message' as a streaming media type. Another possibility is using, as done in the mmusic-file-transfer-mech, the mechanism provided in SDP Offer/Answer Model (RFC3264) for indicating a capability to another endpoint (Section 9 of RFC 3264). RFC 3264 indicates how to build the SDP that is included in the response to a capability query like OPTION. It state that and endpoint builds an SDP body that contains an "m=" line that contains the media type (message, for MSRP). An endpoint that supports the simple-chat SHOULD also add a 'chatroom' media attribute for the "m=message" line. what do you think ? /Sal On Fri, 2007-08-17 at 18:46 -0500, Adam Roach wrote: > As we discussed in Chicago, I have produced a gap analysis document that > discusses the features available in currently deployed chatroom systems > and which of these can be achieved using protocols defined by or > currently under definition within the IETF. > > Until it appears in the archives, you can grab a copy from: > > http://www.nostrum.com/~adam/ids/draft-roach-xcon-chatroom-analysis-00.txt > or > http://www.nostrum.com/~adam/ids/draft-roach-xcon-chatroom-analysis-00.html > > (The document isn't as polished as I'd like, but I think it gets all the > important information across). > > /a > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sat Oct 06 10:27:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeAco-0006co-ET; Sat, 06 Oct 2007 10:27:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeAcm-0006RC-Dx for xcon@ietf.org; Sat, 06 Oct 2007 10:27:24 -0400 Received: from cse.stfx.ca ([141.109.37.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IeAcd-0007F4-A4 for xcon@ietf.org; Sat, 06 Oct 2007 10:27:16 -0400 Received: from cse.stfx.ca (localhost [127.0.0.1] (may be forged)) by cse.stfx.ca (8.14.1/8.13.8) with ESMTP id l96Dn7r7019822 for ; Sat, 6 Oct 2007 10:49:07 -0300 Received: (from mello@localhost) by cse.stfx.ca (8.14.1/8.13.8/Submit) id l96Dn7a2019821; Sat, 6 Oct 2007 10:49:07 -0300 Date: Sat, 6 Oct 2007 10:49:07 -0300 Message-Id: <200710061349.l96Dn7a2019821@cse.stfx.ca> To: xcon@ietf.org From: ltyang@gmail.com X-Mailer: PHP/5.1.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Subject: [XCON] CFP: CSE-08 in Brazil X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ltyang@gmail.com List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Please apologize for multiple copies. *Call for Papers and Workshop Proposals* * 9th IEEE International Conference on Computational Science and Engineering * CSE-08 http://www.icmc.usp.br/cse08 June 25-27, 2008 - Sao Paulo - Brazil *Important Dates* ================= Workshop Proposals due: November 30, 2007 Paper submission due: January 11, 2008 Paper notification of acceptance: March 14, 2008 Final camera ready: April 11, 2008 *Paper submission* ================== Paper submission web site http://cse.stfx.ca/~cse08/sub/ Authors are expected to submit a paper in the PDF format with 5-10 keywords following the IEEE CS format (http://www.icmc.usp.br/~cse08/submission.html). Program committee members and external reviewers will provide authors with at least three technical reviews. Submitted papers will be ranked based on relevance to the Conference and technical merit. Final version of accepted papers should at most 8 pages and will be published by IEEE Computer Society Press as CSE-08 conference proceedings. Authors of accepted papers, or at least one of them, are requested to register and present their work at the conference, otherwise their papers will be removed from the IEEE Digital Library after the conference. Selected best papers will be awarded and also considered for a special issue of International Journal of Computational Science and Engineering (IJCSE) and International Journal of High Performance Computing and Networking (IJHPCN). *Workshop Proposals* ==================== We encourage researches to submit their workshop proposals (according to the guidelines available at http://www.icmc.usp.br/~cse08/submission.html) in any one of the areas listed in the Scope (below) to cse08@icmc.usp.br with the subject 'CSE-08 WORKSHOP PROPOSAL'. *Scope* ======= The Computational Science and Engineering area has earned prominence through advances in electronic and integrated technologies beginning in the 1940s. Current times are very exciting and the years to come will witness a proliferation in the use of advanced computing systems. The scientific and engineering application domains have a key role in shaping future research and development activities in academia and industry, especially when the solution of large and complex problems must cope with tight timing schedules. This Conference is to bring together computer scientists, applied mathematicians, engineers in different disciplines and researchers to present, discuss and exchange ideas, results and experiences in the area of advanced computing for problems in science and engineering applications and inter-disciplinary applications. Among the main topics of interest (but not limited to) are: - Intelligent, Bioinspired and Autonomic Computing - Distributed and Parallel Computing - Distributed Database and Data Mining - Grid, P2P, Web Services and Internet Computing - Mobile Computing and Wireless Communications - HPC Applications - Scientific and Engineering Computing - Embedded and Ubiquitous Computing - Advanced Networking and Applications - Security, Privacy and Trust - Education in Computational Scientific and Engineering - Applications to the following areas, but not limited to: - computational fluid dynamics and mechanics - material sciences - space, weather, climate systems and global changes - computational environment and energy systems - computational ocean and earth sciences - combustion system simulation - computational chemistry - computational physics - bioinformatics and computational biology - medical applications - transportation systems simulations - combinatorial and global optimization problems - structural engineering - computational electro-magnetic - computer graphics and multimedia - semiconductor technology, and electronic circuits and system design - dynamic systems - computational finance - data mining - signal and image processing, etc *Programm Committee* ==================== General Co-Chairs Liria Matsumoto Sato, EP - University of Sao Paulo, Brazil Rodrigo Fernandes de Mello, ICMC - University of Sao Paulo, Brazil Kuan-Ching Li, Providence University, Taiwan Steering Committee Steering Committee Co-Chairs Laurence Tianruo Yang, St. Francis Xavier University, Canada Siang Wun Song, IME - University of Sao Paulo, Brazil Steering Committee Members Jack Dongarra, University of Tennessee, USA Cho-Li Wang, The University of Hong Kong, China Philippe Navaux, Federal University of Rio Grande do Sul, Brazil Alvaro L.G.A. Coutinho, Federal University of Rio de Janeiro, Brazil Jiannong Cao, Hong Kong Polytechnic University, China Rodrigo Fernandes de Mello, ICMC - University of Sao Paulo, Brazil Kuan-Ching Li, Providence University, Taiwan Program Co-Chairs Jose Alberto Cuminato, ICMC - University of Sao Paulo, Brazil Mark Baker, University of Reading, UK Program Vice-Chairs Intelligent, Bioinspired and Autonomic Computing Andre Carlos Ponce de Leon Ferreira de Carvalho, ICMC - University of Sao Paulo, Brazil Distributed and Parallel Computing Marcin Paprzycki, Systems Research Institute Polish Academy of Science, Poland Distributed Database and Data Mining Sunil Prabhakar, Purdue University, USA Grid, P2P, Web Services and Internet Computing Ching-Hsien Hsu, Chung-Hua University, Taiwan Mobile Computing and Wireless Communications Alvin Chan, The Hong Kong Polytechnic University, Hong Kong HPC Applications Daniel Katz, Louisiana State University, USA Scientific and Engineering Computing Osni Marques, Lawrence Berkeley National Laboratory, USA Embedded and Ubiquitous Computing Meikang Qiu, University of New Orleans, USA Advanced Networking and Applications Security, Privacy and Trust Adriano Mauro Cansian, Paulista State University, Brazil Local Arrangements Chairs Maio Donato Marino, EP - University of Sao Paulo, Brazil Francisco Isidro Massetto, EP - University of Sao Paulo, Brazil Evgueni Dodonov, ICMC - University of Sao Paulo, Brazil Jose Augusto Andrade Filho, ICMC - University of Sao Paulo, Brazil Marcelo Keese Albertini, ICMC - University of Sao Paulo, Brazil Ricardo Bertagna, ICMC - University of Sao Paulo, Brazil Publication Chair Luciano Jose Senger, State University of Ponta Grossa, Brazil Panel/Sponsorship Chairs Edson dos Santos Moreira, ICMC - University of Sao Paulo, Brazil Luis Carlos Trevelin, Federal University of Sao Carlos, Brazil Leandro Franco de Souza, ICMC - University of Sao Paulo, Brazil Web Chair Claudia Alves de Souza Mello, St. Francis Xavier University, Canada *About the Conference* ====================== This Conference was previously held as the International Workshop on High Performance Scientific and Engineering Computing for eight editions, previously held as HPSEC-99 (Fukushima, Japan, September 1999), HPSEC-00 (Toronto, Canada, August, 2000), HPSEC-01 (Valencia, Spain, September, 2001), HPSEC-02 (Vancouver, Canada, August, 2002), HPSEC-03 (Kaohsing, Taiwan, October, 2003), HPSEC-04 (Montreal, Canada, August, 2004), HPSEC-05 (Oslo, Norway, June, 2005), and HPSEC-06 (Columbus, USA, August, 2006). After many successful editions, this conference will be organized independently starting in 2008, in Sao Paulo, Brazil. This Conference is sponsored by IEEE TCSC Technical Committee on Scalable Computing and IEEE Computer Society. *About Sao Paulo, Brazil* ========================= Sao Paulo, the 19a richest city of the world, is officially inserted in a larger metropolitan region which holds 39 towns in total, and a population of more than 19 million inhabitants (2005). It is one of the biggest financial centers of Brazil and the world. Its economy is going through a deep transformation. Once a city with a strong industrial character, Sao Paulo's economy has become increasingly based on the tertiary sector, focusing on services and businesses for the country. Sao Paulo is located on a plateau, part of the vast region known as the Brazilian Highlands, with an average elevation of around 800 metres (2,625 ft) above sea level - though at a distance of only about 70 kilometers (43 mi) from the Atlantic Ocean. This distance is covered by two highways, the Anchieta and the Imigrantes, that roll down the range, leading to the portuary city of Santos and the beach resort of Guaruja. Rolling terrain prevails within the urbanized areas of Sao Paulo but in the North of the city - where the Serra da Cantareira Range boasts higher elevations and a sizable remnant of the Atlantic Rain Forest. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Oct 08 09:30:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iesfu-0007fS-RU; Mon, 08 Oct 2007 09:29:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iesfp-0007Fo-NK; Mon, 08 Oct 2007 09:29:29 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iesfp-0008Oa-FF; Mon, 08 Oct 2007 09:29:29 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 2448F175A5; Mon, 8 Oct 2007 13:28:59 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IesfK-00022f-M2; Mon, 08 Oct 2007 09:28:58 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 08 Oct 2007 09:28:58 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: xcon@ietf.org Subject: [XCON] Last Call: draft-ietf-xcon-framework (A Framework for Centralized Conferencing) to Proposed Standard X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org The IESG has received a request from the Centralized Conferencing WG (xcon) to consider the following document: - 'A Framework for Centralized Conferencing ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-10-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13106&rfc_flag=0 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Oct 09 16:56:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfM7o-00023d-FV; Tue, 09 Oct 2007 16:56:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUuSD-0003qN-VC; Fri, 23 Mar 2007 20:49:57 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUuSA-0007om-Kn; Fri, 23 Mar 2007 20:49:57 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l2O0nmEl021455; Fri, 23 Mar 2007 20:49:48 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l2O0nkql024925; Fri, 23 Mar 2007 20:49:47 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Mar 2007 20:49:46 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Mar 2007 20:49:45 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 Thread-Index: AcdtrlF7yP7eXFUGRuWBdZFXUpRBTA== To: , X-OriginalArrivalTime: 24 Mar 2007 00:49:46.0658 (UTC) FILETIME=[51BF5820:01C76DAE] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.23.171934 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-Mailman-Approved-At: Tue, 09 Oct 2007 16:56:08 -0400 Cc: xcon@ietf.org, Black_David@emc.com, tsv-dir@ietf.org Subject: [XCON] tsv-dir review of draft-ietf-xcon-bfcp-connection-04 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. This is a relatively straightforward draft about how a client opens a TCP connection to a BFCP server when it has the server's transport address information. Section 3 ventures into the area of IP address selection - it references RFC 3484 (which is good) and then goes on to make additional comments and recommendations on usage and state of deployment of the techniques specified in RFC 3484. While there's nothing technically wrong with this text, the additional comments and recommendations are not specific to BFCP, and may belong in a more generic document. Section 4 starts with "All BFCP entities implement TLS ..." That is correct, as RFC 4582 requires this, but it would be better to cite RFC 4582 as part of this statement, e.g., "[RFC 4582] requires that all BFCP entities implement TLS ..." In the second paragraph of Section 4, I would change "can request the use of TLS" to "SHOULD request the use of TLS". Section 5.1 specifies that SubjectAltName ideFrom xcon-bounces@ietf.org Tue Oct 09 16:56:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfM7o-00023d-FV; Tue, 09 Oct 2007 16:56:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUuSD-0003qN-VC; Fri, 23 Mar 2007 20:49:57 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUuSA-0007om-Kn; Fri, 23 Mar 2007 20:49:57 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l2O0nmEl021455; Fri, 23 Mar 2007 20:49:48 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l2O0nkql024925; Fri, 23 Mar 2007 20:49:47 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Mar 2007 20:49:46 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Mar 2007 20:49:45 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 Thread-Index: AcdtrlF7yP7eXFUGRuWBdZFXUpRBTA== To: , X-OriginalArrivalTime: 24 Mar 2007 00:49:46.0658 (UTC) FILETIME=[51BF5820:01C76DAE] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.23.171934 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-Mailman-Approved-At: Tue, 09 Oct 2007 16:56:08 -0400 Cc: xcon@ietf.org, Black_David@emc.com, tsv-dir@ietf.org Subject: [XCON] tsv-dir review of draft-ietf-xcon-bfcp-connection-04 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. This is a relatively straightforward draft about how a client opens a TCP connection to a BFCP server when it has the server's transport address information. Section 3 ventures into the area of IP address selection - it references RFC 3484 (which is good) and then goes on to make additional comments and recommendations on usage and state of deployment of the techniques specified in RFC 3484. While there's nothing technically wrong with this text, the additional comments and recommendations are not specific to BFCP, and may belong in a more generic document. Section 4 starts with "All BFCP entities implement TLS ..." That is correct, as RFC 4582 requires this, but it would be better to cite RFC 4582 as part of this statement, e.g., "[RFC 4582] requires that all BFCP entities implement TLS ..." In the second paragraph of Section 4, I would change "can request the use of TLS" to "SHOULD request the use of TLS". Section 5.1 specifies that SubjectAltName identities in certificates are to be preferred to Subject identities. Is this specific to BFCP or more general? The following text appears to be an oversight: If the client knows the server's IP address, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP address known to the client. The client *always* knows the server's IP address (e.g., DNS returns it). I think the intended case here is that the client contacts the server using the server's IP address and as a result does not know the server's hostname. Rephrasing in that sort of fashion would also express a preference for hostname as certificate identity, which I believe is desirable. Section 6 disturbingly shifts between "password" and "pre-shared key" and appears to get a few things wrong in the process. To begin with, the statement that "TLS PSK mode is subject to offline dictionary attacks." is false when the PSK is high-entropy. OTOH, it is correct when the PSK is low-entropy (e.g., a password, or derived from a password without introduction of additional entropy). The discussion in Section 7.2 of RFC 4279 applies, especially the last paragraph about PSK generation. The section needs to be carefully revised to distinguish between "password" and "pre-shared key", especially given the mention of use of PBKDF2 to generate the latter from the former. Thanks,=20 --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Oct 09 16:56:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfM7o-00023i-Kc; Tue, 09 Oct 2007 16:56:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Rpw-0004gW-Cv; Thu, 05 Jul 2007 09:57:36 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Rpr-0008Q6-9O; Thu, 05 Jul 2007 09:57:35 -0400 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l65DvRh8009232; Thu, 5 Jul 2007 09:57:27 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l65DunR8013011; Thu, 5 Jul 2007 09:57:23 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 09:57:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jul 2007 09:57:21 -0400 Message-ID: In-Reply-To: <468CC0CA.7040805@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 Thread-Index: Ace+6xPAh196aV74QVK7eEEEYnu38wAIGufw References: <4675044C.9040004@ericsson.com> <468CC0CA.7040805@ericsson.com> To: X-OriginalArrivalTime: 05 Jul 2007 13:57:22.0774 (UTC) FILETIME=[6922A760:01C7BF0C] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.5.64133 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __ntities in certificates are to be preferred to Subject identities. Is this specific to BFCP or more general? The following text appears to be an oversight: If the client knows the server's IP address, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP address known to the client. The client *always* knows the server's IP address (e.g., DNS returns it). I think the intended case here is that the client contacts the server using the server's IP address and as a result does not know the server's hostname. Rephrasing in that sort of fashion would also express a preference for hostname as certificate identity, which I believe is desirable. Section 6 disturbingly shifts between "password" and "pre-shared key" and appears to get a few things wrong in the process. To begin with, the statement that "TLS PSK mode is subject to offline dictionary attacks." is false when the PSK is high-entropy. OTOH, it is correct when the PSK is low-entropy (e.g., a password, or derived from a password without introduction of additional entropy). The discussion in Section 7.2 of RFC 4279 applies, especially the last paragraph about PSK generation. The section needs to be carefully revised to distinguish between "password" and "pre-shared key", especially given the mention of use of PBKDF2 to generate the latter from the former. Thanks,=20 --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Oct 09 16:56:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfM7o-00023i-Kc; Tue, 09 Oct 2007 16:56:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Rpw-0004gW-Cv; Thu, 05 Jul 2007 09:57:36 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Rpr-0008Q6-9O; Thu, 05 Jul 2007 09:57:35 -0400 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l65DvRh8009232; Thu, 5 Jul 2007 09:57:27 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l65DunR8013011; Thu, 5 Jul 2007 09:57:23 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 09:57:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jul 2007 09:57:21 -0400 Message-ID: In-Reply-To: <468CC0CA.7040805@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 Thread-Index: Ace+6xPAh196aV74QVK7eEEEYnu38wAIGufw References: <4675044C.9040004@ericsson.com> <468CC0CA.7040805@ericsson.com> To: X-OriginalArrivalTime: 05 Jul 2007 13:57:22.0774 (UTC) FILETIME=[6922A760:01C7BF0C] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.5.64133 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 X-Mailman-Approved-At: Tue, 09 Oct 2007 16:56:08 -0400 Cc: fluffy@cisco.com, tsv-dir@ietf.org, ietf@ietf.org, Black_David@emc.com, xcon@ietf.org Subject: [XCON] RE: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Gonzalo, The -05 draft looks fine, and I have no problem with leaving comment (1) [whether to say something applicable beyond BFCP on the subjects of IP address selection and use of SubjectAltName] to the discretion of the ADs. Thanks, --David > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Thursday, July 05, 2007 5:59 AM > To: Black, David > Cc: ietf@ietf.org; xcon@ietf.org; tsv-dir@ietf.org; fluffy@cisco.com > Subject: Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 >=20 > Hi David, >=20 > I have put together a new revision of the draft that=20 > addresses all your=20 > comments. Regarding your comment (1), I will send a note to=20 > the ADs so=20 > that they decide what to do. >=20 > Until the draft appears in the archives, it can be fetched from: >=20 > http://users.piuha.net/gonzalo/temp/draft-ietf-xcon-bfcp-conne ction-05.txt >=20 > Thanks, >=20 > Gonzalo >=20 > Black_David@emc.com wrote: > > Gonzalo, > >=20 > > Most of this looks good; I have a few comments: > >=20 > > (1) In the two places where there are general recommendations that > > are not specific to BFCP (IP address selection and use of > > SubjectAltName in certs in preference to Subject), it would > > be good to note that these are general recommendations > > that are not specific to BFCP, **but** please consult your > > AD on whether and how to do this, as these are cross-area > > issues in the IETF. The existing text is ok. > >=20 > > (2) I would change the sentence about PBKDF2 key strengthening, > > as the use of "security" is questionable:=20 > >=20 > > OLD: > > Because such key derivation functions may incorporate > > iteration functions for key strengthening they provide some > > additional security against dictionary attacks. > > NEW:=20 > > Because such key derivation functions may incorporate > > iteration functions for key strengthening they provide some > > additional protection against dictionary attacks by > > increasing the amount of work that the attacker must perform. > >=20 > > (3) Regarding the "obtain" language, I would make the following > > change to explain why the attacks don't apply - > >=20 > > OLD: > > When the keys are randomly generated and of sufficient length, > > these attacks do not obtain. > > NEW: > > When the keys are randomly generated and of sufficient length, > > dictionary attacks are not effective because such keys are > > highly unlikely to be in the attacker's dictionary. > >=20 > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > >=20 > >> -----Original Message----- > >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > >> Sent: Sunday, June 17, 2007 5:52 AM > >> To: Black, David > >> Cc: ietf@ietf.org; xcon@ietf.org; tsv-dir@ietf.org; Cullen Jennings > >> Subject: Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 > >> > >> HHAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 X-Mailman-Approved-At: Tue, 09 Oct 2007 16:56:08 -0400 Cc: fluffy@cisco.com, tsv-dir@ietf.org, ietf@ietf.org, Black_David@emc.com, xcon@ietf.org Subject: [XCON] RE: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Gonzalo, The -05 draft looks fine, and I have no problem with leaving comment (1) [whether to say something applicable beyond BFCP on the subjects of IP address selection and use of SubjectAltName] to the discretion of the ADs. Thanks, --David > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Thursday, July 05, 2007 5:59 AM > To: Black, David > Cc: ietf@ietf.org; xcon@ietf.org; tsv-dir@ietf.org; fluffy@cisco.com > Subject: Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 >=20 > Hi David, >=20 > I have put together a new revision of the draft that=20 > addresses all your=20 > comments. Regarding your comment (1), I will send a note to=20 > the ADs so=20 > that they decide what to do. >=20 > Until the draft appears in the archives, it can be fetched from: >=20 > http://users.piuha.net/gonzalo/temp/draft-ietf-xcon-bfcp-conne ction-05.txt >=20 > Thanks, >=20 > Gonzalo >=20 > Black_David@emc.com wrote: > > Gonzalo, > >=20 > > Most of this looks good; I have a few comments: > >=20 > > (1) In the two places where there are general recommendations that > > are not specific to BFCP (IP address selection and use of > > SubjectAltName in certs in preference to Subject), it would > > be good to note that these are general recommendations > > that are not specific to BFCP, **but** please consult your > > AD on whether and how to do this, as these are cross-area > > issues in the IETF. The existing text is ok. > >=20 > > (2) I would change the sentence about PBKDF2 key strengthening, > > as the use of "security" is questionable:=20 > >=20 > > OLD: > > Because such key derivation functions may incorporate > > iteration functions for key strengthening they provide some > > additional security against dictionary attacks. > > NEW:=20 > > Because such key derivation functions may incorporate > > iteration functions for key strengthening they provide some > > additional protection against dictionary attacks by > > increasing the amount of work that the attacker must perform. > >=20 > > (3) Regarding the "obtain" language, I would make the following > > change to explain why the attacks don't apply - > >=20 > > OLD: > > When the keys are randomly generated and of sufficient length, > > these attacks do not obtain. > > NEW: > > When the keys are randomly generated and of sufficient length, > > dictionary attacks are not effective because such keys are > > highly unlikely to be in the attacker's dictionary. > >=20 > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > >=20 > >> -----Original Message----- > >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > >> Sent: Sunday, June 17, 2007 5:52 AM > >> To: Black, David > >> Cc: ietf@ietf.org; xcon@ietf.org; tsv-dir@ietf.org; Cullen Jennings > >> Subject: Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 > >> > >> Hi David, > >> > >> thanks for your comments. Answers inline: > >> > >> Black_David@emc.com wrote: > >>> I've reviewed this document as part of the transport area > >>> directorate's ongoing effort to review key IETF documents. > >>> These comments were written primarily for the transport > >>> area directors, but are copied to the document's authors > >>> for their information and to allow them to address any > >>> issues raised. > >>> > >>> This is a relatively straightforward draft about how a > >>> client opens a TCP connection to a BFCP server when it > >>> has the server's transport address information. > >>> > >>> Section 3 ventures into the area of IP address selection - > >>> it references RFC 3484 (which is good) and then goes on to > >>> make additional comments and recommendations on usage and > >>> state of deployment of the techniques specified in RFC 3484. > >>> While there's nothing technically wrong with this text, the > >>> additional comments and recommendations are not specific > >>> to BFCP, and may belong in a more generic document. > >> Given that such a generic document does not exist, we need to=20 > >> give these=20 > >> recommendations here. > >> > >> > >>> Section 4 starts with "All BFCP entities implement TLS ..." > >>> That is correct, as RFC 4582 requires this, but it would be > >>> better to cite RFC 4582 as part of this statement, e.g., > >>> "[RFC 4582] requires that all BFCP entities implement TLS ..." > >> What about performing the following change? > >> > >> OLD: > >> > >> All BFCP entities implement TLS [7] and SHOULD use it in all their > >> connections. > >> > >> NEW: > >> > >> [RFC 4582] requires that all BFCP entities implement TLS and > > recommends=20 > >> that they use it in all their connections. > >> > >> > >>> In the second paragraph of Section 4, I would change > >>> "can request the use of TLS" to "SHOULD request the use > >>> of TLS". > >> OK, I will fix it. > >> > >>> Section 5.1 specifies that SubjectAltName identities in > >>> certificates are to be preferred to Subject identities. > >>> Is this specific to BFCP or more general? > >> We got that recommendation from our security adviser. I do=20 > not know=20 > >> whether this will be documented in a generic document at=20 > some point. > >> > >>> The following text appears to be an oversight: > >>> > >>> If the client knows the server's IP address, the iPAddress > >>> subjectAltName must be present in the certificate and must > >>> exactly match the IP address known to the client. > >>> > >>> The client *always* knows the server's IP address (e.g., > >>> DNS returns it). I think the intended case here is that > >>> the client contacts the server using the server's IP address > >>> and as a result does not know the server's hostname. Rephrasing > >>> in that sort of fashion would also express a preference for > >>> hostname as certificate identity, which I believe is desirable. > >> What about performing the following change?: > >> > >> OLD: > >> If the client knows the server's IP address, the iPAddress > >> subjectAltName must be present in the certificate and=20 > must exactly > >> match the IP address known to the client. > >> > >> NEW: > >> If the client does not know the server's hostname and=20 > contacts the > >> server directly using the server's IP address, the iPAddress > >> subjectAltName must be present in the certificate and=20 > must exactly > >> match the IP address known to the client. > >> > >> > >>> Section 6 disturbingly shifts between "password" and > >>> "pre-shared key" and appears to get a few things wrong in > >>> the process. To begin with, the statement that "TLS PSK mode > >>> is subject to offline dictionary attacks." is false when > >>> the PSK is high-entropy. OTOH, it is correct when the PSK > >>> is low-entropy (e.g., a password, or derived from a password > >>> without introduction of additional entropy). The discussion > >>> in Section 7.2 of RFC 4279 applies, especially the last > >>> paragraph about PSK generation. The section needs to bi David, > >> > >> thanks for your comments. Answers inline: > >> > >> Black_David@emc.com wrote: > >>> I've reviewed this document as part of the transport area > >>> directorate's ongoing effort to review key IETF documents. > >>> These comments were written primarily for the transport > >>> area directors, but are copied to the document's authors > >>> for their information and to allow them to address any > >>> issues raised. > >>> > >>> This is a relatively straightforward draft about how a > >>> client opens a TCP connection to a BFCP server when it > >>> has the server's transport address information. > >>> > >>> Section 3 ventures into the area of IP address selection - > >>> it references RFC 3484 (which is good) and then goes on to > >>> make additional comments and recommendations on usage and > >>> state of deployment of the techniques specified in RFC 3484. > >>> While there's nothing technically wrong with this text, the > >>> additional comments and recommendations are not specific > >>> to BFCP, and may belong in a more generic document. > >> Given that such a generic document does not exist, we need to=20 > >> give these=20 > >> recommendations here. > >> > >> > >>> Section 4 starts with "All BFCP entities implement TLS ..." > >>> That is correct, as RFC 4582 requires this, but it would be > >>> better to cite RFC 4582 as part of this statement, e.g., > >>> "[RFC 4582] requires that all BFCP entities implement TLS ..." > >> What about performing the following change? > >> > >> OLD: > >> > >> All BFCP entities implement TLS [7] and SHOULD use it in all their > >> connections. > >> > >> NEW: > >> > >> [RFC 4582] requires that all BFCP entities implement TLS and > > recommends=20 > >> that they use it in all their connections. > >> > >> > >>> In the second paragraph of Section 4, I would change > >>> "can request the use of TLS" to "SHOULD request the use > >>> of TLS". > >> OK, I will fix it. > >> > >>> Section 5.1 specifies that SubjectAltName identities in > >>> certificates are to be preferred to Subject identities. > >>> Is this specific to BFCP or more general? > >> We got that recommendation from our security adviser. I do=20 > not know=20 > >> whether this will be documented in a generic document at=20 > some point. > >> > >>> The following text appears to be an oversight: > >>> > >>> If the client knows the server's IP address, the iPAddress > >>> subjectAltName must be present in the certificate and must > >>> exactly match the IP address known to the client. > >>> > >>> The client *always* knows the server's IP address (e.g., > >>> DNS returns it). I think the intended case here is that > >>> the client contacts the server using the server's IP address > >>> and as a result does not know the server's hostname. Rephrasing > >>> in that sort of fashion would also express a preference for > >>> hostname as certificate identity, which I believe is desirable. > >> What about performing the following change?: > >> > >> OLD: > >> If the client knows the server's IP address, the iPAddress > >> subjectAltName must be present in the certificate and=20 > must exactly > >> match the IP address known to the client. > >> > >> NEW: > >> If the client does not know the server's hostname and=20 > contacts the > >> server directly using the server's IP address, the iPAddress > >> subjectAltName must be present in the certificate and=20 > must exactly > >> match the IP address known to the client. > >> > >> > >>> Section 6 disturbingly shifts between "password" and > >>> "pre-shared key" and appears to get a few things wrong in > >>> the process. To begin with, the statement that "TLS PSK mode > >>> is subject to offline dictionary attacks." is false when > >>> the PSK is high-entropy. OTOH, it is correct when the PSK > >>> is low-entropy (e.g., a password, or derived from a password > >>> without introduction of additional entropy). The discussion > >>> in Section 7.2 of RFC 4279 applies, especially the last > >>> paragraph about PSK generation. The section needs to be > >>> carefully revised to distinguish between "password" and > >>> "pre-shared key", especially given the mention of use of > >>> PBKDF2 to generate the latter from the former. > >> what about performing the following change?: > >> > >> OLD: > >> > >> TLS PSK mode is subject to offline dictionary attacks.=20 > In DHE and > >> RSA modes, an attacker who can mount a single man-in-the-middle > >> attack on a client/server pair can then mount a=20 > dictionary attack > > on > >> the password. In modes without DHE or RSA, an attacker who can > >> record communications between a client/server pair can mount a > >> dictionary attack on the password. Accordingly, it is=20 > RECOMMENDED > >> that where possible clients use certificate-based server > >> authentication ciphersuites with PSK in order to defend against > >> dictionary attacks. > >> > >> In addition, passwords SHOULD be chosen with enough entropy to > >> provide some protection against dictionary attacks. =20 > Because the > >> entropy of text varies dramatically and is generally=20 > far less than > >> that of an equivalent random bitstring, no hard and fast rules > > about > >> password length are possible. However, in general passwords > > SHOULD > >> be chosen to be at least 8 characters and selected from a pool > >> containing both upper and lower case, numbers, and special > > keyboard > >> characters (note that an 8-character ASCII password=20 > has a maximum > >> entropy of 56 bits and in general far lower). FIPS=20 > PUB 112 [11] > >> provides some guidance on the relevant issues. If possible, > >> passphrases are preferable to passwords. In addition, a > > cooperating > >> client and server pair MAY choose to derive the TLS=20 > PSK shared key > >> from the passphrase via a password-based key=20 > derivation function > > such > >> as PBKDF2 [2]. > >> > >> > >> NEW: > >> > >> TLS PSK simply relies on a pre-shared key without=20 > specifying the > >> nature of the key. In practice, such keys have two=20 > sources: text > >> passwords and randomly generated binary keys. When keys are > > derived > >> from passwords, TLS PSK mode is subject to offline dictionary > >> attacks. In DHE and RSA modes, an attacker who can=20 > mount a single > >> man-in-the-middle attack on a client/server pair can=20 > then mount a > >> dictionary attack on the password. In modes without=20 > DHE or RSA, an > >> attacker who can record communications between a client/server > > pair > >> can mount a dictionary attack on the password.=20 > Accordingly, it is > >> RECOMMENDED that where possible clients use certificate-based > >> server authentication ciphersuites with password-derived PSKs, > >> in order to defend against dictionary attacks. > >> > >> In addition, passwords SHOULD be chosen with enough entropy to > >> provide some protection against dictionary attacks. =20 > Because the > >> entropy of text varies dramatically and is generally=20 > far less than > >> that of an equivalent random bitstring, no hard and fast rules > > about > >> password length are possible. However, in general passwords > > SHOULD > >> be chosen to be at least 8 characters and selected from a pool > >> containing both upper and lower case, numbers, and special > > keyboard > >> characters (note that an 8-character ASCII password=20 > has a maximum > >> entropy of 56 bits and in general far lower). FIPS=20 > PUB 112 [11] > >> provides some guidance on the relevant issues. If possible, > >> passphrases are preferable to passwords. In addition, a > > cooperating > >> client and server pair MAY choose to derive the TLS=20 > PSK shared key > >> from the passphrase via a password-based key=20 > derivation function > > such > >> as PBKDF2 [2]. Because such key derivation functions may > > incorporate > >> iteration functions for key strengthening they provide some > >> additional security againe > >>> carefully revised to distinguish between "password" and > >>> "pre-shared key", especially given the mention of use of > >>> PBKDF2 to generate the latter from the former. > >> what about performing the following change?: > >> > >> OLD: > >> > >> TLS PSK mode is subject to offline dictionary attacks.=20 > In DHE and > >> RSA modes, an attacker who can mount a single man-in-the-middle > >> attack on a client/server pair can then mount a=20 > dictionary attack > > on > >> the password. In modes without DHE or RSA, an attacker who can > >> record communications between a client/server pair can mount a > >> dictionary attack on the password. Accordingly, it is=20 > RECOMMENDED > >> that where possible clients use certificate-based server > >> authentication ciphersuites with PSK in order to defend against > >> dictionary attacks. > >> > >> In addition, passwords SHOULD be chosen with enough entropy to > >> provide some protection against dictionary attacks. =20 > Because the > >> entropy of text varies dramatically and is generally=20 > far less than > >> that of an equivalent random bitstring, no hard and fast rules > > about > >> password length are possible. However, in general passwords > > SHOULD > >> be chosen to be at least 8 characters and selected from a pool > >> containing both upper and lower case, numbers, and special > > keyboard > >> characters (note that an 8-character ASCII password=20 > has a maximum > >> entropy of 56 bits and in general far lower). FIPS=20 > PUB 112 [11] > >> provides some guidance on the relevant issues. If possible, > >> passphrases are preferable to passwords. In addition, a > > cooperating > >> client and server pair MAY choose to derive the TLS=20 > PSK shared key > >> from the passphrase via a password-based key=20 > derivation function > > such > >> as PBKDF2 [2]. > >> > >> > >> NEW: > >> > >> TLS PSK simply relies on a pre-shared key without=20 > specifying the > >> nature of the key. In practice, such keys have two=20 > sources: text > >> passwords and randomly generated binary keys. When keys are > > derived > >> from passwords, TLS PSK mode is subject to offline dictionary > >> attacks. In DHE and RSA modes, an attacker who can=20 > mount a single > >> man-in-the-middle attack on a client/server pair can=20 > then mount a > >> dictionary attack on the password. In modes without=20 > DHE or RSA, an > >> attacker who can record communications between a client/server > > pair > >> can mount a dictionary attack on the password.=20 > Accordingly, it is > >> RECOMMENDED that where possible clients use certificate-based > >> server authentication ciphersuites with password-derived PSKs, > >> in order to defend against dictionary attacks. > >> > >> In addition, passwords SHOULD be chosen with enough entropy to > >> provide some protection against dictionary attacks. =20 > Because the > >> entropy of text varies dramatically and is generally=20 > far less than > >> that of an equivalent random bitstring, no hard and fast rules > > about > >> password length are possible. However, in general passwords > > SHOULD > >> be chosen to be at least 8 characters and selected from a pool > >> containing both upper and lower case, numbers, and special > > keyboard > >> characters (note that an 8-character ASCII password=20 > has a maximum > >> entropy of 56 bits and in general far lower). FIPS=20 > PUB 112 [11] > >> provides some guidance on the relevant issues. If possible, > >> passphrases are preferable to passwords. In addition, a > > cooperating > >> client and server pair MAY choose to derive the TLS=20 > PSK shared key > >> from the passphrase via a password-based key=20 > derivation function > > such > >> as PBKDF2 [2]. Because such key derivation functions may > > incorporate > >> iteration functions for key strengthening they provide some > >> additional security against dictionary attacks. > >> > >> When the keys are randomly generated and of sufficient length, > >> these attacks do not obtain. Where possible, keys SHOULD be > >> generated using a strong random number generator as specified > >> in RFC 4086 [REF]. A minimum key length of 80 bits=20 > SHOULD be used. > >> > >> > >> Thanks, > >> > >> Gonzalo > > =20 >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon st dictionary attacks. > >> > >> When the keys are randomly generated and of sufficient length, > >> these attacks do not obtain. Where possible, keys SHOULD be > >> generated using a strong random number generator as specified > >> in RFC 4086 [REF]. A minimum key length of 80 bits=20 > SHOULD be used. > >> > >> > >> Thanks, > >> > >> Gonzalo > > =20 >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Oct 10 08:37:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifao3-0002Wl-OO; Wed, 10 Oct 2007 08:36:55 -0400 Received: from xcon by megatron.ietf.org with local (Exim 4.43) id 1Ifao1-0002RF-JP for xcon-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 08:36:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifao1-0002Bf-7F for xcon@ietf.org; Wed, 10 Oct 2007 08:36:53 -0400 Received: from oslproxyp1.tandberg.com ([194.0.215.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifanx-00024r-L2 for xcon@ietf.org; Wed, 10 Oct 2007 08:36:50 -0400 Received: from OSLEXCP11.eu.tandberg.int (oslexcp11.eu.tandberg.int [10.47.136.43]) by oslproxyp1.tandberg.com (8.13.1/8.13.1) with ESMTP id l9ACalgG009697; Wed, 10 Oct 2007 14:36:47 +0200 Received: from oslexcp1.eu.tandberg.int ([10.47.136.29]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Oct 2007 14:36:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 10 Oct 2007 14:36:44 +0200 Message-ID: <9F6ACAE02B6DD040A1E259977622CFDB93A794@oslexcp1.eu.tandberg.int> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-sandbakken-xcon-bfcp-udp-00.txt Thread-Index: AcgLOjdlLx6NpVgMTVG5/Wd2Q42KsA== From: "Geir Arne Sandbakken" To: , "Gonzalo Camarillo" X-OriginalArrivalTime: 10 Oct 2007 12:36:47.0470 (UTC) FILETIME=[392390E0:01C80B3A] X-Scanned-By: MIMEDefang 2.62 on 194.0.215.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: "Alfred E. Heggestad" Subject: [XCON] draft-sandbakken-xcon-bfcp-udp-00.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0870686623==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0870686623== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80B3A.38CBED15" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80B3A.38CBED15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have an implementation of BFCP over UDP that we hope can be a starting point of a standardized version. =20 May we draw your attention to a new Internet Draft: http://www.ietf.org/internet-drafts/draft-sandbakken-xcon-bfcp-udp-00.tx t =20 Geir Arne =20 =20 =20 =20 =20 ------_=_NextPart_001_01C80B3A.38CBED15 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have an = implementation of BFCP over UDP that we hope can be a starting point of a standardized = version.

 

May we draw your = attention to a new Internet Draft:

http://www.ietf.org/internet-drafts/draft-sandbakken-xcon-bfcp-= udp-00.txt

 

Geir = Arne

 

 

 

 

 

------_=_NextPart_001_01C80B3A.38CBED15-- --===============0870686623== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0870686623==-- From xcon-bounces@ietf.org Wed Oct 10 08:40:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfarO-0000dw-4v; Wed, 10 Oct 2007 08:40:22 -0400 Received: from xcon by megatron.ietf.org with local (Exim 4.43) id 1IfarM-0000ck-L3 for xcon-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 08:40:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfarM-0000bX-9h for xcon@ietf.org; Wed, 10 Oct 2007 08:40:20 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfarJ-0002AM-UN for xcon@ietf.org; Wed, 10 Oct 2007 08:40:18 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5FD56203CD; Wed, 10 Oct 2007 14:40:17 +0200 (CEST) X-AuditID: c1b4fb3c-b067fbb0000007e1-88-470cc831809d Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 46C732071A; Wed, 10 Oct 2007 14:40:17 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 14:40:17 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 14:40:17 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A19E327D4; Wed, 10 Oct 2007 15:40:16 +0300 (EEST) Message-ID: <470CC830.9070209@ericsson.com> Date: Wed, 10 Oct 2007 15:40:16 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Geir Arne Sandbakken References: <9F6ACAE02B6DD040A1E259977622CFDB93A794@oslexcp1.eu.tandberg.int> In-Reply-To: <9F6ACAE02B6DD040A1E259977622CFDB93A794@oslexcp1.eu.tandberg.int> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Oct 2007 12:40:17.0241 (UTC) FILETIME=[B62C1490:01C80B3A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "Alfred E. Heggestad" , xcon@ietf.org Subject: [XCON] Re: draft-sandbakken-xcon-bfcp-udp-00.txt X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi, this was explicitly discussed when we started developing BFCP and the consensus was to build a simple protocol that would not include different transports. That is why later versions of the specification removed support for different transports. Cheers, Gonzalo Geir Arne Sandbakken wrote: > We have an implementation of BFCP over UDP that we hope can be a > starting point of a standardized version. > > > > May we draw your attention to a new Internet Draft: > > http://www.ietf.org/internet-drafts/draft-sandbakken-xcon-bfcp-udp-00.txt > > > > Geir Arne > > > > > > > > > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Oct 10 09:53:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifc07-0003MY-1x; Wed, 10 Oct 2007 09:53:27 -0400 Received: from xcon by megatron.ietf.org with local (Exim 4.43) id 1Ifc06-0003Ko-Am for xcon-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 09:53:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifc05-0003B6-Rg for xcon@ietf.org; Wed, 10 Oct 2007 09:53:25 -0400 Received: from oslproxyp1.tandberg.com ([194.0.215.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifc00-0004aK-7X for xcon@ietf.org; Wed, 10 Oct 2007 09:53:20 -0400 Received: from OSLEXCP11.eu.tandberg.int (oslexcp11.eu.tandberg.int [10.47.136.43]) by oslproxyp1.tandberg.com (8.13.1/8.13.1) with ESMTP id l9ADrI3u022184; Wed, 10 Oct 2007 15:53:18 +0200 Received: from oslexcp1.eu.tandberg.int ([10.47.136.29]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Oct 2007 15:53:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] draft-sandbakken-xcon-bfcp-udp-00.txt Date: Wed, 10 Oct 2007 15:53:13 +0200 Message-ID: <9F6ACAE02B6DD040A1E259977622CFDB93A7E1@oslexcp1.eu.tandberg.int> In-Reply-To: <470CCA9E.2030707@netlab.hut.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] draft-sandbakken-xcon-bfcp-udp-00.txt Thread-Index: AcgLPDeIoqAoqcosQlOZARfaHQEh4gAAMM2w From: "Geir Arne Sandbakken" To: "Joerg Ott" X-OriginalArrivalTime: 10 Oct 2007 13:53:18.0127 (UTC) FILETIME=[E9623BF0:01C80B44] X-Scanned-By: MIMEDefang 2.62 on 194.0.215.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: "Alfred E. Heggestad" , xcon@ietf.org, Gonzalo Camarillo X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org We use BFCP to floor control our main video and as token control of our second presentation video stream. It is a very important protocol for us. The need for using UDP as transport presented itself when we wanted to deploy into an existing infrastructure that had RTP proxies for NAT and firewall traversal. Using TCP as a transport was not an option without serious upgrades to the proxies, and a possible implementation of ICE-TCP. =20 Adding BFCP over UDP in such a proxy is trivial, and adjusting our implementation to support it in the endpoints was minor work. The solution is successfully deployed with very little effort. My view is that we do not want to change BFCP as such, but present an extension with a slightly different behavior when using UDP as transport. The TCP transport should be the baseline, and ICE should be addressed in the draft.=20 Thanks, Geir Arne > Hi, >=20 > we have carefully considered the alternatives when deciding > to define BFCP for TCP only. It would be nice if you could > expand further on the motivation and point out why TCP is > truly unsuitable for this purpose. And you will need to > address the issues of how to keep NAT bindings alive. Will > you it over ICE (the spec does not make any mention of this). >=20 > I would very much hope that we will not need yet another > spec for a trivial protocol, since then we will also have > to define a baseline for interoperability (which can only > be TCP, IMHO) and so on. >=20 > Cheers, > Joerg >=20 >=20 > > We have an implementation of BFCP over UDP that we hope can be a > > starting point of a standardized version. > > > > > > > > May we draw your attention to a new Internet Draft: > > > > http://www.ietf.org/internet-drafts/draft-sandbakken-xcon-bfcp-udp- > 00.txt > > > > > > > > Geir Arne > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Oct 12 05:57:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgHG9-0006Bp-Ow; Fri, 12 Oct 2007 05:56:45 -0400 Received: from xcon by megatron.ietf.org with local (Exim 4.43) id 1IgHG8-0006Ay-Hi for xcon-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 05:56:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgHG8-00061l-7S; Fri, 12 Oct 2007 05:56:44 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgHFw-00058T-SY; Fri, 12 Oct 2007 05:56:39 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5859820537; Fri, 12 Oct 2007 11:56:22 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-88-470f44c6d974 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3E4FC206C4; Fri, 12 Oct 2007 11:56:22 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 11:56:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Oct 2007 11:48:47 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XCON Chatroom consensus Thread-Index: AcgLGtFp9XDbU19zQQGQfZM9r8ux/ABhBlsg From: "Oscar Novo" To: , X-OriginalArrivalTime: 12 Oct 2007 09:56:21.0926 (UTC) FILETIME=[24B19C60:01C80CB6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: adam@nostrum.com Subject: [XCON] XCON Chatroom consensus X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi, I am the designated editor of a XCON data model WG document (draft-ietf-xcon-common-data-model-05). My purpose with this e-mail is to reach consensus about the required new fields in the XCON data model according to: http://tools.ietf.org/html/draft-roach-xcon-chatroom-analysis-00 Reading the document, it seems there are some sections that propose some modifications in the XCON data model. The following text explains these sections and the new elements we should add (in case we decide to add them) in the data model, comments and ideas are welcome: Section 2.4.3 (Password-Protected Chatrooms) "The current framework described in XCON uses user authentication for admissions control. However, some deployed systems instead use a single, chatroom-wide password that can be used to enter a chatroom. This allows users to disseminate the password as a kind of invitation token without explicitly provisioning the allowed users into the chatroom system." If we decide to add this feature, it will require a new field ("conference password") in the XCON data model under element. =20 2.4.4. (Private and Semi-Private Chatrooms) "Currently, the XCON model allows users to be marked individually as anonymous or not via their corresponding tag. Some systems, however, include a chatroom-wide setting that can be used to specify that all users in a chatroom are either completely anonymous (private), or anonymous to all users with equal or lesser permissions (semi-private)." If we decide to add this feature, it will require to modify the element with the values "private" and "semi-private" instead of Boolean. 2.4.5. (Banned Users) In addition to removing specific users from a conference, most deployed systems permit the specification of "banned" users. Such banned users are prevented from re-joining the chatroom until they have been un-banned. Currently it's needed additional work in the case where all users are authenticated"=20 If we decide to add this feature, a is needed to reject any users in the conference. 2.4.10.3. (Indication of Chatroom Log Archive Location) "Some systems include the ability for clients to access the on-line archive of a chatroom log from within the context of their chatroom client. (e.g., a menu selection or button that brings up a the chatroom log)." This feature can be defined using the element defined in RFC4575. Not need to create new elements. 2.4.12. (Detailed User Registration) "Some chatroom systems allow -- and some require -- registration of detailed information about a user before they are allowed to join a chatroom. Currently, the XCON data model does not include a way to store persistent information (name, nickname, email address, etc.) about users who are not actively part of an ongoing chatroom session." The three solutions propose in the draft are: (1) Adding elements to the / element in the XCON data model that store information about users who are associated with the chatroom, but not presently participating in it; (2) Setting permissions on the operations for adding users to the so that anyone can add such elements (as long as they can authenticate themselves as owning the URI present in the entry); (3) Setting the chatroom to "closedAuthenticated". This would then require users to "register" with a chatroom before joining; 2.4.16. (Designation of Chatroom Language) "The XCON data model does not currently provide a mechanism for indicating the predominant language that is expected to be employed within a conference." The intention of the data model was to define this feature using the attribute 'lang' specify in the element. We'll rewrote the text to make this idea more clear in the next version.=20 Cheers, Oscar _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Oct 12 06:27:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgHji-000206-1U; Fri, 12 Oct 2007 06:27:18 -0400 Received: from xcon by megatron.ietf.org with local (Exim 4.43) id 1IgHjg-0001zu-5L for xcon-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 06:27:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgHjf-0001ze-QY for xcon@ietf.org; Fri, 12 Oct 2007 06:27:15 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgHjd-000735-7f for xcon@ietf.org; Fri, 12 Oct 2007 06:27:13 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8708D20273; Fri, 12 Oct 2007 12:27:12 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-13-470f4c00c7b5 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 77D7D20246; Fri, 12 Oct 2007 12:27:12 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 12:27:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Updated draft-srinivasan-xcon-eventpkg-extensions-02 Date: Fri, 12 Oct 2007 12:24:23 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Updated draft-srinivasan-xcon-eventpkg-extensions-02 Thread-Index: Acfr8XWM3OWRPYjoR52vfABqA25e3Agxzh4A References: From: "Oscar Novo" To: "Srivatsa Srinivasan" , X-OriginalArrivalTime: 12 Oct 2007 10:27:11.0783 (UTC) FILETIME=[734B6370:01C80CBA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: roni.even@polycom.co.il X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi, Couple of comments in your version 02. Section 3.2.1 "Thus, state attributes and element keys (for the sub-elements) have been defined in the data model for these elements." [ON] Actually, the data model does not have to define the attribute 'state' in its schema. The 'state' attribute has to be defined only in the event packages to indicate the information that has changed from the last notification.=20 'Version' attribute: [ON] I know the attribute 'version' is explained in RFC 4575 but maybe it would be nice to mention this attribute and its function in your document. Cheers, Oscar -----Original Message----- From: Srivatsa Srinivasan [mailto:srivats@exchange.microsoft.com]=20 Sent: 31. elokuuta 2007 20:08 To: xcon@ietf.org Cc: roni.even@polycom.co.il Subject: [XCON] Updated draft-srinivasan-xcon-eventpkg-extensions-02 There is an updated XCON event package extensions draft that has been posted. These extensions contain the following changes based on the feedback from Chicago. - Changes to further align to text in RFC 3265 and RFC 4575 - Changes to include examples Feedback welcome, Srivatsa. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Oct 12 06:45:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgI1c-0007dN-BT; Fri, 12 Oct 2007 06:45:48 -0400 Received: from xcon by megatron.ietf.org with local (Exim 4.43) id 1IgI1b-0007dH-D7 for xcon-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 06:45:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgI1b-0007d9-11 for xcon@ietf.org; Fri, 12 Oct 2007 06:45:47 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgI1a-0007ba-2s for xcon@ietf.org; Fri, 12 Oct 2007 06:45:46 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8E48C204A0; Fri, 12 Oct 2007 12:45:45 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-25-470f5059c215 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6D74E201C5; Fri, 12 Oct 2007 12:45:45 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 12:45:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: FW: [XCON] Review of the XCON data model - Avshalom Date: Fri, 12 Oct 2007 12:42:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Review of the XCON data model - Avshalom Thread-Index: Acfv1q4p4RL0PwLLQc2trvZ5KL6XOgYNz4uA From: "Oscar Novo" To: , X-OriginalArrivalTime: 12 Oct 2007 10:45:44.0779 (UTC) FILETIME=[0AB119B0:01C80CBD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0366786826==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0366786826== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C80CBC.A5F3B4BA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C80CBC.A5F3B4BA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Avshalom, =20 Thank you very much for your review. Comments inline as [ON et al] =20 Cheers, =20 Oscar ________________________________ From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]=20 Sent: 5. syyskuuta 2007 19:08 To: XCON Cc: Dave Morgan; Roni Even; Gonzalo Camarillo (JO/LMF) Subject: [XCON] Review of the XCON data model - Avshalom Document: draft-ietf-xcon-common-data-model-05.txt Section 4.1.1 - Second paragraph (last line of the paragraph)=20 'require-participant' should be 'required-participant'=20 =20 [ON et al] OK =20 Section 4.1.1 - Last paragraph=20 Why notify end of conference can be configured to be done before the conference=20 is starting by enabling it to be negative?=20 =20 [ON et al] Yes, that's a cut&paste typo. Thanks! =20 Section 4.1.5.1.1=20 It is not clear what is meant by sentence starting with: "If this control is=20 not specified"=20 =20 [ON et al] we have change the sentence to: "If this control is not specified, the access to the control is not available to the client. " =20 =20 Section 4.1.5.1.2=20 It is not clear what is meant by sentence starting with: "If this control is=20 not specified" =20 [ON et al] we have change the sentence to: "If this control is not specified, the access to the control is not available to the client. " =20 =20 Section 4.5.1 - one paragraph before the last=20 typo - difference -> different=20 =20 [ON et al] Thanks Section 4..5.2 - The paragraph after figure 4=20 "whose identity is present in the conditions." What it means? Probably it=20 meant that the provide-anonymity is True for the user.=20 =20 [ON et al] That's a typo from previous versions of the draft. --Avshalom ------_=_NextPart_001_01C80CBC.A5F3B4BA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Avshalom,
 
Thank=20 you very much for your review. Comments inline as [ON et=20 al]
 
Cheers,
 
Oscar

From: Avshalom Houri=20 [mailto:AVSHALOM@il.ibm.com]
Sent: 5. syyskuuta 2007=20 19:08
To: XCON
Cc: Dave Morgan; Roni Even; Gonzalo = Camarillo=20 (JO/LMF)
Subject: [XCON] Review of the XCON data model -=20 Avshalom


Document:=20 draft-ietf-xcon-common-data-model-05.txt

Section 4.1.1 - Second paragraph (last line of the = paragraph)=20
'require-participant' should be=20 'required-participant' 
 
[ON et=20 al] OK
 
Section=20 4.1.1 - Last paragraph

Why notify = end of=20 conference can be configured to be done before the = conference=20
is starting by enabling it to be=20 negative? 
 
[ON et=20 al] Yes, that's a cut&paste typo. Thanks!
 
 Section=20 4.1.5.1.1

It is not clear what is = meant by=20 sentence starting with: "If this control is
not=20 specified" 
  
[ON et al] = we have=20 change the sentence to: "If this control is not = specified,=20 the access to the control is not = available to=20 the client. "  
 
Section=20 4.1.5.1.2

It is not clear what is = meant by=20 sentence starting with: "If this control is
not=20 specified"
 
[ON et al] = we have=20 change the sentence to: "If this control is not = specified,=20 the access to the control is not = available to=20 the client. "  
 
Section 4.5.1 - one = paragraph=20 before the last

typo -=20 difference -> different 
 
[ON et al] = Thanks

Section 4..5.2 - = The paragraph=20 after figure 4

"whose = identity is=20 present in the conditions." What it means? Probably it
meant that the provide-anonymity is True for = the=20 user. 
 
 [ON et al] That's=20 a typo from previous versions of the=20 draft.

--Avshalom

=
------_=_NextPart_001_01C80CBC.A5F3B4BA-- --===============0366786826== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --===============0366786826==-- From xcon-bounces@ietf.org Fri Oct 12 06:46:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgI2X-0000AL-6U; Fri, 12 Oct 2007 06:46:45 -0400 Received: from xcon by megatron.ietf.org with local (Exim 4.43) id 1IgI2V-00008g-OH for xcon-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 06:46:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgI2V-00008P-EH for xcon@ietf.org; Fri, 12 Oct 2007 06:46:43 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgI2P-0006vf-2O for xcon@ietf.org; Fri, 12 Oct 2007 06:46:43 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7C07F20673; Fri, 12 Oct 2007 12:46:31 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-82-470f5087d351 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5E25920639; Fri, 12 Oct 2007 12:46:31 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 12:46:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [XCON] Comments on draft-ietf-xcon-common-data-model-05 Date: Fri, 12 Oct 2007 12:43:42 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Comments on draft-ietf-xcon-common-data-model-05 Thread-Index: Acfw1shnjkYJnssxQpiy8LdnHMA23gZcUBMA From: "Oscar Novo" To: , X-OriginalArrivalTime: 12 Oct 2007 10:46:30.0699 (UTC) FILETIME=[260FEFB0:01C80CBD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hello Ben, Thanks for your review. Comments are embedded as [ON et al]. Cheers, Oscar -----Original Message----- From: Ben Campbell [mailto:ben@estacado.net]=20 Sent: 7. syyskuuta 2007 1:41 To: XCON-IETF Cc: Dave.Morgan@fmr.com; roni.even@polycom.co.il; Oscar Novo (JO/LMF); Gonzalo Camarillo (JO/LMF) Subject: [XCON] Comments on draft-ietf-xcon-common-data-model-05 Hi, Here are my comments on draft-ietf-xcon-common-data-model-05. They are mostly editorial in nature. Thanks! Ben. --------- General: I share Gonzalo's comment about the scope of the data model being unclear. In particular, is it the goal of this document to define how the contents of a conference object affect behavior of various devices? If so, then there is a notable lack of normative language to that effect throughout the document. [ON et al] We'll modify the introduction of the document to make the scope of the data model more clear.=20 Many element types can be used in different contexts (i.e. as children of different parents), and if I understand correctly, their meaning may be different depending on the context in which they are used. I personally don't feel like I fully understand all of these after multiple detailed reads of the document. It might help to have more examples. Rather than whole documents, it might be useful to put in document fragment examples illustrating specific usages. Section 4 is inconsistent in how it presents elements. In some cases, an element and its children are all defined in the same section. In others, there is a section for each. Furthermore, it requires some reading between the lines to understand when this document is defining an element vs. incorporating an element defined elsewhere. =20 This is explicit in some cases, but not consistent. My personal preference would be to give each element its own section, and use a common list-oriented format for things like contexts, potential children, where the element is defined, cardinality, etc. But the important thing is consistency. [ON et al] In the next section we'll try to re-structure the whole document again giving a section to the element of the schema and lists to the context of this elements. Doing that, we expect the document to be more clear for the reader. If after re-structuring the document still is not clear enough, we will try to put more examples in the document. Specific comments: Section 3.2 Paragraph 2: Why do we need normative statements about what privileges should be associated with each role? [ON et al] We have thought to removed the roles section because of the confusion created to many reviewers. The roles section is not an important part of the document and can be described in the policy draft in the future. Section 4 Paragraph 1: I assume a conference object document and a conference object data model document are the same thing? It would be helpful to be consistent with the terminology. [ON et al] yes, they are the same. We'll change the name of "conference object data model" for "conference object". Paragraph 2: Need a reference for the definition of XCON-URI [ON et al] XCON-URI is defined in the data model document. We'll create a section defining the XCON-URI in the next version.=20 Paragraph 5: (Personal pet peeve nit) I find constructs of the form "...defined in [1]" difficult to follow. The construct "... defined in RFC XXXX[1]" =20 is better. This is partly to save the reader from constant flipping back to the end-notes. But in general the end-note reference is parenthetical, and the sentence should still make sense if the reference is completely removed. [ON et al] We'll do that. Diagram: Is it possible to give this a referenceable "figure" number? Also, it would be helpful if the diagram could show cardinality somehow. [ON et al] we'll give a figure number to the diagram. TO give a cardinality is going to be more complicated. Section 4.1: Paragraph 1. The section gives brief descriptions of each child elements, but the real descriptions occur in the following sections. It would be better to just mention the child elements by name, and refer to the sections for each. Repeating the same info twice is likely to create inconsistencies as the document evolves. [ON et al] we'll fix that in the next version. 4.1.1 This is an example of a section that defines child elements in the same section as its parents. I personally think this would be easier for readers if each element got its own section. But in any case, it should be consistent from section to section. [ON et al] we'll do that. 4.1.5.1 Paragraph 1: What does it mean for an element to contain controls? How is the element actually used? Assuming this is described elsewhere, can we put in a reference to that description [ON et al] when we say 'controls', we refer to 'controls elements'. In next version we'll try to put this in the text more clear.=20 4.1.5.1.4. Entire Section: I find it naive to believe we can specify all useful or likely layouts in advance. Wouldn't it make more sense to describe these in terms of what the focus has to do rather than how a client displays things? (I don't mean to question wg concensus if this has already been discussed to death) [ON et al] yes, we try to reflect the wg consensus but it's possible to discuss again the layout element in the wg if it's not very clear enough.=20 Paragraph 2: I find no reference to a element elsewhere. Should this be [ON et al] yes, that's a typo. 4.5 I am really confused on how all the sub-elements fit together. For example, what would it mean to have allow, an , and a element in the same parent? Some more example scenarios would help. [ON et al] This is explained in a bit more detail in RFC 4575. That's why we try don't repeat again the same thing in the data model. Readers should read first RFC 4575 before to read the data model. 5: I am not familiar with RELAX NG. Hopefully an expert in this is reviewing the document? 7. Example contains a child element of . The text said that we reuse for SIP URIs in this context for backwards compatibility with the SIP conference model. Same for . [ON et al] yes, that's another typo. 8. Security Considerations This section seems rather lightweight. The text motivates why we care about authentication, but does not provide motivation for confidentiality and integrity. I suspect a discussion of possible privacy issues may be in order. Also, I assume these documents may be stored and cached, as well as transferred, so some considerations about whether it is okay to just leave them laying around might be worth having. [ON et al] we'll provide in the next version a confidentiality and integrity section.=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Oct 12 06:46:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgI2X-0000Au-Bs; Fri, 12 Oct 2007 06:46:45 -0400 Received: from xcon by megatron.ietf.org with local (Exim 4.43) id 1IgI2V-00008j-Oc for xcon-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 06:46:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgI2V-00008Q-EX for xcon@ietf.org; Fri, 12 Oct 2007 06:46:43 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgI2P-0006uR-2M for xcon@ietf.org; Fri, 12 Oct 2007 06:46:43 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 814A8206BF; Fri, 12 Oct 2007 12:46:07 +0200 (CEST) X-AuditID: c1b4fb3c-b1681bb0000007e1-53-470f506fb057 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6653920585; Fri, 12 Oct 2007 12:46:07 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 12:46:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Oct 2007 12:43:18 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review: draft-ietf-xcon-common-data-model-05 Thread-Index: Acf0xzj4ZA228CpKQIK5Qj4kzOmgGgTPHMBgAGtpLkA= From: "Oscar Novo" To: "Mary Barnes" , X-OriginalArrivalTime: 12 Oct 2007 10:46:07.0281 (UTC) FILETIME=[181AA210:01C80CBD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: Subject: [XCON] FW: Review: draft-ietf-xcon-common-data-model-05 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Mary, Thank you to review our draft and thank you for your support. We really appreciate it! Comments to your feedback inline as [ON et al]. -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: 12. syyskuuta 2007 3:44 To: Oscar Novo (JO/LMF) Cc: xcon@ietf.org Subject: Review: draft-ietf-xcon-common-data-model-05 Hi Oscar et al, I reviewed this draft and appreciate all the effort that has gone into it. =20 I believe it is on the right track, but does need to resolve a few issues and clarify a few things before progressing. I apologize if some of my comments overlap with those that other's highlighted - I did review them, but may have missed a few. Also, I have slightly different comments on some of the same topics. I've included the Issues/questions first, followed by general comments and then editorial nits. Thanks, Mary. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Issues/questions: ----------------- 1) Section 3.2, 2nd paragraph - discussing the five roles - like others I had some concerns about this text:=20 1a) Like Ben, I do wonder if it needs to be normative or whether we need the text in the second paragraph, particularly given the sentence in the 1st paragraph that "A set of semantics associated with each role is out of scope of this document". The 2nd paragraph seems to try to do just that. The rest of my comments are premised that this paragraph is still deemed useful. If not, then you can ignore.=20 [ON et al] We have decide to remove the role section from the data model. It's a concept that it's not mature enough and we believe it needs more discussion in the WL. It could be include later in the policy draft or in a separate draft. =20 1b) I'm not entirely convinced of the hierarchy concept, especially when you bring in the "observer" role. But, see the comment 1e) as this negates this comment.=20 1c) 4th sentence, As far as the "creator" being the 'owner', wouldn't that be subject to conferencing system policies, as I would think there would be some systems where the 'owner' would be the administrator? It almost seems problematic to make that statement at all, as by defining 'owner' you're implying an additional role. =20 1d) 4th sentence, per my general editorial comment #2 below, the terms in this document should be consistent with the framework. The term instantiated in the framework is used when a conference object is created based on a reservation. The term that you want to use rather than "is instantiated" would be "becomes active". I think the point you're making here is that the creator can modify a conference reservation. But, I think the creator should also be able to modify the conference even after it is active (subject to policy restrictions).=20 So, based on comments 1c) an 1d), I would think we might want to change that 4th sentence from: OLD: The The "creator" is the 'owner' of the conference and has various privileges which SHOULD allow them to modify the conference variables up to the time the conference is instantiated. =20 NEW: The "creator" of the conference has various privileges which SHOULD allow them to modify the conference variables. 1e) I'm also not convinced of the need for the "observer" role, as it doesn't so much apply to privileges in terms of changes to the conference during its lifecycle, but specific media attributes. I would almost think that an observer is just a hidden participant, perhaps only visible to the moderator, consistent with the description in the framework: "The capability to observe a conference allows a participant with the appropriate authority to listen to the conference, typically without being an active participant and often as a hidden participant."=20 1e) Last sentence. It might be also useful to clarify that a conferencing system SHOULD also have at least one of the following {administrator, creator, moderator or observer} or there's really not much point in using this framework. I also can't quite see the point in saying that a conferencing system MAY define the participant role. What would be the point of a conference that didn't have participants, given that each user can have multiple roles (e.g., I would think a very typical set of roles for the moderator would be {creator, moderator, participant} ). =20 2) Section 4.4 (6th para in particular): I also had concerns over the usage of as a boolean and a value for the . Even if you change the names as suggested, it still is unclear whether the can be "FCFS" or "random" if the is "moderator-controlled"? I would think not, in which case, is the really needed or can you just derive the fact that it's "moderator-controlled" from the ?=20 [ON et al] Because this information is redundant. We have removed the "moderator-controlled" attribute from . So, we'll have this information only in element.=20 3) Section 4.5.1 [Note: I think Srivatsa also had a comment on this, but his email specifies section 3.7.1 and Ben also had a comment on this element] My initial concern is that this element is overloaded, in that it defines which users are allowed to be participants in a conference, it defines the methods by which a user may become a participant in a conference and it also indicates direct actions needed to be taken by the focus to add participants to a conference. I also think there's some gap in specification. For example, it seems to me that a user with a 'method' attribute of "refer" MUST also have a 'method' attribute of "dial-in" in order to be a participant in the conference (i.e., otherwise when the resource initiates the request to join the conference, how are they allowed to be added OR is the expectation that there's an indicator that they were referred?). [ON et al] yes, the same user could be in two list at the same time. It also seems that the use of Refer for SIP really isn't particularly useful - i.e., why wouldn't the focus just "dial-out" the specified resources. It does make some sense in the context of alternative communication means. [ON et al] In the IETF-60 XCON meeting, we agreed that a separate refer list is needed, mainly because the list is not a list of users that the focus invites to join the conference (dial-out list). 4) Section 5, page 28, user-admission-policy-type: I'm wondering if there should also not be a plain "Open" (i.e., no auth required, but NOT anonymous). =20 [ON et al] The "openAuthenticated" already fullfil your requirement because the authentication is up to local policy. General editorial comments: --------------------------- [These are based on reviewing the document for consistency with terminology in the Centralized Conferencing Framework document] 1) When referencing the framework change the term from "XCON Conferencing Framework" to "Centralized Conferencing Framework" [this was a change made just before it was forwarded to AD for progression] [ON et al] We'll fix it. 2) It might be better to change the terms the various stages, for example in the first paragraph of the introduction, to be consistent with the framework document (as introduced in the 5th paragraph of section 3 - Overview), particularly since there is the mapping isn't clear to me (e.g., what's the difference between started and running) :=20 OLD: (e.g., reserved, started, running, ended, etc.) NEW: (e.g., created/creation, reserved/reservation, active/activation, completed/completion) [ON et al] OK 3) PSTN reference needs to be changed to explicitly refer to Q.931, ISUP, etc. [another post-WGLC change], for example, 3rd paragraph of the intro: OLD: (e.g., SIP, H.323, PSTN, etc.) NEW:=20 (e.g., SIP, H.323, Q.931, ISUP, etc.) Note: this also impacts the schema. [ON et al] OK Nits: ----- 1) Section 2, last paragraph: change "are supposed to" -> "should" 2) Section 3, last sentence: insert "additional" before "advanced" since this data model should be provided advanced features beyond those provided by the data model in RFC 4575: OLD: It is expected that this data model can be further extended with new elements in the future in order to implement advanced features. NEW: It is expected that this data model can be further extended with new elements in the future in order to implement additional advanced features. 3) Section 4.1.1, next to the last paragraph: is -> are "..when users or resources on the is requested..."=20 4) Section 4.5, last sentence: shouldn't be ?=20 5) Section 4.5.1, last paragraph: change "difference users" -> "different users" _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Oct 12 06:46:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgI2e-0000aY-U0; Fri, 12 Oct 2007 06:46:52 -0400 Received: from xcon by megatron.ietf.org with local (Exim 4.43) id 1IgI2d-0000WG-FG for xcon-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 06:46:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgI2d-0000Vs-57 for xcon@ietf.org; Fri, 12 Oct 2007 06:46:51 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgI2X-0006w2-IN for xcon@ietf.org; Fri, 12 Oct 2007 06:46:51 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1F3112044B; Fri, 12 Oct 2007 12:46:45 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-d6-470f5095edbf Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F30A4201C5; Fri, 12 Oct 2007 12:46:44 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 12:46:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Oct 2007 12:43:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-xcon-common-data-model-05 Thread-Index: AcfxD9kz2G4QvAq2THKlVPPFzG/EKwXAVBww From: "Oscar Novo" To: "Srivatsa Srinivasan" , X-OriginalArrivalTime: 12 Oct 2007 10:46:44.0796 (UTC) FILETIME=[2E76F7C0:01C80CBD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: Subject: [XCON] FW: Comments on draft-ietf-xcon-common-data-model-05 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Srivatsa, Thanks for your review of the document. Comments inline as [ON et al]. Cheers! Oscar -----Original Message----- From: Srivatsa Srinivasan [mailto:srivats@exchange.microsoft.com]=20 Sent: 7. syyskuuta 2007 8:28 To: XCON-IETF Cc: Dave.Morgan@fmr.com; roni.even@polycom.co.il; Oscar Novo (JO/LMF); Gonzalo Camarillo (JO/LMF) Subject: Comments on draft-ietf-xcon-common-data-model-05 Hi, Here are the review comments for the data model. Some of the comments are from an older review and I have repeated them for completeness. Regards, Srivatsa. An overall comment is that the document needs to describe in text those elements that are new and should not re-define elements that were previously described in RFC 4575.=20 [ON et al] This is a bit problematic in RELAX NG because RFC 4575 does not have an informative RNG schema. We could not re-define these elements but from real validation pov this is worse.=20 This needs to be changed throughout the document. Also, sections of the text that describe XML elements should be very explicit about whether this is optional or not. =20 [ON et al] Some people has complained about that. We'll try to change it in next version.=20 Furthermore, you should be very explicit about which elements have a state attribute defined now (this is missing in various places, like and and , ). The RELAX-NG schema is also missing this in one location. [ON et al] The state attribute should be defined in the notification packages but not in the data model. This attribute indicates the amount of information the user receives from the data model.=20 Section 3 " The data model defined in this document is the result of extending the data model defined in RFC 4575 [1] with new elements, which carry information such as non-SIP URIs or floor-control-related parameters." [SS] Suggest rewording -- "The data model specified here includes extensions to the schema defined in RFC 4575. Examples of such extensions include scheduling elements, media control elements, floor control elements, some conference policy elements and addition of localization extensions to text elements." [ON et al] In the text we would like to state that this schema accepts non-SIP URIs. As well, other reviewers have some comments about this paragraph. What do you think if we reword that sentence as followed?: "The data model specified in this document is the result of extending the data format defined in RFC 4575 with new elements. Examples of such extensions include cheduling elements, media control elements, floor control elements, non-SIP URIs, and addition of localization extensions to text elements." [SS] Also, a reminder that the root namespace used in this document is "urn:ietf:params:xml:ns:conference-schema" as opposed to what RFC 4575 uses ("urn:ietf:params:xml:ns:conference-info"). Needs fixing. Also, suggest renaming the extension namespace (where the new XML elements are defined in this document) to " urn:ietf:params:xml:ns:xcon-conference-info" instead of "urn:ietf:params:xml:ns:conference-schema". Or at least something to indicate that this is something completely different from conference-info. [ON et al] We'll create a new section in the overview explaining the new namespace. We'll change the conference-schema namespace for xcon-conference-info=20 [SS] Suggest removing "This data model can be used by conference servers providing different types of basic conferences." [ON et al] before to remove it, could you please explain why do you want to remove that part? Is it not enough clear? Does it create confusion? Section 3.1 [SS] This section has text that is already covered in RFC 4575. Why is it needed? [ON et al] we describe them again because they are part of the structure of the data model. You're right and in the next version we'll explain why we repeat that information in the data model again. Section 3.2 [SS] It is not clear how the definitions are extensible as defined. Also, it is not clear what a conferencing client should do when the conferencing system does not support a certain role. Also, how does the client learn that a conferencing client does not support that role? It may be useful to have text that redirects some of these answers to an external inter-op Spec(T) in-order to clearly delineate areas of the document that were intentionally left open. "If no roles are defined for an entity, they SHOULD by default be a "participant" but local policy MAY define an alternative." [ON et al] Other people has complained about the roles definitions. That's why we have decided to remove them from the data model. [SS] A better way to put this is "If no roles are defined for an entity or the conferencing system cannot grant the requested role, it SHOULD default to the role of a "participant" but local policy MAY define an alternative." Section 3.2.1 [SS] Not clear if is optional or not. [ON et al] Apply previous comment.=20 Section 3.2.2 [SS] Eliminate this section; should be in the conference protocol document, if at all anywhere. [ON et al] We'll do it. Section 4 [SS] Not clear again, if a conferencing system MUST implement/support XCON-URI's. [ON et al] We'll create a new section explaining the XCON-URI. Section 4.1.2 and Section 4.1.3 [SS] Same comment as in Chicago -- not convinced of the use of and elements. [ON et al] After the discussion in Chicago, we'll change that part accordingly.=20 =20 Section 4.1.5 [SS] I am repeating some of my comments from an earlier email regarding mixing mode and mix level. This is an inter-op nightmare, unless specified normatively. Is this still required even after the element was added? [ON et al] we have removed the element from the schema. As you said, it was not very clear its functionality.=20 [SS] Mixing mode is a very specific implementation detail of mixing. What does it mean to define a mixing-mode for every stream -- is this mode applied to the incoming stream to or the outgoing ones from the mixer? [ON et al] to the outgoing ones to the mixer.=20 And why would a conference participant (organizer or moderator or attendee) be interested in choosing one over the other? [ON et al] well, there is a bunch of uses cases where the organizer would be interested to control the mixing mode, for instance, if we want to cease the transmission of media to some of the participants instead of all the participants.=20 [SS] Also, for layouts, an enumeration of specific layout string identifiers with localized description strings for each layout will be more useful than just an integer aka mix-level. Note that this can be clubbed or rather replaced with a element for layouts. Also, a specific mixer output stream may only support one layout. A client capable of receiving multiple streams may receive more than one stream, each with different layouts or multiple streams each with the same layout. For example, a mixer may output two streams each capable of only a single layout (fixed layouts by the mixer) -- the main video with active speaker and another stream (or multiple streams) of a proprietary mix (like enhanced video from a conference room). [ON et al] The purpose in the definition of the controls was to define and covert the very basic use cases, for more complicate use cases it's possible to extend the schema in the future. =20 Section 4.1.5.1.1, 4.1.5.1.2, 4.1.5.1.3, 4.1.5.1.4 [SS] Overall comment: Suggest rewording by reusing some of the text from the media usages draft or pointing to it. [ON et al] We'll rewrote a bit this part to make it more clear "In the element the schema is extensible, hence new control types can be added in the future. Similarly, controls that apply to a specific user would appear under the // element. So moderator controls that affect all media output would go under the element." [SS] Remove the sentence starting with "Similarly" in the above paragraph. Define it separately under definition. [ON et al] We will remove it from here and put it in the place it belongs. "If this control is not specified, access to the control is not available to the client and media SHOULD NOT be transported for the associated media stream." [SS] Avoid repeating, if possible. Just point out similarities in the controls. [ON et al] we will remove the redundancy in this text. "The 'video-layout' control is used in conjunction with a video stream to specify how the video streams (participants) are viewed by each participant." [SS] This section needs to specify how this is extensible. Also, specify whether a conferencing system should implement these? Or are they completely optional? [ON et al] We don't think the data model should specify how the system should implement the controls. That's not the scope of the data model and this is up to implementors decisions. Section 4.2 "The child element contains a sequence of child elements: , , and ." [SS] Remove text. [ON et al] OK Section 3.7.1 " The 'method' attribute is a list with the following values: "dial-in", "dial-out, and "refer". The value "dial-in" is used by the focus to determine who can join the conference. Value "refer" is used by the focus to determine the resources that the focus needs to "refer to" the conference." [SS] Unclear why a conferencing system would want to let the conference organizer describe "how" a conference participant joins? This is up-to local implementation.=20 [ON et al] In the IETF-60 XCON meeting, we agreed that a separate refer list is needed, mainly because the list is not a list of users that the focus invites to join the conference (dial-out list). This is up-to local implementation. If a specific participant has a value of 'dial-in' but is later dialed-out, what does that mean? [ON et al] This is up to local policy. 4.5.2.1. , [SS] Suggest rewording section. "This section specifies controls that apply to a user's media stream being sent from the mixer to the participants endpoint or to the mixer from the participants endpoint. The element details properties associated with the streams sent to the mixer (from the participant). The element details properties associated with the streams sent from the mixer (to the participant). Both of these elements have the attribute 'name'. " [ON et al] What do you think if we reword it as follow? "This section specifies controls that apply to a user's media stream being sent from the mixer to the participants endpoint or to the mixer from the participants endpoint. The element details properties associated with the incoming streams to the mixer (streams sent to the mixer from the participant). The element details properties associated with the outgoing streams from the mixer (sent from the mixer to the participant). Both of these elements have the attribute 'name'. " 4.5.3. and 4.5.4. [SS] These sections are not required (defined in RFC 4575) remove them unless there are some specific extensions defined here. [ON et al] we'll prefer to keep them for a matter of clarity but we'll explain better that they are defined in RFC 4575 [SS] As an end disclaimer, I have not checked the RELAX-NG schema or the examples. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Oct 12 06:47:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgI2n-0000ng-8v; Fri, 12 Oct 2007 06:47:01 -0400 Received: from xcon by megatron.ietf.org with local (Exim 4.43) id 1IgI2l-0000kr-IQ for xcon-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 06:46:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgI2l-0000ja-4e for xcon@ietf.org; Fri, 12 Oct 2007 06:46:59 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IgI2h-0007do-Uy for xcon@ietf.org; Fri, 12 Oct 2007 06:46:59 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 74289206E0; Fri, 12 Oct 2007 12:46:55 +0200 (CEST) X-AuditID: c1b4fb3c-af67dbb0000007e1-a2-470f509f2df3 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 55E5A20009; Fri, 12 Oct 2007 12:46:55 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Oct 2007 12:46:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Oct 2007 12:44:06 +0200 Message-ID: In-Reply-To: <46DE9F5E.8060602@nsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Miguel's Review of the XCON data model Thread-Index: AcfvtxOKsDagqSjzTEizI9SJ/suubQWm+EQA References: <46DE9F5E.8060602@nsn.com> From: "Oscar Novo" To: "Miguel Garcia" , X-OriginalArrivalTime: 12 Oct 2007 10:46:55.0187 (UTC) FILETIME=[34A88230:01C80CBD] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f8267f77ca4545e62c57802503816d5 Cc: Subject: [XCON] RE: Miguel's Review of the XCON data model X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Miguel, Thank you very much for your review. I appreciate the time you spend on it. Comments to your feedback inline as [ON et al]. -----Original Message----- From: Miguel Garcia [mailto:Miguel.Garcia@nsn.com]=20 Sent: 5. syyskuuta 2007 15:22 To: XCON Cc: Oscar Novo (JO/LMF); Gonzalo Camarillo (JO/LMF); Dave Morgan; Roni Even Subject: Miguel's Review of the XCON data model Hi: This is my review of the XCON data model Document: draft-ietf-xcon-common-data-model-05.txt Reviewer: Miguel Garcia Review Date: 4 Sep 2007 1) The the scope of the document is not very clear to me. To be precise, I am not totally sure what the model represents. It can be any of: a) The data in a conference that can be manipulated with a conference control protocol. b) All the exhaustive data needed to instantiate a conference, including data manipulated by the conference control protocol, data needed to control a mixer, data needed to provide scheduling, notifications, etc. c) Data needed to provide an extended notification to participants. I think the aim is 'b', but it is not really clear to me. And this is a fundamental question that the document have to answer. I would suggest that whatever is the answer, it is clearly written perhaps in the abstract and the introduction. [ON et al] This comment surprise me a lot because I thought the scope of the data model was clear but I got the same comment from Ben. We'll try to rewrite again the abstract and the introduction sections to make the scope of the draft more clear. After sending to the ML the version 06 I would appreciate if you can read at least the abstract and tell me if it's enough clear. 2) The document positions itself as an extension to the conference event package (RFC 4575). However, RFC 4575 contains two topics: an event package and a data format for such event package. Since the XCON data model has little (or nothing) to do with the event package, it would be nice to clarify that the XCON data model is an extension to *the data format* specified in RFC 4575. This is visible, for example, in the Abstract: The conference information data model defined in this document is an extension of (and thus, compatible with) the model specified in the Session Initiation Protocol (SIP) Event Package for Conference State. I suggest rewording, such as: The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) Event Package for Conference State. [ON et al] We have made your suggested rewording. Furthermore: RFC 4575 does not use the term "data model", but instead "data format". Please, be precise with the terminology when referring to RFC 4575 (don't refer to the "data model specified in RFC 4575"). [ON et al] We've changed 'data model' for 'data format' when we refer to RFC 4575. 3) On the data model itself. Is there a container for the credentials of the conference? In PSTN conferences these are typically a conference ID number and a PIN. I noticed the element has an attribute 'PIN code', but I am missing the conference ID. On the other side, if you have SIP, these could also be a username/password/realm combination of the conference. I haven't seen these containers, so... am I missing something? [ON et al] The general conference ID of the conference is defined in the entity attribute of the element. defines the identifiers (URI) to be used in order to access the conference by different signaling protocols.=20 4) Section 1, third paragraph, describes Figure 1 and says: A conference control protocol provides the interface between a conference and media control client, and the conference control server. I am not sure if I can understand the sense of the sentence.=20 Furthermore, I didn't find the "media control client" in Figure 1 or defined elsewhere, so probably this is a leftover from the past [ON et al] Yes, that's a typo.=20 5) Section 1, last paragraph: The data model defined in this document extends the one defined in RFC 4575 [1]. I would say that this document is a "superset" rather than "extends": The data model defined in this document constitutes a superset of the data format defined in RFC 4575 [1]. [ON et al] OK 6) Figure 1. There are one or more objects called "Conference Object".=20 Each one contains just another object called "Conference Information Data Model". According to the figure, the Conference Object just contains a Conference Information Data model, nothing else, nothing more. This makes me thing that both things are the same. Or, in other words, perhaps the "Conference information data model" should be removed from the figure. Or, if it shouldn't, then you need to describe the relation between both in textual form. [ON et al] I think the relation between a conference object and the data model is already described in section 1: "Conference Objects are instantiations of the conference information data model defined in this document. Consequently, conference objects follow the XML format defined in this document." 7) Section 3.1 starts with a description of the XML elements of the model. However, it is not mentioned that some of these elements are the same defined in RFC 4575. For example, the text in 3.1 reads: All the information related to a conference is contained in a element. The element contains the following child elements: o The ... Later i the document, it is clearly described that , and other elements are those defined in the data format in RFC 4575. But is not the case here in Section 3.1, which is the main overview. So, please, write it also here. Write a context indicating that some elements are those in RFC 4575 and not invented here, so that the reader knows where he is. [ON et al] We'll explain that difference in the next version. Once you have created the contact, you can, for example, use the adjectives "existing" and "new". You can then refer to the "existing element" and a "new element". 8) I miss a motivation for the existence of roles at the beginning of Section 3.2 [ON et al] Other reviewers had the same problem with the roles. I think the roles should be link to the policy draft of the data model more than this draft. So, we propose to completely remove the roles from the data model and define them in a new draft or in the policy draft.=20 9) Section 3.2, second paragraph, defines several roles. I guess you want to say that a "participant" is the role that provides the user with the privilege to send and receive most of the media streams. Similarly, and "observer" is the role that provides the user with the privilege to receive, but not to send, media. If this is correct, I like these definitions above those in the document. Also note that unlike the document say, these are not _logical entities_, but *roles* [ON et al] apply the previous comment. 10) Section 3.2, last paragraph. The normative "SHOULD" and "MAY" have no impact in interoperability. So this makes me thing that they aren't normative. Proposal: If no roles are defined for an entity, they should default to "participant" but local policy can define an alternative. [ON et al] apply the previous comment. 11) Section 4, the paragraph above Figure 2: it mentions the XCON-URI without a reference to where it is defined. Then I saw it in the IANA considerations section, so THIS might be the canonical document that defines it. So, I think the XCON URI deserves a section by itself, describing the semantics, syntax, etc. [ON et al] You're right. Other reviewers have found the same problem. We'll dedicated a section to the XCON-URI.=20 12) Section 4.1, 1st paragraph: Why is there a normative SHOULD in: It SHOULD have an extra attribute 'xml:lang' to specify the language used in the contents of this element as defined in Section 2.12 of [8]. I think it's nice to see the 'lang' attribute, but honestly, the lack of it is not going to create an interoperability problem, so I consider the SHOULD as a should. [ON et al] Fix it! 13) Section 4.1, reads: The child element describes the capabilities of the conference. I don't think describes any general capabilities of the conference. [ON et al] That's a typo as well. 14) Section 4.1.1: The second paragraph refers to DTSEND and DTSART fields without describing what are those. Then later I understood they are iCal fields. So please, say it and add a reference to the iCal spec. [ON et al] Fix it! 15) Section 4.1.1, second paragraph. The element is mixing two semantics: one one side, it indicates whether mixing starts according to either a specified time or when a participant with a role joins. I think it would much clear to create three elements instead: one is a , which can take the values "by-time", "by-joining-role", or "at-first-join". Another would be the existing , which would be restricted to indicating a time, and only available when takes the value "by-time". A third one is which would take the values "participant", "moderator", "administrator", and is only available is takes the value "by-joining-role". [ON et al] We discussed about the information in the element already in Dallas. If you think we should discuss again that I would prefer to discuss it in the ML before to do any change. 16) First paragraph in Section 4.1.5. The text reads: The 'name' attribute identifies a codec, and the 'decision' attribute contains the policy for that codec (allowed, or disallowed). I suspect you cannot write a free text in the 'name' attribute. Most probably you want to say that the list of possible codecs is controlled by some IANA registry. I suspect that you are looking at the 'encoding name' column in the IANA registry for RTP Payload Types, http://www.iana.org/assignments/rtp-parameters Most likely you also have to take into account the 'subtype' column of the RTP Payload Format media types per [RFC4855] available in the same IANA web page. [ON et al] We will clarify that problem in the next version of the draft. 17) Section 4.1.5, last paragraph describes the attribute. I am sorry to say, but it was hard to understand what this is. I still have my doubts. So... for example, in an audio stream. In a conference with 50 participants, if takes the value 3, which 3 input streams are input to the output stream? Similarly, in a video stream. If takes the value 5, then how does this affect the output stream and which 5 input streams are selected? [ON et al] This parameter has not been clear for many people. So, we have decided to remove it because it's not a fundamental element of the data model. 18) Same section 4.1.5 last paragraph. The text reads: The child element MUST contain one and only one of the "Moderator-controlled", "FCFS", and "Automatic" values indicating the default algorithm to be use with every media stream. Can you please describe the semantics of these values? Since I understand (a bit of) English, I more or less can figure out what you mean. But think for a while if these identifiers would be just called id1, id2, and id3 and try to explain them. [ON et al] OK 19) Section 4.1.5.1.1 defines the element and Section 4.1.5.1.2 defines the element. I think these two are very similar, the only difference being that the former applies to audio streams, the latter to video streams. I would like to see a single element, perhaps called or something like that. This could apply for any kind of media stream, even for MSRP. [ON et al] We decided to put that names to the controls in Dallas. I would prefer to discuss this issue in the ML if you think it's important enough. 20) Section 4.1.5.1.3 defines the element. I am missing attributes that defines the minimum and maximum levels. Without it, if I get that the mixing level is 10, I have now idea if it is 10 in a scale 1-10, 10 in a scale 1-100, or 10 in a scale 1-1000. Further more, without the maximum/minimum level, it wouldn't be possible to create a UI scale representation, making the control totally useless. [ON et al] In the schema the limit of this attribute is defined. This attribute should be inside the limit -127 / 127.=20 21) Section 4.1.5.1.4 defines the element. One possible value is 'multiple-5x1', where "one panel will occupy 4/9 of the mixed video stream while the others will each occupy 1/9 of the stream". My question is: how to select the input video stream that will go into the big panel? And how to select each of the other video streams, if you have, say, 20 input video streams? The same is applicable for any video/audio stream where there more inputs than possible outputs. [ON et al] Here we only define the basic controls for a conference. If you want more complicate actions is posible to extend the XML with new elements. Answering your question, I guess the focus will decide that automatically or randomly if it doesn't have any extra element defining that possibility. And how does this element interact with the element? It seems that the indicates a pure maximum number of inputs, where I think it is irrelevant when you have a element. For example, what is the meaning of having both: automatic automatic [ON et al] We have decided to remove the element for a matter of simplicity. 22) More on Section 4.1.5.1.4. The last paragraph defines the 'automatic' value as: automatic: This option allows the focus to add panels as streams are added up to a limit of "panels". What is this 'limit of "panels"'? Is it a local policy? In either case, I think there should be means to configure this maximum number of panels, so I am missing a "max-panels" attribute or something like that. [ON et al] We have removed that constrain from the definition of 'automatic'.=20 23) Section 4.4, first paragraph describes the element and says: This element has its own XML namespace. What is this own XML namespace. Which one is it? Where is specified? Why none of the examples show any namespace? [ON et al] That's a typo. It existed in previous versions but not anymore.=20 24) Section 4.4, second paragraph tries (but fails) to define the element: The is used by a floor control server to provide a client with a conference ID. The text says how is this used, but doesn't say what it is and how it differentiates from the other zillions conference identifiers we already have. So please first explain what is this element, how is it different from other similar ones, and then you keep the explanation of how it is used (which I haven't understood so far). [ON et al] We'll try to explain it better. 25) Section 4.4, 5th paragraph reads: Note that placing a value of "block" for this element does not guarantee that a participant is blocked from joining the conference. Although the spirit of the text is to avoid misleading the user, it just got the opposite effect. I am aware we are discussing floor control issues, so bringing here the concept of joining a conference created a restart in my mind. I would suggest to either delete or rephrase it better: Note that this section discusses floor control information, therefore, the value "block" in a element is not related with the "block" value in the element (see Section 4.5). [ON et al] OK 26) Same paragraph in Section 4.4 reads: Any other rule that might evaluate to TRUE for this participant that carried an action whose value was higher than "block" would automatically grant confirm/allow permission to that participant. First, the text seems to imply that there are some precedence order between several values, but does not say which are those values. If such precedence order exists, it probably needs to be specified, otherwise, users will have unexpected behaviors depending on the manufacturer of the conference server. Second. Is the paragraph true? Can you give an example of "other rule that might evaluate to TRUE for this participant" that would grant confirm permission instead of block? Third: Which participant this rule applies? I didn't find an element to specify participants in , so I don't understand anything. [ON et al] good catch! That's another typo from previous version. Thanks! 27) Section 4.4, 6th paragraph: The text reads: The element is mandatory and contains the required boolean attribute that indicates if the floor is moderator controlled or not. Please mention the name of the attribute, which I believe is 'moderator-controlled' [ON et al] OK Second and more important thing: I think the schema makes 'moderator-controlled' an attribute of , not an attribute of as the text suggest. [ON et al] True, the text is wrong.=20 28) Same section and topic: I noticed that 'moderator-controlled' can be either an attribute of or a value in the element. I would suggest to rename one to avoid collisions between attributes and values of elements. [ON et al] Because this information is redundant. We have decided to remove the 'moderator-controlled' attribute from . The same information is defined in the element. 29) Same section 4.4, still 6th paragraph: Every floor is defined using the 'label' attribute. I would say that floors are not _defined_, but _identified_, using the 'label' attribute. Also, the schema says 'label' is mandatory, so say it: Every floor is identified by the mandatory 'label' attribute. [ON et al] OK 30) Same section 4.4, still 6th paragraph: A floor can be used for one or more media types; the mandatory element can contain zero or more of the