From rbarnes@bbn.com Thu Oct 15 12:26:14 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D892A3A6947 for ; Thu, 15 Oct 2009 12:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id av3KLVIkHMi7 for ; Thu, 15 Oct 2009 12:26:14 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3FA263A67AA for ; Thu, 15 Oct 2009 12:26:14 -0700 (PDT) Received: from ros-dhcp192-1-51-71.bbn.com ([192.1.51.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MyV1k-0006Hx-Ey for xcon@ietf.org; Thu, 15 Oct 2009 14:26:16 -0400 Message-ID: <4AD77759.5070200@bbn.com> Date: Thu, 15 Oct 2009 15:26:17 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: xcon@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [XCON] Planning for IETF 76 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 19:26:14 -0000 Hi all, If you are planning to speak during the XCON session in Hiroshima, please send an email to Alan and me explaining the topic you would like to discuss. Please let us know by next Thursday, 22 October. Thanks, --Richard From Simo.Veikkolainen@nokia.com Thu Oct 22 03:22:18 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E723A67D4 for ; Thu, 22 Oct 2009 03:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev3V77flzFd0 for ; Thu, 22 Oct 2009 03:22:17 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 24D813A687F for ; Thu, 22 Oct 2009 03:22:16 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9MAM8CK005758 for ; Thu, 22 Oct 2009 13:22:23 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 13:22:05 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 13:22:00 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 22 Oct 2009 12:21:59 +0200 From: To: Date: Thu, 22 Oct 2009 12:21:58 +0200 Thread-Topic: My review of draft-ietf-xcon-ccmp-03 Thread-Index: AcpTAXybWUCNontmRoCv9wMDKWy5jw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Oct 2009 10:22:00.0608 (UTC) FILETIME=[7DEA9A00:01CA5301] X-Nokia-AV: Clean Subject: [XCON] My review of draft-ietf-xcon-ccmp-03 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 10:22:18 -0000 Hello, I have now completed my review of draft-ietf-xcon-ccmp-03, for which I volu= nteered in Stockholm meeting. I apologize for the embarrasingly long time t= his took. Document: draft-ietf-xcon-ccmp-03 Reviewer: Simo Veikkolainen Review date: Oct 22, 2009 General comments ---------------- The document seems to be in a good shape, I only had minor concerns and com= ments. Note that I didn't review the schema because as I'm not very fluent = in XML. P. 7 "... the conference server SHOULD indicate that the data has been modi= fied and return the current conference object to the client." It might be b= eneficial that some operations succeed even if the object does not reflect = the current state. Example: adding a user. P. 13 "[...] delete: to remove from the system a conference object or a con= ference user" Does this apply also to conference sidebars? P. 36 When updating conference information, it was not always clear whether= the 'xxxInfo' should contain the entire element as defined by the XCON dat= a model, or is it possible to update just part of the element. For example,= when performing sending userRequest with operation 'update', does the user= Info contain a complete element as defined by the data model? This s= hould be clearly indicated when describing each update operation. P. 72 The documents states that "For the case of users joining the conferen= ce using the CCMP, TLS is RECOMMENDED". However, this does not cover client= authentication. What should the client authentication mechanism to be (in = case of CCMP), especially when Section 11 says a conferencing client SHOULD= NOT be required to support HTTP authentication. P. 73 Section 12.3 states that the privacy of the conference users is accom= plished by manipulation of the "provide-anonymity" element. The description= of how the "provide-anonymity" element is manipulated leaves some issues: = for example, is it allowed to delete the "provide-anonymity" element, and i= f yes, how can this be done? P. 65 An example of how Alice removes a participant from the conference wou= ld be useful. Editorial and nits ------------------- - check the usage of REQUIRED keyword in the whole document. Often, the wor= d is capitalized when actually there is no normative statement made. For ex= ample: "[...] no additional information is REQUIRED in the 'confResponse'" = on page 29. P. 15 "A specialized response message MUST [...]" should be "A specialized = request message MUST [...]" P. 29 "In case of of a confRequest" -> duplicate "of" P. 29 "A response code of 'success' indicates that the referenced conferenc= e document has not been changed by the conference server." This should be "= [...] has been changed [...]", right? P. 31 "If the 'userInfo' parameter is included [...]" Parameter name should= be 'usersInfo' P. 34 Delete "We remark that" from the beginning of the second paragraph. P. 36 "In both cases [...]" Which both cases do you refer to? P. 36 "In case of of [...]" Delete latter "of" P. 36 "[...] MUST be included in the 'confResponse' and the 'userInfo' para= meter MUST contain the entire element which to which [...]" -> delet= e "which to" P. 53 in the signalling diagram, what is "bp123"? Shouldn't this be the XCO= N URI? P. 58 Similarly, what is "conf456Updates" in the signalling diagram? P. 71 1st bullet: reference is missing. P. 71 2nd bullet: MSUT -> MUST. I would also reword this to require that th= e client must be able check the server's identity (using a certificate).=20 Regards, Simo From 2mkristensen@gmail.com Tue Oct 27 07:30:34 2009 Return-Path: <2mkristensen@gmail.com> X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843F23A6A17 for ; Tue, 27 Oct 2009 07:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ViV3qHfiZOX for ; Tue, 27 Oct 2009 07:30:33 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id CC7343A6832 for ; Tue, 27 Oct 2009 07:30:32 -0700 (PDT) Received: by bwz19 with SMTP id 19so257921bwz.28 for ; Tue, 27 Oct 2009 07:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Luo+8FTQP2YvZUx2xVv9hx65q6XQcQjeFB09j9VndDA=; b=xR1Ht/RMm/nOfn4g606oMcDCy4CtDsZ3gwRIUHFbiWBRSC2SggxAGWgmoDdqP9i/tD j+tHNQ0Xau4fo4q4QeKpEolWT9342aY2yDJMHTkyWch93SZjnPUV2CZ0tHmfBCZShIqe 3A+mHJB2YjulLCsExcSI60dPRY/3AQNd37+GE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fuox72yn0SV9Teq6hDnFZPXKfjxZyCFx+7bk7qpcrxZCvUq2uhwdokI/4E3g2wf3wt xN37A3bxA0HKf765Z1lRkYNhwg0CnUaWKAWzh7P0KNoBV3YoP1F7gXPiO5MwMUMHcV05 KBpDnQteCEOJ6UJBnGsHV59OG3Q6fVvMbKPPQ= MIME-Version: 1.0 Received: by 10.223.18.137 with SMTP id w9mr2966015faa.61.1256653843563; Tue, 27 Oct 2009 07:30:43 -0700 (PDT) In-Reply-To: <20090909113321.4289942c.lorenzo@meetecho.com> References: <4aa3ad23.1358560a.7df0.0213@mx.google.com> <20090909113321.4289942c.lorenzo@meetecho.com> Date: Tue, 27 Oct 2009 15:30:43 +0100 Message-ID: <7e4b541c0910270730p644ae796k41813142cd6da8a4@mail.gmail.com> From: Tom Kristensen <2mkristensen@gmail.com> To: xcon@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: tom.kristensen@tandberg.com Subject: Re: [XCON] BFCP over UDP X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 14:30:34 -0000 As a heads up, since personal draft announcements are not propagated to working group mailing lists: A new version of the draft associated with this thread was submitted a couple of days ago. ------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Revision of the Binary Floor Control Protocol (BFCP) for use over an unreliable transport Author(s) : M. Thompson, et al. Filename : draft-sandbakken-xcon-bfcp-udp-01.txt Pages : 14 Date : 2009-10-23 This memo extends the Binary Floor Control Protocol (BFCP) for use over an unreliable transport. It details a set of revisions to the protocol definition document and the specification of BFCP streams in the Session Description Protocol (SDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sandbakken-xcon-bfcp-udp-01.txt ------------- This submission aims at reviving the draft, to trigger further discussion within XCON and to serve as a starting point for the work on the outstanding issues. Refer to Section 4 of the draft for a list/details of further work. The draft is structured to ease merging into the upcoming bis-drafts for RFC4582 and RFC4583 in a later stage. Cheers, -- Tom 2009/9/9 Lorenzo Miniero : > Hi Roni, > > I also think this would be a very useful solution to have, and would > support a new document addressing the UDP case. For what concerns > fragmentation, however, this is probably an orthogonal issue, since in > my opinion it may affect the BFCP/TCP as well. > > When working on the implementation of the protocol, in fact, we noticed > how large BFCP messages could easily become, and so I raised this issue > on the ML: > > http://www.ietf.org/mail-archive/web/xcon/current/msg01920.html > > but it didn't seem to gather much interest at the time. Anyway, if > anyone is interested in working on this in the future (be it as part of > a potential new BFCP/UDP document or somewhere else), I'd be glad to > cooperate. > > Lorenzo > > > > On Sun, 6 Sep 2009 15:36:42 +0300 > "Roni Even" wrote: > >> Hi, >> >> I reviewed the individual draft draft-sandbakken-xcon-bfcp-udp-00 which have >> expired. I find that this proposal important in order to work in >> environments where TCP will fail because of FW/NWT traversal issues and >> would like to see an update to the draft that will address the security >> issue probably using DTLS. The draft should also address the issue of >> fragmentation. >> >> The use case is for supporting token based presentation and the assumption >> is that the information will be small so the fragmentation will be less >> critical. >> >> >> >> >> >> Roni Even >> >> > > > -- > Lorenzo Miniero > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www.ietf.org/mailman/listinfo/xcon > -- # TANDBERG R&D ## http://www.tandberg.com ### http://folk.uio.no/tomkri/ From oscar.novo@ericsson.com Tue Oct 27 08:24:50 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDC6B3A68ED for ; Tue, 27 Oct 2009 08:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYue0WYU0jcL for ; Tue, 27 Oct 2009 08:24:48 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id AFB823A6951 for ; Tue, 27 Oct 2009 08:24:23 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-42-4ae710b4428e Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 63.CE.31706.4B017EA4; Tue, 27 Oct 2009 16:24:36 +0100 (CET) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 16:24:35 +0100 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: Tue, 27 Oct 2009 16:24:34 +0100 Message-ID: <9520E66537CC4941994C518E3E21091C01E29FEC@esealmw105.eemea.ericsson.se> In-Reply-To: <4A88689A.2050006@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Review of draft-ietf-xcon-common-data-model Thread-Index: AcoeriuffWHw5kJ4Qw6As53Iwfqp6Q4ax0ig References: <4A88689A.2050006@bbn.com> From: "Oscar Novo" To: "Richard Barnes" , X-OriginalArrivalTime: 27 Oct 2009 15:24:35.0571 (UTC) FILETIME=[972EDC30:01CA5719] X-Brightmail-Tracker: AAAAAA== Subject: Re: [XCON] Review of draft-ietf-xcon-common-data-model X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 15:24:50 -0000 Hi Richard, Still I haven't got enough time to work in your comments but, definitely, I'll look into them when I got some time. Thanks for your comments! Oscar -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Richard Barnes Sent: 16. elokuuta 2009 23:14 To: xcon@ietf.org Subject: [XCON] Review of draft-ietf-xcon-common-data-model Hi all, In my effort to get up to speed on XCON, I'm in the process of reviewing the active working group drafts (in addition to the other relevant background). My review of draft-ietf-xcon-common-data-model is below. --Richard ----- Draft: draft-ietf-xcon-common-data-model-13 Reviewer: Richard Barnes Review Date: 13 Mar 07 General Comments: 1. The major challenge I had with this document there doesn't seem to be a clear separation in some cases between what the document describes, and what actions are implied. I'll call out specific instances below, but in future revisions, I would encourage the authors to focus describing clearly what the state of the conference is that this object describes, and separately, what actions this state requires or allows. Specific Comments: Section 1, Paragraph 1 The phrase "... using an Extensible Markup Language (XML)-based." does not parse. Section 1, Paragraph 3 s/and specifies who/and specifies by whom/ Section 3.3.1, ABNF It seems like a lot of the ABNF for the SIP URI (RFC3261, page 222) could be re-usable here. E.g., you could just say XCON-URI =3D "xcon:" [ userinfo ] hostport This would align the sets = of allowed characters in what is now the conf-object-id, which could make parsing easier. It would also add back in the "password" field (within userinfo), which could be useful when these URIs are used to access XCON conferences via CCMP (you would however, have to REQUIRE that the password be the same as the ). Section 4.2.1 It seems like there should be some structure to the element, e.g., using the language tags from RFC1766. Section 4.2.6 This section specifies the meaning of this element if it is present and set to true, but not what it means for it to be present and false, or absent. Is the default for sidebars to be disallowed, confirmed by a moderator, etc.? Section 4.2.9, bullet This section says that the element specifies when mixing starts "before"=20 the conference starts. Should this be "relative to", or is it not allowed for mixing to start after the conference starts? Section 4.2.9, bullet It's a little bit confusing that this element ends in -offset but isn't an offset. Does this interact with the requiredParticipant attribute of the element? E.g., can this element indicate that a privileged participant should be denied an extension to the mixing time? Section 4.2.13, bullet This section specifies what the "Moderator-controlled" and "FCFS"=20 policies mean (although it's not clear to me what "a first-come-first-served" algorithm is when comes to media), but doesn't define what the "Automatic" algorithm means. Section 4.2.13, bullet It's really unclear what this element means. Are the sub-elements of the "controls" element describing controls that are available to a user? Constraints on how the current media streams are handled? I.e., does true tell the conference server to stop sending audio, or does it tell a client to show a "mute" control to the user? Section 4.2.13, bullet Why are these controls necessary? Are there systems that are doing video layout on the server? If not, then isn't it just a client UI issue? Section 4.6.2 For clarity, it might be helpful here (and in the Security Considerations) to say that these elements specify only that the clients must authenticate to the server, using a mechanism of the server's choosing -- the specific mechanism(s) to be used are determined by individual servers for individual CSPs, and are beyond the scope of this document. Section 4.6.5 Why does the "entity" attribute have to be unique in the scope of the conferencing system, rather than within the scope of the conference? At first blush, it might seem like this is necessary for CCMP, but in that case, there is always a conference-ID present to disambiguate. Section 4.6.5.3 s/provides anonymity/specifies what level of anonymity the server should provide/ Section 4.6.5.7 s/boolean action/boolean value/ Section 4.6.5.* It seems like there's an element missing, something like . and correspond to the "dial-out", and "refer" values for "method" above; what about "dial-in"? Section 4.6.5.10, paragraph 3 Is this phrase correct? "... a floor that joins the participant in the conference"? Section 8.1 See above comment on Section 4.6.2 Section 8.2 This section should be rewritten to be a little less hand-wavy. The key points are (1) conference information can be sensitive, so (2) protocols that transmit conference object need to be able to confidentiality-protect them. Couple of sentences describing the risks, then one sentence saying the "Protocols that transmit conference objects (or fragments thereof) MUST be able to provide confidentiality protection to them." Section 8.3 Since we're mostly talking about an object as it resides on the conference server, most of the integrity are related to authentication and access control. So this section could probably be deleted in favor of changing the title of 8.1 to "Authentication, Access Control, & Integrity". The only addition that might be necessary is to ensure that protocols that carry these objects over the wire provide them with integrity protection in order to ensure the integrity of the management process; essentially the confidentiality sentence above, s/confidentiality/integrity/. _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon