From internet-drafts@ietf.org Mon Nov 4 02:47:30 2013 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FD721F9CB5; Mon, 4 Nov 2013 02:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XalYGnrxXoL; Mon, 4 Nov 2013 02:47:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE4921F8DA3; Mon, 4 Nov 2013 02:44:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131104104454.10115.16900.idtracker@ietfa.amsl.com> Date: Mon, 04 Nov 2013 02:44:54 -0800 Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-10.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 10:47:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Binary Floor Control Protocol Bis Workin= g Group of the IETF. Title : The Binary Floor Control Protocol (BFCP) Author(s) : Gonzalo Camarillo Keith Drage Tom Kristensen Joerg Ott Charles Eckel Filename : draft-ietf-bfcpbis-rfc4582bis-10.txt Pages : 90 Date : 2013-11-04 Abstract: Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in Section 16. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfcpbis-rfc4582bis-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Nov 4 02:48:08 2013 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE2D21F9B8A; Mon, 4 Nov 2013 02:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32bHVoNcsTkJ; Mon, 4 Nov 2013 02:48:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB4521F9CBF; Mon, 4 Nov 2013 02:46:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131104104602.10152.53604.idtracker@ietfa.amsl.com> Date: Mon, 04 Nov 2013 02:46:02 -0800 Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-08.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 10:48:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Binary Floor Control Protocol Bis Workin= g Group of the IETF. Title : Session Description Protocol (SDP) Format for Binary Flo= or Control Protocol (BFCP) Streams Author(s) : Gonzalo Camarillo Tom Kristensen Filename : draft-ietf-bfcpbis-rfc4583bis-08.txt Pages : 17 Date : 2013-11-04 Abstract: This document specifies how to describe Binary Floor Control Protocol (BFCP) streams in Session Description Protocol (SDP) descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. This document obsoletes RFC 4583. Changes from RFC 4583 are summarized in Section 12. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfcpbis-rfc4583bis-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tomkrist@cisco.com Mon Nov 4 02:54:40 2013 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DDA21F83EF for ; Mon, 4 Nov 2013 02:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpfjMOhJt0Pr for ; Mon, 4 Nov 2013 02:53:34 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF6321F9D0F for ; Mon, 4 Nov 2013 02:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=756; q=dns/txt; s=iport; t=1383562254; x=1384771854; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=mW/p2ygmNCHx0Mp02Ob4KL2ympSIV+S1xXbWz4z9Vh0=; b=UC9w7k7hLRTxQG3LYpQgL4XjluKepKxq9JjhB+9nMGoMP8m18m68Dqez f+2UvzUUIz+9/UeoPK8c5R0ozOEwGn2aWiZtLh4cXAW+RT3uZEDOTNDjw u5JwmrGF+HH1DzqkNAIHdX60sXNHzFRo963nDknKkgVY6d/lWedk49+W4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAC57d1KQ/khR/2dsb2JhbABZgwfASIEkFnSCJQEBAQQ4QBELGAkWDwkDAgECAUUTBgIBAYd9vhaPXxaEGAOYCoY9i0yDJzs X-IronPort-AV: E=Sophos;i="4.93,631,1378857600"; d="scan'208";a="161358675" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 04 Nov 2013 10:50:53 +0000 Received: from [10.47.38.191] ([10.47.38.191]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA4AolhO029184 for ; Mon, 4 Nov 2013 10:50:49 GMT Message-ID: <52777C07.1080403@cisco.com> Date: Mon, 04 Nov 2013 11:50:47 +0100 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: bfcpbis@ietf.org References: <20131104104454.10115.16900.idtracker@ietfa.amsl.com> In-Reply-To: <20131104104454.10115.16900.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-10.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 10:54:41 -0000 On 11/04/2013 11:44 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Binary Floor Control Protocol Bis Working Group of the IETF. > > Title : The Binary Floor Control Protocol (BFCP) > Author(s) : Gonzalo Camarillo > Keith Drage > Tom Kristensen > Joerg Ott > Charles Eckel > Filename : draft-ietf-bfcpbis-rfc4582bis-10.txt > Pages : 90 > Date : 2013-11-04 > Pure keep-alive version. Only changes are rfc4582bis and rfc4583bis (reference to) version numbers and dates. From tomkrist@cisco.com Mon Nov 4 02:57:52 2013 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D45221F9CBF for ; Mon, 4 Nov 2013 02:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVJ3MfeDYRRM for ; Mon, 4 Nov 2013 02:57:47 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id EFC9211E8292 for ; Mon, 4 Nov 2013 02:54:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=740; q=dns/txt; s=iport; t=1383562489; x=1384772089; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=+FLygzL7axrl2djq56CiJHx42PdwXnl1WQcB0OdOq7Y=; b=chCUzbyTuSdlYnFthWiHN2+F7ws1E0wdaSZBepipG6WODiUU/KvAU3Gt 9ITLZbPH+iCORCDsGFfl17nE7UMCSoI30S1H1dVRnJ6ac8rj6gq4HbfB7 6lHgWcYXyEeeDICWR07h+e4pwjLIpv35OcGi8Ae76niXaV32ZWBD2bHRj o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAC58d1KQ/khM/2dsb2JhbABZgwfASIElFnSCJQEBAQQ4QBELGAkWDwkDAgECAUUTBgIBAYd9vhOPXxaEGAOYCoY9i0yDJzs X-IronPort-AV: E=Sophos;i="4.93,631,1378857600"; d="scan'208";a="19234196" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 04 Nov 2013 10:53:09 +0000 Received: from [10.47.38.191] ([10.47.38.191]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA4Ar2Yc006655 for ; Mon, 4 Nov 2013 10:53:05 GMT Message-ID: <52777C8E.9070007@cisco.com> Date: Mon, 04 Nov 2013 11:53:02 +0100 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: bfcpbis@ietf.org References: <20131104104602.10152.53604.idtracker@ietfa.amsl.com> In-Reply-To: <20131104104602.10152.53604.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-08.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 10:57:52 -0000 On 11/04/2013 11:46 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Binary Floor Control Protocol Bis Working Group of the IETF. > > Title : Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams > Author(s) : Gonzalo Camarillo > Tom Kristensen > Filename : draft-ietf-bfcpbis-rfc4583bis-08.txt > Pages : 17 > Date : 2013-11-04 > Pure keep-alive version. Only changes are rfc4583bis and rfc4582bis (reference to) version numbers and dates. As a bonus one typo is fixed; s/asume/assume/. -- Tom From gonzalo.camarillo@ericsson.com Mon Nov 25 04:24:54 2013 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B9C1AD8F1 for ; Mon, 25 Nov 2013 04:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWgbUAucL1rh for ; Mon, 25 Nov 2013 04:24:52 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 35FDE1AD8F9 for ; Mon, 25 Nov 2013 04:24:52 -0800 (PST) X-AuditID: c1b4fb38-b7f2c8e000006d25-7e-52934193c43f Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id CA.5F.27941.39143925; Mon, 25 Nov 2013 13:24:51 +0100 (CET) Received: from [147.214.22.133] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.328.9; Mon, 25 Nov 2013 13:24:51 +0100 Message-ID: <52934193.5050304@ericsson.com> Date: Mon, 25 Nov 2013 13:24:51 +0100 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Tom Kristensen , References: <20131104104454.10115.16900.idtracker@ietfa.amsl.com> <52777C07.1080403@cisco.com> In-Reply-To: <52777C07.1080403@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkluLIzCtJLcpLzFFi42KZGfG3Vney4+Qgg2m/TC3+rTvKZHHlyC82 ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvj39Pwgn75ipZXXxkbGD9JdDFycEgImEis 2J7RxcgJZIpJXLi3nq2LkYtDSOAIo8TjH7eZIJw1jBJHTh5nA6niFdCW+Pj1IztIM4uAqsT0 ObogYTYBC4ktt+6zgNiiAlES58+9ZIIoF5Q4OfMJC0i5iIC1xMt//CBhYQF3iT/XWsFKhATi JJoaDoBN5xTQlHh5o5sZ4jRxiZ7GIJAws4CexJSrLYwQtrzE9rdzmCFatSWWP2thmcAoOAvJ sllIWmYhaVnAyLyKkaM4tTgpN93IYBMjMBgPbvltsYPx8l+bQ4zSHCxK4rwf3zoHCQmkJ5ak ZqemFqQWxReV5qQWH2Jk4uCUamBs/txt8Zc38XVJtQCDs4Z1RNj6WItzc75PVanOzrHwFZ/U WDL9pWbqsto3egsDb5/w3Mn0kNHF3L+tokbsv+XKZRdXqOhlb58qrVmeIXnxyP5p059suLiQ X1LCnDHAbd57tvQzm7Sn+Vo2MUwqrVoXKFey5GPTxMYFtWnsDrZLy6dqu3qt2KrEUpyRaKjF XFScCAD6dk7IFAIAAA== Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-10.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 12:24:55 -0000 Hi Tom, thanks for keeping the draft alive. I have had q quick look at Section 6 and I have a few comments. http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-10#section-6 The first paragraph of Section 6 states that an entity can choose TCP or UDP depending on the environment. Lately, the IESG is asking authors to be a bit more explicit about operational issues. So, I think we should add a few sentences explaining (briefly) who makes that decision. Is it the implementation that first tries TCP and, if it does not work, it falls back to UDP? Or do we expect administrators to configure this depending on the environment? We can describe several potential different deployment scenarios as well. The second paragraph of Section 6.2 explains that the floor control server is considered present and available upon receiving a HelloAck message. We should also explain the circumstances in which the service is considered to have become unavailable (e.g., ICMP messages or timeouts). The following is the last sentence of the 3rd paragraph of Section 6.2: > Concordantly, messages sent by the floor > control server that are not transaction-completing (e.g., FloorStatus > announcements as part of a FloorQuery subscription) are server- > initiated transactions that require acknowledgement messages from the > floor participant and chair entities to which they were sent. I do not think the term "transaction-completing" have been defined in the document. We should use a different term or, even better, explain explicitly what we mean. Also, I do not understand the point the sentence is intended to make. We should rephrase. The 4th paragraph of Section 6.2 talks about the "Unable to parse" message in the context of unreliable transports. Why don't we use that with TCP as well? Is it because of backward compatibility issues? If so, we should add a clarifying note. The following sentence appears in the first paragraph of page 41: > The subsequent changes in state for > the request are new transactions whose Transaction ID is determined > by the floor control server and whose receipt by the client > participant shall be acknowledged with a FloorRequestStatusAck > message. Instead of "shall be", we should write "MUST be" if this behavior has not been normatively defined anywhere else, or "is" if the behavior has been normatively defined somewhere else. The following paragraph appears later in Section 6.2: > If a client wishes to end its BFCP connection with a floor control > server, it is RECOMMENDED that the client send a Goodbye message to > dissociate itself from any allocated resources. If a floor control > server wishes to end its BFCP connection with a client (e.g., the > Focus of the conference informs the floor control server that the > client has been kicked out from the conference), it is RECOMMENDED > that the floor control server send a Goodbye message towards the > client. Why is it RECOMMENDED (i.e., SHOULD level) instead of REQUIRED (i.e., MUST level)? This comment is also somewhat related to my first comment above about BFCP entities considering other entities gone. Have we defined at which point can they forget their state information? This also relates to the last paragraph of Section 6.2.2 that talks about using STUN connectivity checks for this. We should probably talk about all this somewhere. The following paragraph appears in Section 6.2.3: > When a BFCP implementation receives a BFCP message fragment, it MUST > buffer the fragment until it has received the entire BFCP message. > The state machine should handle the BFCP message only after all the > fragments for the message have been received. However, the paragraph after that seems to contradict the "MUST" above because it allows receivers to discard incomplete buffers. Cheers, Gonzalo