From wuym2000cn@gmail.com Fri Jun 1 02:59:22 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3160121F8665 for ; Fri, 1 Jun 2012 02:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=1.181, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xN5xQDJVvkQF for ; Fri, 1 Jun 2012 02:59:21 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92ADA21F865F for ; Fri, 1 Jun 2012 02:59:21 -0700 (PDT) Received: by qadz3 with SMTP id z3so249646qad.10 for ; Fri, 01 Jun 2012 02:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=InwuakMUVL9V202+abJ84sVHEUVfQPs7t7fECZ7ug2k=; b=PA/CZ1FVoIbDPY2RH6m7xPGB50HpOoAFtgjckXoa9HjXMZbqJMEP7/DXCRyPzjXE6w 5Vkf8vWDUNR6wFzRn/Jc/XEp/i2pRXnifRqWYj9QWkE3NhL1H2whHJTU+CAYEd6zZ5W9 tZx9mF0vSe7g8WMBjl8OfBVgd0MGjIIlcK81xG6qADQkJ4elQlqjW9xKW0FTXhCm71gA 7HxeSWjC2WB5oK0Mm3qm16YqGkXqIPZJ3DTTsPst7MGsFEgI2tWD8yTBVOPOhHDdlsWu Zim8ar7Q5+4VFZZtxmOv2p/m1NWvo1a4WcoYp2++++2Dpk7EVHPgRcOdp2JXjEo98dS3 Y+lg== MIME-Version: 1.0 Received: by 10.224.105.202 with SMTP id u10mr3475937qao.54.1338544761042; Fri, 01 Jun 2012 02:59:21 -0700 (PDT) Received: by 10.229.239.19 with HTTP; Fri, 1 Jun 2012 02:59:20 -0700 (PDT) Date: Fri, 1 Jun 2012 17:59:20 +0800 Message-ID: From: Woo Johnman To: bfcpbis@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [bfcpbis] transaction issue X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 09:59:22 -0000 Hi, The RFC4582bis says:"As described in previous paragraph every entity - client or server - is only allowed to send one request at a time, and await the acknowledging response." I think the condition of only one pending request at a time is too hard. Is it more suitable that there is one pending request at a time per conference or ever per connection(client-server)? Regards, Youngmin From lorenzo@meetecho.com Mon Jun 4 04:15:37 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA0921F86CB for ; Mon, 4 Jun 2012 04:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHoBUFIFiOlj for ; Mon, 4 Jun 2012 04:15:37 -0700 (PDT) Received: from smtplq03.aruba.it (smtplq-out14.aruba.it [62.149.158.34]) by ietfa.amsl.com (Postfix) with SMTP id 9C1ED21F86C8 for ; Mon, 4 Jun 2012 04:15:36 -0700 (PDT) Received: (qmail 7948 invoked by uid 89); 4 Jun 2012 11:15:35 -0000 Received: from unknown (HELO smtp2.aruba.it) (62.149.158.222) by smtplq03.aruba.it with SMTP; 4 Jun 2012 11:15:35 -0000 Received: (qmail 5342 invoked by uid 89); 4 Jun 2012 11:15:35 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.200) by smtp2.ad.aruba.it with SMTP; 4 Jun 2012 11:15:35 -0000 Date: Mon, 4 Jun 2012 13:15:29 +0200 From: Lorenzo Miniero To: bfcpbis@ietf.org Message-ID: <20120604131529.133a66fa@lminiero-acer> Organization: Meetecho X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp2.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Cc: Tom Kristensen <2mkristensen@gmail.com>, Gonzalo Camarillo Subject: Re: [bfcpbis] More comments on RFC 4582 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 11:15:37 -0000 > > o When we get more experience on queue management from real > > deployments, it would be nice to explaining it further in the spec. > > Tom: I have no knowledge of queue management from deployments. > Does anyone else out there have any deployment experience? If not, > we don't really have much to add at present. > We don't do anything fancy with queue management in our current implementation: I don't think the spec needs to say anything about that anyway. > > o A message may need to be longer than the maximum message length > > supported by the protocol > > Tom: We've solved the fragmentation issue. No demands voiced for length > exceeding the maximum message length for reliable transport voiced in > BFCPbis. I was one of those bringing this issue to the ML, back in the days: I think the solution proposed in this new document could correctly address the problem not only when using unreliable connections, but reliable ones too. The only concern I have, though, is that the draft currently says that, when using TCP, the version bit must be set to 1 as per RFC4582: this means that involved entities will get confused about the new fragment part of the header. Legacy implementations instead would definitely fail when fragmentation is involved, since the overall length would now match the actual payload containing the first fragment. I'm not sure how the problem may be solved: I guess setting the version to 2 for reliable connections might be a way, whereas in that case the only new "feature" to be used would be the fragmentation stuff and not the whole spec. Lorenzo -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From internet-drafts@ietf.org Mon Jun 4 05:54:41 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BA521F87A9; Mon, 4 Jun 2012 05:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-DQ7A+t3lqc; Mon, 4 Jun 2012 05:54:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C54621F8736; Mon, 4 Jun 2012 05:54:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120604125441.31194.18776.idtracker@ietfa.amsl.com> Date: Mon, 04 Jun 2012 05:54:41 -0700 Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-03.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 12:54:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Binary Floor Control Protocol Bis Wo= rking Group of the IETF. Title : The Binary Floor Control Protocol (BFCP) Author(s) : Gonzalo Camarillo Keith Drage Tom Kristensen Joerg Ott Charles Eckel Filename : draft-ietf-bfcpbis-rfc4582bis-03.txt Pages : 87 Date : 2012-06-04 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfcpbis-rfc4582bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-bfcpbis-rfc4582bis-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ From internet-drafts@ietf.org Mon Jun 4 05:54:58 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4303F21F8636; Mon, 4 Jun 2012 05:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnVx8-4WDwjw; Mon, 4 Jun 2012 05:54:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62FC21F8542; Mon, 4 Jun 2012 05:54:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120604125457.31448.86063.idtracker@ietfa.amsl.com> Date: Mon, 04 Jun 2012 05:54:57 -0700 Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-01.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 12:54:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Binary Floor Control Protocol Bis Wo= rking Group of the IETF. Title : Session Description Protocol (SDP) Format for Binary Flo= or Control Protocol (BFCP) Streams Author(s) : Gonzalo Camarillo Tom Kristensen Filename : draft-ietf-bfcpbis-rfc4583bis-01.txt Pages : 15 Date : 2012-06-04 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfcpbis-rfc4583bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-bfcpbis-rfc4583bis-01.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis/ From 2mkristensen@gmail.com Mon Jun 4 05:58:48 2012 Return-Path: <2mkristensen@gmail.com> X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D4521F87AE for ; Mon, 4 Jun 2012 05:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNQ7VIWebLP3 for ; Mon, 4 Jun 2012 05:58:48 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC12B21F87AA for ; Mon, 4 Jun 2012 05:58:47 -0700 (PDT) Received: by lagv3 with SMTP id v3so3208684lag.31 for ; Mon, 04 Jun 2012 05:58:46 -0700 (PDT) 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=E25NAAY7sSQ8ryo8aI2RmleWkpu7ZPwbMbJ4JlHjuqU=; b=NdSZ8+GqAZVx0UJlcjQlovJm6XytSPmlmVexet0WYUklt3D8e7gylr4N7u1fpadrdC QWFmnSxwK1ZFBCRcYk8jh6Xv52c3FPoOw83nw4bX5sWEImz+iUu0e1tLlzTezuzhM7b5 7PUAeVedvpF5FyFCfMAThHoWnn35PY2IJpKABcUUonCiAuYp5jEqgZemmmeJq18gS9gQ 3l5Gv0Bm2UFXacIDej+FW1o+RnPn3vfDddcmOkI//ez5Q0zwbUN1Z3iPTjIyBAKHE+hw SB5uSwqlTa267jMNrp4eTgGU0lX7DGJjn1DtryC7axWEk2uCMTic2PGl+cM5kv02j5KR 5FMA== MIME-Version: 1.0 Received: by 10.152.148.169 with SMTP id tt9mr12453943lab.49.1338814726803; Mon, 04 Jun 2012 05:58:46 -0700 (PDT) Received: by 10.112.23.169 with HTTP; Mon, 4 Jun 2012 05:58:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Jun 2012 14:58:46 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: Alan Ford Content-Type: text/plain; charset=ISO-8859-1 Cc: bfcpbis@ietf.org, Woo Johnman Subject: Re: [bfcpbis] BFCP over DTLS X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 12:58:49 -0000 The wording are now fixed in the just submitted rfc4582bis-03 version, according to Alan's input. Please verfify that the current text is suitable and clear. -- Tom On 30/05/2012, Alan Ford wrote: > Hi, > > Yes, there should indeed be a reference to RFC6347 for DTLS in Section 7. > > The line referencing [7] says: > > For a UDP/ DTLS connection established using the same exchange, > either party can be the DTLS server depending on the setup attributes > exchanged, as defined in [7]. > > This is referring to the use of the DTLS setup attributes (a=setup) in the > SDP, which is discussed in [7] (Section 7.1). It definitely does not > suggest > the use of SRTP. I guess it could be a bit clearer in the text; the updates > in 4572bis also touch on this. > > Regards, > Alan > > On 30/05/2012 10:35, "Woo Johnman" wrote: > >> Hi, >> I feel BFCP over DTLS is not well documented in rfc4582bis. >> At section 7 "Lower-Layer Security". >> It says "BFCP floor control servers >> and clients MUST support TLS for transport over TCP and MUST support >> DTLS >> for >> transport over UDP [4]." But reference [4] is only about BFCP over >> TLS. >> Reference for BFCP over DTLS seems missing. >> At the end of the same section,it seems say DTLS connection setup >> procedure shall >> follow [7]. If it is true, does it mean BFCP message is packeted as >> SRTP? If not, would it be better to >> give more details about DTLS connection setup and packetization. >> >> Please give more explain. >> >> Thanks in advance, >> >> Youngmin >> _______________________________________________ >> 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/ From tomkrist@cisco.com Mon Jun 4 06:07:24 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E8A21F87A8 for ; Mon, 4 Jun 2012 06:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PV7Wh1T1UFu4 for ; Mon, 4 Jun 2012 06:07:23 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9B48F21F86AD for ; Mon, 4 Jun 2012 06:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=594; q=dns/txt; s=iport; t=1338815243; x=1340024843; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XXLzKs8tQs26TnRP64N/YQVe7h5PbTcxWqgYrl/0Fy8=; b=HXWx1A5CpKhiCW6ew8VIJBnsYVHmFlhFOafodQZkS5wsmAMaVAT8kBDh wZVU8qXRvv+eRn2MC3yDz/jh29Zsxz37G4aScgfOCriJZ1F9XsFCGRCR5 2QLXOP29EcSi8amwS0HP++9cD5yToz89RxQDOFzu2hkGCalfBIIW8WMNq c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAFAOWxzE+Q/khM/2dsb2JhbABEgx2tN4NTgQeCGAEBAQQSASUwERALGAklDwJGEwEHAQEeh2mXBJ8sixGCeoMWA5UbhVCDWAGEZ4FmgmI X-IronPort-AV: E=Sophos;i="4.75,712,1330905600"; d="scan'208";a="74005535" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 04 Jun 2012 13:07:19 +0000 Received: from [10.61.91.28] (ams3-vpn-dhcp6941.cisco.com [10.61.91.28]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q54D7J1G015918; Mon, 4 Jun 2012 13:07:19 GMT Message-ID: <4FCCB307.40001@cisco.com> Date: Mon, 04 Jun 2012 15:07:19 +0200 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: bfcpbis@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Woo Johnman Subject: Re: [bfcpbis] transaction issue X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 13:07:24 -0000 On 06/01/2012 11:59 AM, Woo Johnman wrote: > Hi, > The RFC4582bis says:"As described in previous paragraph every entity - > client or server - is only allowed to send one request at a time, and > await the acknowledging response." > I think the condition of only one pending request at a time is too hard. > Is it more suitable that there is one pending request at a time per conference > or ever per connection(client-server)? > Woo, Thanks for the comment. I have to read the text chunks related to this once more and rethink this approach; I'll be back! -- Tom From tomkrist@cisco.com Mon Jun 4 06:16:33 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6BE21F8742 for ; Mon, 4 Jun 2012 06:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfFdtTDq4uRN for ; Mon, 4 Jun 2012 06:16:32 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 6F49121F8736 for ; Mon, 4 Jun 2012 06:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=2372; q=dns/txt; s=iport; t=1338815792; x=1340025392; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=6yaT4NNIIlmYPi2g4SXM1QLVQFsFw8LDjgqcI08HCG4=; b=BEFY7R+7ozJ1gUFegxfWl5YdQJY1QB/S8R4eu6xIbtqKN/1Z7S0MT0T3 +Sybtd5505It4RiOIVaVx4StjpHWjSRYlV6duk7TwaUpH6yRHA8mh7f25 E8watC4SMLO4BpKxaYCnZLYZsT1o1o2NlL9izXPE7GI2P348VMKPgy1/8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEFADO0zE+Q/khL/2dsb2JhbABEgx2tN4NTgQeCGAEBAQMBEgElQAEQCxgJFg8JAwIBAgFFBg0BBwEBFweHZAWWfZ8tixGGEAOVG4VQiECBZoJi X-IronPort-AV: E=Sophos;i="4.75,712,1330905600"; d="scan'208";a="5347605" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 04 Jun 2012 13:16:31 +0000 Received: from [10.61.91.28] (ams3-vpn-dhcp6941.cisco.com [10.61.91.28]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q54DGUN5011984; Mon, 4 Jun 2012 13:16:30 GMT Message-ID: <4FCCB52E.5010109@cisco.com> Date: Mon, 04 Jun 2012 15:16:30 +0200 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: Lorenzo Miniero References: <20120604131529.133a66fa@lminiero-acer> In-Reply-To: <20120604131529.133a66fa@lminiero-acer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bfcpbis@ietf.org, Tom Kristensen <2mkristensen@gmail.com>, Gonzalo Camarillo Subject: Re: [bfcpbis] More comments on RFC 4582 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 13:16:33 -0000 On 06/04/2012 01:15 PM, Lorenzo Miniero wrote: > > > >>> o When we get more experience on queue management from real >>> deployments, it would be nice to explaining it further in the spec. >>> >> Tom: I have no knowledge of queue management from deployments. >> Does anyone else out there have any deployment experience? If not, >> we don't really have much to add at present. >> >> > > We don't do anything fancy with queue management in our current > implementation: I don't think the spec needs to say anything about that > anyway. > Agree. And if there's no demand here in BFCPbis, no text will be added for this issue. >>> o A message may need to be longer than the maximum message length >>> supported by the protocol >>> >> Tom: We've solved the fragmentation issue. No demands voiced for length exceeding the maximum message length for reliable transport voiced in BFCPbis. >> > > I was one of those bringing this issue to the ML, back in the days: I > think the solution proposed in this new document could correctly > address the problem not only when using unreliable connections, but > reliable ones too. The only concern I have, though, is that the draft > currently says that, when using TCP, the version bit must be set to 1 > as per RFC4582: this means that involved entities will get confused > about the new fragment part of the header. Legacy implementations > instead would definitely fail when fragmentation is involved, since the > overall length would now match the actual payload containing the first > fragment. > > I'm not sure how the problem may be solved: I guess setting the version > to 2 for reliable connections might be a way, whereas in that case the > only new "feature" to be used would be the fragmentation stuff and not > the whole spec. > My hope is that this kind of fragmentation, due to the existing payload length field in the BFCP messages being 16 bit, could be avoided by pointing at BFCP's usage domain ("small messages...") and if needed recommend using other means for distributing laaaarge messages (SIP Event framework, other conferencing protocols, ...). Note that the BFCP common header payload length field is a 16-bit field that contains the length of the message in 4-octet units. -- Tom From 2mkristensen@gmail.com Mon Jun 4 06:30:56 2012 Return-Path: <2mkristensen@gmail.com> X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6064D21F87E3 for ; Mon, 4 Jun 2012 06:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl7voZd5aeto for ; Mon, 4 Jun 2012 06:30:55 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3DF21F87E7 for ; Mon, 4 Jun 2012 06:30:53 -0700 (PDT) Received: by lagv3 with SMTP id v3so3236617lag.31 for ; Mon, 04 Jun 2012 06:30:52 -0700 (PDT) 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=pZVMK8GBFerSztaPa8Zas1Sptv3gpZRzvv+i7fy4oxU=; b=yYVyosFAoBaAgi/abFBHyu3wV7SDT5k1fABvIAlFUEZVoUXx680cw59S+weNGLHMx1 Y2z2IZ+HTsBGxMPBcJzXrMXesRBG5jxfXbTg7Nz9r83JSb8rA8Veb6017nBmgD1BHjke qb64Lb+So0EmozwJz2fsXLBSrE6Xrty9bpVMOwX/yMRmwhzhwc57Bedtk5tLVjy0R/VX m3x0CvfaWknf52qTBsYYQRW0zsYH8tXXQ/vwF7MSDNIRRRbjHj3dR0qBKGZvQXzoWy4b 6BoXlswNtG/IKPjRK62JQGAlmu77YvWHM3xGpdL173hIQotlYztXkYnz3pJgngQU6YUQ t1ZQ== MIME-Version: 1.0 Received: by 10.112.44.163 with SMTP id f3mr6147778lbm.59.1338816652147; Mon, 04 Jun 2012 06:30:52 -0700 (PDT) Received: by 10.112.23.169 with HTTP; Mon, 4 Jun 2012 06:30:52 -0700 (PDT) In-Reply-To: <20120604125457.31448.86063.idtracker@ietfa.amsl.com> References: <20120604125457.31448.86063.idtracker@ietfa.amsl.com> Date: Mon, 4 Jun 2012 15:30:52 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: bfcpbis@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Tom Kristensen Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-01.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 13:30:56 -0000 On 04/06/2012, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Binary Floor Control Protocol > Bis Working Group of the IETF. > > Title : Session Description Protocol (SDP) Format for Binary > Floor Control Protocol (BFCP) Streams > Author(s) : Gonzalo Camarillo > Tom Kristensen > Filename : draft-ietf-bfcpbis-rfc4583bis-01.txt > Pages : 15 > Date : 2012-06-04 > > 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. Changes from -00 version as agreed in BFCPbis session at IETF-83, Paris. Cf. the meeting minutes. - Recommend interpreting m-stream, as well as the formally correct mstrm - Clarify confid and userid being decimal integers As well as polish and fixes after running IETF tools idnits and idspell tools, updated a number of obsoleted references to current RFCs. Please, read and review ==> post any issues to this list. -- Tom -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ From lorenzo@meetecho.com Mon Jun 4 06:34:00 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34FC21F87E9 for ; Mon, 4 Jun 2012 06:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSPF2JeoHu3H for ; Mon, 4 Jun 2012 06:34:00 -0700 (PDT) Received: from smtplq03.aruba.it (smtplq-out14.aruba.it [62.149.158.34]) by ietfa.amsl.com (Postfix) with SMTP id AA80C21F87E7 for ; Mon, 4 Jun 2012 06:33:59 -0700 (PDT) Received: (qmail 502 invoked by uid 89); 4 Jun 2012 13:33:57 -0000 Received: from unknown (HELO smtp8.aruba.it) (62.149.158.228) by smtplq03.aruba.it with SMTP; 4 Jun 2012 13:33:57 -0000 Received: (qmail 21014 invoked by uid 89); 4 Jun 2012 13:33:57 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.200) by smtp8.ad.aruba.it with SMTP; 4 Jun 2012 13:33:57 -0000 Date: Mon, 4 Jun 2012 15:33:51 +0200 From: Lorenzo Miniero To: Tom Kristensen Message-ID: <20120604153351.0e67d77a@lminiero-acer> In-Reply-To: <4FCCB52E.5010109@cisco.com> References: <20120604131529.133a66fa@lminiero-acer> <4FCCB52E.5010109@cisco.com> Organization: Meetecho X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp8.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Cc: bfcpbis@ietf.org, Tom Kristensen <2mkristensen@gmail.com>, Gonzalo Camarillo Subject: Re: [bfcpbis] More comments on RFC 4582 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 13:34:00 -0000 Il giorno Mon, 04 Jun 2012 15:16:30 +0200 Tom Kristensen ha scritto: > On 06/04/2012 01:15 PM, Lorenzo Miniero wrote: > > > > > > > >>> o When we get more experience on queue management from real > >>> deployments, it would be nice to explaining it further in the > >>> spec. > >> Tom: I have no knowledge of queue management from deployments. > >> Does anyone else out there have any deployment experience? If not, > >> we don't really have much to add at present. > >> > >> > > > > We don't do anything fancy with queue management in our current > > implementation: I don't think the spec needs to say anything about > > that anyway. > > > Agree. And if there's no demand here in BFCPbis, no text will be > added for this issue. > > >>> o A message may need to be longer than the maximum message length > >>> supported by the protocol > >>> > >> Tom: We've solved the fragmentation issue. No demands voiced for > >> length exceeding the maximum message length for reliable transport > >> voiced in BFCPbis. > > > > I was one of those bringing this issue to the ML, back in the days: > > I think the solution proposed in this new document could correctly > > address the problem not only when using unreliable connections, but > > reliable ones too. The only concern I have, though, is that the > > draft currently says that, when using TCP, the version bit must be > > set to 1 as per RFC4582: this means that involved entities will get > > confused about the new fragment part of the header. Legacy > > implementations instead would definitely fail when fragmentation is > > involved, since the overall length would now match the actual > > payload containing the first fragment. > > > > I'm not sure how the problem may be solved: I guess setting the > > version to 2 for reliable connections might be a way, whereas in > > that case the only new "feature" to be used would be the > > fragmentation stuff and not the whole spec. > > > My hope is that this kind of fragmentation, due to the existing > payload length field in the BFCP messages being 16 bit, could be > avoided by pointing at BFCP's usage domain ("small messages...") and > if needed recommend using other means for distributing laaaarge > messages (SIP Event framework, other conferencing protocols, ...). > > Note that the BFCP common header payload length field is a 16-bit > field that contains the length of the message in 4-octet units. > > -- Tom You're right, the scenario I had in mind at the time was probably an edge case that could be solved some other way anyway, as you pointed out. L. -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From 2mkristensen@gmail.com Mon Jun 4 06:38:38 2012 Return-Path: <2mkristensen@gmail.com> X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9904F21F880C for ; Mon, 4 Jun 2012 06:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93M-6tOxCcWm for ; Mon, 4 Jun 2012 06:38:37 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB3721F87E7 for ; Mon, 4 Jun 2012 06:38:37 -0700 (PDT) Received: by lagv3 with SMTP id v3so3243639lag.31 for ; Mon, 04 Jun 2012 06:38:36 -0700 (PDT) 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=N3PDUBiJWy1241FhDpZonmYPtbu8IIqYollSfJfGNoY=; b=eaP/lcv27sE3rOsOqyDkFMWVPA1+4vuBbk2cLHtT37qU9JQb2KAlNOIgXesuGbAWne tQQcfXf46azLl1bafgzkC2jHCk/1fEaseOBDmEX/9mKyWyDeisAOY1PljUhsBYuC99oU byziSAFVBmq9GobhmqcCRHd5P4qOVAOj+y54oOirqrBxpX9ApEfqSDcKP84ycq64AmkO PQ8KrnIjIeMh7WQSFcp0yoTaeYH59VGBGwtvZt2G8k1J3/7Nq180V4bXaMwPVXMO1kPl hoMVcPBX8hEA9sGdBMlbUl8YGpvgSyo13zkwpvVGLGgPoAZws1GwVNz9KFFdBtO5Krtq en2A== MIME-Version: 1.0 Received: by 10.152.108.38 with SMTP id hh6mr12664032lab.28.1338817116451; Mon, 04 Jun 2012 06:38:36 -0700 (PDT) Received: by 10.112.23.169 with HTTP; Mon, 4 Jun 2012 06:38:36 -0700 (PDT) In-Reply-To: <20120604125441.31194.18776.idtracker@ietfa.amsl.com> References: <20120604125441.31194.18776.idtracker@ietfa.amsl.com> Date: Mon, 4 Jun 2012 15:38:36 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "bfcpbis@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: Tom Kristensen Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-03.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 13:38:38 -0000 On 04/06/2012, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Binary Floor Control Protocol > Bis Working Group of the IETF. > > Title : The Binary Floor Control Protocol (BFCP) > Author(s) : Gonzalo Camarillo > Keith Drage > Tom Kristensen > Joerg Ott > Charles Eckel > Filename : draft-ietf-bfcpbis-rfc4582bis-03.txt > Pages : 87 > Date : 2012-06-04 > > 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. Updated as agreed in the BFCPbis session at IETF-83, Paris (cf. meeting minutes). Refer also to the three mail threads initiated by Gonzalo Camarillo at 2012-04-16, where old comments/input from earlier on where re-raised and suggestions for making the motivation appendix better. The DTLS issue discussed on list is also fixed by text clarification in this draft version. Polish and fixes after running the IETF idnits and idspell tools done. Updated a number of references from obsoleted RFCs to current versions. Please, review ==> and post any comments, questions or input to this list. -- Tom -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ From chelliah@cisco.com Mon Jun 4 07:22:25 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EF821F88C4 for ; Mon, 4 Jun 2012 07:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve9I6uf1Wx1a for ; Mon, 4 Jun 2012 07:22:24 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id F085521F88C8 for ; Mon, 4 Jun 2012 07:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=chelliah@cisco.com; l=3208; q=dns/txt; s=iport; t=1338819744; x=1340029344; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=cOQJd5/vx9AhHCaThEen1xAU/lzOzESWBPOSNJmf3Mg=; b=CR9uVWIpRvHWo4741z90Dq8+qkYOZG+PsucoB2Jr77nbaxj42xHaERZ3 ey3/Rosc9V7rxq8fktaq2yibeLylNwm4lsklKe3AFLn0z78xMG2dMNhxw 8mtH/UZQLJGO094a9hvR4Y0jhQSi4rPs4AGtMznWmUHgOmHAmMgyGddwK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPTDzE+rRDoG/2dsb2JhbABEtCiBB4IYAQEBAwEBAQEPAR0KNAsMBAIBCBEEAQEBCgYXAQYBJh8JCAEBBAESCBMHh2QEAQuXDp8lBIsRhTBgA4hAmmuBZoMA X-IronPort-AV: E=Sophos;i="4.75,713,1330905600"; d="scan'208";a="45003919" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 04 Jun 2012 14:22:23 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q54EMNKP012445; Mon, 4 Jun 2012 14:22:23 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Jun 2012 07:22:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Jun 2012 07:22:19 -0700 Message-ID: In-Reply-To: <4FCCB52E.5010109@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [bfcpbis] More comments on RFC 4582 Thread-Index: Ac1CVEYaW6qX7aFrSOCCIIR4ypHvegACRorg References: <20120604131529.133a66fa@lminiero-acer> <4FCCB52E.5010109@cisco.com> From: "Chelliah Sivachelvan (chelliah)" To: "Tom Kristensen (tomkrist)" , "Lorenzo Miniero" X-OriginalArrivalTime: 04 Jun 2012 14:22:23.0183 (UTC) FILETIME=[7559E5F0:01CD425D] Cc: bfcpbis@ietf.org, Tom Kristensen <2mkristensen@gmail.com>, Gonzalo Camarillo Subject: Re: [bfcpbis] More comments on RFC 4582 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 14:22:25 -0000 Tom, A minor comment on the SDP example in section 9. In the context of DTLS, the setup a line must be "actpass" in the offer. See excerpts from RFC 5763: [ The endpoint that is the offerer MUST use the setup attribute value of setup:actpass and be prepared to receive a client_hello before it receives the answer.] Thanks! Chelliah -----Original Message----- From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Tom Kristensen (tomkrist) Sent: Monday, June 04, 2012 8:17 AM To: Lorenzo Miniero Cc: bfcpbis@ietf.org; Tom Kristensen; Gonzalo Camarillo Subject: Re: [bfcpbis] More comments on RFC 4582 On 06/04/2012 01:15 PM, Lorenzo Miniero wrote: > > > =20 >>> o When we get more experience on queue management from real >>> deployments, it would be nice to explaining it further in the spec. >>> =20 >> Tom: I have no knowledge of queue management from deployments. >> Does anyone else out there have any deployment experience? If not, >> we don't really have much to add at present. >> >> =20 > > We don't do anything fancy with queue management in our current > implementation: I don't think the spec needs to say anything about that > anyway. > =20 Agree. And if there's no demand here in BFCPbis, no text will be added=20 for this issue. >>> o A message may need to be longer than the maximum message length >>> supported by the protocol >>> =20 >> Tom: We've solved the fragmentation issue. No demands voiced for length exceeding the maximum message length for reliable transport voiced in BFCPbis. >> =20 > > I was one of those bringing this issue to the ML, back in the days: I > think the solution proposed in this new document could correctly > address the problem not only when using unreliable connections, but > reliable ones too. The only concern I have, though, is that the draft > currently says that, when using TCP, the version bit must be set to 1 > as per RFC4582: this means that involved entities will get confused > about the new fragment part of the header. Legacy implementations > instead would definitely fail when fragmentation is involved, since the > overall length would now match the actual payload containing the first > fragment. > > I'm not sure how the problem may be solved: I guess setting the version > to 2 for reliable connections might be a way, whereas in that case the > only new "feature" to be used would be the fragmentation stuff and not > the whole spec. > =20 My hope is that this kind of fragmentation, due to the existing payload=20 length field in the BFCP messages being 16 bit, could be avoided by=20 pointing at BFCP's usage domain ("small messages...") and if needed=20 recommend using other means for distributing laaaarge messages (SIP=20 Event framework, other conferencing protocols, ...). Note that the BFCP common header payload length field is a 16-bit field=20 that contains the length of the message in 4-octet units. -- Tom _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis From tomkrist@cisco.com Mon Jun 4 22:54:00 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323CF21F8712 for ; Mon, 4 Jun 2012 22:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXD6jEOF0lym for ; Mon, 4 Jun 2012 22:53:59 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8467521F870B for ; Mon, 4 Jun 2012 22:53:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=640; q=dns/txt; s=iport; t=1338875638; x=1340085238; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tHz9Z37tYM97R1KZGaIHDttBDzoP/EuaO7CnzQuRv5Y=; b=NxZvSaCIWtuI4snzEWsXgDo4HfERMnz9eYRLvcqydHvLMdbp1vRdRWAg oOiPnw4bj3RDojsfD4LO3mIX2q+/bzOM0HuQsAIrtZ03MVWA6P/zQxRYn Xaxkgqgy4+/kWa7Uf1JhTLLJlnKo+tp8iDFZ6ss4p6HqXsyNSOu5tr0rC s=; X-IronPort-AV: E=Sophos;i="4.75,716,1330905600"; d="scan'208";a="74033966" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 05 Jun 2012 05:53:57 +0000 Received: from [10.55.90.224] (dhcp-10-55-90-224.cisco.com [10.55.90.224]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q555rvwO008285; Tue, 5 Jun 2012 05:53:57 GMT Message-ID: <4FCD9EF5.80106@cisco.com> Date: Tue, 05 Jun 2012 07:53:57 +0200 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: "Chelliah Sivachelvan (chelliah)" References: <20120604131529.133a66fa@lminiero-acer> <4FCCB52E.5010109@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lorenzo Miniero , bfcpbis@ietf.org, Tom Kristensen <2mkristensen@gmail.com>, Gonzalo Camarillo Subject: [bfcpbis] rfc4583bis TLS SDP example - Re: More comments on RFC 4582 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 05:54:00 -0000 On 06/04/2012 04:22 PM, Chelliah Sivachelvan (chelliah) wrote: > Tom, > > A minor comment on the SDP example in section 9. In the context of DTLS, > the setup a line must be "actpass" in the offer. See excerpts from RFC > 5763: > > [ The endpoint that is the offerer MUST use the setup attribute > value of setup:actpass and be prepared to receive a client_hello > before it receives the answer.] > Yes, this is true for DTLS usage (UDP/TLS/BFCP). However, the example is the original example from RFC 4582 related to TLS (TCP/TLS/BFCP). So I believe the example in rfc4583bis is correct! -- Tom From tomkrist@cisco.com Tue Jun 5 02:18:20 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC2E21F867A for ; Tue, 5 Jun 2012 02:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Njb+aO7PJDRk for ; Tue, 5 Jun 2012 02:18:19 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 91E9B21F853D for ; Tue, 5 Jun 2012 02:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=444; q=dns/txt; s=iport; t=1338887899; x=1340097499; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=OUgk21B1h0CF5TJXg9h6agUgNyUMlkLA3Tu/0CprPy8=; b=Rrp1vsXrg51RLNsMNwGweHQWTjFfDbx48LDyApdanMDwV+JCQ1moSPNo Z4RAKl/F08v+6EY1v9wvDdflce8TrbRO8P50SrK9Pz47R8CJZb8ityyQN gjEKLWFvohSDJsscOb+BVtuaOc5gpGCQJKL9M4Kim+jP0jDwKGboGhBU9 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEvOzU+Q/khN/2dsb2JhbABFtDOBB4IxASVAPRYYAwIBAgFLDQgBAR6HaZYLgSigA5EjA5UbgQ+EQYUugxKBZoJi X-IronPort-AV: E=Sophos;i="4.75,718,1330905600"; d="scan'208";a="5381768" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 05 Jun 2012 09:18:18 +0000 Received: from [10.55.90.224] (dhcp-10-55-90-224.cisco.com [10.55.90.224]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q559IIov030244 for ; Tue, 5 Jun 2012 09:18:18 GMT Message-ID: <4FCDCEDA.7080502@cisco.com> Date: Tue, 05 Jun 2012 11:18:18 +0200 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: "BFCPbis WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [bfcpbis] IETF diff tool and bis drafts X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 09:18:20 -0000 The IETF diff tool http://tools.ietf.org/rfcdiff works reasonably well for both draft-ietf-bfcpbis-rfc4582bis and draft-ietf-bfcpbis-rfc4583bis when compared with the original RFCs. I have done some white space fixes, especially in the BFCP sequence diagram, to reduce the diff size. I've tried all output formats, they work equally fine. (Although, I personally do like the "Side-by-side diff" and "Html wdiff" best). -- Tom From eckelcu@cisco.com Tue Jun 5 10:19:28 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD6521F87A3 for ; Tue, 5 Jun 2012 10:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.532 X-Spam-Level: X-Spam-Status: No, score=-9.532 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wX8xD5-4TbIF for ; Tue, 5 Jun 2012 10:19:28 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0632721F8786 for ; Tue, 5 Jun 2012 10:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=2173; q=dns/txt; s=iport; t=1338916757; x=1340126357; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=mV1bhDFPBw0wKIBN638hpQCDXwa+DA/lQfdxHrjHuts=; b=S+nSXbXgO7FHpAJFVxkZdyi1kmkMVuhaZl7t4BYtpm5wzhALQ4bttK4z zA/ey5x0fsVl3mKPlj9jR5ywNd/PV+hWp7Bv5zaqANHmDBASQ+R7dItJC QDFZUGNCXvXIOqEn0vssIyA15sswN7zk/5eLhNrWv4choocqlOpepcUKp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACk/zk+rRDoI/2dsb2JhbABDArQ6gQeCGAEBAQQBAQEPAR0KNAsMBAIBCBEEAQEBCgYGEQEGASYfCQgBAQQBEggah2gBC5cpoAIEixOCdguCL2ADiECaa4FmgwA X-IronPort-AV: E=Sophos;i="4.75,718,1330905600"; d="scan'208";a="44644863" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 05 Jun 2012 17:19:17 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q55HJHmj025698; Tue, 5 Jun 2012 17:19:17 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jun 2012 10:19:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jun 2012 10:19:14 -0700 Message-ID: In-Reply-To: <4FCD9EF5.80106@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [bfcpbis] rfc4583bis TLS SDP example - Re: More comments on RFC 4582 Thread-Index: Ac1C359jsiRGwCHuQp2OqKC24radnwAXU0qA References: <20120604131529.133a66fa@lminiero-acer><4FCCB52E.5010109@cisco.com> <4FCD9EF5.80106@cisco.com> From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , "Chelliah Sivachelvan (chelliah)" X-OriginalArrivalTime: 05 Jun 2012 17:19:17.0305 (UTC) FILETIME=[56462290:01CD433F] Cc: Lorenzo Miniero , bfcpbis@ietf.org, Tom Kristensen <2mkristensen@gmail.com>, Gonzalo Camarillo Subject: Re: [bfcpbis] rfc4583bis TLS SDP example - Re: More comments on RFC 4582 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 17:19:29 -0000 I agree, however, perhaps it would be useful to add a second example in which an endpoint initiates the offer and uses DTLS; e.g.: Offer from client: m=3Dapplication 50000 UDP/DTLS/BFCP * a=3Dsetup:actpass a=3Dfingerprint:SHA-1 \ 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=3Dfloorctrl:c-only, s-only a=3Dconfid:4321 a=3Duserid:1234=09 a=3Dfloorid:1 mstrm:10 a=3Dfloorid:2 mstrm:11 m=3Daudio 50002 RTP/AVP 0 a=3Dlabel:10 m=3Dvideo 50004 RTP/AVP 31 a=3Dlabel:11 The following is the answer returned by the server. m=3Dapplication 9 UDP/DTLS/BFCP * a=3Dsetup:active a=3Dfingerprint:SHA-1 \ 3D:B4:7B:E3:CC:FC:0D:1B:5D:31:33:9E:48:9B:67:FE:68:40:E8:21 a=3Dfloorctrl:s-only a=3Dconfid:4321 a=3Duserid:1234=09 a=3Dfloorid:1 mstrm:10 a=3Dfloorid:2 mstrm:11 m=3Daudio 55000 RTP/AVP 0 m=3Dvideo 55002 RTP/AVP 31 Cheers, Charles > -----Original Message----- > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On > Behalf Of Tom Kristensen (tomkrist) > Sent: Monday, June 04, 2012 10:54 PM > To: Chelliah Sivachelvan (chelliah) > Cc: Lorenzo Miniero; bfcpbis@ietf.org; Tom Kristensen; Gonzalo > Camarillo > Subject: [bfcpbis] rfc4583bis TLS SDP example - Re: More comments on > RFC 4582 >=20 > On 06/04/2012 04:22 PM, Chelliah Sivachelvan (chelliah) wrote: > > Tom, > > > > A minor comment on the SDP example in section 9. In the context of > DTLS, > > the setup a line must be "actpass" in the offer. See excerpts from > RFC > > 5763: > > > > [ The endpoint that is the offerer MUST use the setup attribute > > value of setup:actpass and be prepared to receive a > client_hello > > before it receives the answer.] > > > Yes, this is true for DTLS usage (UDP/TLS/BFCP). However, the example > is > the original example from RFC 4582 related to TLS (TCP/TLS/BFCP). So I > believe the example in rfc4583bis is correct! >=20 > -- Tom > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From tomkrist@cisco.com Tue Jun 5 22:50:09 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC3B21F8566 for ; Tue, 5 Jun 2012 22:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.624 X-Spam-Level: X-Spam-Status: No, score=-9.624 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAAlFFTU+87Z for ; Tue, 5 Jun 2012 22:50:08 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 92F7E21F855F for ; Tue, 5 Jun 2012 22:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=2576; q=dns/txt; s=iport; t=1338961808; x=1340171408; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=duNK52gW/bSjiCoZAL9x9lVSeImwN75CpS+uZ7gZRtI=; b=cm8ATqmJ/gJNszD3B++bSGEUCoPBq+17kyC/AcflX4aoFK3E96Ei1eXk fABjunGMZQBfNpT54ryIwtbNZLeU2Z/9n7tFHUFZRyaDmSUUtmyrnnJmw OPParNrlUYa/N9aUIAnT03i+/g4yt6aLMDupC4DrN05biXQX/sdQB7TJQ 8=; X-IronPort-AV: E=Sophos;i="4.75,722,1330905600"; d="scan'208";a="5422838" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 06 Jun 2012 05:50:07 +0000 Received: from [10.55.82.232] (dhcp-10-55-82-232.cisco.com [10.55.82.232]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q565o7jS028012; Wed, 6 Jun 2012 05:50:07 GMT Message-ID: <4FCEEF8F.1090903@cisco.com> Date: Wed, 06 Jun 2012 07:50:07 +0200 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <20120604131529.133a66fa@lminiero-acer><4FCCB52E.5010109@cisco.com> <4FCD9EF5.80106@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bfcpbis@ietf.org, "Chelliah Sivachelvan \(chelliah\)" Subject: Re: [bfcpbis] rfc4583bis TLS SDP example - Re: More comments on RFC 4582 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 05:50:09 -0000 Sure, a good idea to add an accompanying DTLS example. If no objections are received, this will be part of the next version of the draft. -- Tom On 06/05/2012 07:19 PM, Charles Eckel (eckelcu) wrote: > I agree, however, perhaps it would be useful to add a second example in > which an endpoint initiates the offer and uses DTLS; e.g.: > > Offer from client: > > m=application 50000 UDP/DTLS/BFCP * > a=setup:actpass > a=fingerprint:SHA-1 \ > 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB > a=floorctrl:c-only, s-only > a=confid:4321 > a=userid:1234 > a=floorid:1 mstrm:10 > a=floorid:2 mstrm:11 > m=audio 50002 RTP/AVP 0 > a=label:10 > m=video 50004 RTP/AVP 31 > a=label:11 > > The following is the answer returned by the server. > > m=application 9 UDP/DTLS/BFCP * > a=setup:active > a=fingerprint:SHA-1 \ > 3D:B4:7B:E3:CC:FC:0D:1B:5D:31:33:9E:48:9B:67:FE:68:40:E8:21 > a=floorctrl:s-only > a=confid:4321 > a=userid:1234 > a=floorid:1 mstrm:10 > a=floorid:2 mstrm:11 > m=audio 55000 RTP/AVP 0 > m=video 55002 RTP/AVP 31 > > Cheers, > Charles > > >> -----Original Message----- >> From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On >> Behalf Of Tom Kristensen (tomkrist) >> Sent: Monday, June 04, 2012 10:54 PM >> To: Chelliah Sivachelvan (chelliah) >> Cc: Lorenzo Miniero; bfcpbis@ietf.org; Tom Kristensen; Gonzalo >> Camarillo >> Subject: [bfcpbis] rfc4583bis TLS SDP example - Re: More comments on >> RFC 4582 >> >> On 06/04/2012 04:22 PM, Chelliah Sivachelvan (chelliah) wrote: >> >>> Tom, >>> >>> A minor comment on the SDP example in section 9. In the context of >>> >> DTLS, >> >>> the setup a line must be "actpass" in the offer. See excerpts from >>> >> RFC >> >>> 5763: >>> >>> [ The endpoint that is the offerer MUST use the setup >>> > attribute > >>> value of setup:actpass and be prepared to receive a >>> >> client_hello >> >>> before it receives the answer.] >>> >>> >> Yes, this is true for DTLS usage (UDP/TLS/BFCP). However, the example >> is >> the original example from RFC 4582 related to TLS (TCP/TLS/BFCP). So I >> believe the example in rfc4583bis is correct! >> >> -- Tom >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >> From tomkrist@cisco.com Wed Jun 6 01:32:53 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3DD21F8853 for ; Wed, 6 Jun 2012 01:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.459 X-Spam-Level: X-Spam-Status: No, score=-9.459 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hVbMUtOr2id for ; Wed, 6 Jun 2012 01:32:52 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 7A24E21F8852 for ; Wed, 6 Jun 2012 01:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=2836; q=dns/txt; s=iport; t=1338971572; x=1340181172; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=5/WcxpA3H0Jg5xsUdJw38EbGJBcdx1NQrJxlYaqr8Q8=; b=W5e3tMCbMUkUGylKK9saFauPOHoHqo8EszD1KYQDy1yV7aBh0VUZ9aj8 2/GZ1RbtCapfwR4N2Iz/fWNPcPyJx7DSuWGPqbx9tGsOCMiBbX8G7t+D+ rgZRRZ3Wj0HA0xdeBfTs+YN6UIAhihO5aDfsRZx2t8odHnieO69KuVRN1 g=; X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="5433138" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 06 Jun 2012 08:32:51 +0000 Received: from [10.55.82.232] (dhcp-10-55-82-232.cisco.com [10.55.82.232]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q568WpBT003331; Wed, 6 Jun 2012 08:32:51 GMT Message-ID: <4FCF15B2.1010008@cisco.com> Date: Wed, 06 Jun 2012 10:32:50 +0200 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: Tom Kristensen References: <20120604131529.133a66fa@lminiero-acer><4FCCB52E.5010109@cisco.com> <4FCD9EF5.80106@cisco.com> <4FCEEF8F.1090903@cisco.com> In-Reply-To: <4FCEEF8F.1090903@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bfcpbis@ietf.org, "Charles Eckel \(eckelcu\)" , "Chelliah Sivachelvan \(chelliah\)" Subject: Re: [bfcpbis] rfc4583bis TLS SDP example - Re: More comments on RFC 4582 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 08:32:53 -0000 Just for the record: Will change Charles' UDP/DTLS/BFCP in the example below ==> UDP/TLS/BFCP. -- Tom On 06/06/2012 07:50 AM, Tom Kristensen wrote: > Sure, a good idea to add an accompanying DTLS example. If no > objections are received, this will be part of the next version of the > draft. > > -- Tom > > On 06/05/2012 07:19 PM, Charles Eckel (eckelcu) wrote: >> I agree, however, perhaps it would be useful to add a second example in >> which an endpoint initiates the offer and uses DTLS; e.g.: >> >> Offer from client: >> >> m=application 50000 UDP/DTLS/BFCP * >> a=setup:actpass >> a=fingerprint:SHA-1 \ >> 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB >> a=floorctrl:c-only, s-only >> a=confid:4321 >> a=userid:1234 >> a=floorid:1 mstrm:10 >> a=floorid:2 mstrm:11 >> m=audio 50002 RTP/AVP 0 >> a=label:10 >> m=video 50004 RTP/AVP 31 >> a=label:11 >> >> The following is the answer returned by the server. >> >> m=application 9 UDP/DTLS/BFCP * >> a=setup:active >> a=fingerprint:SHA-1 \ >> 3D:B4:7B:E3:CC:FC:0D:1B:5D:31:33:9E:48:9B:67:FE:68:40:E8:21 >> a=floorctrl:s-only >> a=confid:4321 >> a=userid:1234 >> a=floorid:1 mstrm:10 >> a=floorid:2 mstrm:11 >> m=audio 55000 RTP/AVP 0 >> m=video 55002 RTP/AVP 31 >> >> Cheers, >> Charles >> >>> -----Original Message----- >>> From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On >>> Behalf Of Tom Kristensen (tomkrist) >>> Sent: Monday, June 04, 2012 10:54 PM >>> To: Chelliah Sivachelvan (chelliah) >>> Cc: Lorenzo Miniero; bfcpbis@ietf.org; Tom Kristensen; Gonzalo >>> Camarillo >>> Subject: [bfcpbis] rfc4583bis TLS SDP example - Re: More comments on >>> RFC 4582 >>> >>> On 06/04/2012 04:22 PM, Chelliah Sivachelvan (chelliah) wrote: >>>> Tom, >>>> >>>> A minor comment on the SDP example in section 9. In the context of >>> DTLS, >>>> the setup a line must be "actpass" in the offer. See excerpts from >>> RFC >>>> 5763: >>>> >>>> [ The endpoint that is the offerer MUST use the setup >> attribute >>>> value of setup:actpass and be prepared to receive a >>> client_hello >>>> before it receives the answer.] >>>> >>> Yes, this is true for DTLS usage (UDP/TLS/BFCP). However, the example >>> is >>> the original example from RFC 4582 related to TLS (TCP/TLS/BFCP). So I >>> believe the example in rfc4583bis is correct! >>> >>> -- 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 > From ernst.horvath@siemens-enterprise.com Fri Jun 15 05:56:33 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E779F21F8589 for ; Fri, 15 Jun 2012 05:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZ3GaOszocJv for ; Fri, 15 Jun 2012 05:56:33 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 53A9321F857F for ; Fri, 15 Jun 2012 05:56:30 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id ABF5323F04F6 for ; Fri, 15 Jun 2012 14:56:29 +0200 (CEST) Received: from MCHP03MSX.global-ad.net ([169.254.2.115]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.01.0339.001; Fri, 15 Jun 2012 14:56:29 +0200 From: "Horvath, Ernst" To: "bfcpbis@ietf.org" Thread-Topic: RFC4582bis: What is the transaction model behind Error/ErrorAck? Thread-Index: Ac1K9kZJSdtXBXd9T9+etIqh4qBCyA== Date: Fri, 15 Jun 2012 12:56:29 +0000 Message-ID: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.26.0.183] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [bfcpbis] RFC4582bis: What is the transaction model behind Error/ErrorAck? X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 12:56:34 -0000 Hi, I have a problem understanding the use of ErrorAck. For unreliable transport RFC4582bis describes two transaction types: 1) Client-initiated: A client (chair or participant) sends a request to the= server and receives a Status or an Error message back; the client runs T1 = and retransmits the request if no response arrives in time, but the server = does not run T1 and does not retransmit the response (Status or Error) unle= ss triggered by receipt of a retransmitted request. The client does not sen= d a StatusAck for the response. 2) Server-initiated: The server sends a notification (i.e. a follow-up stat= us message) to the client and receives a StatusAck back. The server runs T1= and retransmits the notification if no StatusAck arrives, but the client d= oes not retransmit the StatusAck unless triggered by a retransmitted notifi= cation.=20 (Question: Can the client send an Error message instead of StatusAck? Error= seems to be reserved for the direction server to client, but the draft is = not 100% clear about that.) Now, how does ErrorAck fit in? Error is the backward message in a two-step = (request/reponse) transaction model, and BFCPbis did not introduce a three-= step (request/response/ack) model, right? Or can Error be used as a transac= tion-initiating request, with ErrorAck forming the response? If so, this is= currently not described. Regards, Ernst Horvath= From eckelcu@cisco.com Tue Jun 19 11:58:23 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793C511E8144 for ; Tue, 19 Jun 2012 11:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+5Mkqha9xXL for ; Tue, 19 Jun 2012 11:58:22 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id C93E411E8135 for ; Tue, 19 Jun 2012 11:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3166; q=dns/txt; s=iport; t=1340132303; x=1341341903; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=rIjREVi/uhkqXius+FWOAifxnY3AlgYm2KWzFwJBUcg=; b=dda2xskDVIw0CUsQMXHkT4TJ70nwWTk7AbEgUSamPYsSjjEd0PMEgCtD 4jwuT9I3JNokBaQwY440anuLL78j/VJF48nJ0f5dGKB0ypkgw69hOuuWs MfdlRmS/H8gLjLrGukO8wS/znOwPUSJgiaaS04jAAJWB+RWoUW10nGJe4 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGHL4E+rRDoG/2dsb2JhbABFtWqBB4IYAQEBBAEBAQ8BHQo0FwYBCBEEAQELBhcBByYfCQkBBAESCBqHaAELmSGgOQSCQYhuhTlgA4hDlg4BhGqBZoMAgTYH X-IronPort-AV: E=Sophos;i="4.75,799,1330905600"; d="scan'208";a="46951243" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 19 Jun 2012 18:58:22 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5JIwMvZ029723; Tue, 19 Jun 2012 18:58:22 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Jun 2012 11:58:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jun 2012 11:58:21 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [bfcpbis] RFC4582bis: What is the transaction model behindError/ErrorAck? Thread-Index: Ac1OTX9TZCpfQ9MxRY+b6QQ9g+King== From: "Charles Eckel (eckelcu)" To: "Horvath, Ernst" , X-OriginalArrivalTime: 19 Jun 2012 18:58:22.0278 (UTC) FILETIME=[7F898660:01CD4E4D] Subject: Re: [bfcpbis] RFC4582bis: What is the transaction model behindError/ErrorAck? X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 18:58:23 -0000 (as an individual)=20 Hi Ernst, This is a good question. Looking at RFC 4582, table 1 shows the Error primitive as being for Server to Client/Participant only. The details in section 5.3.1.13 and the rest of the RFC are consistent with this. In all cases, the Error primitive from the server is in response to a client request primitive. Section 13.8 states: 13.8. Error Message Generation Error messages are always sent in response to a previous message from the client as part of a client-initiated transaction. The changes made to address unreliable transport in draft-ietf-bfcpbis-rfc4582bis-03 add scenarios in which an Error primitive may be sent by either a client or a server. These scenarios include invalid payload length and not being able to parse a BFCP message in general. I believe the tables and corresponding sections in RFC 4582 need to be updated to reflect this change consistently. As for the ErrorAck message, while it could be argued that it is not strictly necessary, the bis draft does consistently state it as being required. The main benefit is that it allows both sides to unambiguously complete the transaction. I believe the corresponding text is okay as is. Cheers, Charles > -----Original Message----- > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On > Behalf Of Horvath, Ernst > Sent: Friday, June 15, 2012 5:56 AM > To: bfcpbis@ietf.org > Subject: [bfcpbis] RFC4582bis: What is the transaction model > behindError/ErrorAck? >=20 > Hi, >=20 > I have a problem understanding the use of ErrorAck. >=20 > For unreliable transport RFC4582bis describes two transaction types: >=20 > 1) Client-initiated: A client (chair or participant) sends a request to the > server and receives a Status or an Error message back; the client runs T1 and > retransmits the request if no response arrives in time, but the server does > not run T1 and does not retransmit the response (Status or Error) unless > triggered by receipt of a retransmitted request. The client does not send a > StatusAck for the response. >=20 > 2) Server-initiated: The server sends a notification (i.e. a follow-up status > message) to the client and receives a StatusAck back. The server runs T1 and > retransmits the notification if no StatusAck arrives, but the client does not > retransmit the StatusAck unless triggered by a retransmitted notification. > (Question: Can the client send an Error message instead of StatusAck? Error > seems to be reserved for the direction server to client, but the draft is not > 100% clear about that.) >=20 > Now, how does ErrorAck fit in? Error is the backward message in a two-step > (request/reponse) transaction model, and BFCPbis did not introduce a > three-step (request/response/ack) model, right? Or can Error be used as a > transaction-initiating request, with ErrorAck forming the response? If so, > this is currently not described. >=20 > Regards, > Ernst Horvath > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From ernst.horvath@siemens-enterprise.com Wed Jun 20 00:18:28 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA1F21F8704 for ; Wed, 20 Jun 2012 00:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQbdotWKTMae for ; Wed, 20 Jun 2012 00:18:27 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 73B0821F8703 for ; Wed, 20 Jun 2012 00:18:27 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 3629D23F058C; Wed, 20 Jun 2012 09:18:24 +0200 (CEST) Received: from MCHP03MSX.global-ad.net ([169.254.2.115]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Wed, 20 Jun 2012 09:18:23 +0200 From: "Horvath, Ernst" To: "Charles Eckel (eckelcu)" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] RFC4582bis: What is the transaction model behindError/ErrorAck? Thread-Index: Ac1OTX9TZCpfQ9MxRY+b6QQ9g+KingAYw6Ug Date: Wed, 20 Jun 2012 07:18:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.26.0.183] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [bfcpbis] RFC4582bis: What is the transaction model behindError/ErrorAck? X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 07:18:28 -0000 Charles,=20 Well, I did not find answers in the existing text to questions such as: - Is ErrorAck sent in reply to every Error message, or only in some cases? - Which transaction ID is used in ErrorAck? I assume the one from the origi= nal request, but then we would have the 3-stage transaction model I mention= ed in my original mail.=20 - Would the sender retransmit the Error message if it does not receive Erro= rAck? Then the sender would need to keep state and run timer T1 for respons= es, which is currently not described. - Can Error create its own transaction, using a new transaction ID, e.g. if= a datagram could not be parsed? I guess some additional text is needed to clarify the use of Error/ErrorAck= in general, and maybe some specific failure scenarios deserve their own de= scription. =20 Regards, Ernst > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: Dienstag, 19. Juni 2012 20:58 > To: Horvath, Ernst; bfcpbis@ietf.org > Subject: RE: [bfcpbis] RFC4582bis: What is the transaction=20 > model behindError/ErrorAck? >=20 > (as an individual)=20 >=20 > Hi Ernst, >=20 > This is a good question. Looking at RFC 4582, table 1 shows the Error > primitive as being for Server to Client/Participant only. The=20 > details in > section 5.3.1.13 and the rest of the RFC are consistent with this. In > all cases, the Error primitive from the server is in response to a > client request primitive. Section 13.8 states: >=20 > 13.8. Error Message Generation >=20 > Error messages are always sent in response to a previous=20 > message from > the client as part of a client-initiated transaction. >=20 > The changes made to address unreliable transport in > draft-ietf-bfcpbis-rfc4582bis-03 add scenarios in which an Error > primitive may be sent by either a client or a server. These scenarios > include invalid payload length and not being able to parse a BFCP > message in general. I believe the tables and corresponding sections in > RFC 4582 need to be updated to reflect this change consistently. > As for the ErrorAck message, while it could be argued that it is not > strictly necessary, the bis draft does consistently state it as being > required. The main benefit is that it allows both sides to=20 > unambiguously > complete the transaction. I believe the corresponding text is okay as > is. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On > > Behalf Of Horvath, Ernst > > Sent: Friday, June 15, 2012 5:56 AM > > To: bfcpbis@ietf.org > > Subject: [bfcpbis] RFC4582bis: What is the transaction model > > behindError/ErrorAck? > >=20 > > Hi, > >=20 > > I have a problem understanding the use of ErrorAck. > >=20 > > For unreliable transport RFC4582bis describes two transaction types: > >=20 > > 1) Client-initiated: A client (chair or participant) sends a request > to the > > server and receives a Status or an Error message back; the=20 > client runs > T1 and > > retransmits the request if no response arrives in time, but=20 > the server > does > > not run T1 and does not retransmit the response (Status or Error) > unless > > triggered by receipt of a retransmitted request. The client does not > send a > > StatusAck for the response. > >=20 > > 2) Server-initiated: The server sends a notification (i.e.=20 > a follow-up > status > > message) to the client and receives a StatusAck back. The=20 > server runs > T1 and > > retransmits the notification if no StatusAck arrives, but the client > does not > > retransmit the StatusAck unless triggered by a retransmitted > notification. > > (Question: Can the client send an Error message instead of=20 > StatusAck? > Error > > seems to be reserved for the direction server to client,=20 > but the draft > is not > > 100% clear about that.) > >=20 > > Now, how does ErrorAck fit in? Error is the backward message in a > two-step > > (request/reponse) transaction model, and BFCPbis did not introduce a > > three-step (request/response/ack) model, right? Or can Error be used > as a > > transaction-initiating request, with ErrorAck forming the=20 > response? If > so, > > this is currently not described. > >=20 > > Regards, > > Ernst Horvath > > _______________________________________________ > > bfcpbis mailing list > > bfcpbis@ietf.org > > https://www.ietf.org/mailman/listinfo/bfcpbis > = From eckelcu@cisco.com Thu Jun 21 15:30:15 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C787411E8093 for ; Thu, 21 Jun 2012 15:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZimFrWKACrTb for ; Thu, 21 Jun 2012 15:30:14 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A4DB711E8079 for ; Thu, 21 Jun 2012 15:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=6924; q=dns/txt; s=iport; t=1340317814; x=1341527414; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=egRbgveBnjCOZT92tUoyi0+HeYb2/mEKVHxi0HjnEwQ=; b=JHkpu+brLxVRaSj0ITVDlkphVFO2TN8uGyXUDtSsm9RAqpoH/R3mnT/j 5LFwCb7oQ2DeZ32s44gY4iZAGJU5svUxFp6BxCDGrQIXp5A/IAry/4x8T uxjhG19Vf2NF4IqRZ0FKsezquoT8mEgDOYMktGgpX5Mdd4YMU2AoebN6G 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAag40+tJXG+/2dsb2JhbABFtVeBB4IYAQEBBAEBAQ8BJzQGEQQCAQgRBAEBCxQJBycLFAkIAgQBEggah2gBC5oLoBIEgkGIbRqFCGADnlgBhGyBZoJfgVYFAgI X-IronPort-AV: E=Sophos;i="4.77,454,1336348800"; d="scan'208";a="94732525" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 21 Jun 2012 22:30:14 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5LMUDCX013904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Jun 2012 22:30:14 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.248]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Thu, 21 Jun 2012 17:30:13 -0500 From: "Charles Eckel (eckelcu)" To: "Horvath, Ernst" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] RFC4582bis: What is the transaction model behindError/ErrorAck? Thread-Index: AQHNTrTiz/xmitc28EeHhoXKx6yXbZcFU0+Q Date: Thu, 21 Jun 2012 22:29:08 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882801AAF4@xmb-aln-x08.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.122.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18988.001 x-tm-as-result: No--63.281400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [bfcpbis] RFC4582bis: What is the transaction model behindError/ErrorAck? X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 22:30:15 -0000 Hi Ernst, I agree with you that specification of Error and ErrorAck within this draft= needs some work. When I stated that the corresponding text was okay as is,= I meant that in regard to the sending of ErrorAck primitives only. However= , upon closer inspection, I am reconsidering.=20 In RFC 4582, the Error message is always a response, as you correctly point= ed out. As such, there is not a real need for an ErrorAck. This is similar = to the FloorRelease/FloorRequestStatus exchange. In this case, a FloorReque= stStatusAck is not necessary. Similarly, if a server responds to a client i= nitiated transaction message with an Error, that should complete the transa= ction without the need for an ErrorAck. The current draft includes new cases in which an Error message may be sent,= including upon receiving a message with invalid payload length or an unsup= ported BFCP version. You correctly point out that the usage of Error/ErrorA= ck in these scenarios is underspecified. I'd like to propose that we restri= ct this new usage as well to cases in which a server is responding to a cli= ent initiated transaction. I believe this remains consistent with the spiri= t of the Error message in RFC 4582 and removes the need for the ErrorAck. Cheers, Charles > -----Original Message----- > From: Horvath, Ernst [mailto:ernst.horvath@siemens-enterprise.com] > Sent: Wednesday, June 20, 2012 12:18 AM > To: Charles Eckel (eckelcu); bfcpbis@ietf.org > Subject: RE: [bfcpbis] RFC4582bis: What is the transaction model > behindError/ErrorAck? >=20 > Charles, >=20 > Well, I did not find answers in the existing text to questions such as: >=20 > - Is ErrorAck sent in reply to every Error message, or only in some cases= ? For each Error messages. My suggested change to section 13.9 is as follows: When communicating over unreliable transport and upon receiving an Error message from a floor control server, the participant MUST respond with a ErrorAck message within the transaction failure window to complete the transaction. Change to: When communicating over unreliable transport and upon receiving an Error message, the recipient MUST respond with a ErrorAck message=20 within the transaction failure window to complete the transaction. > - Which transaction ID is used in ErrorAck? I assume the one from the > original request, but then we would have the 3-stage transaction model I > mentioned in my original mail. The transaction ID should match that specified in the Error message. > - Would the sender retransmit the Error message if it does not receive > ErrorAck? Then the sender would need to keep state and run timer T1 for > responses, which is currently not described. > - Can Error create its own transaction, using a new transaction ID, e.g. = if a > datagram could not be parsed? >=20 > I guess some additional text is needed to clarify the use of Error/ErrorA= ck in > general, and maybe some specific failure scenarios deserve their own > description. >=20 > Regards, > Ernst >=20 >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: Dienstag, 19. Juni 2012 20:58 > > To: Horvath, Ernst; bfcpbis@ietf.org > > Subject: RE: [bfcpbis] RFC4582bis: What is the transaction > > model behindError/ErrorAck? > > > > (as an individual) > > > > Hi Ernst, > > > > This is a good question. Looking at RFC 4582, table 1 shows the Error > > primitive as being for Server to Client/Participant only. The > > details in > > section 5.3.1.13 and the rest of the RFC are consistent with this. In > > all cases, the Error primitive from the server is in response to a > > client request primitive. Section 13.8 states: > > > > 13.8. Error Message Generation > > > > Error messages are always sent in response to a previous > > message from > > the client as part of a client-initiated transaction. > > > > The changes made to address unreliable transport in > > draft-ietf-bfcpbis-rfc4582bis-03 add scenarios in which an Error > > primitive may be sent by either a client or a server. These scenarios > > include invalid payload length and not being able to parse a BFCP > > message in general. I believe the tables and corresponding sections in > > RFC 4582 need to be updated to reflect this change consistently. > > As for the ErrorAck message, while it could be argued that it is not > > strictly necessary, the bis draft does consistently state it as being > > required. The main benefit is that it allows both sides to > > unambiguously > > complete the transaction. I believe the corresponding text is okay as > > is. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On > > > Behalf Of Horvath, Ernst > > > Sent: Friday, June 15, 2012 5:56 AM > > > To: bfcpbis@ietf.org > > > Subject: [bfcpbis] RFC4582bis: What is the transaction model > > > behindError/ErrorAck? > > > > > > Hi, > > > > > > I have a problem understanding the use of ErrorAck. > > > > > > For unreliable transport RFC4582bis describes two transaction types: > > > > > > 1) Client-initiated: A client (chair or participant) sends a request > > to the > > > server and receives a Status or an Error message back; the > > client runs > > T1 and > > > retransmits the request if no response arrives in time, but > > the server > > does > > > not run T1 and does not retransmit the response (Status or Error) > > unless > > > triggered by receipt of a retransmitted request. The client does not > > send a > > > StatusAck for the response. > > > > > > 2) Server-initiated: The server sends a notification (i.e. > > a follow-up > > status > > > message) to the client and receives a StatusAck back. The > > server runs > > T1 and > > > retransmits the notification if no StatusAck arrives, but the client > > does not > > > retransmit the StatusAck unless triggered by a retransmitted > > notification. > > > (Question: Can the client send an Error message instead of > > StatusAck? > > Error > > > seems to be reserved for the direction server to client, > > but the draft > > is not > > > 100% clear about that.) > > > > > > Now, how does ErrorAck fit in? Error is the backward message in a > > two-step > > > (request/reponse) transaction model, and BFCPbis did not introduce a > > > three-step (request/response/ack) model, right? Or can Error be used > > as a > > > transaction-initiating request, with ErrorAck forming the > > response? If > > so, > > > this is currently not described. > > > > > > Regards, > > > Ernst Horvath > > > _______________________________________________ > > > bfcpbis mailing list > > > bfcpbis@ietf.org > > > https://www.ietf.org/mailman/listinfo/bfcpbis > > From tomkrist@cisco.com Fri Jun 22 06:18:30 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719E121F85D3 for ; Fri, 22 Jun 2012 06:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+8bs6I6s30T for ; Fri, 22 Jun 2012 06:18:29 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id CFC9021F8592 for ; Fri, 22 Jun 2012 06:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=7857; q=dns/txt; s=iport; t=1340371109; x=1341580709; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=SdY97OqPKrGssCu10mRMzK/elk2EiP6Sh+yJxdMUdSc=; b=UgtNxYy1kzSDmf91CKgpVOL9+Dkv1kAQxnynIaRAvLj2Cpo5ha9NQQMz 4JS0LwTJh+chRDhoXUJ7nQV/cgQ8FDu+TxiIKuQPWjQZx0iqmnN/ZHfek 0w266NXLWh2ctTaRw19fhWlTz3afrTQ3B5rFV8cVZnlK6+L0Xdlw/0bzk I=; X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="6112107" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 22 Jun 2012 13:18:28 +0000 Received: from [10.55.88.51] (dhcp-10-55-88-51.cisco.com [10.55.88.51]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5MDIRAI020346; Fri, 22 Jun 2012 13:18:27 GMT Message-ID: <4FE470A3.8020506@cisco.com> Date: Fri, 22 Jun 2012 15:18:27 +0200 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" References: <92B7E61ADAC1BB4F941F943788C0882801AAF4@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882801AAF4@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Horvath, Ernst" , "bfcpbis@ietf.org" Subject: Re: [bfcpbis] RFC4582bis: What is the transaction model behindError/ErrorAck? X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 13:18:30 -0000 I concur with the conclusions here, the ErrorAck does not have any actual need and use. So thanks to Ernst for spotting this issue and to Charles for analysis. Given no protests over the weekend, the ErrorAck will be removed from the next draft version. -- Tom On 06/22/2012 12:29 AM, Charles Eckel (eckelcu) wrote: > Hi Ernst, > > I agree with you that specification of Error and ErrorAck within this draft needs some work. When I stated that the corresponding text was okay as is, I meant that in regard to the sending of ErrorAck primitives only. However, upon closer inspection, I am reconsidering. > In RFC 4582, the Error message is always a response, as you correctly pointed out. As such, there is not a real need for an ErrorAck. This is similar to the FloorRelease/FloorRequestStatus exchange. In this case, a FloorRequestStatusAck is not necessary. Similarly, if a server responds to a client initiated transaction message with an Error, that should complete the transaction without the need for an ErrorAck. > The current draft includes new cases in which an Error message may be sent, including upon receiving a message with invalid payload length or an unsupported BFCP version. You correctly point out that the usage of Error/ErrorAck in these scenarios is underspecified. I'd like to propose that we restrict this new usage as well to cases in which a server is responding to a client initiated transaction. I believe this remains consistent with the spirit of the Error message in RFC 4582 and removes the need for the ErrorAck. > > Cheers, > Charles > > >> -----Original Message----- >> From: Horvath, Ernst [mailto:ernst.horvath@siemens-enterprise.com] >> Sent: Wednesday, June 20, 2012 12:18 AM >> To: Charles Eckel (eckelcu); bfcpbis@ietf.org >> Subject: RE: [bfcpbis] RFC4582bis: What is the transaction model >> behindError/ErrorAck? >> >> Charles, >> >> Well, I did not find answers in the existing text to questions such as: >> >> - Is ErrorAck sent in reply to every Error message, or only in some cases? >> > For each Error messages. My suggested change to section 13.9 is as follows: > > When communicating over unreliable transport and upon receiving an > Error message from a floor control server, the participant MUST > respond with a ErrorAck message within the transaction failure window > to complete the transaction. > > Change to: > > When communicating over unreliable transport and upon receiving an > Error message, the recipient MUST respond with a ErrorAck message > within the transaction failure window to complete the transaction. > > >> - Which transaction ID is used in ErrorAck? I assume the one from the >> original request, but then we would have the 3-stage transaction model I >> mentioned in my original mail. >> > The transaction ID should match that specified in the Error message. > > > >> - Would the sender retransmit the Error message if it does not receive >> ErrorAck? Then the sender would need to keep state and run timer T1 for >> responses, which is currently not described. >> - Can Error create its own transaction, using a new transaction ID, e.g. if a >> datagram could not be parsed? >> >> I guess some additional text is needed to clarify the use of Error/ErrorAck in >> general, and maybe some specific failure scenarios deserve their own >> description. >> >> Regards, >> Ernst >> >> >> >>> -----Original Message----- >>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] >>> Sent: Dienstag, 19. Juni 2012 20:58 >>> To: Horvath, Ernst; bfcpbis@ietf.org >>> Subject: RE: [bfcpbis] RFC4582bis: What is the transaction >>> model behindError/ErrorAck? >>> >>> (as an individual) >>> >>> Hi Ernst, >>> >>> This is a good question. Looking at RFC 4582, table 1 shows the Error >>> primitive as being for Server to Client/Participant only. The >>> details in >>> section 5.3.1.13 and the rest of the RFC are consistent with this. In >>> all cases, the Error primitive from the server is in response to a >>> client request primitive. Section 13.8 states: >>> >>> 13.8. Error Message Generation >>> >>> Error messages are always sent in response to a previous >>> message from >>> the client as part of a client-initiated transaction. >>> >>> The changes made to address unreliable transport in >>> draft-ietf-bfcpbis-rfc4582bis-03 add scenarios in which an Error >>> primitive may be sent by either a client or a server. These scenarios >>> include invalid payload length and not being able to parse a BFCP >>> message in general. I believe the tables and corresponding sections in >>> RFC 4582 need to be updated to reflect this change consistently. >>> As for the ErrorAck message, while it could be argued that it is not >>> strictly necessary, the bis draft does consistently state it as being >>> required. The main benefit is that it allows both sides to >>> unambiguously >>> complete the transaction. I believe the corresponding text is okay as >>> is. >>> >>> Cheers, >>> Charles >>> >>> >>>> -----Original Message----- >>>> From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On >>>> Behalf Of Horvath, Ernst >>>> Sent: Friday, June 15, 2012 5:56 AM >>>> To: bfcpbis@ietf.org >>>> Subject: [bfcpbis] RFC4582bis: What is the transaction model >>>> behindError/ErrorAck? >>>> >>>> Hi, >>>> >>>> I have a problem understanding the use of ErrorAck. >>>> >>>> For unreliable transport RFC4582bis describes two transaction types: >>>> >>>> 1) Client-initiated: A client (chair or participant) sends a request >>>> >>> to the >>> >>>> server and receives a Status or an Error message back; the >>>> >>> client runs >>> T1 and >>> >>>> retransmits the request if no response arrives in time, but >>>> >>> the server >>> does >>> >>>> not run T1 and does not retransmit the response (Status or Error) >>>> >>> unless >>> >>>> triggered by receipt of a retransmitted request. The client does not >>>> >>> send a >>> >>>> StatusAck for the response. >>>> >>>> 2) Server-initiated: The server sends a notification (i.e. >>>> >>> a follow-up >>> status >>> >>>> message) to the client and receives a StatusAck back. The >>>> >>> server runs >>> T1 and >>> >>>> retransmits the notification if no StatusAck arrives, but the client >>>> >>> does not >>> >>>> retransmit the StatusAck unless triggered by a retransmitted >>>> >>> notification. >>> >>>> (Question: Can the client send an Error message instead of >>>> >>> StatusAck? >>> Error >>> >>>> seems to be reserved for the direction server to client, >>>> >>> but the draft >>> is not >>> >>>> 100% clear about that.) >>>> >>>> Now, how does ErrorAck fit in? Error is the backward message in a >>>> >>> two-step >>> >>>> (request/reponse) transaction model, and BFCPbis did not introduce a >>>> three-step (request/response/ack) model, right? Or can Error be used >>>> >>> as a >>> >>>> transaction-initiating request, with ErrorAck forming the >>>> >>> response? If >>> so, >>> >>>> this is currently not described. >>>> >>>> Regards, >>>> Ernst Horvath >>>> _______________________________________________ >>>> 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 > From tomkrist@cisco.com Fri Jun 22 07:01:54 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F2521F84B3 for ; Fri, 22 Jun 2012 07:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSf7hJ0lEPHJ for ; Fri, 22 Jun 2012 07:01:54 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id E90F221F84B2 for ; Fri, 22 Jun 2012 07:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=901; q=dns/txt; s=iport; t=1340373714; x=1341583314; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=PbTS9mYCU4QNXS0kBQL8SvxthS2RtrruL3pPKMxzDWM=; b=IPFEQGu+5Fuia6M/mch7v4oWQWwe7+o99JWUHTsavYAC2eSTM6k4jSUE R/pegXAhVxP2mYodKAKbJ8ip63joFmyPE+DT5gfo4Ms1m4SRwgd5Dg3jd UZ93hwIdKSnmSOflwcxd1Xd3Y1lMtenAMQUv/U8NpixyvEa2iMBZP/beE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQJAN555E+Q/khN/2dsb2JhbABFshuCFwQEgSqBB4IYAQEBBBIBJTAQARALDgoJFg8JAwIBAgFFBg0BBwEBHodpmhCgEYsuhgIDlSyFVoNYAYRsgWaCYQ X-IronPort-AV: E=Sophos;i="4.77,458,1336348800"; d="scan'208";a="6114187" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 22 Jun 2012 14:01:53 +0000 Received: from [10.55.95.75] (dhcp-10-55-95-75.cisco.com [10.55.95.75]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5ME1q8j022957; Fri, 22 Jun 2012 14:01:52 GMT Message-ID: <4FE47AD0.5090603@cisco.com> Date: Fri, 22 Jun 2012 16:01:52 +0200 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: Woo Johnman References: <4FCCB307.40001@cisco.com> In-Reply-To: <4FCCB307.40001@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bfcpbis@ietf.org, 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] transaction issue X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 14:01:54 -0000 On 06/04/2012 03:07 PM, Tom Kristensen wrote: > On 06/01/2012 11:59 AM, Woo Johnman wrote: >> Hi, >> The RFC4582bis says:"As described in previous paragraph every entity - >> client or server - is only allowed to send one request at a time, and >> await the acknowledging response." >> I think the condition of only one pending request at a time is too hard. >> Is it more suitable that there is one pending request at a time per >> conference >> or ever per connection(client-server)? > Woo, > > Thanks for the comment. I have to read the text chunks related to this > once more and rethink this approach; I'll be back! So, I have always assumed the restrictions to send one request at a time, applied per connection/association between one client-server pair. I'm ready to change and clarify the draft text to express just that. Any protests/other views out there? -- Tom From eckelcu@cisco.com Fri Jun 22 10:57:37 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BC521F86CF for ; Fri, 22 Jun 2012 10:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-+zXp+QWTiN for ; Fri, 22 Jun 2012 10:57:36 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFB721F86C9 for ; Fri, 22 Jun 2012 10:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1554; q=dns/txt; s=iport; t=1340387856; x=1341597456; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Qe0sa41g45CZLXWVOmx1zFTKwg2mbvbtIXGlFcWKTJY=; b=T4OrzQMnbm+x5bqztzKZqwplVH6jTjrGQSDgIZNps0z2SWLjk2ataLlR i+NhfH0WpB7xiel7ptfBqkw3hakLUKAQ+Fb/VP4Ze2ELNtwRyMFDQLha/ tvEr5AkGhC5yvXV5nByTAdglpqgUSsnHUxoH9dDjpE6ziySGkqtsH8/I3 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEux5E+tJV2Z/2dsb2JhbABFtWSBB4IYAQEBBAEBAQ8BJy4GCwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQgah2gBC5ogoAIEiy6FImADnloBhGyBZoJf X-IronPort-AV: E=Sophos;i="4.77,459,1336348800"; d="scan'208";a="95060446" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 22 Jun 2012 17:57:36 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5MHva44021672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Jun 2012 17:57:36 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.248]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Fri, 22 Jun 2012 12:57:35 -0500 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , Woo Johnman Thread-Topic: [bfcpbis] transaction issue Thread-Index: AQHNUH+a8hhbO/9pTkSdnORC9pDIZ5cGn7bQ Date: Fri, 22 Jun 2012 17:56:28 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882801B3E0@xmb-aln-x08.cisco.com> References: <4FCCB307.40001@cisco.com> <4FE47AD0.5090603@cisco.com> In-Reply-To: <4FE47AD0.5090603@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.122.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18988.006 x-tm-as-result: No--58.099400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bfcpbis@ietf.org" , 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] transaction issue X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 17:57:37 -0000 (as an individual) That matches my understanding/assumption as well. Adding text to make that = assumption explicit sounds good to me. Cheers, Charles > -----Original Message----- > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On > Behalf Of Tom Kristensen (tomkrist) > Sent: Friday, June 22, 2012 7:02 AM > To: Woo Johnman > Cc: bfcpbis@ietf.org; 'Tom Kristensen' > Subject: Re: [bfcpbis] transaction issue >=20 > On 06/04/2012 03:07 PM, Tom Kristensen wrote: > > On 06/01/2012 11:59 AM, Woo Johnman wrote: > >> Hi, > >> The RFC4582bis says:"As described in previous paragraph every entity - > >> client or server - is only allowed to send one request at a time, and > >> await the acknowledging response." > >> I think the condition of only one pending request at a time is too har= d. > >> Is it more suitable that there is one pending request at a time per > >> conference > >> or ever per connection(client-server)? > > Woo, > > > > Thanks for the comment. I have to read the text chunks related to this > > once more and rethink this approach; I'll be back! >=20 > So, I have always assumed the restrictions to send one request at a > time, applied per connection/association between one client-server pair. >=20 > I'm ready to change and clarify the draft text to express just that. Any > protests/other views out there? >=20 > -- Tom >=20 > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From ernst.horvath@siemens-enterprise.com Mon Jun 25 06:19:14 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CC721F8608 for ; Mon, 25 Jun 2012 06:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcejQ9apqQW3 for ; Mon, 25 Jun 2012 06:19:14 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id B4A1B21F8607 for ; Mon, 25 Jun 2012 06:19:13 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 5F2E323F046C for ; Mon, 25 Jun 2012 15:19:12 +0200 (CEST) Received: from MCHP03MSX.global-ad.net ([169.254.2.115]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Mon, 25 Jun 2012 15:19:12 +0200 From: "Horvath, Ernst" To: "bfcpbis@ietf.org" Thread-Topic: RFC 4582bis: More comments on error handling Thread-Index: Ac1S1Rv/v5byP1cXQDegIQKTfvJmBg== Date: Mon, 25 Jun 2012 13:19:11 +0000 Message-ID: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.26.0.183] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [bfcpbis] RFC 4582bis: More comments on error handling X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 13:19:14 -0000 The following items are some comments on error procedures in draft-ietf-bfc= pbis-rfc4582bis-03. I noticed that some of them concern text inherited from= RFC4582, which should nevertheless be fixed in 4582bis. 1) Ambiguous text in 5.1: In the sentence on top of page 17: "If a BFCP entity receives a message with an unsupported version field value, the receiving participant MAY send an Error message with parameter value 12 to indicate this", Shouldn't "BFCP entity" better be "Floor Control Server" and "paricipant" b= e "server", given that Error is a message for the server to client directio= n according to table 1? Similarly on page 18: "If a BFCP entity receives a message with an incorrect payload length field value, the receiving participant MAY send an Error message with parameter value 13 to indicate this". 2) In 5.2, 1st paragraph below table 2, the sentence=20 "If an unrecognized attribute with the 'M' bit set is received, the message= is rejected"=20 could be expanded to=20 "If a Floor Control Server receives an unrecognized attribute with the 'M' = bit set the server MAY (or SHOULD/MUST?) send an Error message with paramet= er value 4 to indicate this",=20 to be consistent with text on other error cases. 3) In 5.2.6, regarding the sentence below Figure 12: "Error Code: This 8-bit field contains an error code from the following table. If an error code is not recognized by the receiver, then the receiver MUST assume that an error exists, and therefore that the message is processed, but the nature of the error is unclear.", I don't understand what "the message is processed" refers to - the processi= ng of the original message by the sender of Error or the processing of the = received error message. Maybe a clearer wording can be found. 4) In 6.2, 4th paragraph, the sentence=20 "If a BFCP entity receives data that cannot be parsed, the receiving partic= ipant MAY send an Error message with parameter value 10 indicating receipt = of a malformed message"=20 has the same problem as indicated in comment 1) above. 5) In 13, last paragraph, "with Error code 2 (Authentication Failed)" is wr= ong. First, code 2 means "User does not Exist" (there is no error code for = "Authentication Failed"), and second, I think code 4 (Unknown Mandatory Att= ribute) is meant here. Regards, Ernst From ernst.horvath@siemens-enterprise.com Mon Jun 25 08:34:04 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D28411E808F for ; Mon, 25 Jun 2012 08:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlHXtMfQ97YX for ; Mon, 25 Jun 2012 08:34:03 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2BD11E808D for ; Mon, 25 Jun 2012 08:34:03 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 3E6B41EB8432 for ; Mon, 25 Jun 2012 17:34:02 +0200 (CEST) Received: from MCHP03MSX.global-ad.net ([169.254.2.115]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.01.0339.001; Mon, 25 Jun 2012 17:34:02 +0200 From: "Horvath, Ernst" To: "bfcpbis@ietf.org" Thread-Topic: Misplaced text in draft-ietf-bfcpbis-rfc4582bis-03 Thread-Index: Ac1S5/HkYI/piRinSlOhwdh8xyarUg== Date: Mon, 25 Jun 2012 15:34:01 +0000 Message-ID: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.26.0.183] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [bfcpbis] Misplaced text in draft-ietf-bfcpbis-rfc4582bis-03 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 15:34:04 -0000 I think some text needs to be shifted into a different section, as detailed= below. Sections 10.1.2 and 10.2.2 both start with a sentence "When communicating over unreliable transport and upon receiving a [FloorRequest/FloorRelease] from a participant, the floor control server= MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction." These statements put a normative requirement on the floor control server an= d should therefore go into section 13.1 and 13.4, respectively. Similarly, the sentence "When communicating over unreliable transport and upon receiving a ChairAction from a participant, the floor control server MUST respond with a ChairActionAck message within the transaction failure window to complete the transaction." from 11.2 belongs into section 13.6. In addition, "from a participant" shou= ld rather be "from a chair" in that sentence. The same applies to - 12.1.2, where the 1st sentence should go into 13.5; - 12.2.2, where the 1st sentence should go into 13.2; - 12.3.2, where the 1st sentence should go into 13.3; - 12.4.2, where the 1st sentence should go into 13.7. Furthermore, section 13.1.3 specifies participant behaviour and should be m= oved into section 10.1, possibly under the heading "Reception of a Subseque= nt FloorRequestStatus Message". What could be covered in 13.1.3 (or as part of 13.1.2) instead is retransmi= ssion of a subsequent FloorRequestStatus message, which is currently not sp= ecified explicitly. Simlarly for 13.5.3, which should go into 12.1; retransmission of subsequen= t FloorStatus messages could be covered in 13.5.3 instead. 13.9 is also in the wrong section, but this subsection will disappear anywa= y if ErrorAck is removed as a whole. Regards, Ernst= From tomkrist@cisco.com Tue Jun 26 05:07:41 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B396921F85F1 for ; Tue, 26 Jun 2012 05:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwKM+tFRbQ+q for ; Tue, 26 Jun 2012 05:07:41 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D450C21F8599 for ; Tue, 26 Jun 2012 05:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=3040; q=dns/txt; s=iport; t=1340712461; x=1341922061; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=CY7UUIgo9nr0TkI/gHKTSJba1oRUOtef1vZuWs9ppyc=; b=bKYwJqefBI0bphs18EjnCZxepL0YxJfw/WXXH2fnSG9tFhsy/H5c1Jri WpSLWUI2UnI/zI73XmbzrlbMM1vR7rBV8AHrq7nEO8Jhu0Rad/aejvy/1 x9+6icHIJelkAgpzA1Yl39ZxeTMIBEd8g1I6ucfn60BB1G5No3FSl7gFx U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAJal6U+Q/khN/2dsb2JhbABEsliDU4EHghgBAQEDARIBJUABBQsLGAkWDwkDAgECAUUGDQEHAQEeh2QFmFegRIszhgQDlTGFVohHgWaCYYFUBg X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="74854415" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 26 Jun 2012 12:07:37 +0000 Received: from [10.54.86.31] (dhcp-10-54-86-31.cisco.com [10.54.86.31]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5QC7aRN013652; Tue, 26 Jun 2012 12:07:37 GMT Message-ID: <4FE9A608.9040000@cisco.com> Date: Tue, 26 Jun 2012 14:07:36 +0200 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: "Horvath, Ernst" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bfcpbis@ietf.org" Subject: Re: [bfcpbis] RFC 4582bis: More comments on error handling X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 12:07:41 -0000 On 06/25/2012 03:19 PM, Horvath, Ernst wrote: > The following items are some comments on error procedures in draft-ietf-bfcpbis-rfc4582bis-03. I noticed that some of them concern text inherited from RFC4582, which should nevertheless be fixed in 4582bis. > > 1) Ambiguous text in 5.1: > > In the sentence on top of page 17: "If a BFCP entity receives a > message with an unsupported version field value, the receiving > participant MAY send an Error message with parameter value 12 to > indicate this", > Shouldn't "BFCP entity" better be "Floor Control Server" and "paricipant" be "server", given that Error is a message for the server to client direction according to table 1? > I agree, that is a more correct description here. > Similarly on page 18: "If a BFCP entity > receives a message with an incorrect payload length field value, the > receiving participant MAY send an Error message with parameter value > 13 to indicate this". > True also here. > 2) In 5.2, 1st paragraph below table 2, the sentence > "If an unrecognized attribute with the 'M' bit set is received, the message is rejected" > could be expanded to > "If a Floor Control Server receives an unrecognized attribute with the 'M' bit set the server MAY (or SHOULD/MUST?) send an Error message with parameter value 4 to indicate this", > to be consistent with text on other error cases. > Yes, this seems to be a plausible clarification on how to react in that case. > 3) In 5.2.6, regarding the sentence below Figure 12: > "Error Code: This 8-bit field contains an error code from the > following table. If an error code is not recognized by the receiver, > then the receiver MUST assume that an error exists, and therefore > that the message is processed, but the nature of the error is > unclear.", > I don't understand what "the message is processed" refers to - the processing of the original message by the sender of Error or the processing of the received error message. Maybe a clearer wording can be found. > I read this as meaning the original message (that triggered the Error back) was processed and we may add text underlining this - given this is the interpretation by other people as well? > 4) In 6.2, 4th paragraph, the sentence > "If a BFCP entity receives data that cannot be parsed, the receiving participant MAY send an Error message with parameter value 10 indicating receipt of a malformed message" > has the same problem as indicated in comment 1) above. > Will fix! > 5) In 13, last paragraph, "with Error code 2 (Authentication Failed)" is wrong. First, code 2 means "User does not Exist" (there is no error code for "Authentication Failed"), and second, I think code 4 (Unknown Mandatory Attribute) is meant here. > Indeed, I agree with you. Good catch - especially since "Authentication Failed" doesn't even exist. Thanks for good comments based on what must be a thorough review of the draft! -- Tom From tomkrist@cisco.com Tue Jun 26 05:22:20 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE8221F85A1 for ; Tue, 26 Jun 2012 05:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMIAzbeozeUe for ; Tue, 26 Jun 2012 05:22:13 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 381DF21F853B for ; Tue, 26 Jun 2012 05:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=2540; q=dns/txt; s=iport; t=1340713333; x=1341922933; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rCMmkql5GCY2x2O4F3dd3axfYK3om7QEaqAc5V9m1Ac=; b=Uwo6MzFytBdZz9eFTNkVeLznXJ8ZURNqimqWm8HzEFfRRSgoOm7zhIkg 0x6i89l3h1z4gbIEzhGv8GoyJWCLYGYtQhCj/MfAM8Lx9bvthTCRZX1a0 FZEwQp5JNmdrxgSHKyiYNbKRgXgG6x/YGgJMaOUSINObj8Ie/oetPUmlv s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFGo6U+Q/khM/2dsb2JhbABFtiuBB4IYAQEBBAEBAQ8BJTYKARALGAkWDwkDAgECARUwBg0BBQIBAR6HaQuYQaBABIszhgQDlTGFVohHgWaCYQ X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="6196616" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 26 Jun 2012 12:22:12 +0000 Received: from [10.54.86.31] (dhcp-10-54-86-31.cisco.com [10.54.86.31]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5QCMBN3017971; Tue, 26 Jun 2012 12:22:12 GMT Message-ID: <4FE9A973.9090709@cisco.com> Date: Tue, 26 Jun 2012 14:22:11 +0200 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: "Horvath, Ernst" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bfcpbis@ietf.org" Subject: Re: [bfcpbis] Misplaced text in draft-ietf-bfcpbis-rfc4582bis-03 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 12:22:20 -0000 The changes you propose below seems to make sense and will keep the logic partitioning of the text with regards to requirements/behaviour for the different roles in the separate sections: 10. Floor Participant Operations 11. Chair Operations 12. General Client Operations 13. Floor Control Server Operations I no objections are received, I'll proceed to shuffle the text across according to your comments; thank you very much! -- Tom On 06/25/2012 05:34 PM, Horvath, Ernst wrote: > I think some text needs to be shifted into a different section, as detailed below. > > Sections 10.1.2 and 10.2.2 both start with a sentence > "When communicating over unreliable transport and upon receiving a > [FloorRequest/FloorRelease] from a participant, the floor control server MUST > respond with a FloorRequestStatus message within the transaction > failure window to complete the transaction." > These statements put a normative requirement on the floor control server and should therefore go into section 13.1 and 13.4, respectively. > > Similarly, the sentence > "When communicating over unreliable transport and upon receiving a > ChairAction from a participant, the floor control server MUST respond > with a ChairActionAck message within the transaction failure window > to complete the transaction." > from 11.2 belongs into section 13.6. In addition, "from a participant" should rather be "from a chair" in that sentence. > > The same applies to > - 12.1.2, where the 1st sentence should go into 13.5; > - 12.2.2, where the 1st sentence should go into 13.2; > - 12.3.2, where the 1st sentence should go into 13.3; > - 12.4.2, where the 1st sentence should go into 13.7. > > Furthermore, section 13.1.3 specifies participant behaviour and should be moved into section 10.1, possibly under the heading "Reception of a Subsequent FloorRequestStatus Message". > What could be covered in 13.1.3 (or as part of 13.1.2) instead is retransmission of a subsequent FloorRequestStatus message, which is currently not specified explicitly. > > Simlarly for 13.5.3, which should go into 12.1; retransmission of subsequent FloorStatus messages could be covered in 13.5.3 instead. > > 13.9 is also in the wrong section, but this subsection will disappear anyway if ErrorAck is removed as a whole. > > Regards, > Ernst > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > From eckelcu@cisco.com Tue Jun 26 11:13:56 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5BC11E808C for ; Tue, 26 Jun 2012 11:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwtmLb8V7cOb for ; Tue, 26 Jun 2012 11:13:55 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 99CF711E8088 for ; Tue, 26 Jun 2012 11:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3884; q=dns/txt; s=iport; t=1340734435; x=1341944035; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Suk9ji+mOR53yp6vrmV7OqIZ09jWtqsQhCWq76shGXA=; b=cRlglkM75tVlzwvEpLcsFKTDGBdJeJbMMYu+YpkS1GP2ekGjWOaT3XKg FuyodoQQKa2LD5QwP0IQffHnMKTtcSdcp/JFifkok04AXTpGFu5QKfh2u kc5D68HA9vBbQKANNBnrXZOZegWX2FaoXSbfanXiR8XqCJOo15KAQcK+D U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAND66U+tJV2d/2dsb2JhbABEtjWBB4IYAQEBAwEBAQEPASc0CwwEAgEIEQQBAQEKFAkHJwsUCQgBAQQOBQgah2QEAQuZCqBABIs3hSRgA6NPgWaCX4FWBg X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="93172251" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 26 Jun 2012 18:13:55 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q5QIDsTu028051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Jun 2012 18:13:54 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.248]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Tue, 26 Jun 2012 13:13:54 -0500 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , "Horvath, Ernst" Thread-Topic: [bfcpbis] RFC 4582bis: More comments on error handling Thread-Index: Ac1S1Rv/v5byP1cXQDegIQKTfvJmBgA6RLwAAAJBb+A= Date: Tue, 26 Jun 2012 18:12:34 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088280224FA@xmb-aln-x08.cisco.com> References: <4FE9A608.9040000@cisco.com> In-Reply-To: <4FE9A608.9040000@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.122.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18996.004 x-tm-as-result: No--62.405900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bfcpbis@ietf.org" Subject: Re: [bfcpbis] RFC 4582bis: More comments on error handling X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 18:13:56 -0000 ( as an individual) All the proposed changes look good to me. One comment inline regarding Tom'= s question. > -----Original Message----- > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On > Behalf Of Tom Kristensen > Sent: Tuesday, June 26, 2012 5:08 AM > To: Horvath, Ernst > Cc: bfcpbis@ietf.org > Subject: Re: [bfcpbis] RFC 4582bis: More comments on error handling >=20 > On 06/25/2012 03:19 PM, Horvath, Ernst wrote: > > The following items are some comments on error procedures in draft-ietf= - > bfcpbis-rfc4582bis-03. I noticed that some of them concern text inherited > from RFC4582, which should nevertheless be fixed in 4582bis. > > > > 1) Ambiguous text in 5.1: > > > > In the sentence on top of page 17: "If a BFCP entity receives a > > message with an unsupported version field value, the receiving > > participant MAY send an Error message with parameter value 12 to > > indicate this", > > Shouldn't "BFCP entity" better be "Floor Control Server" and "paricipan= t" > be "server", given that Error is a message for the server to client direc= tion > according to table 1? > > > I agree, that is a more correct description here. >=20 > > Similarly on page 18: "If a BFCP entity > > receives a message with an incorrect payload length field value, th= e > > receiving participant MAY send an Error message with parameter valu= e > > 13 to indicate this". > > > True also here. >=20 > > 2) In 5.2, 1st paragraph below table 2, the sentence > > "If an unrecognized attribute with the 'M' bit set is received, the mes= sage > is rejected" > > could be expanded to > > "If a Floor Control Server receives an unrecognized attribute with the = 'M' > bit set the server MAY (or SHOULD/MUST?) send an Error message with > parameter value 4 to indicate this", > > to be consistent with text on other error cases. > > > Yes, this seems to be a plausible clarification on how to react in that > case. >=20 > > 3) In 5.2.6, regarding the sentence below Figure 12: > > "Error Code: This 8-bit field contains an error code from the > > following table. If an error code is not recognized by the receive= r, > > then the receiver MUST assume that an error exists, and therefore > > that the message is processed, but the nature of the error is > > unclear.", > > I don't understand what "the message is processed" refers to - the > processing of the original message by the sender of Error or the processi= ng > of the received error message. Maybe a clearer wording can be found. > > > I read this as meaning the original message (that triggered the Error > back) was processed and we may add text underlining this - given this is > the interpretation by other people as well? Yes, that is my understanding as well, and I agree that clarification text = would be helpful. Cheers, Charles > > 4) In 6.2, 4th paragraph, the sentence > > "If a BFCP entity receives data that cannot be parsed, the receiving > participant MAY send an Error message with parameter value 10 indicating > receipt of a malformed message" > > has the same problem as indicated in comment 1) above. > > > Will fix! >=20 > > 5) In 13, last paragraph, "with Error code 2 (Authentication Failed)" i= s > wrong. First, code 2 means "User does not Exist" (there is no error code = for > "Authentication Failed"), and second, I think code 4 (Unknown Mandatory > Attribute) is meant here. > > > Indeed, I agree with you. Good catch - especially since "Authentication > Failed" doesn't even exist. >=20 >=20 > Thanks for good comments based on what must be a thorough review of the > draft! >=20 > -- Tom > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From eckelcu@cisco.com Tue Jun 26 11:16:17 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA9B21F8567 for ; Tue, 26 Jun 2012 11:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXRe4270hfeG for ; Tue, 26 Jun 2012 11:16:16 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECB811E809B for ; Tue, 26 Jun 2012 11:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3187; q=dns/txt; s=iport; t=1340734576; x=1341944176; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FVMVz1PGfStXUe/e4YjAXB12mc3vjrJUBGMlu8k48S0=; b=apAN++qQrsGht0lz452K9Y/hNVB5PbNixGqajaXPp1FLvVeIsYBWVNAR G2YVS76ZGla2aABPxo9/PUDrnyg+HYJlgqJ/UcQG6mXG98jtJNoy/+qxW I4Xaww8TnFK/HpFKTc2o5CRn8/A8sYnLTK74juGukr8XYjXFYfi9fn3wn Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACP76U+tJV2Y/2dsb2JhbABEtjWBB4IYAQEBAwEBAQEPASc0CwwEAgEIEQQBAQEKFAkHJwsUCQgBAQQOBQgah2QEAQuZCqBABIs3hSRgA6NPgWaCXw X-IronPort-AV: E=Sophos;i="4.77,478,1336348800"; d="scan'208";a="95956361" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jun 2012 18:16:15 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5QIGFPW025546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Jun 2012 18:16:15 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.248]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Tue, 26 Jun 2012 13:16:15 -0500 From: "Charles Eckel (eckelcu)" To: "Tom Kristensen (tomkrist)" , "Horvath, Ernst" Thread-Topic: [bfcpbis] Misplaced text in draft-ietf-bfcpbis-rfc4582bis-03 Thread-Index: Ac1S5/HkYI/piRinSlOhwdh8xyarUgA2EaWAAAHhcAA= Date: Tue, 26 Jun 2012 18:14:55 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828022523@xmb-aln-x08.cisco.com> References: <4FE9A973.9090709@cisco.com> In-Reply-To: <4FE9A973.9090709@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.122.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18996.004 x-tm-as-result: No--45.861700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bfcpbis@ietf.org" Subject: Re: [bfcpbis] Misplaced text in draft-ietf-bfcpbis-rfc4582bis-03 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 18:16:17 -0000 Works for me. Cheers, Charles > -----Original Message----- > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On > Behalf Of Tom Kristensen (tomkrist) > Sent: Tuesday, June 26, 2012 5:22 AM > To: Horvath, Ernst > Cc: bfcpbis@ietf.org > Subject: Re: [bfcpbis] Misplaced text in draft-ietf-bfcpbis-rfc4582bis-03 >=20 > The changes you propose below seems to make sense and will keep the > logic partitioning of the text with regards to requirements/behaviour > for the different roles in the separate sections: >=20 > 10. Floor Participant Operations > 11. Chair Operations > 12. General Client Operations > 13. Floor Control Server Operations >=20 > I no objections are received, I'll proceed to shuffle the text across > according to your comments; thank you very much! >=20 > -- Tom >=20 > On 06/25/2012 05:34 PM, Horvath, Ernst wrote: > > I think some text needs to be shifted into a different section, as deta= iled > below. > > > > Sections 10.1.2 and 10.2.2 both start with a sentence > > "When communicating over unreliable transport and upon receiving a > > [FloorRequest/FloorRelease] from a participant, the floor control s= erver > MUST > > respond with a FloorRequestStatus message within the transaction > > failure window to complete the transaction." > > These statements put a normative requirement on the floor control serve= r > and should therefore go into section 13.1 and 13.4, respectively. > > > > Similarly, the sentence > > "When communicating over unreliable transport and upon receiving a > > ChairAction from a participant, the floor control server MUST respo= nd > > with a ChairActionAck message within the transaction failure window > > to complete the transaction." > > from 11.2 belongs into section 13.6. In addition, "from a participant" > should rather be "from a chair" in that sentence. > > > > The same applies to > > - 12.1.2, where the 1st sentence should go into 13.5; > > - 12.2.2, where the 1st sentence should go into 13.2; > > - 12.3.2, where the 1st sentence should go into 13.3; > > - 12.4.2, where the 1st sentence should go into 13.7. > > > > Furthermore, section 13.1.3 specifies participant behaviour and should = be > moved into section 10.1, possibly under the heading "Reception of a > Subsequent FloorRequestStatus Message". > > What could be covered in 13.1.3 (or as part of 13.1.2) instead is > retransmission of a subsequent FloorRequestStatus message, which is > currently not specified explicitly. > > > > Simlarly for 13.5.3, which should go into 12.1; retransmission of > subsequent FloorStatus messages could be covered in 13.5.3 instead. > > > > 13.9 is also in the wrong section, but this subsection will disappear a= nyway > if ErrorAck is removed as a whole. > > > > Regards, > > Ernst > > _______________________________________________ > > bfcpbis mailing list > > bfcpbis@ietf.org > > https://www.ietf.org/mailman/listinfo/bfcpbis > > >=20 > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From ernst.horvath@siemens-enterprise.com Wed Jun 27 08:20:06 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8E221F873A for ; Wed, 27 Jun 2012 08:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LIST=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EvRUJs93TwD for ; Wed, 27 Jun 2012 08:20:06 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id ABABF21F8736 for ; Wed, 27 Jun 2012 08:20:05 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 4DD371EB84FF; Wed, 27 Jun 2012 17:20:04 +0200 (CEST) Received: from MCHP03MSX.global-ad.net ([169.254.2.115]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Wed, 27 Jun 2012 17:20:04 +0200 From: "Horvath, Ernst" To: Tom Kristensen Thread-Topic: More comments on draft-ietf-bfcpbis-rfc4582bis-03 Thread-Index: AQHNVHhTDz+k+A4RcUuwy0a8/WYs/g== Date: Wed, 27 Jun 2012 15:20:03 +0000 Message-ID: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.26.0.183] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bfcpbis@ietf.org" Subject: [bfcpbis] More comments on draft-ietf-bfcpbis-rfc4582bis-03 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:20:06 -0000 Tom, Here is the rest of (mostly minor) things I noticed during my review of the= -03 draft: Section 5.20.10: The explanation of Padding below Table 17 says "Two octets of padding...". = Why not one or three octets as well, as in other similar caeses? Section 5.3.14: Should the 1st sentence read "... on receipt of a _subsequent_ FloorRequest= Status message ..." since the first FlooRequestStatus is itself an acknowle= dgement and needs no further acknowledgment? Section 5.3.16: Similar to previous comment, should it be "... of a subsequent FloorStatus = message ..."? Section 6.1: Why was the final paragraph of RFC 4582 section 6 omitted from the -bis dra= ft? I assume it's an editorial slip. Section 6.2, 2nd paragraph: Change "only upon receipt can the client consider" to "only upon receipt of= HelloAck can the client consider". Section 6.2.1: "... the message is retransmitted up to three times." Does that mean 3 retr= ansmissions (i.e. 4 transmissions altogether) or the original transmission = plus 2 retransmissions? The latter seems to be meant in section 8.3.1, whic= h says "failing after three unacknowledged transmission attempts". Or shoul= d 8.3.1 also say "retransmission attempts"? Section 6.2.2: The text "and behave accordingly" at the end of the 1st sentence seems redu= ndant. Section 11.1: In the 2nd paragraph, shouldn't "floor participant's identifier" be "floor= chair's identifier"? Section 13, 2nd paragraph: The second sentence should start "If it is not" (rather than "If it does no= t"). Section 13.1.1, 1st paragraph: "... the first of which SHOULD be generated as soon as possible" could be m= ade more specific with a hint to the retransmision window in case of an unr= eliable transport. Similarly in later subsections of 13. Section 13.1.2: The third paragraph is only true for reliable transport, a 2nd statement sh= ould be added for unreliable transport. Section 13.4, 6th paragraph: Change "the floors being requested" to "the floors being released". Section 13.5, 1st paragraph: On the 3rd line, change "FloorRelease message" to "FloorQuery message". Section 13.5.2, end of 1st paragraph: "but their Transaction ID is 0" is true for reliable transport only. Add a = statement for unreliable transport. Similarly at the end of the 2nd paragra= ph. Section 14, 4th paragraph: I am not sure whether "Floor control server impersonation is avoided by hav= ing servers only accept BFCP messages over authenticated TLS/DTLS connectio= ns" is sufficient. Shouldn't there also be an onus on a client to send and = accept messages over secure connections only? Section 15: Delete "This" from the start of the 1st sentence below the editorial note. Regards, Ernst= From tomkrist@cisco.com Fri Jun 29 06:13:01 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E3D21F8648 for ; Fri, 29 Jun 2012 06:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.449 X-Spam-Level: X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VweiI3XTZIVa for ; Fri, 29 Jun 2012 06:13:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 25F7521F85D2 for ; Fri, 29 Jun 2012 06:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=3184; q=dns/txt; s=iport; t=1340975580; x=1342185180; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=RlPM2j0KpsxU90XRXvMEMmXCImDIGbOYtmeQ3g+Tydk=; b=C+UsertA0iatpzW3B5aTlA27yax0iYrwRYL7W60pDr4p0kwzZCmUj3z0 zPUzRrg8ootPENKWS4KxbsrOyO6p3VJMZNMn2kOyuhkoAtSJHwvfh6JOq y8XQsnLxgY2G+0+Sc5XMqDD6mWO+H2ZdrV1MEVxiC+5RT84rve0yg+Ew5 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA+p7U+Q/khM/2dsb2JhbABFtleBB4IYAQEBBAEBAQ8BJTYKARALGAkWDwkDAgECARUwBg0BBQIBAR6HaQubXKBTBIs3hgoDlTOFVohHgWaCYQ X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="140474135" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 29 Jun 2012 13:12:58 +0000 Received: from [10.61.92.94] (ams3-vpn-dhcp7263.cisco.com [10.61.92.94]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5TDCwF5004670; Fri, 29 Jun 2012 13:12:58 GMT Message-ID: <4FEDA9DA.3040004@cisco.com> Date: Fri, 29 Jun 2012 15:12:58 +0200 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: "Horvath, Ernst" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bfcpbis@ietf.org" Subject: Re: [bfcpbis] More comments on draft-ietf-bfcpbis-rfc4582bis-03 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 13:13:01 -0000 Great; impressing review and feedback! I have just browsed through your comments and will provide feedback as I carefully read through the draft. -- Tom On 06/27/2012 05:20 PM, Horvath, Ernst wrote: > Tom, > > Here is the rest of (mostly minor) things I noticed during my review of the -03 draft: > > Section 5.20.10: > The explanation of Padding below Table 17 says "Two octets of padding...". Why not one or three octets as well, as in other similar caeses? > > Section 5.3.14: > Should the 1st sentence read "... on receipt of a _subsequent_ FloorRequestStatus message ..." since the first FlooRequestStatus is itself an acknowledgement and needs no further acknowledgment? > > Section 5.3.16: > Similar to previous comment, should it be "... of a subsequent FloorStatus message ..."? > > Section 6.1: > Why was the final paragraph of RFC 4582 section 6 omitted from the -bis draft? I assume it's an editorial slip. > > Section 6.2, 2nd paragraph: > Change "only upon receipt can the client consider" to "only upon receipt of HelloAck can the client consider". > > Section 6.2.1: > "... the message is retransmitted up to three times." Does that mean 3 retransmissions (i.e. 4 transmissions altogether) or the original transmission plus 2 retransmissions? The latter seems to be meant in section 8.3.1, which says "failing after three unacknowledged transmission attempts". Or should 8.3.1 also say "retransmission attempts"? > > Section 6.2.2: > The text "and behave accordingly" at the end of the 1st sentence seems redundant. > > Section 11.1: > In the 2nd paragraph, shouldn't "floor participant's identifier" be "floor chair's identifier"? > > Section 13, 2nd paragraph: > The second sentence should start "If it is not" (rather than "If it does not"). > > Section 13.1.1, 1st paragraph: > "... the first of which SHOULD be generated as soon as possible" could be made more specific with a hint to the retransmision window in case of an unreliable transport. Similarly in later subsections of 13. > > Section 13.1.2: > The third paragraph is only true for reliable transport, a 2nd statement should be added for unreliable transport. > > Section 13.4, 6th paragraph: > Change "the floors being requested" to "the floors being released". > > Section 13.5, 1st paragraph: > On the 3rd line, change "FloorRelease message" to "FloorQuery message". > > Section 13.5.2, end of 1st paragraph: > "but their Transaction ID is 0" is true for reliable transport only. Add a statement for unreliable transport. Similarly at the end of the 2nd paragraph. > > Section 14, 4th paragraph: > I am not sure whether "Floor control server impersonation is avoided by having servers only accept BFCP messages over authenticated TLS/DTLS connections" is sufficient. Shouldn't there also be an onus on a client to send and accept messages over secure connections only? > > Section 15: > Delete "This" from the start of the 1st sentence below the editorial note. > > Regards, > Ernst > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > From eckelcu@cisco.com Fri Jun 29 08:56:27 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DBF21F87CA for ; Fri, 29 Jun 2012 08:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pG9kkABLBB4P for ; Fri, 29 Jun 2012 08:56:27 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E155F21F87CB for ; Fri, 29 Jun 2012 08:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1735; q=dns/txt; s=iport; t=1340985387; x=1342194987; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=WNfdR7NL8gDDJebhblNutRcMs2LYz2HO0DzvchkuwdA=; b=eX6XfosS+ZgeN9lQGHbGyhWZ6yacwtDSBLAH4SIS64yDJjIIFBh+uQdq TjtVuAatmvVa7LxqXFHaes6C1HR8TzsgCGn6h3XEvdSmwpoxJlJ0W4Cwt ou4miQoq4Snym4xwI00H/fJI4q4vQDrq1NdSbuD2gT9WiPkucUBkcAizH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMHP7U+tJXHB/2dsb2JhbABFtleBB4IaAQQSASdRASoUQiYBBBsah2gBC5o0gSigTIs3hSpgA5ZFjQuBZoJf X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="97332943" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 29 Jun 2012 15:56:26 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q5TFuP4m023066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 29 Jun 2012 15:56:26 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.248]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Fri, 29 Jun 2012 10:56:22 -0500 From: "Charles Eckel (eckelcu)" To: "bfcpbis@ietf.org" Thread-Topic: preparations for IETF 84 Thread-Index: Ac1WD7QnmQASxxSrRVKrG9ZmlgzdqA== Date: Fri, 29 Jun 2012 15:54:53 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828024C34@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.122.35] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19004.004 x-tm-as-result: No--39.635500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [bfcpbis] preparations for IETF 84 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 15:56:28 -0000 IETF 84 is less than a month away. The preliminary agenda has the session = for BFCPBIS as follows: FRIDAY, August 3, 2012 1230-1330 Afternoon Session II Regency A RAI bfcpbis Binary Floor Control Protocol Bis WG That's right, we are at the very end. Unfortunately, that does not buy us a= ny extra time for the prep work. The remaining and rapidly approaching IETF= 84 deadlines are as follows: # 2012-06-28 (Thursday): Preliminary agenda published for comment. # 2012-07-02 (Monday): Cutoff date for requests to reschedule Working Group= and BOF meetings 17:00 PT (UTC -7). # 2012-07-02 (Monday): Working Group Chair approval for initial document (V= ersion -00) submissions appreciated by 17:00 PT (UTC -7). # 2012-07-06 (Friday): Final agenda to be published. # 2012-07-09 (Monday): Internet Draft Cut-off for initial document (-00) su= bmission by 17:00 PT (UTC -7), upload using IETF ID Submission Tool. # 2012-07-16 (Monday): Internet Draft final submission cut-off by 17:00 PT = (UTC -7), upload using IETF ID Submission Tool. # 2012-07-18 (Wednesday): Draft Working Group agendas due by 17:00 PT (UTC = -7), upload using IETF Meeting Materials Management Tool. We do not anticipate any new (version-00) drafts. We do; however, need to h= ave more review and comments on the existing drafts ASAP, such that these c= omments may be addressed in updated versions that post prior to the July 16= th deadline. The comments and corresponding resolutions, or lack thereof, w= ill be used as input to the agenda for the working group session, which is = due July 18. The current versions of both drafts are available at http://tools.ietf.org/= wg/bfcpbis/.=20 Cheers, Charles