From eckelcu@cisco.com Fri Feb 7 16:01:19 2014 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 EEF571A04C8 for ; Fri, 7 Feb 2014 16:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 15dRhkZFcp5O for ; Fri, 7 Feb 2014 16:01:17 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 69CBF1A0512 for ; Fri, 7 Feb 2014 16:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1461; q=dns/txt; s=iport; t=1391817677; x=1393027277; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=QzFcAg4fWcP7wufXH7vY3Jj0M3zEoR1rqdKW+vN/ufQ=; b=R/DV9uLr9GCCbJeIhLiUVW0spIwQK8qtdYpuv4ggpv4UUOYtML1UpAFX 7JP7qn9bVygOicqhwEQ22HcqUjN+88bcoW0KKblbMCaWGpEb8k9BwS6TH tp5M0lUqNzCt2bgtUlRuvkT0lcUH/Jkzw6wv1qOETdbZrofclvuRbHtvZ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUFAE5z9VKtJV2c/2dsb2JhbABZgww4V6QwCQGaO4EJFnSCJQEBAQQ6TwIBCDYQMhsBBgMCBBMJh3wNswuOG4seF44pVgWEOASYK5Ihgy2CKg X-IronPort-AV: E=Sophos;i="4.95,803,1384300800"; d="scan'208";a="302754503" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 08 Feb 2014 00:01:17 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1801HOI032030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 8 Feb 2014 00:01:17 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.41]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 18:01:16 -0600 From: "Charles Eckel (eckelcu)" To: "bfcpbis@ietf.org" Thread-Topic: IETF 89 Final Agenda Thread-Index: AQHPJFXbV5/utTAHiUOjOv4mVAn/zJqqUAaA Date: Sat, 8 Feb 2014 00:01:16 +0000 Message-ID: References: <20140207224211.1515.26498.idtracker@ietfa.amsl.com> In-Reply-To: <20140207224211.1515.26498.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.148.216] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [bfcpbis] FW: IETF 89 Final Agenda 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: Sat, 08 Feb 2014 00:01:19 -0000 Please note that we will be having a BFCPBIS session at IETF. 1420-1550 GMT Tuesday Afternoon Session II, Palace C Please also note the new date and time, as it differs from the preliminary agenda. The session was requested to close on any remaining issues with draft-ietf-bfcpbis-rfc4582bis and draft-ietf-bfcpbis-rfc4583bis. Please let the chairs know if you would like agenda time for any specific issues with these drafts, or if you have anything else you would like to be considered for the agenda. Cheers, Charles =20 On 2/7/14 2:42 PM, "IETF Agenda" wrote: > >Hello Everyone! > >NOTE:You will not receive an automatic notification informing you that >your session has been scheduled or if it has been changed from the >preliminary agenda. Please see >https://datatracker.ietf.org/meeting/89/agenda.html to determine the >time(s) of your session(s). > >The final agenda is ready for viewing. Please take a moment to note the >time of your session(s) and meeting room(s). At this point only Area >Directors can submit changes in the form of a swap to agenda@ietf.org. >Please let me know if you have any questions. > >https://datatracker.ietf.org/meeting/89/agenda.html >https://datatracker.ietf.org/meeting/89/agenda.txt > >Information on the 89th IETF meeting in London, England can be found >here: http://www.ietf.org/meeting/89/index.html > >Thank you! > >Stephanie McCammon From victor.pascual.avila@gmail.com Sun Feb 9 13:40:43 2014 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 9C4AE1A0601 for ; Sun, 9 Feb 2014 13:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 w_52xyF0xhfN for ; Sun, 9 Feb 2014 13:40:41 -0800 (PST) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7CB1A0612 for ; Sun, 9 Feb 2014 13:40:39 -0800 (PST) Received: by mail-pd0-f180.google.com with SMTP id x10so5280174pdj.25 for ; Sun, 09 Feb 2014 13:40:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yJ1PeP1ZmxG8I1qo9lbN/heeDPDr3u0aVR9z4l1qhao=; b=SuXUJyiUDRr6Z+0kFW+93Y6zZPAtkvQ3OfnAEklElLFp0s83jhaLJ51mBac+Jf6Z/R 4gnS2519Yl46IcFWFi0xUpHyNUSDDO+oFRsLrOHFYH+pu1KaN8M+b8RzEjvwJnZU7EiX jZeiZWBxDfd3g552DqeMhC1Lx0g+yZDOe7j4RmrEsP/GgpNgUki6Q1dRIOG6ozs6cUUn JZTwA9xuOzSo0SeYZU5g//F5x3cm1G3rXgCg4ID1TwdHnwIoPYb9Kbrqk6gF5PzHMIT+ fJ4CR41ulom/O72K497NaxwgN4F/nS+k+lgYAa4Wevpt92OWoa6UFYcT7m9s+uCPLpow KlDw== MIME-Version: 1.0 X-Received: by 10.68.14.130 with SMTP id p2mr33968041pbc.17.1391982039867; Sun, 09 Feb 2014 13:40:39 -0800 (PST) Received: by 10.68.184.161 with HTTP; Sun, 9 Feb 2014 13:40:39 -0800 (PST) In-Reply-To: <20140209205037.18117.63043.idtracker@ietfa.amsl.com> References: <20140209205037.18117.63043.idtracker@ietfa.amsl.com> Date: Sun, 9 Feb 2014 22:40:39 +0100 Message-ID: From: Victor Pascual Avila To: bfcpbis@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [bfcpbis] Fwd: I-D Action: draft-pascual-bfcpbis-bfcp-websocket-00.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: Sun, 09 Feb 2014 21:40:43 -0000 Hi all, We have submitted a new Internet draft to describe the WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP). We are looking forward to your review comments. http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00 Thank you, -Victor ---------- Forwarded message ---------- From: Date: Sun, Feb 9, 2014 at 9:50 PM Subject: I-D Action: draft-pascual-bfcpbis-bfcp-websocket-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP) Authors : Victor Pascual Anton Roman Stephane Cazeaux Gonzalo Salgueiro Sergio Garcia Murillo Filename : draft-pascual-bfcpbis-bfcp-websocket-00.txt Pages : 11 Date : 2014-02-09 Abstract: The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies a new WebSocket sub- protocol as a reliable transport mechanism between Binary Floor Control Protocol (BFCP) entities to enable usage of BFCP in new scenarios. This document normatively updates [I-D.draft-ietf- bfcpbis-rfc4582bis] and [I-D.draft-ietf-bfcpbis-rfc4583bis] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-pascual-bfcpbis-bfcp-websocket/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From eckelcu@cisco.com Mon Feb 10 11:28:29 2014 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 91ED71A050E for ; Mon, 10 Feb 2014 11:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 qhPAjufJtTMj for ; Mon, 10 Feb 2014 11:28:27 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFFB1A0450 for ; Mon, 10 Feb 2014 11:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2811; q=dns/txt; s=iport; t=1392060507; x=1393270107; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=sZHuCC+xI34D2SgWJKYc4sDdGubz9wTByVfWucPZMyU=; b=fnjOAD/Dhj+OV3IdtJkt+V3dZ5XSI30LvQBN1KKxc9CJabFj36qN8uLT 5dT+a4rVbvOjXKiIBy3H4lv9ISd+cWf5LHK8bmE7WFogxfGKkBv5r0QXI gx+r+XC8vnyWrPztcLl0YXY6RS+fcQLEHkmHTeqzG5tbmCHAjaj83UaPv o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFADwo+VKtJXG+/2dsb2JhbABZgww4V78ST4EVFnSCJQEBAQQBAQE3NBsCAQgRAwECHxAhBgsdCAIEARIJh2gDEAENwTsNh2UXjGaCGQUGhDIElj+BbIEyiysDhUCDLYIq X-IronPort-AV: E=Sophos;i="4.95,819,1384300800"; d="scan'208";a="19348718" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-7.cisco.com with ESMTP; 10 Feb 2014 19:28:25 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1AJSP8X009799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 19:28:25 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.41]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 13:28:25 -0600 From: "Charles Eckel (eckelcu)" To: Victor Pascual Avila , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] Fwd: I-D Action: draft-pascual-bfcpbis-bfcp-websocket-00.txt Thread-Index: AQHPJpZEnjN5xVEoiEihlztIIhSxcw== Date: Mon, 10 Feb 2014 19:28:25 +0000 Message-ID: References: <20140209205037.18117.63043.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [171.68.20.17] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [bfcpbis] Fwd: I-D Action: draft-pascual-bfcpbis-bfcp-websocket-00.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, 10 Feb 2014 19:28:29 -0000 For those of you interested in this draft, which was previously discussed within DISPATCH, please provide your comments asap. The chairs will use this as input when determining whether to place this draft on the agenda and how much time to allocate to it. Cheers, Charles=20 On 2/9/14 1:40 PM, "Victor Pascual Avila" wrote: >Hi all, > >We have submitted a new Internet draft to describe the WebSocket >Protocol as a Transport for the Binary Floor Control Protocol (BFCP). >We are looking forward to your review comments. > >http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00 > >Thank you, >-Victor > >---------- Forwarded message ---------- >From: >Date: Sun, Feb 9, 2014 at 9:50 PM >Subject: I-D Action: draft-pascual-bfcpbis-bfcp-websocket-00.txt >To: i-d-announce@ietf.org > > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : The WebSocket Protocol as a Transport for >the Binary Floor Control Protocol (BFCP) > Authors : Victor Pascual > Anton Roman > Stephane Cazeaux > Gonzalo Salgueiro > Sergio Garcia Murillo > Filename : draft-pascual-bfcpbis-bfcp-websocket-00.txt > Pages : 11 > Date : 2014-02-09 > >Abstract: > The WebSocket protocol enables two-way realtime communication between > clients and servers. This document specifies a new WebSocket sub- > protocol as a reliable transport mechanism between Binary Floor > Control Protocol (BFCP) entities to enable usage of BFCP in new > scenarios. This document normatively updates [I-D.draft-ietf- > bfcpbis-rfc4582bis] and [I-D.draft-ietf-bfcpbis-rfc4583bis] > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-pascual-bfcpbis-bfcp-websocket/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00 > > >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/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >_______________________________________________ >bfcpbis mailing list >bfcpbis@ietf.org >https://www.ietf.org/mailman/listinfo/bfcpbis From 2mkristensen@gmail.com Thu Feb 13 06:50:45 2014 Return-Path: <2mkristensen@gmail.com> 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 0A99E1A02C5 for ; Thu, 13 Feb 2014 06:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, SPF_PASS=-0.001] autolearn=no 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 9m3N_UBGG59u for ; Thu, 13 Feb 2014 06:50:41 -0800 (PST) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 03A1F1A02BD for ; Thu, 13 Feb 2014 06:50:40 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id w8so16341342qac.14 for ; Thu, 13 Feb 2014 06:50:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XyARt2Vy3dBdOZdHt03fByVLB/VvTZTtG3/UyR70Ox0=; b=e89A8ZR1vR2PntA70pIeGvK5fsO2NY6ffJao/4zv2jk89bZ8y/BHtgE3M9hNyJyTa1 6Hx+NUeCNbsZ561bXmqd29qgEBQgHfUXSRjgCyf7qx07kQBKI39fU3/niU/3diWodMdw j4NIQOkGmpxCO888CxTfL+nl2HHiSA0FT8qcT2i8YqIQJA/2BVCweBwpZAP2tBvAqKQV 3pjmUo7lewqWSFO0XghA8PDZHkR+usZDEd5/MUQdBOkNjwaRjWEJ2bsqreSkFb5hfXn/ 4eb4nuK+Tfp0Kd49m2NYVeV6lKvLJwd9tjt0UxXkdVmv2LHgDIeea8cX8v20w6ovtGrC e1xQ== MIME-Version: 1.0 X-Received: by 10.224.165.133 with SMTP id i5mr3049834qay.75.1392303039165; Thu, 13 Feb 2014 06:50:39 -0800 (PST) Received: by 10.229.2.69 with HTTP; Thu, 13 Feb 2014 06:50:39 -0800 (PST) In-Reply-To: References: <52D7F10B.5070401@cisco.com> Date: Thu, 13 Feb 2014 15:50:39 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=089e0149c6c011c0a104f24ad087 Cc: "draft-ietf-bfcpbis-rfc4583bis.authors@tools.ietf.org" , "bfcpbis-chairs@tools.ietf.org" , "Tom Kristensen \(tomkrist\)" , Richard Barnes , "bfcpbis@ietf.org" , Mary Barnes Subject: Re: [bfcpbis] PROTO review comments on draft-ietf-bfcpbis-rfc4583bis-08 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: Thu, 13 Feb 2014 14:50:45 -0000 --089e0149c6c011c0a104f24ad087 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All the issues here are resolved inline in line with Mary's suggestions - as adjusted and commented by Charles and myself in this thread. The upcoming version will include the changes. -- Tom On 24 January 2014 23:41, Charles Eckel (eckelcu) wrote= : > On 1/16/14 6:47 AM, "Tom Kristensen (tomkrist)" > wrote: > > >I went through and commented on this in my favourite editor (Emacs > >obviously), but forgot to paste it in and respond until now. I have > >updated my comments to align with Charles Eckel's recent response too. > > Thanks for that. More inline. > > > > >Inline below. > > > > > >On 12/18/2013 11:38 PM, Mary Barnes wrote: > > > Hi all, > > > > > > I have agreed to shepherd this document on behalf of the WG. I have > > > reviewed this document in preparation for doing the PROTO write-up. > > > > > > I think the document needs a bit of work before it's ready to progres= s. > > > I have a few questions/comments, as well as editorial nits which I > >think > > > would improve readability and ease of understanding. > > > > > > _General Comments:_ > > > > > > The document requires an SDP directorate review prior to progressing.= I > > > have requested that of the MMUSIC WG chairs. At the time of this > >review, > > > Ali Begen has agreed to do that review. > > > >Yes, I have commented on his issues on the MMUSIC mailing list. > > > > > _Comments/Questions:_ > > > > > > 1) I am slightly puzzled by the following in section 3: > > > > > > m=3D ... > > > > > > Section 5.14 of RFC 4566 states the following: > > > > > > m=3D ... > > > > > > So, this looks to be like the RFC 2327 ABNF for m lines is being used > > > (rather than RFC 4566 which is the normative SDP specification for th= is > > > document)? > > > > > > m=3D > > > > > > Note, that the IANA registration section appears to be based on RFC > >4566 > > > as the values are specified as being applicable to the 'pro to' field= . > > > So, my guess is that this is a bug from RFC 4583. > > > >Yes, an inherited bug that will be fixed without complications. > > > > > 2) Section 3, next to last paragraph. I think it would be more precis= e > > > to reword this as: > > > > > > OLD: > > > > > > The fmt (format) list is ignored for BFCP. The fmt list of BFCP 'm' > > > lines SHOULD contain a single "*" character. > > > > > > NEW: > > > > > > The fmt (format) list is not applicable to BFCP. The fmt list of 'm' > > > lines in the case of any proto field value related to BFCP SHOULD > > > contain a single "*" character. If the the fmt list contains any othe= r > > > value it is ignored. > > > >Agree. That is a more precise wording for the fmt part. > > > >Charles Eckel touched upon this as well and was okay with this, > >especially if there are known reasons and/or implementations that > >already do otherwise. Well, once upon a time there was a SIP based > >product from a (large french) vendor that used 0 (I think) - don't think > >that product is still maintained. But it might be out there in the wild > >still. Will fix. > > > > > 3) Section 4, paragraph above table 1, 1st sentence. I suggest for > > > clarification to make the following change: > > > > > > OLD > > > > > > MUST include one in the corresponding media description > > > > > > NEW > > > > > > MUST include a 'floorctrl' attribute in the corresponding media > >description > > > >Fine with me, will update. > > > > > 4) Section 4, 3rd paragraph from the end: > > > > > > "Endpoints that use the offer/answer model to establish BFCP > >connections > > > MUST support the 'floorctrl' attribute. A floor control server acting > >as > > > an offerer or as an answerer SHOULD include the attribute in its > >session > > > descriptions." > > > > > > Since the latter is a SHOULD what happens if the attribute is NOT > > > included? Under what circumstances is it okay for the server not to > > > include it? IF bad things happen if it's not included, then this > > > probably ought to be a MUST. Or, if there's reasonable situations in > > > which the floor control server doesn't include the attribute, those > > > should be explained or at least an example provided. > > > >The default behaviour/assumption if the 'floorctrl' attribute is not > >used is explained in the paragraph below, i.e. offerer =3D=3D client and > >answerer =3D=3D server. > > > >I agree that the formulation "is not used in an offer/answer exchange" > >might point towards usage other than offer/answer, but the sentence > >continues with explaining what the offerer and answerer will assume. So > >fine with me. OK? > > > >If not, I will not object using MUST here - as also proposed by Charles > >Eckel. > > > > > 5) Section 7. > > > > > > a) 1st paragraph after ABNF. "..versions SHOULD be integers..". I wou= ld > > > think that ought to be a MUST. What happens if the token isn't an > > > integer and what was the motivation for not defining the version as a= n > > > integer versus a token? If non-integers can be used, the scope of wha= t > > > is acceptable for the field needs to be explained. > > > >I agree, this will be upgraded to a MUST if people doesn't object. > > > >And if this will ever change non-integer versions must be specified in > >another draft/RFC and this draft probably have to be updated as well - > >since semantics for specific versions are specified later in Section 7. > > > > > b) 2nd paragraph after ABNF. I can see why supporting the version is = a > > > SHOULD (since it is a new field) and RFC 4583 did not define a versio= n, > > > but I think that needs to be more clearly documented and I think it > > > ought to be REQUIRED for anyone that is using UDP and obviously, olde= r > > > implementations of TCP (i.e., those only compliant to RFC 4583 and no= t > > > this document) ought to be the only ones that aren't using the versio= n > > > field. > > > >Is it sufficient to merge in the following sentence after the second > >sentence in that paragraph? > >"However, endpoints that supports RFCXXXX, and not only the RFC 4583 > >subset, is REQUIRED to support and use the 'bfcpver' attribute." > >(Or something along those lines). > > Works for me, though should be "endpoints =C5=A0 are". > > > > >A complicating factor here is that some pre-standard implementations, as > >experienced on recent SIPit and SuperOp test events, is out there and is > >not using the 'bfcpver' attribute. However, demanding that > >implementations following the new RFC from this draft have to use the > >version attribute should be perfectly fine. > > Agreed, and stating that when omitted the default is "1" for TCP and "2" > for UDP addresses the problem of pre-standard UDP implementations as well= . > > > > > > c) last paragraph. Related to b, I would think that in the case of > > > unreliable transports, it's not that an endpoint MUST "assume". An > > > endpoint MUST "use" and signal a version number of 2. In the case of = a > > > reliable transport, if the endpoint does not signal a > > > bfcpversion-attribute, then the floor control server MUST use a value > >of > > > 1. I'm recalling a fair amount of mailing list discussion on this one= , > > > so if you can point to the thread where this text was agreed, I can l= et > > > this one go. I still think it's not specified quite right, but I can > > > live with it. > > > >I can't find too much discussion about this, but I agree that the word > >"assume" is not good here. What about reformulating this last paragraph > >to: > > > >"If a 'bfcpver' attribute is not present, default values are based on > >the transport specified in the m-line (Section 3). When used over an > >unreliable transport, an endpoint MUST use a value of "2", and when used > >over a reliable transport, an endpoint MUST use a value of "1". This is > >in line with the definition of the Version field in [8]." > > > >Any better? > > Better, but how about: > > "If a 'bfcpver' attribute is not present, default values are inferred fro= m > the transport specified in the m-line (Section 3). In accordance with > definition of the Version field in [8], when used over a reliable > transport the default value is "1", and when used over an unreliable > transport the default value is "2". > > > > > > > 6) Section 8. 1st sentence. I think this should be a "can use TCP or > > > UDP" and not a "may use TCP or UDP". Note, there is the perennial > >debate > > > with regards to whether something is normative even when it's not CAP= S. > > > I prefer to just use a different word to remove any confusion, > > > particularly when a different word is actually more correct. > > > >Well explained, the change is fine with me. > > > > > 7) Section 8.1, 4th paragraph, 1st sentence and last sentence. I thin= k > > > the two "SHOULD generate and offer" ought to be a MUST generate an > >offer > > > OR you need to specify the circumstances under which a client would n= ot > > > generate an offer. > > > >OK > > > > > 8) Section 9, 1st paragraph. You're going to have to be more specific > > > about the potential mechanisms for authentication - at least provide = an > > > example of mechanisms - i.e., I don't think "some mechanism" will fly > > > with the SecDir folks. > > > >Too bad, since this is inherited from RFC 4583 - but of course that text > >wasn't perfect ;) > >Anyway, isn't the mechanisms meant here mentioned in the paragraphs > >below? If so, might extending to "using some mechanism, as explained > >below" be a valid solution in front of the SecDir review? > > > >Or as Charles Eckel proposed, pointing towards TLS/DTLS as the preferred > >mechanism, but other mechanisms exists but are outside the scope of this > >document. > > This still works for me :) > > Cheers, > Charles > > > > > > 9) Section 11, 2nd paragraph. I think that the assumes in the followi= ng > > > statement needs to be a required. I suggest the following change: > > > > > > OLD > > > > > > BFCP assumes that an initial integrity-protected channel is used to > > > exchange... > > > > > > NEW > > > > > > An initial integrity-protected channel is REQUIRED for BFCP to > >exchange... > > > >Yes, I'll adopt that one. No assumption, we will require! > > > > > 10) Related to item 7, this list of changes has no mention of the new > > > "bfcpver" attribute. That definitely should be on this list. > > > >Indeed! It's missing since it arrived late, but that's just a poor > >excuse... > > > > > > > _Editorial nits:_ > > > > > > 1) Introduction. "These data includes..." -> "This data includes...." > > > (data is now grammatically considered to be a singular noun). > > > >OK > > > > > 2) Section 3. 1st paragraph after the indented text. This could be > > > written more concisely (and per technical doc standards not as the 1s= t > > > person) as follows (and per comment 1) above, I think this should be > >the > > > 'proto' field: > > > > > > OLD: > > > > > > We define four new values for the transport field: > > > > > > NEW: > > > > > > This document defines four values for the proto field: > > > >OK > > > > > 3) Section 5. I suggest the following change: > > > > > > OLD: > > > > > > We define the 'confid' and the 'userid' SDP media-level attributes. > > > > > > NEW: > > > > > > This document defines two SDP media-level attributes: 'confid' and > >'userid'. > > > >OK > > > > > 4) Section 6. I suggest the following change: > > > > > > OLD: > > > > > > We define the 'floorid' SDP media-level attribute. > > > > > > NEW: > > > > > > This document defines the 'floorid' SDP media-level attribute. > > > >OK > > > > > 5) Section 13. I found this really, really hard to read. I suggest yo= u > > > use a bulleted or numbered list versus this hanging list style. > > > >Sure, I'll tweak the XML curses and make it more readable. > > > > > >-- Tom > >_______________________________________________ > >bfcpbis mailing list > >bfcpbis@ietf.org > >https://www.ietf.org/mailman/listinfo/bfcpbis > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > --=20 # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --089e0149c6c011c0a104f24ad087 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All the issues here are resolved inline in line with Mary&= #39;s suggestions - as adjusted and commented by Charles and myself in this= thread. The upcoming version will include the changes.

-- Tom


On 24 January 2014 23:41, Charles Eckel (eckelcu) &l= t;eckelcu@cisco.com<= /a>> wrote:
On 1/16/14 6:47 AM, "To= m Kristensen (tomkrist)" <tom= krist@cisco.com> wrote:

>I went through and commented on this in my favourite editor (Emacs
>obviously), but forgot to paste it in and respond until now. I have
>updated my comments to align with Charles Eckel's =C2=A0recent resp= onse too.

Thanks for that. More inline.

>
>Inline below.
>
>
>On 12/18/2013 11:38 PM, Mary Barnes wrote:
> > Hi all,
> >
> > I have agreed to shepherd this document on behalf of the WG. I ha= ve
> > reviewed this document in preparation for doing the PROTO write-u= p.
> >
> > I think the document needs a bit of work before it's ready to= progress.
> > I have a few questions/comments, as well as editorial nits which = I
>think
> > would improve readability and ease of understanding.
> >
> > _General Comments:_
> >
> > The document requires an SDP directorate review prior to progress= ing. I
> > have requested that of the MMUSIC WG chairs. At the time of this<= br> >review,
> > Ali Begen has agreed to do that review.
>
>Yes, I have commented on his issues on the MMUSIC mailing list.
>
> > _Comments/Questions:_
> >
> > 1) I am slightly puzzled by the following in section 3:
> >
> > m=3D<media> <port> <transport> <fmt> ...<= br> > >
> > Section 5.14 of RFC 4566 states the following:
> >
> > m=3D<media> <port> <proto> <fmt> ...
> >
> > So, this looks to be like the RFC 2327 ABNF for m lines is being = used
> > (rather than RFC 4566 which is the normative SDP specification fo= r this
> > document)?
> >
> > m=3D<media> <port> <transport> <fmt list>=
> >
> > Note, that the IANA registration section appears to be based on R= FC
>4566
> > as the values are specified as being applicable to the 'pro t= o' field.
> > So, my guess is that this is a bug from RFC 4583.
>
>Yes, an inherited bug that will be fixed without complications.
>
> > 2) Section 3, next to last paragraph. I think it would be more pr= ecise
> > to reword this as:
> >
> > OLD:
> >
> > The fmt (format) list is ignored for BFCP. The fmt list of BFCP &= #39;m'
> > lines SHOULD contain a single "*" character.
> >
> > NEW:
> >
> > The fmt (format) list is not applicable to BFCP. The fmt list of = 'm'
> > lines in the case of any proto field value related to BFCP SHOULD=
> > contain a single "*" character. If the the fmt list con= tains any other
> > value it is ignored.
>
>Agree. That is a more precise wording for the fmt part.
>
>Charles Eckel touched upon this as well and was okay with this,
>especially if there are known reasons and/or implementations that
>already do otherwise. Well, once upon a time there was a SIP based
>product from a (large french) vendor that used 0 (I think) - don't = think
>that product is still maintained. But it might be out there in the wild=
>still. Will fix.
>
> > 3) Section 4, paragraph above table 1, 1st sentence. I suggest fo= r
> > clarification to make the following change:
> >
> > OLD
> >
> > MUST include one in the corresponding media description
> >
> > NEW
> >
> > MUST include a 'floorctrl' attribute in the corresponding= media
>description
>
>Fine with me, will update.
>
> > 4) Section 4, 3rd paragraph from the end:
> >
> > "Endpoints that use the offer/answer model to establish BFCP=
>connections
> > MUST support the 'floorctrl' attribute. A floor control s= erver acting
>as
> > an offerer or as an answerer SHOULD include the attribute in its<= br> >session
> > descriptions."
> >
> > Since the latter is a SHOULD what happens if the attribute is NOT=
> > included? Under what circumstances is it okay for the server not = to
> > include it? IF bad things happen if it's not included, then t= his
> > probably ought to be a MUST. Or, if there's reasonable situat= ions in
> > which the floor control server doesn't include the attribute,= those
> > should be explained or at least an example provided.
>
>The default behaviour/assumption if the 'floorctrl' attribute i= s not
>used is explained in the paragraph below, i.e. offerer =3D=3D client an= d
>answerer =3D=3D server.
>
>I agree that the formulation "is not used in an offer/answer excha= nge"
>might point towards usage other than offer/answer, but the sentence
>continues with explaining what the offerer and answerer will assume. So=
>fine with me. OK?
>
>If not, I will not object using MUST here - as also proposed by Charles=
>Eckel.
>
> > 5) Section 7.
> >
> > a) 1st paragraph after ABNF. "..versions SHOULD be integers.= .". I would
> > think that ought to be a MUST. What happens if the token isn'= t an
> > integer and what was the motivation for not defining the version = as an
> > integer versus a token? If non-integers can be used, the scope of= what
> > is acceptable for the field needs to be explained.
>
>I agree, this will be upgraded to a MUST if people doesn't object.<= br> >
>And if this will ever change non-integer versions must be specified in<= br> >another draft/RFC and this draft probably have to be updated as well -<= br> >since semantics for specific versions are specified later in Section 7.=
>
> > b) 2nd paragraph after ABNF. I can see why supporting the version= is a
> > SHOULD (since it is a new field) and RFC 4583 did not define a ve= rsion,
> > but I think that needs to be more clearly documented and I think = it
> > ought to be REQUIRED for anyone that is using UDP and obviously, = older
> > implementations of TCP (i.e., those only compliant to RFC 4583 an= d not
> > this document) ought to be the only ones that aren't using th= e version
> > field.
>
>Is it sufficient to merge in the following sentence after the second >sentence in that paragraph?
>"However, endpoints that supports RFCXXXX, and not only the RFC 45= 83
>subset, is REQUIRED to support and use the 'bfcpver' attribute.= "
>(Or something along those lines).

Works for me, though should be "endpoints =C5=A0 are"= .

>
>A complicating factor here is that some pre-standard implementations, a= s
>experienced on recent SIPit and SuperOp test events, is out there and i= s
>not using the 'bfcpver' attribute. However, demanding that
>implementations following the new RFC from this draft have to use the >version attribute should be perfectly fine.

Agreed, and stating that when omitted the default is "1" fo= r TCP and "2"
for UDP addresses the problem of pre-standard UDP implementations as well.<= br>

>
> > c) last paragraph. Related to b, I would think that in the case o= f
> > unreliable transports, it's not that an endpoint MUST "a= ssume". An
> > endpoint MUST "use" and signal a version number of 2. I= n the case of a
> > reliable transport, if the endpoint does not signal a
> > bfcpversion-attribute, then the floor control server MUST use a v= alue
>of
> > 1. I'm recalling a fair amount of mailing list discussion on = this one,
> > so if you can point to the thread where this text was agreed, I c= an let
> > this one go. I still think it's not specified quite right, bu= t I can
> > live with it.
>
>I can't find too much discussion about this, but I agree that the w= ord
>"assume" is not good here. What about reformulating this last= paragraph
>to:
>
>"If a 'bfcpver' attribute is not present, default values a= re based on
>the transport specified in the m-line (Section 3). When used over an >unreliable transport, an endpoint MUST use a value of "2", an= d when used
>over a reliable transport, an endpoint MUST use a value of "1"= ;. This is
>in line with the definition of the Version field in [8]."
>
>Any better?

Better, but how about:

"If a 'bfcpver' attribute is not present, default values are i= nferred from
the transport specified in the m-line (Section 3). In accordance with
definition of the Version field in [8], when used over a reliable
transport the default value is "1", and when used over an unrelia= ble
transport the default value is "2".


>
> > 6) Section 8. 1st sentence. I think this should be a "can us= e TCP or
> > UDP" and not a "may use TCP or UDP". Note, there i= s the perennial
>debate
> > with regards to whether something is normative even when it's= not CAPS.
> > I prefer to just use a different word to remove any confusion, > > particularly when a different word is actually more correct.
>
>Well explained, the change is fine with me.
>
> > 7) Section 8.1, 4th paragraph, 1st sentence and last sentence. I = think
> > the two "SHOULD generate and offer" ought to be a MUST = generate an
>offer
> > OR you need to specify the circumstances under which a client wou= ld not
> > generate an offer.
>
>OK
>
> > 8) Section 9, 1st paragraph. You're going to have to be more = specific
> > about the potential mechanisms for authentication - at least prov= ide an
> > example of mechanisms - i.e., I don't think "some mechan= ism" will fly
> > with the SecDir folks.
>
>Too bad, since this is inherited from RFC 4583 - but of course that tex= t
>wasn't perfect ;)
>Anyway, isn't the mechanisms meant here mentioned in the paragraphs=
>below? If so, might extending to "using some mechanism, as explain= ed
>below" be a valid solution in front of the SecDir review?
>
>Or as Charles Eckel proposed, pointing towards TLS/DTLS as the preferre= d
>mechanism, but other mechanisms exists but are outside the scope of thi= s
>document.

This still works for me :)

Cheers,
Charles

>
> > 9) Section 11, 2nd paragraph. I think that the assumes in the fol= lowing
> > statement needs to be a required. I suggest the following change:=
> >
> > OLD
> >
> > BFCP assumes that an initial integrity-protected channel is used = to
> > exchange...
> >
> > NEW
> >
> > An initial integrity-protected channel is REQUIRED for BFCP to >exchange...
>
>Yes, I'll adopt that one. No assumption, we will require!
>
> > 10) Related to item 7, this list of changes has no mention of the= new
> > "bfcpver" attribute. That definitely should be on this = list.
>
>Indeed! It's missing since it arrived late, but that's just a p= oor
>excuse...
>
>
> > _Editorial nits:_
> >
> > 1) Introduction. "These data includes..." -> "T= his data includes...."
> > (data is now grammatically considered to be a singular noun).
>
>OK
>
> > 2) Section 3. 1st paragraph after the indented text. This could b= e
> > written more concisely (and per technical doc standards not as th= e 1st
> > person) as follows (and per comment 1) above, I think this should= be
>the
> > 'proto' field:
> >
> > OLD:
> >
> > We define four new values for the transport field:
> >
> > NEW:
> >
> > This document defines four values for the proto field:
>
>OK
>
> > 3) Section 5. I suggest the following change:
> >
> > OLD:
> >
> > We define the 'confid' and the 'userid' SDP media= -level attributes.
> >
> > NEW:
> >
> > This document defines two SDP media-level attributes: 'confid= ' and
>'userid'.
>
>OK
>
> > 4) Section 6. I suggest the following change:
> >
> > OLD:
> >
> > We define the 'floorid' SDP media-level attribute.
> >
> > NEW:
> >
> > This document defines the 'floorid' SDP media-level attri= bute.
>
>OK
>
> > 5) Section 13. I found this really, really hard to read. I sugges= t you
> > use a bulleted or numbered list versus this hanging list style. >
>Sure, I'll tweak the XML curses and make it more readable.
>
>
>-- Tom
>_______________________________________________
>bfcpbis mailing list
>bfcpbis@ietf.org
>https://www.ietf.org/mailman/listinfo/bfcpbis

_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org
https://www.ietf.org/mailman/listinfo/bfcpbis



--
= # Cisco =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0http://www.cisco.com/telepresence/
## tomkrist@cisco.com =C2=A0| = =C2=A0http://www.tand= berg.com
### =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://folk.uio.no/tomkri/
--089e0149c6c011c0a104f24ad087-- From nobody Fri Feb 14 04:15:23 2014 Return-Path: <2mkristensen@gmail.com> 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 B49CA1A0212 for ; Fri, 14 Feb 2014 04:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 5nVoGuDlCRZL for ; Fri, 14 Feb 2014 04:15:13 -0800 (PST) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7E31A021B for ; Fri, 14 Feb 2014 04:15:13 -0800 (PST) Received: by mail-qa0-f53.google.com with SMTP id cm18so17796549qab.26 for ; Fri, 14 Feb 2014 04:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a9v3CLKXxcozSKp1T56yWcdmKkjbnGFLF39Atzckozk=; b=vK1JYyC6XV21QrK/oe6k9lh7zG+kn5dpMrztacg/UL74aT67ZsmD+CzbN1Ndq2uvzu 3pW15vaCKW/5j1LFw2nFzFF9IItbXdXqUkrXDNowUbo8v1NhX95T4wDr8/iLzw2wPcgC hJjKkjw22lyfowD6F5IMPD9lEf847PisShpq3cXzFrUIfZeRTXH1nTrO9L6Qj79SelEI ojNAGbYG7AM0Cxlocq/thUR0R69qb2z35bpTgtIwBZLDIaeGT2ceMIE4IiWk14zQGmug etg0c9eszXCn4xL0iL8HQdMZqVlUg1vDFkLivrk4bxw5dpnM6yglkrRj1W4iJjVxjSym mDMA== MIME-Version: 1.0 X-Received: by 10.140.105.196 with SMTP id c62mr11511769qgf.29.1392380111349; Fri, 14 Feb 2014 04:15:11 -0800 (PST) Received: by 10.229.2.69 with HTTP; Fri, 14 Feb 2014 04:15:11 -0800 (PST) In-Reply-To: References: <529C456D.60508@cisco.com> <52CE9BC6.1090109@cisco.com> Date: Fri, 14 Feb 2014 13:15:11 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Charles Eckel (eckelcu)" , Joerg Ott Content-Type: multipart/alternative; boundary=001a113a99d2edeaf604f25cc169 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/S5nJVs8cbWAVPgL-RUOViDXafU4 Cc: "bfcpbis@ietf.org" , "Tom Kristensen \(tomkrist\)" Subject: Re: [bfcpbis] Joerg's review - Fwd: Reviewing draft-ietf-bfcpbis-rfc4582bis 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: Fri, 14 Feb 2014 12:15:20 -0000 --001a113a99d2edeaf604f25cc169 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 13 January 2014 19:41, Charles Eckel (eckelcu) wrote= : > > On 1/9/14 4:53 AM, "Tom Kristensen (tomkrist)" wrote= : > > > > >Inline below. > > > >On 12/02/2013 09:31 AM, Tom Kristensen wrote: > > > Relaying J=F6rg's review sent to the authors of the draft 2013-11-30. > [...] > > > -------- Original Message -------- > > > > > > Hi Gonzalo and all, > > > > > > thanks a lot for the diff, this is really useful! > > > > > > So, I have gone in some detail through the document and found a > > > bunch of issues to be addressed. Most of those revolve around > > > the use of unreliable transport, which appears to be underspecified > > > in a number of ways. > > > >[...] > > > > > 5.1. General > > > > > > SHOULD -> MUST be cleared by the sender > > > >I don't see the need for change since the flag has no meaning when using > >reliable transport and especially not since it is a MUST for the > >receiver to ignore it in that case. Anyway, changing it to MUST works > >fine with me if that's what the WG wants! > > > >Also, since this is an extension of RFC 4582 we have used the same style > >as in the original draft. For instance in 5.2.6 (for the Padding bits) > >and in 5.2.6.1 (for the R bits), where the sender SHOULD set clear the > >bits and the receiver MUST ignore them. > > After rereading RFC 2119, this looks like a case where it is better to fi= x > the original RFC as part of extending it rather than follow the > conventions put in place by the origin RFC. As there does not seem to be > any reason or circumstances to justify NOT clearing the flag/bits, I thin= k > both instances should be changed from SHOULD to MUST. Changed across the document a number of places where the sender earlier SHOULD clear bits, that the receiver MUST ignore. From now MUST + MUST! > > > When moving from a 16- or 32-bit "value" to an unsigned > > > integer, the byte order must be specified. > > > >The second sentence in Section 5 says that all "the protocol values MUST > >be sent in network byte order". That should be sufficient, shouldn't it? > > I think so. > No changes, since it was taken care of. > > > > 5.1. R bit > > > > > > Question: Can it happen that transport changes in a relay? If > > > my dim memory serves me right, then STUN relay may change the > > > transport and thus the reliability. They won't interpret BFCP, > > > however, and so the bit would suddenly be wrong. Or is this > > > scenario prohibited? > > > >You mean TURN not STUN I presume. A TURN relay may have an unreliable > >and reliable hop on each hop. However, the TURN relaying(/"tunneling") > >magic added to the packets will be removed before the BFCP packets > >reaches the BFCP stack. And since on hop is unreliable the extensions > >for unreliable transport is still needed. > No changes, is taken care of below BFCP. > > > 5.2. Use of SHOULD > > > > > > Quite a few places state a SHOULD requirement, e.g., for sending > > > error messages. But this doesn't make sense. Based upon which > > > grounds would an endpoint _not_ send an error message? > > > >I do agree in principle, but again and if I remember correctly the > >SHOULD here was used to comply with the style used in the original RFC > >4582. See for instance the SHOULD requirement to send an Error message > >in Section 13 (for Unknown Primitive). > > > >Since the revision of RFC 4582 was done to add support for unreliable > >transport and in addition to fix important issues (such known > >bugs/typos/unclear text), I'm not sure we want to change the SHOULD to > >MUST and potentially generate issues for existing RFC 4582 compliant > >implementations out there. > > > >However, we can without any problem make the use of error messages > >mandatory (with MUST) in the sections added for unreliable transport of > >course. Such as in Section 6.2 and probably some more places. > > Here as well, I think it best to adhere to RFC 2119 rather than follow > conventions used previously in RFC 4582. We have fixed some other issues > with the original already, and I think we should fix these as well. I > believe this to be more of matter of interpretation of the guidance of RF= C > 2119 rather than a real change to the BFCP protocol. > Changed accordingly. Sending Error messages is now required throughout the document. > > > > > 5.2.6 Generic error > > > > > > Is it specified what the receiver of a non-specific error is > > > supposed to do? Apparently, it cannot talk to the server. So, > > > abandon floor control? > > > >Well, for me the Generic Error is kind of a safety net in situations > >where the existing error codes are not meaningful. So one implementation > >might simply abandon floor control/BFCP as a consequence another might > >have some error recovery that is possible - depending on context. > > > >Any need for text describing this fluffy assumption? :) Or do people > >have other interpretations? > > The paragraph above the table states: > > If an error code is not recognized by the receiver, > then the receiver MUST assume that an error exists, and therefore > that the original message that triggered the Error message to be sent > is processed, but the nature of the error is unclear. > > I would expect the same to be true when receiving a "Generic Error". The > action taken in response to such an error is implementation and context > dependent. No changes, the behaviour is described sufficiently already. > > > > > 5.3.14, 5.3.15., and 5.3.17 > > > > > > It seems that FloorRequestStatusAck, FloorStatusAck, and GoodbyeAck > > > are essentially packet-level acks. So why not have just a single > > > code point for those, since they all carry a transaction id anyway? > > > >True and if I remember correctly this has been discussed earlier on. > >Reasons like having explicit acks matching request primitive and > >potentially extensibility per request type later on might be enough to > >keep it as is? I think so at least. > > I agree. No changes. Earlier agreement still in place. > > > > > 6.2 Unreliable Transport > > > > > > The text often talks about UDP datagrams, even though DTLS > > > transport appears assumed. > > > > > > "Entities MUST have at most one outstanding request transaction at > > > any one time." > > > > > > This probably wants the addition of a "per peer", otherwise a floor > > > control server would be in trouble. (Section 6.2.1 has this right) > > > >Indeed, a good point! This will be changed to make it consistent and > >clear. > > Yes, good catch. > Fixed! > > > > > 6.2 Hello > > > > > > Clients MUST announce their presence to the floor control server by > > > sending a Hello message. The floor control server responds to the > > > Hello message with a HelloAck message. The client considers the > > > floor control service as present and available only upon receiving > > > the HelloAck message. > > > > > > When does the server consider the client to have disappeared so that > > > it can discard state? > > > > > > It seems I can run a client, send a Hello message, get the HelloAck, > > > and then send a floor control request with a spoofed IP address, and > > > predict and fake the response for the first message I am expecting > > > from the server in response. Then, I have state installed that will > > > generate packets and retransmissions to a random target until the > > > server discards the client state. But there is no mention when the > > > state would be discarded. > > > > > > Maybe this is less of an attack problem since this is bound to a > > > conference somewhere, but I still don't have a mechanism to get > > > rid of the transport state -- could be important particularly when > > > new connections are instantiated. While it is stated that the old > > > state is lost (for the new instance of the client), will it be > > > discarded? There is no guidance. > > > >Hmmm, not sure how to best handle that situation. > > > >Using DTLS would make the IP address spoofing harder at least, and it is > >recommended to use TLS for both TCP and UDP transport. > > > >What can people propose for this? Is it sufficient to describe what the > >server should do when the number of retransmissions are tried? > > That sounds sensible for UDP. For TCP, it can be based on not being able > to establish a connection to the client. Both of these are similar to > receiving an ICMP error, as described in section 6.2.2. No fix needed, since this was already described where the retransmission timer and behaviour for max number of retries was specified (Section 8). > > > 6.2.3 Fragmentation > > > > > > Is there any guidance on transmitting fragments? (any pacing?) > > > >No, and one justification for keeping the fragmentation scheme simple > >and avoid specifying for instance pacing, is that the BFCP messages are > >binary and generally small in size. The probability for using the > >fragmentation scheme is smal and the need for pacing fragments even lowe= r! > > > > > How is N defined? One would assume N =3D ceil (msgsize/MTUsize), but > > > an implementer might decide to use a larger N. In any case, when > > > we use N in the spec, it must be said how it is established. > > > >I agree and I think using N =3D ceil(msgsize/MTUsize) is a good way to > >specify how to choose N. > Added this to define how to choose the value for N. > > > 8.2 Transaction number re-use. > > > > > > The text currently states that a transaction number "MUST NOT be > > > reused in another message from the floor control server checks > > > whether until the appropriate response from the client sending is > > > received for the transaction". > > > > > > If the ID is monotonically increasing (modulo wrap-around) why not > > > make re-use illegal? Allowing re-use seems to be calling for > > > trouble, especially in case some transactions may refer to others > > > by their ID or if transactions last longer. > > > >Very true and a good point. Re-use is potentially creating trouble... > >And since monotonical increasing values are required in the second last > >paragraph of Section 8, we should ban re-use in Section 8.2. OK? > > Works for me. Of course the ID will need to be able to wrap around once > the defined range is exhausted. Fixed accordingly. Also added MUST for using monotonically increasing IDs for it to be consistent. > > > 8.3.2. T2 is unclear > > > >Yes, probably true! One way of dealing with that is to remove timer T2 > >completely and let the implementations decide when to release knowledge. > >Another to brush up the specification of T2 of course. > > Perhaps it is better to remove T2 and instead rely on T1 expiration > following final retransmission serving as trigger to release knowledge o= f > transaction. All traces of T2 removed. Added a sentence describing that the entity was free to release the knowledge of the transaction in question at that point. > > > 9.1 Authentication > > > > > > The text states: > > > > > > BFCP messages received over an authenticated TLS/DTLS connection are > > > considered authenticated. A floor control server that receives a > > > BFCP message over TCP/UDP (no TLS/DTLS) can request the use of TLS/ > > > DTLS by generating an Error message, as described in Section 13.8, > > > with an Error code with a value of 9 (Use TLS) or a value of 11 (Use > > > DTLS) respectively. Clients SHOULD simply ignore unauthenticated > > > messages. > > > > > > "can" -> MUST or MAY (this is normative behavior) > > > >True. > > MAY seems appropriate to me. > Me too. Fixed. > > But does this work? A server has one connection to a client. So, > > > if the server has at its disposition to accept TCP/UDP but the client > > > should ignore such messages, with the connection bidirectional, then > > > this de-facto mandates TLS/DTLS, doesn't it? Or the client would > > > never react. > > > >I'n not that fluent in TLS/DTLS to make a definitive answer there. > >Anybody out there willing to explain why this works or not? > > I think the last sentence need to be changes to read as follows: > > "Clients configured to require the use of TLS/DTLS MUST ignore > unauthenticated messages." > Yes, changed to that sentence. > > > > Appendix A: Wouldn't the monoticity of the transaction IDs become > > > clearer if increments or 1 in numbers were used? > > > >True, but increments of 1 is not mandated. What do you mean by using > >increments, having an initial Transaction ID and using "+x" or something > >in later messages? > Well, I see the point and the Transaction IDs used are no incremented by 1 in the sequence. Updated draft will be submitted ASAP. -- Tom --001a113a99d2edeaf604f25cc169 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 13 January 2014 19:41, Charles Eckel (eckelcu) <eckelc= u@cisco.com> wrote:

On 1/9/14 4:53 AM, "Tom Kristensen (tomkrist)" <tomkrist@cisco.com> wrote:

>
>Inline below.
>
>On 12/02/2013 09:31 AM, Tom Kristensen wrote:
> > Relaying J=F6rg's review sent to the authors of the draft 201= 3-11-30.
[...]
> > -------- Original Message --------
> >
> > Hi Gonzalo and all,
> >
> > thanks a lot for the diff, this is really useful!
> >
> > So, I have gone in some detail through the document and found a > > bunch of issues to be addressed. Most of those revolve around
> > the use of unreliable transport, which appears to be underspecifi= ed
> > in a number of ways.
>
>[...]
>
> > 5.1. General
> >
> > SHOULD -> MUST be cleared by the sender
>
>I don't see the need for change since the flag has no meaning when = using
>reliable transport and especially not since it is a MUST for the
>receiver to ignore it in that case. Anyway, changing it to MUST works >fine with me if that's what the WG wants!
>
>Also, since this is an extension of RFC 4582 we have used the same styl= e
>as in the original draft. For instance in 5.2.6 (for the Padding bits)<= br> >and in 5.2.6.1 (for the R bits), where the sender SHOULD set clear the<= br> >bits and the receiver MUST ignore them.

After rereading RFC 2119, this looks like a case where it is be= tter to fix
the original RFC as part of extending it rather than follow the
conventions put in place by the origin RFC. As there does not seem to be any reason or circumstances to justify NOT clearing the flag/bits, I think<= br> both instances should be changed from SHOULD to MUST.

=
Changed across the document a number of places where the s= ender earlier SHOULD clear bits, that the receiver MUST ignore. From now MU= ST + MUST!
=A0
> > When moving from a 16- or 32-bit "value" to an unsigned=
> > integer, the byte order must be specified.
>
>The second sentence in Section 5 says that all "the protocol value= s MUST
>be sent in network byte order". That should be sufficient, shouldn= 't it?

I think so.

No changes, sin= ce it was taken care of.=A0

>
> > 5.1. R bit
> >
> > Question: Can it happen that transport changes in a relay? If
> > my dim memory serves me right, then STUN relay may change the
> > transport and thus the reliability. They won't interpret BFCP= ,
> > however, and so the bit would suddenly be wrong. Or is this
> > scenario prohibited?
>
>You mean TURN not STUN I presume. A TURN relay may have an unreliable >and reliable hop on each hop. However, the TURN relaying(/"tunneli= ng")
>magic added to the packets will be removed before the BFCP packets
>reaches the BFCP stack. And since on hop is unreliable the extensions >for unreliable transport is still needed.
<= div>
No changes, is taken care of below BFCP.
=A0
> > 5.2. Use of SHOULD
> >
> > Quite a few places state a SHOULD requirement, e.g., for sending<= br> > > error messages. But this doesn't make sense. Based upon which=
> > grounds would an endpoint _not_ send an error message?
>
>I do agree in principle, but again and if I remember correctly the
>SHOULD here was used to comply with the style used in the original RFC<= br> >4582. See for instance the SHOULD requirement to send an Error message<= br> >in Section 13 (for Unknown Primitive).
>
>Since the revision of RFC 4582 was done to add support for unreliable >transport and in addition to fix important issues (such known
>bugs/typos/unclear text), I'm not sure we want to change the SHOULD= to
>MUST and potentially generate issues for existing RFC 4582 compliant >implementations out there.
>
>However, we can without any problem make the use of error messages
>mandatory (with MUST) in the sections added for unreliable transport of=
>course. Such as in Section 6.2 and probably some more places.

Here as well, I think it best to adhere to RFC 2119 rather than= follow
conventions used previously in RFC 4582. We have fixed some other issues with the original already, and I think we should fix these as well. I
believe this to be more of matter of interpretation of the guidance of RFC<= br> 2119 rather than a real change to the BFCP protocol.
<= br>
Changed accordingly. Sending Error messages is now requ= ired throughout the document.
=A0
>
> > 5.2.6 Generic error
> >
> > Is it specified what the receiver of a non-specific error is
> > supposed to do? Apparently, it cannot talk to the server. So,
> > abandon floor control?
>
>Well, for me the Generic Error is kind of a safety net in situations >where the existing error codes are not meaningful. So one implementatio= n
>might simply abandon floor control/BFCP as a consequence another might<= br> >have some error recovery that is possible - depending on context.
>
>Any need for text describing this fluffy assumption? :) Or do people >have other interpretations?

The paragraph above the table states:

If an error code is not recognized by the receiver,
=A0 =A0then the receiver MUST assume that an error exists, and therefore =A0 =A0that the original message that triggered the Error message to be sen= t
=A0 =A0is processed, but the nature of the error is unclear.

I would expect the same to be true when receiving a "Generic Error&quo= t;. The
action taken in response to such an error is implementation and context
dependent.

No changes, the behaviour = is described sufficiently already.
=A0
>
> > 5.3.14, 5.3.15., and 5.3.17
> >
> > It seems that FloorRequestStatusAck, FloorStatusAck, and GoodbyeA= ck
> > are essentially packet-level acks. So why not have just a single<= br> > > code point for those, since they all carry a transaction id anywa= y?
>
>True and if I remember correctly this has been discussed earlier on. >Reasons like having explicit acks matching request primitive and
>potentially extensibility per request type later on might be enough to<= br> >keep it as is? I think so at least.

I agree.

No changes. Earlier ag= reement still in place.
=A0
>
> > 6.2 Unreliable Transport
> >
> > The text often talks about UDP datagrams, even though DTLS
> > transport appears assumed.
> >
> > "Entities MUST have at most one outstanding request transact= ion at
> > any one time."
> >
> > This probably wants the addition of a "per peer", other= wise a floor
> > control server would be in trouble. (Section 6.2.1 has this right= )
>
>Indeed, a good point! This will be changed to make it consistent and >clear.

Yes, good catch.

Fixed!=A0<= /div>
=A0
>
> > 6.2 Hello
> >
> > Clients MUST announce their presence to the floor control server = by
> > sending a Hello message. The floor control server responds to the=
> > Hello message with a HelloAck message. The client considers the > > floor control service as present and available only upon receivin= g
> > the HelloAck message.
> >
> > When does the server consider the client to have disappeared so t= hat
> > it can discard state?
> >
> > It seems I can run a client, send a Hello message, get the HelloA= ck,
> > and then send a floor control request with a spoofed IP address, = and
> > predict and fake the response for the first message I am expectin= g
> > from the server in response. Then, I have state installed that wi= ll
> > generate packets and retransmissions to a random target until the=
> > server discards the client state. But there is no mention when th= e
> > state would be discarded.
> >
> > Maybe this is less of an attack problem since this is bound to a<= br> > > conference somewhere, but I still don't have a mechanism to g= et
> > rid of the transport state -- could be important particularly whe= n
> > new connections are instantiated. While it is stated that the old=
> > state is lost (for the new instance of the client), will it be > > discarded? There is no guidance.
>
>Hmmm, not sure how to best handle that situation.
>
>Using DTLS would make the IP address spoofing harder at least, and it i= s
>recommended to use TLS for both TCP and UDP transport.
>
>What can people propose for this? Is it sufficient to describe what the=
>server should do when the number of retransmissions are tried?

That sounds sensible for UDP. For TCP, it can be based on not b= eing able
to establish a connection to the client. Both of these are similar to
receiving an ICMP error, as described in section 6.2.2.
No fix needed, since this was already described where th= e retransmission timer and behaviour for max number of retries was specifie= d (Section 8).=A0
=A0
> > 6.2.3 Fragmentation
> >
> > Is there any guidance on transmitting fragments? (any pacing?) >
>No, and one justification for keeping the fragmentation scheme simple >and avoid specifying for instance pacing, is that the BFCP messages are=
>binary and generally small in size. The probability for using the
>fragmentation scheme is smal and the need for pacing fragments even low= er!
>
> > How is N defined? One would assume N =3D ceil (msgsize/MTUsize), = but
> > an implementer might decide to use a larger N. In any case, when<= br> > > we use N in the spec, it must be said how it is established.
>
>I agree and I think using N =3D ceil(msgsize/MTUsize) is a good way to<= br> >specify how to choose N.

Added this to define how to choose the value for N.
=A0
> > 8.2 Transaction number re-use.
> >
> > The text currently states that a transaction number "MUST NO= T be
> > reused in another message from the floor control server checks > > whether until the appropriate response from the client sending is=
> > received for the transaction".
> >
> > If the ID is monotonically increasing (modulo wrap-around) why no= t
> > make re-use illegal? Allowing re-use seems to be calling for
> > trouble, especially in case some transactions may refer to others=
> > by their ID or if transactions last longer.
>
>Very true and a good point. Re-use is potentially creating trouble... >And since monotonical increasing values are required in the second last=
>paragraph of Section 8, we should ban re-use in Section 8.2. OK?

Works for me. Of course the ID will need to be able to wrap around on= ce
the defined range is exhausted.

Fixed= accordingly. Also added MUST for using monotonically increasing IDs for it= to be consistent.
=A0
> > 8.3.2. T2 is unclear
>
>Yes, probably true! One way of dealing with that is to remove timer T2<= br> >completely and let the implementations decide when to release knowledge= .
>Another to brush up the specification of T2 of course.

Perhaps it is better to remove T2 and instead rely on T1 expiration following final =A0retransmission serving as trigger to release knowledge o= f
transaction.

All traces of T2 removed= . Added a sentence describing that the entity was free to release the knowl= edge of the transaction in question at that point.
=A0
> > 9.1 Authentication
> >
> > The text states:
> >
> > BFCP messages received over an authenticated TLS/DTLS connection = are
> > considered authenticated. A floor control server that receives a<= br> > > BFCP message over TCP/UDP (no TLS/DTLS) can request the use of TL= S/
> > DTLS by generating an Error message, as described in Section 13.8= ,
> > with an Error code with a value of 9 (Use TLS) or a value of 11 (= Use
> > DTLS) respectively. Clients SHOULD simply ignore unauthenticated<= br> > > messages.
> >
> > "can" -> MUST or MAY (this is normative behavior) >
>True.

MAY seems appropriate to me.

Me too. Fixed.=A0

> > But does this work? A server has one connection to a client. So,<= br> > > if the server has at its disposition to accept TCP/UDP but the cl= ient
> > should ignore such messages, with the connection bidirectional, t= hen
> > this de-facto mandates TLS/DTLS, doesn't it? Or the client wo= uld
> > never react.
>
>I'n not that fluent in TLS/DTLS to make a definitive answer there.<= br> >Anybody out there willing to explain why this works or not?

I think the last sentence need to be changes to read as follows:

"Clients configured to require the use of TLS/DTLS MUST ignore
unauthenticated messages."

Y= es, changed to that sentence.=A0

>
> > Appendix A: Wouldn't the monoticity of the transaction IDs be= come
> > clearer if increments or 1 in numbers were used?
>
>True, but increments of 1 is not mandated. What do you mean by using >increments, having an initial Transaction ID and using "+x" o= r something
>in later messages?

Well= , I see the point and the Transaction IDs used are no incremented by 1 in t= he sequence.

Updated draft will be sub= mitted ASAP.

-- Tom=A0
--001a113a99d2edeaf604f25cc169-- From nobody Fri Feb 14 08:22:22 2014 Return-Path: <2mkristensen@gmail.com> 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 BB0E21A02CC for ; Fri, 14 Feb 2014 08:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 8thaYHl9U0qa for ; Fri, 14 Feb 2014 08:22:15 -0800 (PST) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 79BA21A02EB for ; Fri, 14 Feb 2014 08:22:14 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id k4so18836574qaq.1 for ; Fri, 14 Feb 2014 08:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pmRpqpaebA/HfKcLaPL9q0E1c34ifEgjNFrOy03coR0=; b=iSlC0UQeOYXSAV6cZ24BuatgiVhWtS4B7Jk/XCrcmQP1qtt+Fr96U1AzZefFSCCRsG +pCMJrr80VNlPkCv10w4jojJhcVrrOS5Ewh4nRIQE+PEGa78ek6knVkmLQOimdsfU1+D IWfDfiUFtG72OhjvBbyBcVPX5xIozmY2RLFQFY3KC17fup/rxzZDaOGyyi2EgFdeyMxQ JUN3tjk2UpWHoUuV504OyoEPR8TMrWUdvbhGXgVxP0YNI+CjBAQUkbxteHZEf8B1k1uv YWHRczv4xpYy6APFCThVLIUjbdc/3QR5OOtdAJNjmjG7Mz31tLxU4O5Q1p/2aQH2yMM6 oBOg== MIME-Version: 1.0 X-Received: by 10.224.165.133 with SMTP id i5mr14675205qay.75.1392394931650; Fri, 14 Feb 2014 08:22:11 -0800 (PST) Received: by 10.229.2.69 with HTTP; Fri, 14 Feb 2014 08:22:11 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se> <52D7F766.8000402@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C642F14@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D10FE85@ESESSMB209.ericsson.se> <52DDCE70.1090707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D110ECA@ESESSMB209.ericsson.se> <52DE7FE6.3000203@alum.mit.edu> Date: Fri, 14 Feb 2014 17:22:11 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0149c6c049c54c04f26035d4 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/FB9cNz2nJANl4S8dTFhVLspAa7g Cc: "bfcpbis@ietf.org" , Paul Kyzivat , Tom Kristensen Subject: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? 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: Fri, 14 Feb 2014 16:22:19 -0000 --089e0149c6c049c54c04f26035d4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI. The text included in the next version will be (Section 7, 3rd and 4th paragraphs): ---- Which party, the client or the floor control server, acts as the TLS/ DTLS server depends on how the underlying TLS/DTLS connection is established. For a TCP/TLS connection established using an SDP offer/answer exchange [7], the answerer (which may be the client or the floor control server) always acts as the TLS server. If the TCP connection is lost, the active endpoint, i.e., the current TLS client, is responsible for re-establishing the TCP connection. Unless a new TLS session is negotiated, subsequent SDP offers and answers will not impact the previously negotiated TLS roles. For a UDP/DTLS connection established using the an SDP offer/answer exchange, either party can be the DTLS server depending on the setup attributes exchanged; examples can be found in [22]. ---- I do hope that defines it correctly. -- Tom On 23 January 2014 11:48, Tom Kristensen <2mkristensen@gmail.com> wrote: > Thanks Christer, not only did you discover the issue - you also provided > the fix (and text for it). That solves what is currently missing in the > draft and in RFC 4582. > > I will add your text, or at least a very similar version, to the upcoming > version of the draft. > > -- Tom > > > On 21 January 2014 15:10, Paul Kyzivat wrote: > >> On 1/20/14 8:44 PM, Christer Holmberg wrote: >> >>> Hi, >>> >>> Some initial text proposal: >>>>> >>>>> "If the TCP connection is lost, the "active" endpoint is responsible >>>>> for re-establishing the TCP connection. >>>>> >>>>> Unless a new TLS session is negotiated, subsequent SDP Offers and >>>>> Answers will not impact the previously negotiated TLS roles." >>>>> >>>> >>>> Is the passive endpoint expected to listen for the connection attempt >>>> at all times, or when it has noticed that the old connection is lost, = or >>>> only when >>>> there has been a new O/A? (It is kind of a waste to maintain a listene= r >>>> when you have an active connection and aren't expecting more. >>>> And it is asking for trouble, since you might get a new connection whe= n >>>> you think the old one is still functional.) >>>> >>> >>> If a TCP connection has been established, I think it is enough to liste= n >>> for the connection when it has noticed that the old connection is lost.= I >>> assume both endpoints would detect that more or less at the same time, = or? >>> >>> If a TCP connection has NOT been established, one would listen only whe= n >>> there has been a O/A used to negotiate the TCP connection. >>> >> >> WFM. >> >> >> I realize this is old stuff, but I'm surprised that it didn't follow >>>> comedia about all of this, including who is active. >>>> >>> >>> I am not sure I understand. Comedia IS used to indicate who is active. >>> However, comedia is NOT used to indicate who is TLS client/server. >>> >> >> OK. >> >> >> Regards, >>> >>> Christer >>> >>> >>> >>> >>> -----Alkuper=E4inen viesti----- >>>> L=E4hett=E4j=E4: bfcpbis [mailto:bfcpbis-bounces@ietf.org] Puolesta Ch= rister >>>> Holmberg >>>> L=E4hetetty: 16. tammikuuta 2014 21:36 >>>> Vastaanottaja: Tom Kristensen >>>> Kopio: bfcpbis@ietf.org >>>> Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goe= s >>>> down and is re-established? >>>> >>>> >>>> Hi Tom, >>>> >>>> I realize the following comes late in the process, and I apologize >>>>>> if it has been discussed, but it is related to something which just >>>>>> has recently popped up in 3GPP, and it's not addressed in the draft. >>>>>> >>>>> >>>>> Not too late, since we are still not finished! Anyway, the TCP/TLS >>>>> connection reuse is not altered while extending BFCP to support >>>>> unreliable transport. Any fixes now must be backwards compatible in >>>>> some way. >>>>> >>>>> That said and based on what I have seen from different vendors, most >>>>> of them still use TCP (without TLS) :) >>>>> >>>>> So, at least if we are changing anything to solve these issues, we >>>>> should add an informational note indicating this is a change where >>>>> legacy, pure RFC 4582 implementations might differ in behaviour... >>>>> >>>> >>>> I am not suggesting to change anything - I am suggesting to specify >>>> something which is currently unspecified :) >>>> >>>> By the way: How these issues was solved in 3GPP are along the lines o= f >>>>> what you propose below? >>>>> >>>> >>>> We have had some discussions in 3GPP, and there are some text >>>> suggestions for the upcoming meeting next week. >>>> >>>> However, the discussions so far have been mostly about Q2. Q1 came up >>>> on a mailing list just this week, and whill be discussed at the 3GPP >>>> meeting next week. >>>> >>>> Section 7 says the following: >>>>>> >>>>>> "For a TCP/TLS connection established using an SDP >>>>>> >>>>>> offer/answer exchange [7], the answerer (which may be the client or >>>>>> >>>>>> the floor control server) always acts as the TLS server." >>>>>> >>>>>> Q1: >>>>>> >>>>>> Assume the TCP/TLS connection, for whatever reason, goes down. >>>>>> >>>>>> Now, I assume that whoever endpoint is "active" will most likely try >>>>>> to re-establish the TCP connection. >>>>>> >>>>>> But, if the "active" endpoint doesn't send an Offer (i.e. it simply >>>>>> tries to re-establish the TCP connection based on the previously >>>>>> negotiated SDP information), who will act as TLS server? There is no >>>>>> Answerer. >>>>>> >>>>>> One alternative would be to mandate the sending of an Offer when the >>>>>> TCP/TLS connection is re-established. Then it would be clear who is >>>>>> Offerer, and who is Answerer. >>>>>> >>>>>> Another alternative would be to say that whoever was previously >>>>>> Answerer will act as TLS server. >>>>>> >>>>> >>>>> I'm not too fond of yet another re-INVITE being mandated, so if we >>>>> will fix this issue mandating the previous answerer to be the TLS >>>>> server would be my preference. >>>>> >>>> >>>> Assuming that, then my follow-up question is: >>>> >>>> When you say "previous answerer", do you refer to the answerer in the >>>> latest Offer/Answer transaction, OR the answerer in the last Offer/Ans= wer >>>> transaction that established/re-established the TCP/TLS connection (th= ose >>>> Offer/Answer transactions may, or may not, be the same). >>>> >>>> >>>> Q2: >>>>>> >>>>>> Assume there is an Offer/Answer transaction during the session. Now, >>>>>> the TCP/TLS connection is not affected by that, but the TLS roles >>>>>> may change (if whoever was Offerer in the previous O/A transaction i= s >>>>>> now Answerer). >>>>>> >>>>>> I think some wording would be needed about that also. >>>>>> >>>>>> One alternative is to say that the TLS roles may change, but that >>>>>> doesn't affect the TCP/TLS connection. >>>>>> >>>>> >>>>> A healthy TCP/TLS connection shouldn't be affected at all, should it? >>>>> >>>> >>>> Correct. The question is whether such Offer/Answer can affect the >>>> TCP/TLS roles - even if the TCP/TLS connection itself if not affected.= That >>>> could have impact on the case in Q1, where the TCP/TLC connection goes >>>> down, and it needs to be determined who is TLS server. >>>> >>>> However, any potential connection re-establishment will need to >>>>> monitor who was the last answerer to do the TLS initiation correctly. >>>>> >>>>> Hopefully I did understand the issue here, and added my 2 zlotys or >>>>> pence or whatever, >>>>> >>>> >>>> I think you did understand the issue :) >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> _______________________________________________ >>>> bfcpbis mailing list >>>> bfcpbis@ietf.org >>>> https://www.ietf.org/mailman/listinfo/bfcpbis >>>> _______________________________________________ >>>> bfcpbis mailing list >>>> bfcpbis@ietf.org >>>> https://www.ietf.org/mailman/listinfo/bfcpbis >>>> >>>> >>> _______________________________________________ >>> bfcpbis mailing list >>> bfcpbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/bfcpbis >>> >>> >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >> > > > > -- > # Cisco | http://www.cisco.com/telepresence/ > ## tomkrist@cisco.com | http://www.tandberg.com > ### | http://folk.uio.no/tomkri/ > --=20 # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --089e0149c6c049c54c04f26035d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI. The text included in the next version will be (Sectio= n 7, 3rd and 4th paragraphs):

----
=A0Whi= ch party, the client or the floor control server, acts as the TLS/
=A0 =A0DTLS server depends on how the underlying TLS/DTLS connection is
=A0 =A0established. =A0For a TCP/TLS connection established using an= SDP
=A0 =A0offer/answer exchange [7], the answerer (which ma= y be the client or
=A0 =A0the floor control server) always acts as the TLS server. =A0If = the TCP
=A0 =A0connection is lost, the active endpoint, i.e., the= current TLS
=A0 =A0client, is responsible for re-establishing th= e TCP connection.
=A0 =A0Unless a new TLS session is negotiated, subsequent SDP offers a= nd
=A0 =A0answers will not impact the previously negotiated TLS r= oles.

=A0 =A0For a UDP/DTLS connection established= using the an SDP offer/answer
=A0 =A0exchange, either party can be the DTLS server depending on the = setup
=A0 =A0attributes exchanged; examples can be found in [22].=
----

I do hope that defines= it correctly.

-- Tom



On 23 January 201= 4 11:48, Tom Kristensen <2mkristensen@gmail.com> wrote:=
Thanks Christer, not only d= id you discover the issue - you also provided the fix (and text for it). Th= at solves what is currently missing in the draft and in RFC 4582.

I will add your text, or at least a very similar version, to= the upcoming version of the draft.

-- Tom


On 21 January 2014 15:10, = Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 1/20/14 8:44 PM, Christer Holmberg w= rote:
Hi,

Some initial text proposal:

"If the TCP connection is lost, the "active" endpoint is res= ponsible for re-establishing the TCP connection.

Unless a new TLS session is negotiated, subsequent SDP Offers and Answers w= ill not impact the previously negotiated TLS roles."

Is the passive endpoint expected to listen for the connection attempt at al= l times, or when it has noticed that the old connection is lost, or only wh= en
there has been a new O/A? (It is kind of a waste to maintain a listener whe= n you have an active connection and aren't expecting more.
And it is asking for trouble, since you might get a new connection when you= think the old one is still functional.)

If a TCP connection has been established, I think it is enough to listen fo= r the connection when it has noticed that the old connection is lost. I ass= ume both endpoints would detect that more or less at the same time, or?

If a TCP connection has NOT been established, one would listen only when th= ere has been a O/A used to negotiate the TCP connection.

WFM.


I realize this is old stuff, but I'm surprised that it didn't follo= w comedia about all of this, including who is active.

I am not sure I understand. Comedia IS used to indicate who is active. Howe= ver, comedia is NOT used to indicate who is TLS client/server.

OK.


Regards,

Christer




-----Alkuper=E4inen viesti-----
L=E4hett=E4j=E4: bfcpbis [mailto:bfcpbis-bounces@ietf.org] Puolesta Christer<= br> Holmberg
L=E4hetetty: 16. tammikuuta 2014 21:36
Vastaanottaja: Tom Kristensen
Kopio: bfcpbis@ietf.o= rg
Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes dow= n and is re-established?


Hi Tom,

I realize the following comes late in the process, and I apologize
if it has been discussed, but it is related to something which just
has recently popped up in 3GPP, and it's not addressed in the draft.

Not too late, since we are still not finished! Anyway, the TCP/TLS
connection reuse is not altered while extending BFCP to support
unreliable transport. Any fixes now must be backwards compatible in
some way.

That said and based on what I have seen from different vendors, most
of them still use TCP (without TLS) :)

So, at least if we are changing anything to solve these issues, we
should add an informational note indicating this is a change where
legacy, pure RFC 4582 implementations might differ in behaviour...

I am not suggesting to change anything - I am suggesting to specify
something which is currently unspecified :)

By the way: How these issues was solved in 3GPP are along the lines of what= you propose below?

We have had some discussions in 3GPP, and there are some text suggestions f= or the upcoming meeting next week.

However, the discussions so far have been mostly about Q2. Q1 came up on a = mailing list just this week, and whill be discussed at the 3GPP meeting nex= t week.

Section 7 says the following:

"For a TCP/TLS connection established using an SDP

offer/answer exchange [7], the answerer (which may be the client or

the floor control server) always acts as the TLS server."

Q1:

Assume the TCP/TLS connection, for whatever reason, goes down.

Now, I assume that whoever endpoint is "active" will most likely = try
to re-establish the TCP connection.

But, if the "active" endpoint doesn't send an Offer (i.e. it = simply
tries to re-establish the TCP connection based on the previously
negotiated SDP information), who will act as TLS server? There is no
Answerer.

One alternative would be to mandate the sending of an Offer when the
TCP/TLS connection is re-established. Then it would be clear who is
Offerer, and who is Answerer.

Another alternative would be to say that whoever was previously
Answerer will act as TLS server.

I'm not too fond of yet another re-INVITE being mandated, so if we
will fix this issue mandating the previous answerer to be the TLS
server would be my preference.

Assuming that, then my follow-up question is:

When you say "previous answerer", do you refer to the answerer in= the latest Offer/Answer transaction, OR the answerer in the last Offer/Ans= wer transaction that established/re-established the TCP/TLS connection (tho= se Offer/Answer transactions may, or may not, be the same).


Q2:

Assume there is an Offer/Answer transaction during the session. Now,
the TCP/TLS connection is not affected by that, but the TLS roles
may change (if whoever was Offerer in the previous O/A transaction is now A= nswerer).

I think some wording would be needed about that also.

One alternative is to say that the TLS roles may change, but that
doesn't affect the TCP/TLS connection.

A healthy TCP/TLS connection shouldn't be affected at all, should it?

Correct. The question is whether such Offer/Answer can affect the TCP/TLS r= oles - even if the TCP/TLS connection itself if not affected. That could ha= ve impact on the case in Q1, where the TCP/TLC connection goes down, and it= needs to be determined who is TLS server.

However, any potential connection re-establishment will need to
monitor who was the last answerer to do the TLS initiation correctly.

Hopefully I did understand the issue here, and added my 2 zlotys or
pence or whatever,

I think you did understand the issue :)

Regards,

Christer

_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis
_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis


_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis


_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis



<= /div>--
# Cisco =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://www.cisco.com/telepresence/ ## tomkrist@cisco.c= om =A0| =A0http:/= /www.tandberg.com
### =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://folk.uio.no/tomkr= i/



--
# Cisco =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://www.cisco.com/telepresence/
## tomkrist@c= isco.com =A0| =A0= http://www.tandberg.com
### =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0http://folk.uio.no/tomkr= i/ --089e0149c6c049c54c04f26035d4-- From nobody Fri Feb 14 13:38:38 2014 Return-Path: <2mkristensen@gmail.com> 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 657721A03ED for ; Fri, 14 Feb 2014 13:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 1UP_uYSqElRA for ; Fri, 14 Feb 2014 13:38:24 -0800 (PST) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6B21A03C8 for ; Fri, 14 Feb 2014 13:38:24 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id n7so21347870qcx.30 for ; Fri, 14 Feb 2014 13:38:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mmj6dFnINeM3TPmseBAwf1I40lTS0sK8SekMnY3Q0b4=; b=G8To8nk/eK6EsyFTekWcRFZ89QuZK2PPfm2H0iEzScd0xPlrMsRgv486c60jrkuzHb T+aInLKy0QMOwW7GnGzGQI/Ks9my5mK7XShprSx9z/fqR+NBq8YMcGM0S9wYnNVXfCLn 1EXXr5l6pDHLrSDqQQWnJdEvNaK498O9xGrO6BtvUAg+YRpKiLxPwVpkZ4pK345rxq7w y54ej1pkhf0X4FDswiJ6LNuQFuGh+s617AaLGacvXJnmEc0wuB9wbBzUl0buy3hX5drC zeyhqxYXtAx34nhwKjdZpc3CMpgFsLJKFN0nd85xjeTsWtQTfCDHyiIeAy7hD4XpB2Ur LBaw== MIME-Version: 1.0 X-Received: by 10.224.88.131 with SMTP id a3mr17725291qam.34.1392413902718; Fri, 14 Feb 2014 13:38:22 -0800 (PST) Received: by 10.229.2.69 with HTTP; Fri, 14 Feb 2014 13:38:22 -0800 (PST) In-Reply-To: References: <20131104104454.10115.16900.idtracker@ietfa.amsl.com> <52777C07.1080403@cisco.com> <52934193.5050304@ericsson.com> Date: Fri, 14 Feb 2014 22:38:22 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=001a11c2dac00d4b9204f264a0c3 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/BK6DOUa4QmAcoyx40U-ejMUVd9s Cc: "bfcpbis@ietf.org" , Gonzalo Camarillo , "Tom Kristensen \(tomkrist\)" 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: Fri, 14 Feb 2014 21:38:28 -0000 --001a11c2dac00d4b9204f264a0c3 Content-Type: text/plain; charset=ISO-8859-1 On 14 January 2014 20:03, Charles Eckel (eckelcu) wrote: > Hi Gonzalo, > > I was looking through the archives and did not see any response to you > comments. Sorry for the delay. Please see inline. > > On 11/25/13 4:24 AM, "Gonzalo Camarillo" > wrote: > > >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. > > In practice I have typically seen this configured as either use TCP first > and fallback to UDP or vice versa. Depending on the product and > environment, the choose of defaulting to TCP vs. UDP is made. The text in > Appendix B describes the challenges with using TCP in some environments. > In such environments, UDP would be typically be configured as the default. I have added an informational note in Section 6, it reads as follows: "Informational note: In practice products is configured to try one transport initially and use the other one as a fallback. Whether TCP or UDP is chosen as underlying transport depends on type of product and the nature of the environment it is deployed, here the considerations in Appendix B is an important input." > >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 ICMP behaviour is defined in 6.2.2. Also, the behaviour when timers fire are described in Section 8. >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. > > How about: > Concordantly, messages sent by the floor control server that initiate new > transactions (e.g., FloorStatus announcements as part of a FloorQuery > subscription) require acknowledgement messages from the floor participant > and chair entities to which they were sent > A better explanation and we avoid introducing a term (transaction-completing), that is not defined or even needed. >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. > > RFC 4582 stated the following, "If a BFCP entity (a client or a floor > control server) receives data from TCP that cannot be parsed, the entity > MUST close the TCP connection, and the connection SHOULD be reestablished." > As there is no concept of a connection with UDP, we decided to handle by > defining the new error code. > Right. And there's no need for an explanation of that rationale in the draft I assume. >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 normative language for this situation is in section 10.1.3, "When > communicating over an unreliable transport and upon receiving a > FloorRequestStatus message from a floor control server, the > participant MUST respond with a FloorRequestStatusAck message within > the transaction failure window to complete the transaction." > I think replacing "shall be" with "is" is fine. > Yes, fixed to avoid "confusion" as normative statements are provided for this elsewhere. > >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. > > I cannot think of good reason for not sending a Goodbye. It may be that > the Goodbye fails, and I think there may be existing implementations that > do not send the Goodbye, but from a protocol perspective MUST/REQUIRED > strength seems appropriate. > I agree. I'm not quite sure, but it might be that the SHOULD level stems from earlier versions where Goodbye also was an option specified for TCP in a common section. Will change to REQUIRED in that paragraph. >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. > > I think it needs to read as follows, "When a BFCP implementation receives > a BFCP message fragment, it MUST buffer the fragment until either it has > received the entire BFCP message, or until the Response Retransmission > Timer expires." > There is also a "must" that should be changed to "MUST" in the paragraph > describing the retransmission timer. Yes, fixed accordingly. -- Tom -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --001a11c2dac00d4b9204f264a0c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 14 January 2014 20:03, Charles Eckel (eckelcu) <eckelc= u@cisco.com> wrote:
Hi Gonzalo,

I was looking through the archives and did not see any response to you
comments. Sorry for the delay. Please see inline.

On 11/25/13 4:24 AM, "Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>
wrote:

>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 o= r
>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<= br> >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.

In practice I have typically seen this configured as either use TCP f= irst
and fallback to UDP or vice versa. Depending on the product and
environment, the choose of defaulting to TCP vs. UDP is made. The text in Appendix B describes the challenges with using TCP in some environments. In such environments, UDP would be typically be configured as the default.<= /blockquote>

I have added an informational note in= Section 6, it reads as follows:

=A0 =A0 =A0"Informational note: In practice products is configure= d to try one
=A0 =A0 =A0 transport initially and use the other on= e as a fallback. =A0Whether
=A0 =A0 =A0 TCP or UDP is chosen as u= nderlying transport depends on type of
=A0 =A0 =A0 product and the nature of the environment it is deployed, = here the
=A0 =A0 =A0 considerations in Appendix B is an important= input."
=A0
>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<= br> >is considered to have become unavailable (e.g., ICMP messages or
>timeouts)

The ICMP beha= viour is defined in=A06.2.2. Also, the behaviour when timers fire are descr= ibed in Section 8.

>The following is the last sentence of the 3rd paragraph of Section 6.2:=
>
>> =A0 =A0Concordantly, messages sent by the floor
>> =A0 =A0control server that are not transaction-completing (e.g., F= loorStatus
>> =A0 =A0announcements as part of a FloorQuery subscription) are ser= ver-
>> =A0 =A0initiated transactions that require acknowledgement message= s from the
>> =A0 =A0floor participant and chair entities to which they were sen= t.
>
>
>I do not think the term "transaction-completing" have been de= fined 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.

How about:
Concordantly, messages sent by the floor control server that initiate new transactions (e.g., FloorStatus announcements as part of a FloorQuery
subscription) require acknowledgement messages from the floor participant
and chair entities to which they were sent

A better explanation and we avoid introducing a= term (transaction-completing), that is not defined or even needed.=A0

>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 t= hat
>with TCP as well? Is it because of backward compatibility issues? If so= ,
>we should add a clarifying note.

RFC 4582 stated the following, "If a BFCP entity (a client or a = floor
control server) receives data from TCP that cannot be parsed, the entity MUST close the TCP connection, and the connection SHOULD be reestablished.&= quot;
As there is no concept of a connection with UDP, we decided to handle by defining the new error code.

Righ= t. And there's no need for an explanation of that rationale in the draf= t I assume. =A0

>The following sentence appears in the first paragraph of page 41:
>
>> =A0 =A0The subsequent changes in state for
>> =A0 =A0the request are new transactions whose Transaction ID is de= termined
>> =A0 =A0by the floor control server and whose receipt by the client=
>> =A0 =A0participant shall be acknowledged with a FloorRequestStatus= Ack
>> =A0 =A0message.
>
>Instead of "shall be", we should write "MUST be" if= this behavior has
>not been normatively defined anywhere else, or "is" if the be= havior has
>been normatively defined somewhere else.

The normative language for this situation is in section 10.1.3, "= ;When
communicating over an unreliable transport and upon receiving a
=A0 =A0FloorRequestStatus message from a floor control server, the
=A0 =A0participant MUST respond with a FloorRequestStatusAck message within=
=A0 =A0the transaction failure window to complete the transaction." I think replacing "shall be" with "is" is fine.

Yes, fixed to avoid "confusion"= ; as normative statements are provided for this elsewhere.
=A0
>The following paragraph appears later in Section 6.2:
>
>> =A0 =A0If a client wishes to end its BFCP connection with a floor = control
>> =A0 =A0server, it is RECOMMENDED that the client send a Goodbye me= ssage to
>> =A0 =A0dissociate itself from any allocated resources. =A0If a flo= or control
>> =A0 =A0server wishes to end its BFCP connection with a client (e.g= ., the
>> =A0 =A0Focus of the conference informs the floor control server th= at the
>> =A0 =A0client has been kicked out from the conference), it is RECO= MMENDED
>> =A0 =A0that the floor control server send a Goodbye message toward= s the
>> =A0 =A0client.
>
>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<= br> >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<= br> >all this somewhere.

I cannot think of good reason for not sending a Goodbye. It may be th= at
the Goodbye fails, and I think there may be existing implementations that do not send the Goodbye, but from a protocol perspective MUST/REQUIRED
strength seems appropriate.

I agr= ee. I'm not quite sure, but it might be that the SHOULD level stems fro= m earlier versions where Goodbye also was an option specified for TCP in a = common section. Will change to REQUIRED in that paragraph.

>The following paragraph appears in Section 6.2.3:
>
>> =A0 =A0When a BFCP implementation receives a BFCP message fragment= , it MUST
>> =A0 =A0buffer the fragment until it has received the entire BFCP m= essage.
>> =A0 =A0The state machine should handle the BFCP message only after= all the
>> =A0 =A0fragments for the message have been received.
>
>However, the paragraph after that seems to contradict the "MUST&qu= ot; above
>because it allows receivers to discard incomplete buffers.

I think it needs to read as follows, "When a BFCP implementation= receives
a BFCP message fragment, it MUST buffer the fragment until either it has received the entire BFCP message, or until the Response Retransmission
Timer expires."
There is also a "must" that should be changed to "MUST"= in the paragraph
describing the retransmission timer.

= Yes, fixed accordingly.

-- Tom

--
# Cisco =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 | =A0http://www.cisco.com/telepresence/
## tomkrist@cisco.c= om =A0| =A0http:/= /www.tandberg.com
### =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | =A0http://folk.uio.no/tomkri/
--001a11c2dac00d4b9204f264a0c3-- From nobody Fri Feb 14 14:28:47 2014 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 789BD1A0252 for ; Fri, 14 Feb 2014 14:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 kcGKEafSihdp for ; Fri, 14 Feb 2014 14:28:37 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 74AD51A02C6 for ; Fri, 14 Feb 2014 14:28:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24345; q=dns/txt; s=iport; t=1392416905; x=1393626505; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nvf57ULevgBGKHnmo/Sj2SXwDLWGcAGqO4xOWOhwNSI=; b=jw34dzU3Ejh5rLIwhBIbCXoDw1Pp/RWXheaSvYp9YP/gP2ETJtNJEexy QESyECQFeTDgSoQrPtuJNr0uDKc5yQ0oGJkO0m+DTz8g3dbYb2zcuBQ02 hlJi55YZpcGeRVOEpdvtgKBsd+UoxK9YlOYVmizWYmcej22Ey7dO7t/o6 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosGAMWX/lKtJV2Z/2dsb2JhbABZgkJEOFe2XYhVgRgWdIIlAQEBBCcuExEQAgEIDgMDAQIOGgchERQJCAIEDgWHcQMQAQ3APw2IDxeMX4FvGhEHAgQDhC8ElkCBbIEyiywDhUKDLYIq X-IronPort-AV: E=Sophos;i="4.95,847,1384300800"; d="scan'208,217";a="304209436" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 14 Feb 2014 22:28:24 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1EMSO1D009570 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 22:28:24 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.47]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 16:28:23 -0600 From: "Charles Eckel (eckelcu)" To: Tom Kristensen <2mkristensen@gmail.com> Thread-Topic: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-10.txt Thread-Index: AQHO2UtQ49CFBHKOV0uSdd6Uxkz0ApoVSW6AgCEbPYCATn30AIAxaYoA//+H3AA= Date: Fri, 14 Feb 2014 22:28:23 +0000 Message-ID: References: <20131104104454.10115.16900.idtracker@ietfa.amsl.com> <52777C07.1080403@cisco.com> <52934193.5050304@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [171.68.20.23] Content-Type: multipart/alternative; boundary="_000_CF23D77E1F021eckelcuciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/t0AJls_ggXwfoTpj1yiXQvjJbFw Cc: "bfcpbis@ietf.org" , Gonzalo Camarillo , "Tom Kristensen \(tomkrist\)" 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: Fri, 14 Feb 2014 22:28:42 -0000 --_000_CF23D77E1F021eckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Editorial nits inline in case you have not submitted yet. From: Tom Kristensen <2mkristensen@gmail.com= > Date: Friday, February 14, 2014 1:38 PM To: Charles Eckel > Cc: Gonzalo Camarillo >, Tom Kristensen >, "bfcpbis@ietf.org" > Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-10.txt On 14 January 2014 20:03, Charles Eckel (eckelcu) > wrote: Hi Gonzalo, I was looking through the archives and did not see any response to you comments. Sorry for the delay. Please see inline. On 11/25/13 4:24 AM, "Gonzalo Camarillo" > wrote: >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. In practice I have typically seen this configured as either use TCP first and fallback to UDP or vice versa. Depending on the product and environment, the choose of defaulting to TCP vs. UDP is made. The text in Appendix B describes the challenges with using TCP in some environments. In such environments, UDP would be typically be configured as the default. I have added an informational note in Section 6, it reads as follows: "Informational note: In practice products is configured to try one In practice, products are =85 transport initially and use the other one as a fallback. Whether TCP or UDP is chosen as underlying transport depends on type of product and the nature of the environment it is deployed, here the deployed. Here =85 considerations in Appendix B is an important input."' =85 Appendix B are important to consider. >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 ICMP behaviour is defined in 6.2.2. Also, the behaviour when timers fir= e are described in Section 8. are described -> is described Cheers, Charles >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. How about: Concordantly, messages sent by the floor control server that initiate new transactions (e.g., FloorStatus announcements as part of a FloorQuery subscription) require acknowledgement messages from the floor participant and chair entities to which they were sent A better explanation and we avoid introducing a term (transaction-completin= g), that is not defined or even needed. >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. RFC 4582 stated the following, "If a BFCP entity (a client or a floor control server) receives data from TCP that cannot be parsed, the entity MUST close the TCP connection, and the connection SHOULD be reestablished." As there is no concept of a connection with UDP, we decided to handle by defining the new error code. Right. And there's no need for an explanation of that rationale in the draf= t I assume. >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 normative language for this situation is in section 10.1.3, "When communicating over an unreliable transport and upon receiving a FloorRequestStatus message from a floor control server, the participant MUST respond with a FloorRequestStatusAck message within the transaction failure window to complete the transaction." I think replacing "shall be" with "is" is fine. Yes, fixed to avoid "confusion" as normative statements are provided for th= is elsewhere. >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. I cannot think of good reason for not sending a Goodbye. It may be that the Goodbye fails, and I think there may be existing implementations that do not send the Goodbye, but from a protocol perspective MUST/REQUIRED strength seems appropriate. I agree. I'm not quite sure, but it might be that the SHOULD level stems fr= om earlier versions where Goodbye also was an option specified for TCP in a= common section. Will change to REQUIRED in that paragraph. >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. I think it needs to read as follows, "When a BFCP implementation receives a BFCP message fragment, it MUST buffer the fragment until either it has received the entire BFCP message, or until the Response Retransmission Timer expires." There is also a "must" that should be changed to "MUST" in the paragraph describing the retransmission timer. Yes, fixed accordingly. -- Tom -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.co= m ### | http://folk.uio.no/tomkri/ --_000_CF23D77E1F021eckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Editorial nits inline in case you have not submitted yet.

From: Tom Kristensen <2mkristensen@gmail.com>
Date: Friday, February 14, 2014 1:3= 8 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, Tom Kristensen <tomkrist@c= isco.com>, "bfcpbis@ietf.or= g" <bfcpbis@ietf.org>
Subject: Re: [bfcpbis] I-D Action: = draft-ietf-bfcpbis-rfc4582bis-10.txt

On 14 January 2014 20:03, Charles Eckel (eckelcu) <eckelcu@cisco.co= m> wrote:
Hi Gonzalo,

I was looking through the archives and did not see any response to you
comments. Sorry for the delay. Please see inline.

On 11/25/13 4:24 AM, "Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>
wrote:

>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 o= r
>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<= br> >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.

In practice I have typically seen this configured as either use TCP first and fallback to UDP or vice versa. Depending on the product and
environment, the choose of defaulting to TCP vs. UDP is made. The text in Appendix B describes the challenges with using TCP in some environments. In such environments, UDP would be typically be configured as the default.<= /blockquote>

I have added an informational note in Section 6, it reads a= s follows:

     "Informational note: In practice products is = configured to try one

In practice, products are =85

      transport initially and use the other one as a fa= llback.  Whether
      TCP or UDP is chosen as underlying transport depe= nds on type of
      product and the nature of the environment it is d= eployed, here the

deployed. Here =85

      considerations in Appendix B is an important inpu= t."'

=85 Appendix B are important to consider.

 
>The second paragraph of Section 6.2 explains that the f= loor control
>server is considered present and available upon receiving a HelloAck >message. We should also explain the circumstances in which the service<= br> >is considered to have become unavailable (e.g., ICMP messages or
>timeouts)

The ICMP behaviour is defined in 6.2.2. Also, the beha= viour when timers fire are described in Section 8.

are described -> is described

Cheers,
Charles


>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) a= re server-
>>    initiated transactions that require acknowledgement m= essages from the
>>    floor participant and chair entities to which they we= re sent.
>
>
>I do not think the term "transaction-completing" have been de= fined 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.

How about:
Concordantly, messages sent by the floor control server that initiate new transactions (e.g., FloorStatus announcements as part of a FloorQuery
subscription) require acknowledgement messages from the floor participant
and chair entities to which they were sent

A better explanation and we avoid introducing a term (trans= action-completing), that is not defined or even needed. 

>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<= br> >with TCP as well? Is it because of backward compatibility issues? If so= ,
>we should add a clarifying note.

RFC 4582 stated the following, "If a BFCP entity (a client or a floor<= br> control server) receives data from TCP that cannot be parsed, the entity MUST close the TCP connection, and the connection SHOULD be reestablished.&= quot;
As there is no concept of a connection with UDP, we decided to handle by defining the new error code.

Right. And there's no need for an explanation of that ratio= nale in the draft I assume.  

>The following sentence appears in the first paragraph o= f 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 FloorRequest= StatusAck
>>    message.
>
>Instead of "shall be", we should write "MUST be" if= this behavior has
>not been normatively defined anywhere else, or "is" if the be= havior has
>been normatively defined somewhere else.

The normative language for this situation is in section 10.1.3, "When<= br> communicating over an unreliable transport and upon receiving a
   FloorRequestStatus message from a floor control server, the    participant MUST respond with a FloorRequestStatusAck message = within
   the transaction failure window to complete the transaction.&qu= ot;
I think replacing "shall be" with "is" is fine.

Yes, fixed to avoid "confusion" as normative stat= ements are provided for this elsewhere.
 
>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 Good= bye message to
>>    dissociate itself from any allocated resources.  = ;If a floor control
>>    server wishes to end its BFCP connection with a clien= t (e.g., the
>>    Focus of the conference informs the floor control ser= ver that the
>>    client has been kicked out from the conference), it i= s 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<= br> >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<= br> >all this somewhere.

I cannot think of good reason for not sending a Goodbye. It may be that
the Goodbye fails, and I think there may be existing implementations that do not send the Goodbye, but from a protocol perspective MUST/REQUIRED
strength seems appropriate.

I agree. I'm not quite sure, but it might be that the SHOUL= D level stems from earlier versions where Goodbye also was an option specif= ied for TCP in a common section. Will change to REQUIRED in that paragraph.=

>The following paragraph appears in Section 6.2.3:
>
>>    When a BFCP implementation receives a BFCP message fr= agment, 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&qu= ot; above
>because it allows receivers to discard incomplete buffers.

I think it needs to read as follows, "When a BFCP implementation recei= ves
a BFCP message fragment, it MUST buffer the fragment until either it has received the entire BFCP message, or until the Response Retransmission
Timer expires."
There is also a "must" that should be changed to "MUST"= in the paragraph
describing the retransmission timer.

Yes, fixed accordingly.

-- Tom

--
# Cisco                   &nbs= p;     |  http://www.cisco.com/telepresence/
## tomkrist@cisco.c= om  |  = http://www.tandberg.com
###                     &= nbsp;         |  http://folk.uio.no/tomkri/
 --_000_CF23D77E1F021eckelcuciscocom_-- From nobody Fri Feb 14 15:14:58 2014 Return-Path: <2mkristensen@gmail.com> 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 8CF791A045D for ; Fri, 14 Feb 2014 15:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, SPF_PASS=-0.001] autolearn=no 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 4wnhfO1z4x_Y for ; Fri, 14 Feb 2014 15:14:45 -0800 (PST) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id A5DB21A040B for ; Fri, 14 Feb 2014 15:14:39 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id j15so19117566qaq.39 for ; Fri, 14 Feb 2014 15:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WgLSB17M5q0QY10rFdb+q6fgMFqxGIfXVgWMXMa6I7I=; b=dnxbu9arGZZhlCP9QBLZFcDEajMzIr/ab0/BJP2WtFuUKy+n+ZcAwQFlFcqiVzBFb6 EldAtLjgOwhCXj2pGYSjhDPi8RF3ey2lyuVpkRVCUCXq8I9u4Jse4INaQN3+NNNgw98I PdYORBFQCmR/R4ntuKQVoIlgNRYSWJbT2Gdt0S3KJDnb4Ydh5W1/im7YI2OD6aid+I81 2WNILBSVf49UhgdiQFH6ZAsifPFyuCcYza+qJyHT8kinGWMFf57bCljDjFpSzPXWjCEm w+KGaBc3QH7o9uT898bjgBtekPOrCta50GHt5NJMuKqXFMegpImzD6Lg9kRZTKZuTpUw vBOg== MIME-Version: 1.0 X-Received: by 10.140.108.116 with SMTP id i107mr16991623qgf.80.1392419677852; Fri, 14 Feb 2014 15:14:37 -0800 (PST) Received: by 10.229.2.69 with HTTP; Fri, 14 Feb 2014 15:14:37 -0800 (PST) In-Reply-To: References: Date: Sat, 15 Feb 2014 00:14:37 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Charles Eckel (eckelcu)" , Mary Barnes Content-Type: multipart/alternative; boundary=001a113aadc246d8cd04f265f80a Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/dtHcSGVvhjvV0bnzqT6XWtyrBFU Cc: Richard Barnes , "bfcpbis@ietf.org" , "bfcpbis-chairs@tools.ietf.org" , "draft-ietf-bfcpbis-rfc4582bis.authors@tools.ietf.org" , Tom Kristensen Subject: Re: [bfcpbis] PROTO review comments on draft-ietf-bfcpbis-rfc4582bis-10 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: Fri, 14 Feb 2014 23:14:51 -0000 --001a113aadc246d8cd04f265f80a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 14 January 2014 20:44, Charles Eckel (eckelcu) wrote= : > > From: Mary Barnes > Date: Thursday, December 19, 2013 12:27 PM > [...] *General:* > 1) I still have not had a response from Keith Drage nor Joerg Ott with > regards to IPR, so I cannot forward the document to the AD even after the > document is updated until I get those responses. > > Hopefully, this is now taken care of! > 2) Obviously, the WG needs to agree proposed solutions to the points made > by Joerg: > http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00249.html > At this time, I've not seen the authors post any proposals as to how to > deal with those comments/concerns > > This should be solved, with the amount of commenting and proposals that has been published on the list. > 3) I have reviewed the document in detail - both the entire document and > the diffs between RFC4582. I have both comments and nits on text that was > also in RFC 4582, as well as on the new text, detailed below. Note, that = a > number of nits are around the use of lower case normative words which oug= ht > to be uppercase to distinguish them from the normal English usage. I thin= k > there are a number of cases where "may"s for example would be much better > stated as "can"s. I've identified some of those below, but I don't think > it's worth the effort to change them all (nor my effort to identify them > all). ` > > I've done a scan and do think the ones you have found should be sufficien= t to deal with. > *Comments/questions:* > > 1) Section 3.4, 1st paragraph. You need to specify what you mean by the > parenthetical "in a certain way" - that doesn't tell you anything. > Something like "depending upon policies, privileges, etc." is probably > more appropriate. > > Well, with the simple example and later reference to RFC 5239, I do think the explanation of how resources may be used is not needed here. Removed "(in a certain way)". > 2) Section 6.2. > a) 3rd paragraph, 1st sentence: I don't think this is normative since > you're referring to the normative section. I suggest "shall form" -> > "forms". > > Fixed. > b) 4th paragraph. Under what conditions would a server not send an Error > message or is that statement just specifically sending an error message > with a parameter value of 10? I can't see why this isn't a MUST. If it's > really a should, more text is needed as to what happens if it isn't sent > (or why not sending the Error message is okay). > > I believe this was because it may not be possible to form a valid respons= e > because it was not possible to parse fields that are required to be > included in the response, such as the transaction ID. > Yes, I have therefore changed to MUST and appended: ", , given that it is possible to parse the received message to such an extent that an Error message may be built." to the sentence. > c) 4th para, last sentence: "shall" -> "SHALL" > > This is already fixed according to Gonzalo Camarillo's comment. > d) last para, next to last sentence. Why isn't this "MUST" request the > use of DTLS? If it's a SHOULD, then the impacts or criteria under which > DTLS isn't REQUIRED should be clarified. I see that the paragraph has > references to 5018 Section 5. I think it also should be clarified that > the "section 6" reference in that paragraph is also in 5018 (as I don't > think you're referring to section 6 of this document). > > > I think the server can choose to require DTLS or not. If it requires > DTLS for the request, it MUST respond the request with "Use DTLS). > Keeping the SHOULD, but adding a sentence in addition so that it reads: "In , Section 4 applies, but when using BFCP ov= er an unreliable transport the floor control server that receives a BFCP message over UDP (no DTLS) SHOULD request the use of DTLS by generating an Error message with an Error code with a value of 11 (Use DTLS). A floor control server that is configured to require DTLS MUST request the use of DTLS this way. " 3) Section 6.2.1 > a) 1st para, 3rd sentence. I don't think "previous paragraph" is accurate= . > I think it would be better to include an explicit reference to section 6= .2 > or say "previous section". > > Yes, cross reference added. > b) next to last sentence ought to be written normatively > OLD > The default initial > interval is set to 500ms and the interval is doubled after each > retransmission attempt. > NEW > The default initial > interval MUST be set to 500ms and the interval MUST be doubled after > each > retransmission attempt. > > Yes, fixed. > 4) Section 6.2.2, 1st sentence. What happens if the connection isn't > treated as closed (since this is a SHOULD and not a MUST)? Either this i= s > a MUST or the reasons one wouldn't treat the connection as closed and wha= t > happens when it's not treated as closed need to be explained. > > True, a bit fuzzy as it was. Fixed. > 5) Section 6.2.3, indented paragraph. What happens if the cookie exchang= e > mechanisms in DTLS aren't used and/or what other mechanisms could be used= ? > (Note, also that the should ought to be SHOULD). > > Well, by not using that mechanism spoofing is a bit easier. I don't know what other mechanisms to mention, and will assume the usage are based on environment and probability for + consequence of such an attack. > 6) Section 9.1. > a) 1st para, 2nd sentence. (Similar to comment 9 on rfc4583-bis). The > "assumes" needs to a REQUIRED. > OLD: > BFCP assumes that there is an integrity- > protected channel between the client and the floor control server > that can be used to exchange their self-signed certificates or, more > commonly, the fingerprints of these certificates. > > NEW: > An initial integrity-protected channel is REQUIRED between the client > and the floor control server that can be used to exchange their > self-signed certificates or, more commonly, the fingerprints of > these certificates. > > OR this needs to be a SHOULD and then include the text that's in the > "Note..." in the 3rd paragraph that indicates if there are additional > authentication mechanisms defined that don't require the integrity > protected channel. > > I'm adopting the new text, but adding " If TLS/DTLS is used, an initial ..." in front of it. > b) 2nd paragraph, last sentence. Under what criteria would a client NOT > ignore unauthenticated messages or what bad things can happen if a client > doesn't ignore the messages. It might be better to make this a MUST. > > Agree. Changed to MUST. > c) 4th paragraph, 2nd sentence. "SHOULD check" -> "MUST check" or explai= n > what might happen if the floor control servers doesn't check that the > messages aren't using an authorized User ID. > > I cannot see why this won't be checked, so requiring a check sounds reasonable. > 7) Section 11.1. > a) 4th paragraph. There's three SH OULDs in there that all ought to be > MUSTs OR the situations under which the action doesn't need to be done > needs to be specified. > b) 5th paragraph: I don't think that the use of Queue position field in > the last sentence prior to the indented text ought to be normative - i.e.= , > I think the " MAY use the Queue Position field" ought to be "can use the > Queue Position field". > c) Indented text (1st para) after 5th para. There are several "may"s: > (lower case) in this paragraph (and the next note), that probably all oug= ht > to be "can"s > d) last paragraph. It's not clear to me whether this "may" ought to be > normative. If so, it should be a MAY and perhaps reworded as I think it'= s > trying to say that "the floor chair MAY include STATUS-INFO attributes" i= n > Otherwise, a "can" would suffice. > > I agree with these issues. Reworded as suggested for issue d). > 8) Section 12.1.2. There is no normative language in this section. It > needs to be revisited. For example, 2nd para, 1st sentence. It would se= em > that "the floor control server will > respond with a FloorStatus message or with an Error message" > ought to be "MUST respond. > > Revisited and the MUST is added. > 9) Section 13.6, 1st para. Under what circumstances would the server NOT > generate an Error response (i.e., why is it a SHOULD and not a MUST)? > > This is inherited from RFC 4582. I agree that MUST seems appropriate. > Fixed. These cases are fixed across the document, since it was pointed out by J=F6rg too and recommended being fixed by Charles as well (when reading RFC 2119). > 10) Section 13.7, 1st para. Same comment as 9 above. > > Fixed. > 11) Section 16.1. I think there should be mention of the additional text > added for handling incorrect payload length. > > In Section 16.2. > 12) Section 16.1. "Requiring timely response". Shouldn't there be a > reference to section 8.3 (Timers)? > > Yes. > Added. > 13) Appendix A. Has there been anyone that has verified the call flows > with a tool or in the lab? If so, who was that? > > Not sure, but I expect yes. Hopefully someone can else can respond to thi= s > No verification other than review and comparing with actual implementations= . *Nits:* > > 1) Section 3.1, last paragraph. I would prefer this be updated to be > much more precise in terms of CCM P. I realize that this document was > published well before CCMP, so the text in RFC 4582 is based on draft > versions. > OLD: > Conference control clients using CCMP [17] can specify such floor- > related settings by editing the floor-information section of the > to-be created conference object provided in the body of a CCMP > confRequest/create message issued to the conference control server. > > NEW: > Conference control clients using CCMP [17] can specify such floor- > related settings in the [RFC6501]element of the > to-be created conference object provided in the body of a CCMP > confRequest/create message issued to the conference control server. > > Adopted. > 2) Section 3.2, 1st para, 2nd sentence. "These data include..." -> This > data includes > > OK! > 3) Section 3.3, last paragraph. " section" -> > " element" > > OK! > 4) Section 6.2, 4th para, last sentence: "shall" -> "SHALL" > > Already taken care of. > 5) Section 6.2.3: > - seventh paragraph. "must then retransmit" -> "MUST then retransmit" > - indented paragraph. "the Payload Length field may be compared" - > "can > be compared" > > OK! > 6) Section 8, 2nd indented paragraph. "must be non-zero" -> "MUST be > non-zero" > > Indeed. > 7) Section 10.1.1. 1st paragraph after 2nd indented para. "must insert" -= > > "MUST insert" > > Indeed. > 8) Section 10.1.2, 5th & 6th paragraphs. "MAY display" -> "can display" > > True, no mandatory language needed here. > 9) Section 12.2.1. last paragraph. "must insert" -> "MUST insert" > > OK! > 10) Section 12.3.1. last paragraph. "must insert" -> "MUST insert" > > OK! > 11) Section 16.1. This is a bit hard to read. I would suggest you use a > bulleted or numbered list rather than this hanging list format. > > Fixed! > 12) References: > a) Per the first nit, a reference to RFC 6501 (XCON Data model) should be > added to this document. > b) RFC 4582 should be a normative reference > c) I also suggest that RFC 5018 is normative as this document relies on > RFC 5018 for authentication and security. > > Sounds good. > Yes and fixed. -- Tom --=20 # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --001a113aadc246d8cd04f265f80a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 14 January 2014 20:44, Charles Eckel (eckelcu) <eckelc= u@cisco.com> wrote:

From: Mary Barnes <mary.ietf.barnes@gmail.c= om>
Date: Thursday, December 19, 2013 1= 2:27 PM

[...]

General:
1) I still have not had a response from Keith Drage nor Joerg Ott with= regards to IPR, so I cannot forward the document to the AD even after the = document is updated until I get those responses.
Hopefully, th= is is now taken care of! 
2) Obviously, the WG needs to agree proposed solutions to the points m= ade by Joerg:
At this time, I've not seen the authors post any proposals as to h= ow to deal with those comments/concerns
This should be solved, wi= th the amount of commenting and proposals that has been published on the li= st. 
3) I have reviewed the document in detail - both the entire document a= nd the diffs between RFC4582. I have both comments and nits on text that wa= s also in RFC 4582, as well as on the new text, detailed below. Note, that = a number of nits are around the use of lower case normative words which ought to be uppercase to distingui= sh them from the normal English usage. I think there are a number of cases = where "may"s for example would be much better stated as "can= "s.  I've identified some of those below, but I don't think it's worth the effort to change them all (nor my effor= t to identify them all). `
=
I've done a scan and do think the = ones you have found should be sufficient to deal with.
Comments/questions:

1) Section 3.4, 1st paragraph.  You need to specify what you mean= by the parenthetical "in a certain way" - that doesn't tell = you anything.  Something like "depending upon policies, privilege= s, etc." is probably more appropriate. 
Well, with the simple example and later reference to RFC 5239, I do th= ink the explanation of how resources may be used is not needed here. Remove= d "(in a certain way)". 
2) Section 6.2.
a) 3rd paragraph, 1st sentence: I don't think this is normative si= nce you're referring to the normative section.  I suggest "sh= all form" -> "forms".
Fixed. 
b) 4th paragraph. Under what conditions would a server not send an Err= or message or is that statement just specifically sending an error message = with a parameter value of 10?  I can't see why this isn't a MU= ST. If it's really a should, more text is needed as to what happens if it isn't sent (or why not sending the Error mess= age is okay). 
I believe this was because it may not be possible to form a valid resp= onse because it was not possible to parse fields that are required to be in= cluded in the response, such as the transaction ID.

Yes, I have therefore changed to MUST and appende= d: ",  , given that it is possible to parse the received message = to such an extent that an Error message may be built." to the sentence= .
c) 4th para, last sentence: "shall" -> "SHALL"<= /div>
<= div style>This is already fixed according to Gonzalo Camarillo's commen= t.
d) last para, next to last sentence.  Why isn't this "MU= ST" request the use of DTLS? If it's a SHOULD, then the impacts or= criteria under which DTLS isn't REQUIRED should be clarified.  I = see that the paragraph has references to  5018 Section 5.  I thin= k it also should be clarified that the "section 6" reference in th= at paragraph is also in 5018 (as I don't think you're referring to = section 6 of this document). 

I think the server can choose to require DTLS or not. If it requ= ires DTLS for the request, it MUST respond the request with "Use DTLS)= .

Keeping the SHOULD, but= adding a sentence in addition so that it reads:

  "In <xref target=3D"RFC= 5018"/>, Section 4 applies, but when using BFCP over an unreliable = transport the floor control server that receives a BFCP message over UDP (n= o DTLS) SHOULD request the use of DTLS by generating an Error message with = an Error code with a value of 11 (Use DTLS). A floor control server that is= configured to require DTLS MUST request the use of DTLS this way. "

3) Section 6.2.1
a) 1st para, 3rd sentence. I don't think "previous paragraph&= quot; is accurate.  I think it would be better to include an explicit = reference to section 6.2 or say "previous section".   <= /div>
Yes, cross reference added. 
b) next to last sentence ought to be written normatively
OLD
   The default initial
   interval is set to 500ms and the interval is doubled afte= r each
   retransmission attempt.
NEW
   The default initial
   interval MUST be set to 500ms and the interval MUST be do= ubled after each
   retransmission attempt.
Yes, fixed. =
4) Section 6.2.2, 1st sentence.  What happens if the connection i= sn't treated as closed (since this is a SHOULD and not a MUST)?  E= ither this is a MUST or the reasons one wouldn't treat the connection a= s closed and what happens when it's not treated as closed need to be explained.  
True, a bit fuzzy as i= t was. Fixed.
5) Section 6.2.3, indented paragraph.  What happens if the cookie= exchange mechanisms in DTLS aren't used and/or what other mechanisms c= ould be used?   (Note, also that the should ought to be SHOULD).
=
 Well, by not using that mechanism spoofing is a bit easier. I do= n't know what other mechanisms to mention, and will assume the usage ar= e based on environment and probability for + consequence of such an attack.=
6) Section 9.1. 
a) 1st para, 2nd sentence. (Similar to comment 9 on rfc4583-bis). &nbs= p;The "assumes" needs to a REQUIRED.  
OLD:
   BFCP assumes that there is an integrity-
   protected channel between the client and the floor contro= l server
   that can be used to exchange their self-signed certificat= es or, more
   commonly, the fingerprints of these certificates. 

NEW: 
   An initial integrity-protected channel is REQUIRED betwee= n the client 
   and the floor control server that can be used to exchange= their 
   self-signed certificates or, more commonly, the fingerpri= nts of 
   these certificates. 

OR  this needs to be a SHOULD and then include the text that'= s in the "Note…" in the 3rd paragraph that indicates if th= ere are additional authentication mechanisms defined that don't require= the integrity protected channel. 
=
I'm adopting the new text, but adding "  If T= LS/DTLS is used, an initial ..." in front of it.
b) 2nd paragraph, last sentence.  Under what criteria would a cli= ent NOT ignore unauthenticated messages or what bad things can happen if a = client doesn't ignore the messages.  It might be better to make th= is a MUST.   
=
Agree. Changed to MUST. 
c) 4th paragraph, 2nd sentence.  "SHOULD check" -> &= quot;MUST check" or explain what might happen if the floor control ser= vers doesn't check that the messages aren't using an authorized Use= r ID.   
=
 I cannot see why this won't be checked, so requiring a= check sounds reasonable.
7) Section 11.1.
a) 4th paragraph.  There's three SH OULDs in there that all o= ught to be MUSTs OR the situations under which the action doesn't need = to be done needs to be specified. 
b) 5th paragraph: I don't think that the use of Queue position fie= ld in the last sentence prior to the indented text ought to be normative - = i.e., I think the " MAY use the Queue Position field" ought to be= "can use the Queue Position field".  
c) Indented text (1st para) after 5th para.   There are several &= quot;may"s: (lower case) in this paragraph (and the next note), that p= robably all ought to be "can"s  
d) last paragraph. It's not clear to me whether this "may&quo= t; ought to be normative. If so, it should be a MAY and perhaps reworded a= s I think it's trying to say that "the floor chair MAY include STA= TUS-INFO attributes" in    Otherwise, a "can" woul= d suffice.  
=
I agree with these issues. Reworded as suggested fo= r issue d). 
8) Section 12.1.2.  There is no normative language in this sectio= n.  It needs to be revisited.  For example, 2nd para, 1st sentenc= e.  It would seem that "the floor control server will
   respond with a FloorStatus message or with an Error messa= ge" 
ought to be "MUST respond. 
Revisited and th= e MUST is added. 
9) Section 13.6, 1st para.  Under what circumstances would the se= rver NOT generate an Error response (i.e., why is it a SHOULD and not a MUS= T)?  
This is inherited from RFC 4582. I agree that MUST seems a= ppropriate.
 
Fixed. Thes= e cases are fixed across the document, since it was pointed out by J=F6rg t= oo and recommended being fixed by Charles as well (when reading RFC 2119).<= /div>
10) Section 13.7, 1st para. Same comment as 9 above. 
=
F= ixed. 
11) Section 16.1.  I think there should be mention of the additio= nal text added for handling incorrect payload length.
In Section = 16.2. 
12) Section 16.1. "Requiring timely response".  Shouldn= 't there be a reference to section 8.3 (Timers)?   
Yes.

Add= ed.
 
13) Appendix A. Has there been anyone that has verified the call flows= with a tool or in the lab?  If so, who was that?   
Not sure, but I expect yes. Hopefully someone can else can respo= nd to this

No verificatio= n other than review and comparing with actual implementations.

Nits:

1) Section 3.1, last paragraph.  I would prefer this be updated t= o be much more precise in terms of CCM P.  I realize that this documen= t was published well before CCMP, so the text in RFC 4582 is based on draft= versions. 
OLD:
   Conference control clients using CCMP [17] can specify su= ch floor-
   related settings by editing the floor-information section= of the
   to-be created conference object provided in the body of a= CCMP
   confRequest/create message issued to the conference contr= ol server.

NEW: 
    Conference control clients using CCMP [17] can specify s= uch floor-
   related settings in the <floor-information> [RFC650= 1]element of the
   to-be created conference object provided in the body of a= CCMP
   confRequest/create message issued to the conference contr= ol server.
Adopted. 
2) Section 3.2, 1st para, 2nd sentence.  "These data include= …" -> This data includes
OK! 
3) Section 3.3, last paragraph. "<floor-information> sectio= n" ->  "<floor-information> element"
OK! 
4) Section 6.2, 4th para, last sentence: "shall" -> "= ;SHALL"
<= /div>
Already taken care of. 
5) Section 6.2.3:
- seventh paragraph. "must then retransmit" -> "MUST= then retransmit" 
- indented paragraph. "the Payload Length field may be compared&q= uot; - > "can be compared" 
=
OK! 
6) Section 8, 2nd indented paragraph. "must be non-zero" -&g= t; "MUST be non-zero"
<= /span>
Indeed. 
7) Section 10.1.1. 1st paragraph after 2nd indented para. "must i= nsert" -> "MUST insert"
Indeed. 
8) Section 10.1.2, 5th & 6th paragraphs.  "MAY display&q= uot; -> "can display"  
True, no mandator= y language needed here. 
9) Section 12.2.1. last paragraph. "must insert" -> "= ;MUST insert"
<= /div>
OK! 
10) Section 12.3.1.   last paragraph. "must insert" -&g= t; "MUST insert"
OK! 
11) Section 16.1.  This is a bit hard to read.  I would sugg= est you use a bulleted or numbered list rather than this hanging list forma= t. 
Fixed! 
12) References:
a) Per the first nit, a reference to RFC 6501 (XCON Data model) should= be added to this document. 
b) RFC 4582 should be a normative reference
c) I also suggest that RFC 5018 is normative as this document relies o= n RFC 5018 for authentication and security. 
Sounds good.

Yes and fixed.

-- Tom
 
--
# Cisco           &n= bsp;             |  http://www.cisco.com/teleprese= nce/
## tomkrist@cisco.c= om  |  = http://www.tandberg.com
###            = ;                   |  http://folk.uio.no/t= omkri/
--001a113aadc246d8cd04f265f80a-- From nobody Fri Feb 14 15:24:43 2014 Return-Path: <2mkristensen@gmail.com> 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 DBB571A0332 for ; Fri, 14 Feb 2014 15:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 2IQpWfAET0PG for ; Fri, 14 Feb 2014 15:24:37 -0800 (PST) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id D65131A048B for ; Fri, 14 Feb 2014 15:24:36 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id i17so20841297qcy.25 for ; Fri, 14 Feb 2014 15:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sERx1vKBDXn4FyqjF/7HNsL4KBvIvUXXUAwKLR7RdRk=; b=m3KdZlW+jW4mHriju9VdST62a84mZro1SAMPfovPUxagx4gfNhqST3gamrUprGSS/k 3zM5rOUFGTsMI/a4SweMsygvM3Cck2lmxJIjeoAnpHA7PHtB6A24KRh35HpkSE5/WOg6 d02GQCN9SU7LqthOqphQ/j/E4CTWfz9JqzCr4eHggvqRmATwcRVIiTfg7rSTaaM+IHul ZSgRkB92Qzvglpwg8wtV+pA3xz5t63soMcVo0pg+4EdTe1vfz8Axl6n13NjhUGSsyMgw q3IELPWgyjxT14iWf+OyVosbr16iE6KVrxPLojsvbDyOibpQ1S81Qv2UGR1cp4w+P9vC UKIQ== MIME-Version: 1.0 X-Received: by 10.224.41.70 with SMTP id n6mr18071783qae.96.1392420275068; Fri, 14 Feb 2014 15:24:35 -0800 (PST) Received: by 10.229.2.69 with HTTP; Fri, 14 Feb 2014 15:24:34 -0800 (PST) In-Reply-To: References: <20131104104454.10115.16900.idtracker@ietfa.amsl.com> <52777C07.1080403@cisco.com> <52934193.5050304@ericsson.com> Date: Sat, 15 Feb 2014 00:24:34 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=047d7bdc8a0adfa4ca04f2661b48 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/-kjk-DcCds27pEln328qM3GWcFw Cc: "bfcpbis@ietf.org" , Gonzalo Camarillo , "Tom Kristensen \(tomkrist\)" 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: Fri, 14 Feb 2014 23:24:42 -0000 --047d7bdc8a0adfa4ca04f2661b48 Content-Type: text/plain; charset=ISO-8859-1 Thanks, a bit hasty there. Fixed now, time to submit just-in-time. -- Tom On 14 February 2014 23:28, Charles Eckel (eckelcu) wrote: > Editorial nits inline in case you have not submitted yet. > > From: Tom Kristensen <2mkristensen@gmail.com> > Date: Friday, February 14, 2014 1:38 PM > To: Charles Eckel > Cc: Gonzalo Camarillo , Tom Kristensen < > tomkrist@cisco.com>, "bfcpbis@ietf.org" > Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-10.txt > > On 14 January 2014 20:03, Charles Eckel (eckelcu) wrote: > >> Hi Gonzalo, >> >> I was looking through the archives and did not see any response to you >> comments. Sorry for the delay. Please see inline. >> >> On 11/25/13 4:24 AM, "Gonzalo Camarillo" >> wrote: >> >> >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. >> >> In practice I have typically seen this configured as either use TCP first >> and fallback to UDP or vice versa. Depending on the product and >> environment, the choose of defaulting to TCP vs. UDP is made. The text in >> Appendix B describes the challenges with using TCP in some environments. >> In such environments, UDP would be typically be configured as the default. > > > I have added an informational note in Section 6, it reads as follows: > > "Informational note: In practice products is configured to try one > > > In practice, products are ... > > transport initially and use the other one as a fallback. > Whether > TCP or UDP is chosen as underlying transport depends on type of > product and the nature of the environment it is deployed, here the > > > deployed. Here ... > > considerations in Appendix B is an important input."' > > > ... Appendix B are important to consider. > > > >> >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 ICMP behaviour is defined in 6.2.2. Also, the behaviour when timers > fire are described in Section 8. > > > are described -> is described > > Cheers, > Charles > > > >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. >> >> How about: >> Concordantly, messages sent by the floor control server that initiate new >> transactions (e.g., FloorStatus announcements as part of a FloorQuery >> subscription) require acknowledgement messages from the floor participant >> and chair entities to which they were sent >> > > A better explanation and we avoid introducing a term > (transaction-completing), that is not defined or even needed. > > >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. >> >> RFC 4582 stated the following, "If a BFCP entity (a client or a floor >> control server) receives data from TCP that cannot be parsed, the entity >> MUST close the TCP connection, and the connection SHOULD be >> reestablished." >> As there is no concept of a connection with UDP, we decided to handle by >> defining the new error code. >> > > Right. And there's no need for an explanation of that rationale in the > draft I assume. > > >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 normative language for this situation is in section 10.1.3, "When >> communicating over an unreliable transport and upon receiving a >> FloorRequestStatus message from a floor control server, the >> participant MUST respond with a FloorRequestStatusAck message within >> the transaction failure window to complete the transaction." >> I think replacing "shall be" with "is" is fine. >> > > Yes, fixed to avoid "confusion" as normative statements are provided for > this elsewhere. > > >> >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. >> >> I cannot think of good reason for not sending a Goodbye. It may be that >> the Goodbye fails, and I think there may be existing implementations that >> do not send the Goodbye, but from a protocol perspective MUST/REQUIRED >> strength seems appropriate. >> > > I agree. I'm not quite sure, but it might be that the SHOULD level stems > from earlier versions where Goodbye also was an option specified for TCP in > a common section. Will change to REQUIRED in that paragraph. > > >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. >> >> I think it needs to read as follows, "When a BFCP implementation receives >> a BFCP message fragment, it MUST buffer the fragment until either it has >> received the entire BFCP message, or until the Response Retransmission >> Timer expires." >> There is also a "must" that should be changed to "MUST" in the paragraph >> describing the retransmission timer. > > > Yes, fixed accordingly. > > -- Tom > > -- > # Cisco | http://www.cisco.com/telepresence/ > ## tomkrist@cisco.com | http://www.tandberg.com > ### | http://folk.uio.no/tomkri/ > > -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --047d7bdc8a0adfa4ca04f2661b48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, a bit hasty there. Fixed now, time to submit just-= in-time.

-- Tom


On 14 February 2014 23:28, Charles E= ckel (eckelcu) <eckelcu@cisco.com> wrote:
Editorial nits inline in case you have not submitted yet.

From: Tom Kristensen <2mkristensen@gmail.com>
Date: Friday, February 14, 2014 1:3= 8 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Gonzalo Camarillo <Gonzalo.Camari= llo@ericsson.com>, Tom Kristensen <tomkrist@cisco.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org= >
Subject: Re: [bfcpbis] I-D Action: = draft-ietf-bfcpbis-rfc4582bis-10.txt

On 14 January 2014 20:03, Charles Eckel (eckelcu) <eckelcu@cisco.co= m> wrote:
Hi Gonzalo,

I was looking through the archives and did not see any response to you
comments. Sorry for the delay. Please see inline.

On 11/25/13 4:24 AM, "Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.= com>
wrote:

>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 o= r
>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<= br> >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.

In practice I have typically seen this configured as either use TCP first and fallback to UDP or vice versa. Depending on the product and
environment, the choose of defaulting to TCP vs. UDP is made. The text in Appendix B describes the challenges with using TCP in some environments. In such environments, UDP would be typically be configured as the default.<= /blockquote>

I have added an informational note in Section 6, it reads as follows:<= /div>

     "Informational note: In practice products is = configured to try one

In practice, products are …

      transport initially and use the other one as a fa= llback.  Whether
      TCP or UDP is chosen as underlying transport depe= nds on type of
      product and the nature of the environment it is d= eployed, here the

deployed. Here …

      considerations in Appendix B is an important inpu= t."'

… Appendix B are important to consider.

 
>The second paragraph of Section 6.2 explains that the floor contro= l
>server is considered present and available upon receiving a HelloAck >message. We should also explain the circumstances in which the service<= br> >is considered to have become unavailable (e.g., ICMP messages or
>timeouts)

The ICMP behaviour is defined in 6.2.2. Also, the behaviour when = timers fire are described in Section 8.

are described -> is described

Cheers,
Charles


>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) a= re server-
>>    initiated transactions that require acknowledgement m= essages from the
>>    floor participant and chair entities to which they we= re sent.
>
>
>I do not think the term "transaction-completing" have been de= fined 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.

How about:
Concordantly, messages sent by the floor control server that initiate new transactions (e.g., FloorStatus announcements as part of a FloorQuery
subscription) require acknowledgement messages from the floor participant
and chair entities to which they were sent

A better explanation and we avoid introducing a term (transaction-comp= leting), that is not defined or even needed. 

>The 4th paragraph of Section 6.2 talks about the "Unable to p= arse"
>message in the context of unreliable transports. Why don't we use t= hat
>with TCP as well? Is it because of backward compatibility issues? If so= ,
>we should add a clarifying note.

RFC 4582 stated the following, "If a BFCP entity (a client or a floor<= br> control server) receives data from TCP that cannot be parsed, the entity MUST close the TCP connection, and the connection SHOULD be reestablished.&= quot;
As there is no concept of a connection with UDP, we decided to handle by defining the new error code.

Right. And there's no need for an explanation of that rationale in= the draft I assume.  

>The following sentence appears in the first paragraph of page 41:<= br> >
>>    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 FloorRequest= StatusAck
>>    message.
>
>Instead of "shall be", we should write "MUST be" if= this behavior has
>not been normatively defined anywhere else, or "is" if the be= havior has
>been normatively defined somewhere else.

The normative language for this situation is in section 10.1.3, "When<= br> communicating over an unreliable transport and upon receiving a
   FloorRequestStatus message from a floor control server, the    participant MUST respond with a FloorRequestStatusAck message = within
   the transaction failure window to complete the transaction.&qu= ot;
I think replacing "shall be" with "is" is fine.

Yes, fixed to avoid "confusion" as normative statements are = provided for this elsewhere.
 
>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 Good= bye message to
>>    dissociate itself from any allocated resources.  = ;If a floor control
>>    server wishes to end its BFCP connection with a clien= t (e.g., the
>>    Focus of the conference informs the floor control ser= ver that the
>>    client has been kicked out from the conference), it i= s 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<= br> >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<= br> >all this somewhere.

I cannot think of good reason for not sending a Goodbye. It may be that
the Goodbye fails, and I think there may be existing implementations that do not send the Goodbye, but from a protocol perspective MUST/REQUIRED
strength seems appropriate.

I agree. I'm not quite sure, but it might be that the SHOULD level= stems from earlier versions where Goodbye also was an option specified for= TCP in a common section. Will change to REQUIRED in that paragraph.

>The following paragraph appears in Section 6.2.3:
>
>>    When a BFCP implementation receives a BFCP message fr= agment, 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&qu= ot; above
>because it allows receivers to discard incomplete buffers.

I think it needs to read as follows, "When a BFCP implementation recei= ves
a BFCP message fragment, it MUST buffer the fragment until either it has received the entire BFCP message, or until the Response Retransmission
Timer expires."
There is also a "must" that should be changed to "MUST"= in the paragraph
describing the retransmission timer.

Yes, fixed accordingly.

-- Tom

--
# Cisco                   &nbs= p;     |  http://www.cisco.com/telepresence/
## tomkrist@cisco.c= om  |  = http://www.tandberg.com
###                     &= nbsp;         |  http://folk.uio.no/tomkri/



--
# Cisco &nbs= p;                     &n= bsp; |  http://www.cisco.com/telepresence/
## tomkrist@cisco.com  |  http://www.tandberg.com<= br> ###                     &= nbsp;         |  http://folk.uio.no/tomkri/
--047d7bdc8a0adfa4ca04f2661b48-- From nobody Fri Feb 14 15:36:32 2014 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 361471A04FF; Fri, 14 Feb 2014 15:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 At457lxD5Hfi; Fri, 14 Feb 2014 15:36:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A1A1A0109; Fri, 14 Feb 2014 15:36:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214233629.1461.21296.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:36:29 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/DAHOhi3enev4sHwtfGW3_r05auU Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-09.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:36:31 -0000 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 Authors : Gonzalo Camarillo Tom Kristensen Filename : draft-ietf-bfcpbis-rfc4583bis-09.txt Pages : 17 Date : 2014-02-14 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-rfc4583bis-09 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 nobody Fri Feb 14 15:37:25 2014 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 1A0B51A0109; Fri, 14 Feb 2014 15:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 wxCiS8vASYRv; Fri, 14 Feb 2014 15:37:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 665531A04F9; Fri, 14 Feb 2014 15:37:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214233719.16513.46043.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:37:19 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/PbgwZ5H474HMt1Iwixy-9XF7J4g Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-11.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:37:21 -0000 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) Authors : Gonzalo Camarillo Keith Drage Tom Kristensen Joerg Ott Charles Eckel Filename : draft-ietf-bfcpbis-rfc4582bis-11.txt Pages : 90 Date : 2014-02-14 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-rfc4582bis-11 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 nobody Sun Feb 16 01:16:12 2014 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 038CB1A03A7 for ; Sun, 16 Feb 2014 01:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.851 X-Spam-Level: X-Spam-Status: No, score=-103.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 n-sVQcu7bj1D for ; Sun, 16 Feb 2014 01:16:07 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7D61A013A for ; Sun, 16 Feb 2014 01:15:53 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-48-530081c019f0 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 32.69.23809.0C180035; Sun, 16 Feb 2014 10:15:45 +0100 (CET) Received: from [131.160.126.48] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.2.347.0; Sun, 16 Feb 2014 10:15:44 +0100 Message-ID: <530081BE.6060706@ericsson.com> Date: Sun, 16 Feb 2014 11:15:42 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Tom Kristensen <2mkristensen@gmail.com>, "Charles Eckel (eckelcu)" References: <20131104104454.10115.16900.idtracker@ietfa.amsl.com> <52777C07.1080403@cisco.com> <52934193.5050304@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+Jvje7BRoZgg9dnOCy2HH/HYvFv3VEm i02zvrBZXDnyi82BxWPK742sHjtn3WX3WLLkJ1MAcxSXTUpqTmZZapG+XQJXxqSlU1kK5kVW fGj7zdrAeM+yi5GTQ0LARKJ9ehszhC0mceHeerYuRi4OIYFDjBInD/9kh3DWMEo8WH6aDaSK V0BbYv3yHWAdLAKqEv3T17OC2GwCFhJbbt1nAbFFBaIkfl5ZwA5RLyhxcuYTsLiIQIzEygMN YDazQKxE19RjTCC2sIC7xJ9rrWC2kMA5Jome7dFdjBwcnAKBEg/nBIOYEgLiEj2NQRCdBhJH Fs1hhbDlJZq3zmaG6NSWWP6shWUCo9AsJItnIWmZhaRlASPzKkb23MTMnPRyo02MwDA+uOW3 6g7GO+dEDjFKc7AoifN+eOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGx+J3d5Wfn5Yt+ arxdPu0KO7OI5yujWSv4eL64NyfOlkgoLNnu1ODqWWQruqm3oDr63rvAowJPiyO+bdEqm1Dq rnTvetzuNO4cffsz6Ss5TJ34D27OfHxqpV798tC9NnoPT62U8fqZkL1pNVfg3va2pZ0O1n9P hufmd04sd5NhS91xY8PHZVOUWIozEg21mIuKEwFVy55QMQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/6YJHVWc4irElo0azecU8TTNh3MI Cc: "bfcpbis@ietf.org" , "Tom Kristensen \(tomkrist\)" 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: Sun, 16 Feb 2014 09:16:10 -0000 Thanks! Gonzalo On 15/02/2014 1:24 AM, Tom Kristensen wrote: > Thanks, a bit hasty there. Fixed now, time to submit just-in-time. > > -- Tom > > > On 14 February 2014 23:28, Charles Eckel (eckelcu) > wrote: > > Editorial nits inline in case you have not submitted yet. > > From: Tom Kristensen <2mkristensen@gmail.com > > > Date: Friday, February 14, 2014 1:38 PM > To: Charles Eckel > > Cc: Gonzalo Camarillo >, Tom Kristensen > >, "bfcpbis@ietf.org > " > > Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-10.txt > > On 14 January 2014 20:03, Charles Eckel (eckelcu) > > wrote: > > Hi Gonzalo, > > I was looking through the archives and did not see any > response to you > comments. Sorry for the delay. Please see inline. > > On 11/25/13 4:24 AM, "Gonzalo Camarillo" > > > wrote: > > >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. > > In practice I have typically seen this configured as either > use TCP first > and fallback to UDP or vice versa. Depending on the product and > environment, the choose of defaulting to TCP vs. UDP is > made. The text in > Appendix B describes the challenges with using TCP in some > environments. > In such environments, UDP would be typically be configured > as the default. > > > I have added an informational note in Section 6, it reads as > follows: > > "Informational note: In practice products is configured to > try one > > > In practice, products are … > > transport initially and use the other one as a fallback. > Whether > TCP or UDP is chosen as underlying transport depends on > type of > product and the nature of the environment it is deployed, > here the > > > deployed. Here … > > considerations in Appendix B is an important input."' > > > … Appendix B are important to consider. > > > > >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 ICMP behaviour is defined in 6.2.2. Also, the behaviour when > timers fire are described in Section 8. > > > are described -> is described > > Cheers, > Charles > > > >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. > > How about: > Concordantly, messages sent by the floor control server that > initiate new > transactions (e.g., FloorStatus announcements as part of a > FloorQuery > subscription) require acknowledgement messages from the > floor participant > and chair entities to which they were sent > > > A better explanation and we avoid introducing a term > (transaction-completing), that is not defined or even needed. > > >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. > > RFC 4582 stated the following, "If a BFCP entity (a client > or a floor > control server) receives data from TCP that cannot be > parsed, the entity > MUST close the TCP connection, and the connection SHOULD be > reestablished." > As there is no concept of a connection with UDP, we decided > to handle by > defining the new error code. > > > Right. And there's no need for an explanation of that rationale > in the draft I assume. > > >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 normative language for this situation is in section > 10.1.3, "When > communicating over an unreliable transport and upon receiving a > FloorRequestStatus message from a floor control server, the > participant MUST respond with a FloorRequestStatusAck > message within > the transaction failure window to complete the transaction." > I think replacing "shall be" with "is" is fine. > > > Yes, fixed to avoid "confusion" as normative statements are > provided for this elsewhere. > > > >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. > > I cannot think of good reason for not sending a Goodbye. It > may be that > the Goodbye fails, and I think there may be existing > implementations that > do not send the Goodbye, but from a protocol perspective > MUST/REQUIRED > strength seems appropriate. > > > I agree. I'm not quite sure, but it might be that the SHOULD > level stems from earlier versions where Goodbye also was an > option specified for TCP in a common section. Will change to > REQUIRED in that paragraph. > > >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. > > I think it needs to read as follows, "When a BFCP > implementation receives > a BFCP message fragment, it MUST buffer the fragment until > either it has > received the entire BFCP message, or until the Response > Retransmission > Timer expires." > There is also a "must" that should be changed to "MUST" in > the paragraph > describing the retransmission timer. > > > Yes, fixed accordingly. > > -- Tom > > -- > # Cisco | > http://www.cisco.com/telepresence/ > ## tomkrist@cisco.com | > http://www.tandberg.com > ### | http://folk.uio.no/tomkri/ > > > > > -- > # Cisco | http://www.cisco.com/telepresence/ > ## tomkrist@cisco.com | > http://www.tandberg.com > ### | http://folk.uio.no/tomkri/ From nobody Sun Feb 16 09:22:16 2014 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 C66D81A0105 for ; Sun, 16 Feb 2014 09:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 wwkSeOwBXLaQ for ; Sun, 16 Feb 2014 09:22:07 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5781A00F2 for ; Sun, 16 Feb 2014 09:22:06 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-86-5300f3ba060e Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 97.69.10875.AB3F0035; Sun, 16 Feb 2014 18:22:03 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Sun, 16 Feb 2014 18:22:02 +0100 From: Christer Holmberg To: Tom Kristensen <2mkristensen@gmail.com> Thread-Topic: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? Thread-Index: AQHPGCixVGWcSTqIKUqSD2pVAesatpq1AL6AgANFhsA= Date: Sun, 16 Feb 2014 17:22:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D193AE1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se> <52D7F766.8000402@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C642F14@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D10FE85@ESESSMB209.ericsson.se> <52DDCE70.1090707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D110ECA@ESESSMB209.ericsson.se> <52DE7FE6.3000203@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D193AE1ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM+Jvje7uzwzBBkfm8VhsOf6OxeLfuqNM Fis2HGC1uHLkF5sDi8ff9x+YPKb83sjqsXPWXXaPJUt+MgWwRHHZpKTmZJalFunbJXBlfP53 mb1g913GijevFzE1MPbtZexi5OSQEDCReLf4AAuELSZx4d56ti5GLg4hgUOMEi+vdzJCOEsY JX68+gSU4eBgE7CQ6P6nDdIgIqAtcfj0QWYQm1mgTOLPwS9gQ4UFMiSW/DsBVi4ikCnRMFkB otxK4uLy2awgNouAqsT0LQ/BbF4BX4mXJ69CrepikVi9fwsTSIJTIFDi0frNYMcxAh33/dQa Johd4hIfDl5nhjhaQGLJnvNQtqjEy8f/WCFsJYlFtz9D1edLLJ51jwVimaDEyZlPWCYwis5C MmoWkrJZSMog4noSN6ZOYYOwtSWWLXwNVa8rMePfIRZk8QWM7KsY2XMTM3PSyw03MQLj7+CW 37o7GE+dEznEKM3BoiTO++Gtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxvKjfUVHtLS7 N7jxHNH/Zq71auU99zsn06bl7MqyXMtYvaUh7/X/3dHTLl9t9Ld59/PF7PjP6m4bPc+Z7Gc9 n33h8QHZ64dap9cELr21zCfJgqvnwbSPKdYp1Vk/PquaFORKX5E/Unqi9rlv9+R7n9bf/Hk6 T6Ow9OaBup6fwge3i4SIsxsqBSmxFGckGmoxFxUnAgBfL1B3jQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/HAYhaiI3Sb7XXrLMDe03s07pFAY Cc: "bfcpbis@ietf.org" , Paul Kyzivat , Tom Kristensen Subject: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? 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: Sun, 16 Feb 2014 17:22:14 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D193AE1ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tom, You say that, if the TCP connection is lost, then the TLS client is respons= ible for re-establishing it. Isn't it the active TCP endpoint that is respo= nsible for re-establishing the TCP connection? Regards, Christer L=E4hett=E4j=E4: Tom Kristensen [mailto:2mkristensen@gmail.com] L=E4hetetty: 14. helmikuuta 2014 18:22 Vastaanottaja: Christer Holmberg Kopio: bfcpbis@ietf.org; Paul Kyzivat; Tom Kristensen Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes dow= n and is re-established? FYI. The text included in the next version will be (Section 7, 3rd and 4th = paragraphs): ---- Which party, the client or the floor control server, acts as the TLS/ DTLS server depends on how the underlying TLS/DTLS connection is established. For a TCP/TLS connection established using an SDP offer/answer exchange [7], the answerer (which may be the client or the floor control server) always acts as the TLS server. If the TCP connection is lost, the active endpoint, i.e., the current TLS client, is responsible for re-establishing the TCP connection. Unless a new TLS session is negotiated, subsequent SDP offers and answers will not impact the previously negotiated TLS roles. For a UDP/DTLS connection established using the an SDP offer/answer exchange, either party can be the DTLS server depending on the setup attributes exchanged; examples can be found in [22]. ---- I do hope that defines it correctly. -- Tom On 23 January 2014 11:48, Tom Kristensen <2mkristensen@gmail.com> wrote: Thanks Christer, not only did you discover the issue - you also provided th= e fix (and text for it). That solves what is currently missing in the draft= and in RFC 4582. I will add your text, or at least a very similar version, to the upcoming v= ersion of the draft. -- Tom On 21 January 2014 15:10, Paul Kyzivat > wrote: On 1/20/14 8:44 PM, Christer Holmberg wrote: Hi, Some initial text proposal: "If the TCP connection is lost, the "active" endpoint is responsible for re= -establishing the TCP connection. Unless a new TLS session is negotiated, subsequent SDP Offers and Answers w= ill not impact the previously negotiated TLS roles." Is the passive endpoint expected to listen for the connection attempt at al= l times, or when it has noticed that the old connection is lost, or only wh= en there has been a new O/A? (It is kind of a waste to maintain a listener whe= n you have an active connection and aren't expecting more. And it is asking for trouble, since you might get a new connection when you= think the old one is still functional.) If a TCP connection has been established, I think it is enough to listen fo= r the connection when it has noticed that the old connection is lost. I ass= ume both endpoints would detect that more or less at the same time, or? If a TCP connection has NOT been established, one would listen only when th= ere has been a O/A used to negotiate the TCP connection. WFM. I realize this is old stuff, but I'm surprised that it didn't follow comedi= a about all of this, including who is active. I am not sure I understand. Comedia IS used to indicate who is active. Howe= ver, comedia is NOT used to indicate who is TLS client/server. OK. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: bfcpbis [mailto:bfcpbis-bounces@ietf.org] Puolesta Christer Holmberg L=E4hetetty: 16. tammikuuta 2014 21:36 Vastaanottaja: Tom Kristensen Kopio: bfcpbis@ietf.org Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes dow= n and is re-established? Hi Tom, I realize the following comes late in the process, and I apologize if it has been discussed, but it is related to something which just has recently popped up in 3GPP, and it's not addressed in the draft. Not too late, since we are still not finished! Anyway, the TCP/TLS connection reuse is not altered while extending BFCP to support unreliable transport. Any fixes now must be backwards compatible in some way. That said and based on what I have seen from different vendors, most of them still use TCP (without TLS) :) So, at least if we are changing anything to solve these issues, we should add an informational note indicating this is a change where legacy, pure RFC 4582 implementations might differ in behaviour... I am not suggesting to change anything - I am suggesting to specify something which is currently unspecified :) By the way: How these issues was solved in 3GPP are along the lines of what= you propose below? We have had some discussions in 3GPP, and there are some text suggestions f= or the upcoming meeting next week. However, the discussions so far have been mostly about Q2. Q1 came up on a = mailing list just this week, and whill be discussed at the 3GPP meeting nex= t week. Section 7 says the following: "For a TCP/TLS connection established using an SDP offer/answer exchange [7], the answerer (which may be the client or the floor control server) always acts as the TLS server." Q1: Assume the TCP/TLS connection, for whatever reason, goes down. Now, I assume that whoever endpoint is "active" will most likely try to re-establish the TCP connection. But, if the "active" endpoint doesn't send an Offer (i.e. it simply tries to re-establish the TCP connection based on the previously negotiated SDP information), who will act as TLS server? There is no Answerer. One alternative would be to mandate the sending of an Offer when the TCP/TLS connection is re-established. Then it would be clear who is Offerer, and who is Answerer. Another alternative would be to say that whoever was previously Answerer will act as TLS server. I'm not too fond of yet another re-INVITE being mandated, so if we will fix this issue mandating the previous answerer to be the TLS server would be my preference. Assuming that, then my follow-up question is: When you say "previous answerer", do you refer to the answerer in the lates= t Offer/Answer transaction, OR the answerer in the last Offer/Answer transa= ction that established/re-established the TCP/TLS connection (those Offer/A= nswer transactions may, or may not, be the same). Q2: Assume there is an Offer/Answer transaction during the session. Now, the TCP/TLS connection is not affected by that, but the TLS roles may change (if whoever was Offerer in the previous O/A transaction is now A= nswerer). I think some wording would be needed about that also. One alternative is to say that the TLS roles may change, but that doesn't affect the TCP/TLS connection. A healthy TCP/TLS connection shouldn't be affected at all, should it? Correct. The question is whether such Offer/Answer can affect the TCP/TLS r= oles - even if the TCP/TLS connection itself if not affected. That could ha= ve impact on the case in Q1, where the TCP/TLC connection goes down, and it= needs to be determined who is TLS server. However, any potential connection re-establishment will need to monitor who was the last answerer to do the TLS initiation correctly. Hopefully I did understand the issue here, and added my 2 zlotys or pence or whatever, I think you did understand the issue :) Regards, Christer _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.co= m ### | http://folk.uio.no/tomkri/ -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.co= m ### | http://folk.uio.no/tomkri/ --_000_7594FB04B1934943A5C02806D1A2204B1D193AE1ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tom,

 = ;

You say th= at, if the TCP connection is lost, then the TLS client is responsible for re-es= tablishing it. Isn’t it the active TCP endpoint that is responsible for re-establishing the T= CP connection?

 = ;

Regards,

 = ;

Christer

 = ;

L=E4hett=E4j=E4: Tom Kristensen [mailto:2mkristensen@gmail.com]
L=E4hetetty: 14. helmikuuta 2014 18:22
Vastaanottaja: Christer Holmberg
Kopio: bfcpbis@ietf.org; Paul Kyzivat; Tom Kristensen
Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection g= oes down and is re-established?

 

FYI. The text included in the next version will be (= Section 7, 3rd and 4th paragraphs):

 

----

 Which party, the client or the floor control s= erver, acts as the TLS/

   DTLS server depends on how the underlyi= ng TLS/DTLS connection is

   established.  For a TCP/TLS connec= tion established using an SDP

   offer/answer exchange [7], the answerer= (which may be the client or

   the floor control server) always acts a= s the TLS server.  If the TCP

   connection is lost, the active endpoint= , i.e., the current TLS

   client, is responsible for re-establish= ing the TCP connection.

   Unless a new TLS session is negotiated,= subsequent SDP offers and

   answers will not impact the previously = negotiated TLS roles.

 

   For a UDP/DTLS connection established u= sing the an SDP offer/answer

   exchange, either party can be the DTLS = server depending on the setup

   attributes exchanged; examples can be f= ound in [22].

----

 

I do hope that defines it correctly.

 

-- Tom

 

 

On 23 January 2014 11:48, Tom Kristensen <2mkristensen@gmail.com= > wrote:

Thanks Christer, not only did you discover the issue= - you also provided the fix (and text for it). That solves what is current= ly missing in the draft and in RFC 4582.

 

I will add your text, or at least a very similar ver= sion, to the upcoming version of the draft.

 

-- Tom

 

On 21 January 2014 15:10, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 1/20/14 8:44 PM, Christer Holmberg wrote:

Hi,

Some initial text proposal:

"If the TCP connection is lost, the "active" endpoint is res= ponsible for re-establishing the TCP connection.

Unless a new TLS session is negotiated, subsequent SDP Offers and Answers w= ill not impact the previously negotiated TLS roles."


Is the passive endpoint expected to listen for the connection attempt at al= l times, or when it has noticed that the old connection is lost, or only wh= en
there has been a new O/A? (It is kind of a waste to maintain a listener whe= n you have an active connection and aren't expecting more.
And it is asking for trouble, since you might get a new connection when you= think the old one is still functional.)


If a TCP connection has been established, I think it is enough to listen fo= r the connection when it has noticed that the old connection is lost. I ass= ume both endpoints would detect that more or less at the same time, or?

If a TCP connection has NOT been established, one would listen only when th= ere has been a O/A used to negotiate the TCP connection.

 

WFM.

 

I realize this is old stuff, but I'm surprised that = it didn't follow comedia about all of this, including who is active.


I am not sure I understand. Comedia IS used to indicate who is active. Howe= ver, comedia is NOT used to indicate who is TLS client/server.

 

OK.

 

Regards,

Christer



-----Alkuper=E4inen v= iesti-----
L=E4hett=E4j=E4: bfcpbis [mailto:bfcpbis-bounces@ietf.org] Puolesta Christer
Holmberg
L=E4hetetty: 16. tammikuuta 2014 21:36
Vastaanottaja: Tom Kristensen
Kopio: bfcpbis@ietf.o= rg
Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes dow= n and is re-established?


Hi Tom,

I realize the following comes late in the process, a= nd I apologize
if it has been discussed, but it is related to something which just
has recently popped up in 3GPP, and it's not addressed in the draft.


Not too late, since we are still not finished! Anyway, the TCP/TLS
connection reuse is not altered while extending BFCP to support
unreliable transport. Any fixes now must be backwards compatible in
some way.

That said and based on what I have seen from different vendors, most
of them still use TCP (without TLS) :)

So, at least if we are changing anything to solve these issues, we
should add an informational note indicating this is a change where
legacy, pure RFC 4582 implementations might differ in behaviour...


I am not suggesting to change anything - I am suggesting to specify
something which is currently unspecified :)

By the way: How these issues was solved in 3GPP are = along the lines of what you propose below?


We have had some discussions in 3GPP, and there are some text suggestions f= or the upcoming meeting next week.

However, the discussions so far have been mostly about Q2. Q1 came up on a = mailing list just this week, and whill be discussed at the 3GPP meeting nex= t week.

Section 7 says the following:

"For a TCP/TLS connection established using an SDP

offer/answer exchange [7], the answerer (which may be the client or

the floor control server) always acts as the TLS server."

Q1:

Assume the TCP/TLS connection, for whatever reason, goes down.

Now, I assume that whoever endpoint is "active" will most likely = try
to re-establish the TCP connection.

But, if the "active" endpoint doesn't send an Offer (i.e. it simp= ly
tries to re-establish the TCP connection based on the previously
negotiated SDP information), who will act as TLS server? There is no
Answerer.

One alternative would be to mandate the sending of an Offer when the
TCP/TLS connection is re-established. Then it would be clear who is
Offerer, and who is Answerer.

Another alternative would be to say that whoever was previously
Answerer will act as TLS server.


I'm not too fond of yet another re-INVITE being mandated, so if we
will fix this issue mandating the previous answerer to be the TLS
server would be my preference.


Assuming that, then my follow-up question is:

When you say "previous answerer", do you refer to the answerer in= the latest Offer/Answer transaction, OR the answerer in the last Offer/Ans= wer transaction that established/re-established the TCP/TLS connection (tho= se Offer/Answer transactions may, or may not, be the same).

Q2:

Assume there is an Offer/Answer transaction during the session. Now,
the TCP/TLS connection is not affected by that, but the TLS roles
may change (if whoever was Offerer in the previous O/A transaction is now A= nswerer).

I think some wording would be needed about that also.

One alternative is to say that the TLS roles may change, but that
doesn't affect the TCP/TLS connection.


A healthy TCP/TLS connection shouldn't be affected at all, should it?<= /o:p>


Correct. The question is whether such Offer/Answer can affect the TCP/TLS r= oles - even if the TCP/TLS connection itself if not affected. That could ha= ve impact on the case in Q1, where the TCP/TLC connection goes down, and it= needs to be determined who is TLS server.

However, any potential connection re-establishment w= ill need to
monitor who was the last answerer to do the TLS initiation correctly.

Hopefully I did understand the issue here, and added my 2 zlotys or
pence or whatever,


I think you did understand the issue :)

Regards,

Christer

_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis
_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis


_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis


_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis



 

--
# Cisco             &n= bsp;           |  http://www.cisco.com/telepresence/
## tomkrist@cisco.com  |  http://www.tandberg.com
###              =                 |  http://folk.uio.no/tomkri/



 

--
# Cisco                   &nbs= p;     |  http://www.cisco.com/telepresence/
## tomkrist@cisco.c= om  |  = http://www.tandberg.com
###                     &= nbsp;         |  http://folk.uio.no/tomkri/

--_000_7594FB04B1934943A5C02806D1A2204B1D193AE1ESESSMB209erics_-- From nobody Tue Feb 18 16:34:01 2014 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 441E91A0423 for ; Tue, 18 Feb 2014 16:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ieOaCGZGRL3z for ; Tue, 18 Feb 2014 16:33:58 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id E59DE1A0013 for ; Tue, 18 Feb 2014 16:33:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=245; q=dns/txt; s=iport; t=1392770035; x=1393979635; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=jyQu7ZUQyQbYUjEt0jKeb2bThRQswpWNp0aediX38IQ=; b=fsiDVgQU/np3tfgWRLiWpKONCzbiNaGhZ9ecIFaNG7wGTTmhq3UEqvkl mCjWewOaqz+NAU/0Z1vYG4FSUoIJc/CdQ+JgXV9P5usEt/YSPPgO/lGyY 144782NOIvFJb/82GQ7m1K+bAqoZ7lpDN1NmhLux5i1NAIeotvvtE8L01 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAFb7A1OtJXG+/2dsb2JhbABZgwY4V8FjFnSCLDpRAT5CJwQch3wNm3mwTBeTIwSYMJIkgy2CKg X-IronPort-AV: E=Sophos;i="4.97,503,1389744000"; d="scan'208";a="21442396" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-7.cisco.com with ESMTP; 19 Feb 2014 00:33:54 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1J0XsZH002865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 19 Feb 2014 00:33:54 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 18:33:54 -0600 From: "Charles Eckel (eckelcu)" To: "bfcpbis@ietf.org" Thread-Topic: draft agenda for BFCPBIS session Thread-Index: AQHPLQpE9jGaFPQnWkSCiTeUuNDAeA== Date: Wed, 19 Feb 2014 00:33:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.74.217] Content-Type: text/plain; charset="us-ascii" Content-ID: <8136900B65C3B24EADB462D600BEA94D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/TcyPCPzm6rIw9IQsnojREpeDAJc Subject: [bfcpbis] draft agenda for BFCPBIS session 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: Wed, 19 Feb 2014 00:33:59 -0000 The draft agenda has been posted: http://www.ietf.org/proceedings/89/agenda/agenda-89-bfcpbis Please share any comments or concerns. For those with presentation slots, let me know if the time allocated is appropriate. Cheers, Charles From nobody Wed Feb 26 05:41:24 2014 Return-Path: <2mkristensen@gmail.com> 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 A0F571A030D for ; Wed, 26 Feb 2014 05:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001] autolearn=no 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 LSEmChBJWsUp for ; Wed, 26 Feb 2014 05:41:11 -0800 (PST) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id C49291A01E8 for ; Wed, 26 Feb 2014 05:41:10 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id o15so2261416qap.35 for ; Wed, 26 Feb 2014 05:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5+xlbr2SlmroITbbYwpXtP0bSOtKNb9Ex+4/fXBjwk0=; b=JF3oxlFgLt7TO1/Lx3lXBkvkd41ZaTwSvE5iWvV6Hs+MuWcwZu2Qkn2yRLoBKpR5BW GauQQEcrWJTCHsNbPoxKivOAXtBNG0lxIWKMlud+LkwiIO8XoIAp43hnbP8quMKHj+D2 tBHjD3aN40wcRGB6lZ5tLb+hZo7fA8dryDJdU7fnwnOTllYjl7eQXAaAXz5CHkYAZA8E WRMba2voiGEeALB0ibWRwi/iB+djIvNTui2sNTOGNWYNDad9bjwY55zlD477m7QWotFc 0N4KB2mv3t7a9dzZBA15vkx162uIE1yBE9HScNR2hjXGgp3Uw00Wk2TmLn9vciklKoKr OnEg== MIME-Version: 1.0 X-Received: by 10.224.165.133 with SMTP id i5mr7493997qay.75.1393422069424; Wed, 26 Feb 2014 05:41:09 -0800 (PST) Received: by 10.229.2.69 with HTTP; Wed, 26 Feb 2014 05:41:09 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D193AE1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se> <52D7F766.8000402@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C642F14@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D10FE85@ESESSMB209.ericsson.se> <52DDCE70.1090707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D110ECA@ESESSMB209.ericsson.se> <52DE7FE6.3000203@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D193AE1@ESESSMB209.ericsson.se> Date: Wed, 26 Feb 2014 14:41:09 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0149c6c07866ee04f34f5be5 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/4oh5q-ssAOa0o7wJqbs3YZwhFjA Cc: "bfcpbis@ietf.org" , Paul Kyzivat , Tom Kristensen Subject: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? 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: Wed, 26 Feb 2014 13:41:16 -0000 --089e0149c6c07866ee04f34f5be5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Right. An internal short-circuit there... I'll fix the wording as soon as the submission gate has opened, it is the active TCP endpoint that is responsible for re-establishing. And yes this is the TCP layer and should not rely on roles on the TLS level= . -- Tom On 16 February 2014 18:22, Christer Holmberg wrote: > Hi Tom, > > > > You say that, if the *TCP connection* is lost, then the TLS client is > responsible for re-establishing it. Isn't it the *active TCP endpoint*tha= t is responsible for re-establishing the *TCP > connection*? > > > > Regards, > > > > Christer > > > > *L=E4hett=E4j=E4:* Tom Kristensen [mailto:2mkristensen@gmail.com] > *L=E4hetetty:* 14. helmikuuta 2014 18:22 > *Vastaanottaja:* Christer Holmberg > *Kopio:* bfcpbis@ietf.org; Paul Kyzivat; Tom Kristensen > > *Aihe:* Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes > down and is re-established? > > > > FYI. The text included in the next version will be (Section 7, 3rd and 4t= h > paragraphs): > > > > ---- > > Which party, the client or the floor control server, acts as the TLS/ > > DTLS server depends on how the underlying TLS/DTLS connection is > > established. For a TCP/TLS connection established using an SDP > > offer/answer exchange [7], the answerer (which may be the client or > > the floor control server) always acts as the TLS server. If the TCP > > connection is lost, the active endpoint, i.e., the current TLS > > client, is responsible for re-establishing the TCP connection. > > Unless a new TLS session is negotiated, subsequent SDP offers and > > answers will not impact the previously negotiated TLS roles. > > > > For a UDP/DTLS connection established using the an SDP offer/answer > > exchange, either party can be the DTLS server depending on the setup > > attributes exchanged; examples can be found in [22]. > > ---- > > > > I do hope that defines it correctly. > > > > -- Tom > > > > > > On 23 January 2014 11:48, Tom Kristensen <2mkristensen@gmail.com> wrote: > > Thanks Christer, not only did you discover the issue - you also provided > the fix (and text for it). That solves what is currently missing in the > draft and in RFC 4582. > > > > I will add your text, or at least a very similar version, to the upcoming > version of the draft. > > > > -- Tom > > > > On 21 January 2014 15:10, Paul Kyzivat wrote: > > On 1/20/14 8:44 PM, Christer Holmberg wrote: > > Hi, > > Some initial text proposal: > > "If the TCP connection is lost, the "active" endpoint is responsible for > re-establishing the TCP connection. > > Unless a new TLS session is negotiated, subsequent SDP Offers and Answers > will not impact the previously negotiated TLS roles." > > > Is the passive endpoint expected to listen for the connection attempt at > all times, or when it has noticed that the old connection is lost, or onl= y > when > there has been a new O/A? (It is kind of a waste to maintain a listener > when you have an active connection and aren't expecting more. > And it is asking for trouble, since you might get a new connection when > you think the old one is still functional.) > > > If a TCP connection has been established, I think it is enough to listen > for the connection when it has noticed that the old connection is lost. I > assume both endpoints would detect that more or less at the same time, or= ? > > If a TCP connection has NOT been established, one would listen only when > there has been a O/A used to negotiate the TCP connection. > > > > WFM. > > > > I realize this is old stuff, but I'm surprised that it didn't follow > comedia about all of this, including who is active. > > > I am not sure I understand. Comedia IS used to indicate who is active. > However, comedia is NOT used to indicate who is TLS client/server. > > > > OK. > > > > Regards, > > Christer > > > > -----Alkuper=E4inen viesti----- > L=E4hett=E4j=E4: bfcpbis [mailto:bfcpbis-bounces@ietf.org] Puolesta Chris= ter > Holmberg > L=E4hetetty: 16. tammikuuta 2014 21:36 > Vastaanottaja: Tom Kristensen > Kopio: bfcpbis@ietf.org > Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes > down and is re-established? > > > Hi Tom, > > I realize the following comes late in the process, and I apologize > if it has been discussed, but it is related to something which just > has recently popped up in 3GPP, and it's not addressed in the draft. > > > Not too late, since we are still not finished! Anyway, the TCP/TLS > connection reuse is not altered while extending BFCP to support > unreliable transport. Any fixes now must be backwards compatible in > some way. > > That said and based on what I have seen from different vendors, most > of them still use TCP (without TLS) :) > > So, at least if we are changing anything to solve these issues, we > should add an informational note indicating this is a change where > legacy, pure RFC 4582 implementations might differ in behaviour... > > > I am not suggesting to change anything - I am suggesting to specify > something which is currently unspecified :) > > By the way: How these issues was solved in 3GPP are along the lines of > what you propose below? > > > We have had some discussions in 3GPP, and there are some text suggestions > for the upcoming meeting next week. > > However, the discussions so far have been mostly about Q2. Q1 came up on = a > mailing list just this week, and whill be discussed at the 3GPP meeting > next week. > > Section 7 says the following: > > "For a TCP/TLS connection established using an SDP > > offer/answer exchange [7], the answerer (which may be the client or > > the floor control server) always acts as the TLS server." > > Q1: > > Assume the TCP/TLS connection, for whatever reason, goes down. > > Now, I assume that whoever endpoint is "active" will most likely try > to re-establish the TCP connection. > > But, if the "active" endpoint doesn't send an Offer (i.e. it simply > tries to re-establish the TCP connection based on the previously > negotiated SDP information), who will act as TLS server? There is no > Answerer. > > One alternative would be to mandate the sending of an Offer when the > TCP/TLS connection is re-established. Then it would be clear who is > Offerer, and who is Answerer. > > Another alternative would be to say that whoever was previously > Answerer will act as TLS server. > > > I'm not too fond of yet another re-INVITE being mandated, so if we > will fix this issue mandating the previous answerer to be the TLS > server would be my preference. > > > Assuming that, then my follow-up question is: > > When you say "previous answerer", do you refer to the answerer in the > latest Offer/Answer transaction, OR the answerer in the last Offer/Answer > transaction that established/re-established the TCP/TLS connection (those > Offer/Answer transactions may, or may not, be the same). > > Q2: > > Assume there is an Offer/Answer transaction during the session. Now, > the TCP/TLS connection is not affected by that, but the TLS roles > may change (if whoever was Offerer in the previous O/A transaction is now > Answerer). > > I think some wording would be needed about that also. > > One alternative is to say that the TLS roles may change, but that > doesn't affect the TCP/TLS connection. > > > A healthy TCP/TLS connection shouldn't be affected at all, should it? > > > Correct. The question is whether such Offer/Answer can affect the TCP/TLS > roles - even if the TCP/TLS connection itself if not affected. That could > have impact on the case in Q1, where the TCP/TLC connection goes down, an= d > it needs to be determined who is TLS server. > > However, any potential connection re-establishment will need to > monitor who was the last answerer to do the TLS initiation correctly. > > Hopefully I did understand the issue here, and added my 2 zlotys or > pence or whatever, > > > I think you did understand the issue :) > > Regards, > > Christer > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > > > > > > -- > # Cisco | http://www.cisco.com/telepresence/ > ## tomkrist@cisco.com | http://www.tandberg.com > ### | http://folk.uio.no/tomkri/ > > > > > > -- > # Cisco | http://www.cisco.com/telepresence/ > ## tomkrist@cisco.com | http://www.tandberg.com > ### | http://folk.uio.no/tomkri/ > --=20 # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --089e0149c6c07866ee04f34f5be5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Right. An internal short-circuit there...
I'= ll fix the wording as soon as the submission gate has opened, it is the act= ive TCP endpoint that is responsible for re-establishing. 

And yes this is the TCP layer and should not rely on r= oles on the TLS level.

-- Tom


On 16 Febr= uary 2014 18:22, Christer Holmberg <christer.holmberg@ericsso= n.com> wrote:

Hi Tom,=

&nb= sp;

You say th= at, if the TCP connection is lost, then the TLS client is responsible for re-es= tablishing it. Isn’t it the active TCP endpoint that is responsible for re-establishing the T= CP connection?

&nb= sp;

Regards,

&nb= sp;

Christer

&nb= sp;

L=E4hett=E4j=E4: Tom Kristensen [mailto:2mkristensen@gmail.com]
L=E4hetetty: 14. helmikuuta 2014 18:22
Vastaanottaja: Christer Holmberg
Kopio: bfcpbis= @ietf.org; Paul Kyzivat; Tom Kristensen


Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection g= oes down and is re-established?

 

FYI. The text included in the next version will be (= Section 7, 3rd and 4th paragraphs):

 

----

 Which party, the client or the floor control s= erver, acts as the TLS/

   DTLS server depends on how the underlyi= ng TLS/DTLS connection is

   established.  For a TCP/TLS connec= tion established using an SDP

   offer/answer exchange [7], the answerer= (which may be the client or

   the floor control server) always acts a= s the TLS server.  If the TCP

   connection is lost, the active endpoint= , i.e., the current TLS

   client, is responsible for re-establish= ing the TCP connection.

   Unless a new TLS session is negotiated,= subsequent SDP offers and

   answers will not impact the previously = negotiated TLS roles.

 

   For a UDP/DTLS connection established u= sing the an SDP offer/answer

   exchange, either party can be the DTLS = server depending on the setup

   attributes exchanged; examples can be f= ound in [22].

----

 

I do hope that defines it correctly.

 

-- Tom

 

 <= /p>

On 23 January 2014 11:48, Tom Kristensen <2mkristensen@gmail.com= > wrote:

Thanks Christer, not only did you discover the issue= - you also provided the fix (and text for it). That solves what is current= ly missing in the draft and in RFC 4582.

 

I will add your text, or at least a very similar ver= sion, to the upcoming version of the draft.

 

-- Tom

 <= /p>

On 21 January 2014 15:10, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 1/20/14 8:44 PM, Christer Holmberg wrote:<= u>

Hi,

Some initial text proposal:

"If the TCP connection is lost, the "active" endpoint is res= ponsible for re-establishing the TCP connection.

Unless a new TLS session is negotiated, subsequent SDP Offers and Answers w= ill not impact the previously negotiated TLS roles."


Is the passive endpoint expected to listen for the connection attempt at al= l times, or when it has noticed that the old connection is lost, or only wh= en
there has been a new O/A? (It is kind of a waste to maintain a listener whe= n you have an active connection and aren't expecting more.
And it is asking for trouble, since you might get a new connection when you= think the old one is still functional.)


If a TCP connection has been established, I think it is enough to listen fo= r the connection when it has noticed that the old connection is lost. I ass= ume both endpoints would detect that more or less at the same time, or?

If a TCP connection has NOT been established, one would listen only when th= ere has been a O/A used to negotiate the TCP connection.

 

WFM.

 <= /p>

I realize this is old stuff, but I'm surprised t= hat it didn't follow comedia about all of this, including who is active= .


I am not sure I understand. Comedia IS used to indicate who is active. Howe= ver, comedia is NOT used to indicate who is TLS client/server.

 

OK.

 <= /p>

Regards,

Christer



-----Alkuper=E4inen v= iesti-----
L=E4hett=E4j=E4: bfcpbis [mailto:bfcpbis-bounces@ietf.org] Puolesta Christer
Holmberg
L=E4hetetty: 16. tammikuuta 2014 21:36
Vastaanottaja: Tom Kristensen
Kopio: bfcpbis@ietf.o= rg
Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes dow= n and is re-established?


Hi Tom,

I realize the following comes late in the process, a= nd I apologize
if it has been discussed, but it is related to something which just
has recently popped up in 3GPP, and it's not addressed in the draft.=


Not too late, since we are still not finished! Anyway, the TCP/TLS
connection reuse is not altered while extending BFCP to support
unreliable transport. Any fixes now must be backwards compatible in
some way.

That said and based on what I have seen from different vendors, most
of them still use TCP (without TLS) :)

So, at least if we are changing anything to solve these issues, we
should add an informational note indicating this is a change where
legacy, pure RFC 4582 implementations might differ in behaviour...


I am not suggesting to change anything - I am suggesting to specify
something which is currently unspecified :)

By the way: How these issues was solved in 3GPP are = along the lines of what you propose below?


We have had some discussions in 3GPP, and there are some text suggestions f= or the upcoming meeting next week.

However, the discussions so far have been mostly about Q2. Q1 came up on a = mailing list just this week, and whill be discussed at the 3GPP meeting nex= t week.

Section 7 says the following:

"For a TCP/TLS connection established using an SDP

offer/answer exchange [7], the answerer (which may be the client or

the floor control server) always acts as the TLS server."

Q1:

Assume the TCP/TLS connection, for whatever reason, goes down.

Now, I assume that whoever endpoint is "active" will most likely = try
to re-establish the TCP connection.

But, if the "active" endpoint doesn't send an Offer (i.e. it = simply
tries to re-establish the TCP connection based on the previously
negotiated SDP information), who will act as TLS server? There is no
Answerer.

One alternative would be to mandate the sending of an Offer when the
TCP/TLS connection is re-established. Then it would be clear who is
Offerer, and who is Answerer.

Another alternative would be to say that whoever was previously
Answerer will act as TLS server.


I'm not too fond of yet another re-INVITE being mandated, so if we
will fix this issue mandating the previous answerer to be the TLS
server would be my preference.


Assuming that, then my follow-up question is:

When you say "previous answerer", do you refer to the answerer in= the latest Offer/Answer transaction, OR the answerer in the last Offer/Ans= wer transaction that established/re-established the TCP/TLS connection (tho= se Offer/Answer transactions may, or may not, be the same).

Q2:

Assume there is an Offer/Answer transaction during the session. Now,
the TCP/TLS connection is not affected by that, but the TLS roles
may change (if whoever was Offerer in the previous O/A transaction is now A= nswerer).

I think some wording would be needed about that also.

One alternative is to say that the TLS roles may change, but that
doesn't affect the TCP/TLS connection.


A healthy TCP/TLS connection shouldn't be affected at all, should it?


Correct. The question is whether such Offer/Answer can affect the TCP/TLS r= oles - even if the TCP/TLS connection itself if not affected. That could ha= ve impact on the case in Q1, where the TCP/TLC connection goes down, and it= needs to be determined who is TLS server.

However, any potential connection re-establishment w= ill need to
monitor who was the last answerer to do the TLS initiation correctly.

Hopefully I did understand the issue here, and added my 2 zlotys or
pence or whatever,


I think you did understand the issue :)

Regards,

Christer

_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis
_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis


_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis


_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis



 

--
# Cisco                  = ;       |  http://www.cisco.com/telepresence/
## tomkrist@c= isco.com  |  http://www.tandberg.com
###                   &n= bsp;           |  http://folk.uio.no/tomkri/



 

--
# Cisco                   &nbs= p;     |  http://www.cisco.com/telepresence/
## tomkrist@cisco.c= om  |  = http://www.tandberg.com
###                     &= nbsp;         |  http://folk.uio.no/tomkri/




--
# Cisco &nbs= p;                     &n= bsp; |  http://www.cisco.com/telepresence/
## tomkrist@cisco.com  |  http://www.tandberg.com<= br> ###                     &= nbsp;         |  http://folk.uio.no/tomkri/
--089e0149c6c07866ee04f34f5be5-- From nobody Wed Feb 26 09:17:51 2014 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 09D021A070D for ; Wed, 26 Feb 2014 09:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] 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 wosE_A6qs7yX for ; Wed, 26 Feb 2014 09:17:29 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id C68361A06FD for ; Wed, 26 Feb 2014 09:17:24 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1QHHFGq009290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 11:17:17 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1QHHEvq010017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 18:17:14 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 26 Feb 2014 18:17:14 +0100 From: "DRAGE, Keith (Keith)" To: Tom Kristensen <2mkristensen@gmail.com>, Christer Holmberg Thread-Topic: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? Thread-Index: Ac8R+ZA84xutttU1TFChlBiOsCWPngAy768AAAq9+j4FrDUvOwJV1nFUAASTZAA= Date: Wed, 26 Feb 2014 17:17:13 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B13A243@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se> <52D7F766.8000402@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C642F14@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D10FE85@ESESSMB209.ericsson.se> <52DDCE70.1090707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D110ECA@ESESSMB209.ericsson.se> <52DE7FE6.3000203@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D193AE1@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B13A243FR712WXCHMBA11zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/qWi2aV9yS_5QUCtgjC56z0c0kbQ Cc: "bfcpbis@ietf.org" , Paul Kyzivat , Tom Kristensen Subject: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established? 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: Wed, 26 Feb 2014 17:17:39 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B13A243FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (As WG cochair) I would rather not have a new draft on the table immediately before the fac= e to face meeting. I would suggest you briefly list it in the identified changes in your prese= ntation to the WG, and then produce the new draft immediately following the= face to face meeting. Keith ________________________________ From: bfcpbis [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Tom Kristensen Sent: 26 February 2014 13:41 To: Christer Holmberg Cc: bfcpbis@ietf.org; Paul Kyzivat; Tom Kristensen Subject: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes = down and is re-established? Right. An internal short-circuit there... I'll fix the wording as soon as the submission gate has opened, it is the a= ctive TCP endpoint that is responsible for re-establishing. And yes this is the TCP layer and should not rely on roles on the TLS level= . -- Tom On 16 February 2014 18:22, Christer Holmberg > wrote: Hi Tom, You say that, if the TCP connection is lost, then the TLS client is respons= ible for re-establishing it. Isn't it the active TCP endpoint that is respo= nsible for re-establishing the TCP connection? Regards, Christer L=E4hett=E4j=E4: Tom Kristensen [mailto:2mkristensen@gmail.com] L=E4hetetty: 14. helmikuuta 2014 18:22 Vastaanottaja: Christer Holmberg Kopio: bfcpbis@ietf.org; Paul Kyzivat; Tom Kristen= sen Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes dow= n and is re-established? FYI. The text included in the next version will be (Section 7, 3rd and 4th = paragraphs): ---- Which party, the client or the floor control server, acts as the TLS/ DTLS server depends on how the underlying TLS/DTLS connection is established. For a TCP/TLS connection established using an SDP offer/answer exchange [7], the answerer (which may be the client or the floor control server) always acts as the TLS server. If the TCP connection is lost, the active endpoint, i.e., the current TLS client, is responsible for re-establishing the TCP connection. Unless a new TLS session is negotiated, subsequent SDP offers and answers will not impact the previously negotiated TLS roles. For a UDP/DTLS connection established using the an SDP offer/answer exchange, either party can be the DTLS server depending on the setup attributes exchanged; examples can be found in [22]. ---- I do hope that defines it correctly. -- Tom On 23 January 2014 11:48, Tom Kristensen <2mkristensen@gmail.com> wrote: Thanks Christer, not only did you discover the issue - you also provided th= e fix (and text for it). That solves what is currently missing in the draft= and in RFC 4582. I will add your text, or at least a very similar version, to the upcoming v= ersion of the draft. -- Tom On 21 January 2014 15:10, Paul Kyzivat > wrote: On 1/20/14 8:44 PM, Christer Holmberg wrote: Hi, Some initial text proposal: "If the TCP connection is lost, the "active" endpoint is responsible for re= -establishing the TCP connection. Unless a new TLS session is negotiated, subsequent SDP Offers and Answers w= ill not impact the previously negotiated TLS roles." Is the passive endpoint expected to listen for the connection attempt at al= l times, or when it has noticed that the old connection is lost, or only wh= en there has been a new O/A? (It is kind of a waste to maintain a listener whe= n you have an active connection and aren't expecting more. And it is asking for trouble, since you might get a new connection when you= think the old one is still functional.) If a TCP connection has been established, I think it is enough to listen fo= r the connection when it has noticed that the old connection is lost. I ass= ume both endpoints would detect that more or less at the same time, or? If a TCP connection has NOT been established, one would listen only when th= ere has been a O/A used to negotiate the TCP connection. WFM. I realize this is old stuff, but I'm surprised that it didn't follow comedi= a about all of this, including who is active. I am not sure I understand. Comedia IS used to indicate who is active. Howe= ver, comedia is NOT used to indicate who is TLS client/server. OK. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: bfcpbis [mailto:bfcpbis-bounces@ietf.org] Puolesta Christer Holmberg L=E4hetetty: 16. tammikuuta 2014 21:36 Vastaanottaja: Tom Kristensen Kopio: bfcpbis@ietf.org Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes dow= n and is re-established? Hi Tom, I realize the following comes late in the process, and I apologize if it has been discussed, but it is related to something which just has recently popped up in 3GPP, and it's not addressed in the draft. Not too late, since we are still not finished! Anyway, the TCP/TLS connection reuse is not altered while extending BFCP to support unreliable transport. Any fixes now must be backwards compatible in some way. That said and based on what I have seen from different vendors, most of them still use TCP (without TLS) :) So, at least if we are changing anything to solve these issues, we should add an informational note indicating this is a change where legacy, pure RFC 4582 implementations might differ in behaviour... I am not suggesting to change anything - I am suggesting to specify something which is currently unspecified :) By the way: How these issues was solved in 3GPP are along the lines of what= you propose below? We have had some discussions in 3GPP, and there are some text suggestions f= or the upcoming meeting next week. However, the discussions so far have been mostly about Q2. Q1 came up on a = mailing list just this week, and whill be discussed at the 3GPP meeting nex= t week. Section 7 says the following: "For a TCP/TLS connection established using an SDP offer/answer exchange [7], the answerer (which may be the client or the floor control server) always acts as the TLS server." Q1: Assume the TCP/TLS connection, for whatever reason, goes down. Now, I assume that whoever endpoint is "active" will most likely try to re-establish the TCP connection. But, if the "active" endpoint doesn't send an Offer (i.e. it simply tries to re-establish the TCP connection based on the previously negotiated SDP information), who will act as TLS server? There is no Answerer. One alternative would be to mandate the sending of an Offer when the TCP/TLS connection is re-established. Then it would be clear who is Offerer, and who is Answerer. Another alternative would be to say that whoever was previously Answerer will act as TLS server. I'm not too fond of yet another re-INVITE being mandated, so if we will fix this issue mandating the previous answerer to be the TLS server would be my preference. Assuming that, then my follow-up question is: When you say "previous answerer", do you refer to the answerer in the lates= t Offer/Answer transaction, OR the answerer in the last Offer/Answer transa= ction that established/re-established the TCP/TLS connection (those Offer/A= nswer transactions may, or may not, be the same). Q2: Assume there is an Offer/Answer transaction during the session. Now, the TCP/TLS connection is not affected by that, but the TLS roles may change (if whoever was Offerer in the previous O/A transaction is now A= nswerer). I think some wording would be needed about that also. One alternative is to say that the TLS roles may change, but that doesn't affect the TCP/TLS connection. A healthy TCP/TLS connection shouldn't be affected at all, should it? Correct. The question is whether such Offer/Answer can affect the TCP/TLS r= oles - even if the TCP/TLS connection itself if not affected. That could ha= ve impact on the case in Q1, where the TCP/TLC connection goes down, and it= needs to be determined who is TLS server. However, any potential connection re-establishment will need to monitor who was the last answerer to do the TLS initiation correctly. Hopefully I did understand the issue here, and added my 2 zlotys or pence or whatever, I think you did understand the issue :) Regards, Christer _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.co= m ### | http://folk.uio.no/tomkri/ -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.co= m ### | http://folk.uio.no/tomkri/ -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.co= m ### | http://folk.uio.no/tomkri/ --_000_949EF20990823C4C85C18D59AA11AD8B13A243FR712WXCHMBA11zeu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
(As WG cochair)
 
I would rather not have a new dra= ft on the table immediately before the face to face meeting.<= /div>
 
I would suggest you briefly list = it in the identified changes in your presentation to the WG, and then produ= ce the new draft immediately following the face to face meeting.
 
Keith

From: bfcpbis [mailto:bfcpbis-bounc= es@ietf.org] On Behalf Of Tom Kristensen
Sent: 26 February 2014 13:41
To: Christer Holmberg
Cc: bfcpbis@ietf.org; Paul Kyzivat; Tom Kristensen
Subject: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connectio= n goes down and is re-established?

Right. An internal short-circuit there...
I'll fix the wording as soon as the submission gate has opened, it is = the active TCP endpoint that is responsible for re-establishing. 

And yes this is the TCP layer and should not rely on roles on the TLS = level.

-- Tom


On 16 February 2014 18:22, Christer Holmberg <chr= ister.holmberg@ericsson.com> wrote:

Hi Tom,

 =

You say that, if the TCP connection is lost, then the TLS client is responsible for re-es= tablishing it. Isn’t it the active TCP endpoint that is responsible for re-establishing the T= CP connection?

 =

Regards,

 =

Christer

 =

L=E4hett=E4j=E4: Tom Kristensen [mailto:2mkristensen@gmail.com]
L=E4hetetty: 14. helmikuuta 2014 18:22
Vastaanottaja: Christer Holmberg
Kopio: bfcpbis= @ietf.org; Paul Kyzivat; Tom Kristensen


Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection g= oes down and is re-established?

 

FYI. The text included in the next version will be (= Section 7, 3rd and 4th paragraphs):

 

----

 Which party, the client or the floor control s= erver, acts as the TLS/

   DTLS server depends on how the underlyi= ng TLS/DTLS connection is

   established.  For a TCP/TLS connec= tion established using an SDP

   offer/answer exchange [7], the answerer= (which may be the client or

   the floor control server) always acts a= s the TLS server.  If the TCP

   connection is lost, the active endpoint= , i.e., the current TLS

   client, is responsible for re-establish= ing the TCP connection.

   Unless a new TLS session is negotiated,= subsequent SDP offers and

   answers will not impact the previously = negotiated TLS roles.

 

   For a UDP/DTLS connection established u= sing the an SDP offer/answer

   exchange, either party can be the DTLS = server depending on the setup

   attributes exchanged; examples can be f= ound in [22].

----

 

I do hope that defines it correctly.

 

-- Tom

 

 

On 23 January 2014 11:48, Tom Kristensen <2mkristensen@gmail.com= > wrote:

Thanks Christer, not only did you discover the issue= - you also provided the fix (and text for it). That solves what is current= ly missing in the draft and in RFC 4582.

 

I will add your text, or at least a very similar ver= sion, to the upcoming version of the draft.

 

-- Tom

 

On 21 January 2014 15:10, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 1/20/14 8:44 PM, Christer Holmberg wrote:<= u>

Hi,

Some initial text proposal:

"If the TCP connection is lost, the "active" endpoint is res= ponsible for re-establishing the TCP connection.

Unless a new TLS session is negotiated, subsequent SDP Offers and Answers w= ill not impact the previously negotiated TLS roles."


Is the passive endpoint expected to listen for the connection attempt at al= l times, or when it has noticed that the old connection is lost, or only wh= en
there has been a new O/A? (It is kind of a waste to maintain a listener whe= n you have an active connection and aren't expecting more.
And it is asking for trouble, since you might get a new connection when you= think the old one is still functional.)


If a TCP connection has been established, I think it is enough to listen fo= r the connection when it has noticed that the old connection is lost. I ass= ume both endpoints would detect that more or less at the same time, or?

If a TCP connection has NOT been established, one would listen only when th= ere has been a O/A used to negotiate the TCP connection.

 

WFM.

 

I realize this is old stuff, but I'm surprised that = it didn't follow comedia about all of this, including who is active.=


I am not sure I understand. Comedia IS used to indicate who is active. Howe= ver, comedia is NOT used to indicate who is TLS client/server.

 

OK.

 

Regards,

Christer



-----Alkuper=E4inen vi= esti-----
L=E4hett=E4j=E4: bfcpbis [mailto:bfcpbis-bounces@ietf.org] Puolesta Christer
Holmberg
L=E4hetetty: 16. tammikuuta 2014 21:36
Vastaanottaja: Tom Kristensen
Kopio: bfcpbis@ietf.o= rg
Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes dow= n and is re-established?


Hi Tom,

I realize the following comes late in the process, a= nd I apologize
if it has been discussed, but it is related to something which just
has recently popped up in 3GPP, and it's not addressed in the draft.=


Not too late, since we are still not finished! Anyway, the TCP/TLS
connection reuse is not altered while extending BFCP to support
unreliable transport. Any fixes now must be backwards compatible in
some way.

That said and based on what I have seen from different vendors, most
of them still use TCP (without TLS) :)

So, at least if we are changing anything to solve these issues, we
should add an informational note indicating this is a change where
legacy, pure RFC 4582 implementations might differ in behaviour...


I am not suggesting to change anything - I am suggesting to specify
something which is currently unspecified :)

By the way: How these issues was solved in 3GPP are = along the lines of what you propose below?


We have had some discussions in 3GPP, and there are some text suggestions f= or the upcoming meeting next week.

However, the discussions so far have been mostly about Q2. Q1 came up on a = mailing list just this week, and whill be discussed at the 3GPP meeting nex= t week.

Section 7 says the following:

"For a TCP/TLS connection established using an SDP

offer/answer exchange [7], the answerer (which may be the client or

the floor control server) always acts as the TLS server."

Q1:

Assume the TCP/TLS connection, for whatever reason, goes down.

Now, I assume that whoever endpoint is "active" will most likely = try
to re-establish the TCP connection.

But, if the "active" endpoint doesn't send an Offer (i.e. it simp= ly
tries to re-establish the TCP connection based on the previously
negotiated SDP information), who will act as TLS server? There is no
Answerer.

One alternative would be to mandate the sending of an Offer when the
TCP/TLS connection is re-established. Then it would be clear who is
Offerer, and who is Answerer.

Another alternative would be to say that whoever was previously
Answerer will act as TLS server.


I'm not too fond of yet another re-INVITE being mandated, so if we
will fix this issue mandating the previous answerer to be the TLS
server would be my preference.


Assuming that, then my follow-up question is:

When you say "previous answerer", do you refer to the answerer in= the latest Offer/Answer transaction, OR the answerer in the last Offer/Ans= wer transaction that established/re-established the TCP/TLS connection (tho= se Offer/Answer transactions may, or may not, be the same).

Q2:

Assume there is an Offer/Answer transaction during the session. Now,
the TCP/TLS connection is not affected by that, but the TLS roles
may change (if whoever was Offerer in the previous O/A transaction is now A= nswerer).

I think some wording would be needed about that also.

One alternative is to say that the TLS roles may change, but that
doesn't affect the TCP/TLS connection.


A healthy TCP/TLS connection shouldn't be affected at all, should it?


Correct. The question is whether such Offer/Answer can affect the TCP/TLS r= oles - even if the TCP/TLS connection itself if not affected. That could ha= ve impact on the case in Q1, where the TCP/TLC connection goes down, and it= needs to be determined who is TLS server.

However, any potential connection re-establishment w= ill need to
monitor who was the last answerer to do the TLS initiation correctly.

Hopefully I did understand the issue here, and added my 2 zlotys or
pence or whatever,


I think you did understand the issue :)

Regards,

Christer

_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis
_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis


_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis


_______________________________________________
bfcpbis mailing list
bfcpbis@ietf.org<= br> https://www.ietf.org/mailman/listinfo/bfcpbis



 

--
# Cisco                  = ;       |  http://www.cisco.com/telepresence/
## tomkrist@c= isco.com  |  http://www.tandberg.com
###                   &n= bsp;           |  http://folk.uio.no/tomkri/



 

--
# Cisco                   &nbs= p;     |  http://www.cisco.com/telepresence/
## tomkrist@cisco.c= om  |  = http://www.tandberg.com
###                     &= nbsp;         |  http://folk.uio.no/tomkri/




--
# Cisco                   &nbs= p;     |  http://www.cisco.com/telepresence/
## tomkrist@cisco.c= om  |  = http://www.tandberg.com
###                     &= nbsp;         |  http://folk.uio.no/tomkri/
--_000_949EF20990823C4C85C18D59AA11AD8B13A243FR712WXCHMBA11zeu_-- From nobody Thu Feb 27 10:54:54 2014 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 7DC641A005B for ; Thu, 27 Feb 2014 10:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 hNnYXpU4VDOR for ; Thu, 27 Feb 2014 10:54:52 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E88B61A014F for ; Thu, 27 Feb 2014 10:54:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=580; q=dns/txt; s=iport; t=1393527290; x=1394736890; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ZrYggvIYSfuCNmI8hkSt1fzjzbJIA9NwTzDdzEB9fhI=; b=VB5+UGKavuKrex2JB6SVJiu1IaaMNB9YeSeq3g5Kq61tYUosK23/pmfy pAfvPn3m75mmUXNGlNbJ6sq1CGduHlIMYEags+IuokW0+1RsLjqY8ze/q bbPn7gZo5x1amVg1+h54fYSRfcGvAcMecSxISSFgCpW0nJo6aFHK0U0VL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFALKID1OtJV2d/2dsb2JhbABagwY7V8ELgR0WdIImAQEEOk8CAQg2EDIlAgQTCYdvAQ3LDReOXIQ3BJg4kiqDLYIq X-IronPort-AV: E=Sophos;i="4.97,556,1389744000"; d="scan'208";a="306805671" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 27 Feb 2014 18:54:50 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1RIso1S015340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 27 Feb 2014 18:54:50 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Thu, 27 Feb 2014 12:54:50 -0600 From: "Charles Eckel (eckelcu)" To: "bfcpbis@ietf.org" Thread-Topic: draft agenda for BFCPBIS session Thread-Index: AQHPLQpE9jGaFPQnWkSCiTeUuNDAeJrJXyuA Date: Thu, 27 Feb 2014 18:54:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [171.68.20.21] Content-Type: text/plain; charset="us-ascii" Content-ID: <3C9B80EF10FFDE4B83C561A59F31D359@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/Tb2E9_UTD3ouvUf9YW0biOgFcEI Subject: Re: [bfcpbis] draft agenda for BFCPBIS session 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: Thu, 27 Feb 2014 18:54:53 -0000 Just a reminder that the BFCPBIS session is Tuesday. A link to the agenda is provided below. For those of you presenting, please send a copy of your presentation to the chairs by Sunday, Monday at the absolute latest. Cheers, Charles On 2/18/14, 4:33 PM, "Charles Eckel (eckelcu)" wrote: >The draft agenda has been posted: >http://www.ietf.org/proceedings/89/agenda/agenda-89-bfcpbis > >Please share any comments or concerns. >For those with presentation slots, let me know if the time allocated is >appropriate. > >Cheers, >Charles > > From nobody Thu Feb 27 11:50:50 2014 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 AC4E71A0662 for ; Thu, 27 Feb 2014 11:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 IXWzOqca0ulX for ; Thu, 27 Feb 2014 11:50:48 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 685C41A0658 for ; Thu, 27 Feb 2014 11:50:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=559; q=dns/txt; s=iport; t=1393530647; x=1394740247; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=NREJ303WOmoXtU6cgeQ0pCWNWcdkHS8oXMG9alO4oBY=; b=AyncV2JuoQS3c4z3cw0ADnkQ9Dy/Q5ZEPpUo+eOpg9ElgnWSzJpOKjTe Tf+fTXybCCZlSn4KhwzfbKYc7zKarv/4zokqM75NFSkzlu66tuBz3SaNh S2UPsR6lq4/MfeaVSFMwKW546bu9NJZwOWt4UTS0uiw/VDGI2mfpaIbv8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAEGWD1OtJV2a/2dsb2JhbABagwY7V8A+T4EdFnSCLIELAYEAJwQch28BDZsIsAwXjgEDAQFRhDwEiRKPJpIqgy2BcTk X-IronPort-AV: E=Sophos;i="4.97,556,1389744000"; d="scan'208";a="23740276" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 27 Feb 2014 19:50:46 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1RJokW2020257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 27 Feb 2014 19:50:46 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Thu, 27 Feb 2014 13:50:46 -0600 From: "Charles Eckel (eckelcu)" To: "bfcpbis@ietf.org" Thread-Topic: prep for BFCPBIS session Thread-Index: AQHPM/U0a9dPiikAnUyMlyhXjMox+g== Date: Thu, 27 Feb 2014 19:50:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [171.68.20.21] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0FF2F92706A628428161F697C5CFC82C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/NRDyN9TPGJPT-mv4scBbsBF3BYo Subject: [bfcpbis] prep for BFCPBIS session 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: Thu, 27 Feb 2014 19:50:49 -0000 BFCPBIS=B9ers, To make best use of our time together in London, please review the recently updated version of both drafts and share your comments/concerns on the list prior to the meeting. For your convenience, here are the announcements of both drafts: 4582bis: http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00281.html 4583bis: http://www.ietf.org/mail-archive/web/bfcpbis/current/msg00280.html We are very close to completing both of this drafts. Please make the effort to help us get the rest of the way there. Cheers, Charles