From eckelcu@cisco.com Tue Jul 3 15:15: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 C209721F860E for ; Tue, 3 Jul 2012 15:15:00 -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 VKkay8dKlYKm for ; Tue, 3 Jul 2012 15:14:59 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF2421F8601 for ; Tue, 3 Jul 2012 15:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4802; q=dns/txt; s=iport; t=1341353708; x=1342563308; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Y94HywS4Ve4nHbTMcmzhXE5NJGE/H/AjKA5b82p3GBI=; b=Xz4kh4LOJFJET8GVRVHSaozXV2SuOCrGAqYm8cGfP09cutghT4gstw4c EkWWOCE89TWEdzvA6j6ubGOHznVb8wQVbpFPJBVN+3ILOnmGYQMW8Shhs ur3T5fAt1AT8XU9NbR6+9ZP/2FXzwqTRbU8Il+sLiVFt22roMabEuo6/q Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPBt80+tJV2Y/2dsb2JhbABFtxKBB4IYAQEBAwEBAQEPASc0CwUHBAIBCBEEAQELFAkHJwsUCQgCBAENBQgah2QEAQuaDaBLBIs3hVdgA6NSgWaCXw X-IronPort-AV: E=Sophos;i="4.77,518,1336348800"; d="scan'208";a="98547502" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 03 Jul 2012 22:15:08 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q63MF7J7012604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jul 2012 22:15:07 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.248]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Tue, 3 Jul 2012 17:15:07 -0500 From: "Charles Eckel (eckelcu)" To: "Horvath, Ernst" , "Tom Kristensen (tomkrist)" Thread-Topic: More comments on draft-ietf-bfcpbis-rfc4582bis-03 Thread-Index: AQHNVHhTDz+k+A4RcUuwy0a8/WYs/pcX+Y/w Date: Tue, 3 Jul 2012 22:13:28 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828026FC7@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-19016.001 x-tm-as-result: No--47.850400-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] 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: Tue, 03 Jul 2012 22:15:01 -0000 (as an individual) Thanks again for the thorough review and comments! Please see comments inline. > -----Original Message----- > From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On > Behalf Of Horvath, Ernst > Sent: Wednesday, June 27, 2012 8:20 AM > To: Tom Kristensen (tomkrist) > Cc: bfcpbis@ietf.org > Subject: [bfcpbis] More comments on draft-ietf-bfcpbis-rfc4582bis-03 >=20 > Tom, >=20 > Here is the rest of (mostly minor) things I noticed during my review of t= he - > 03 draft: >=20 > 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? This is a carryover from RFC 4582, and should be corrected. The table and t= ext should be modified. The following wording is used for similar scenarios= elsewhere: Padding: One, two, or three octets of padding added so that the contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit aligned. The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. If the attribute is already 32-bit aligned, no padding is needed. =20 > Section 5.3.14: > Should the 1st sentence read "... on receipt of a _subsequent_ > FloorRequestStatus message ..." since the first FlooRequestStatus is itse= lf > an acknowledgement and needs no further acknowledgment? I agree that the first FloorRequestStatus for a FloorRequest or FloorRelea= se does not require a FloorRequestStatusAck, and that clarification should = be added here. =20 > Section 5.3.16: > Similar to previous comment, should it be "... of a subsequent FloorStatu= s > message ..."? I agree that the first FloorStatus for a FloorQuery does not require a Flo= orStatusAck, and that clarification should be added here. > 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. Yes, I think so as well. We do have the corresponding text in section 6.2 f= or when using UDP. > Section 6.2, 2nd paragraph: > Change "only upon receipt can the client consider" to "only upon receipt = of > HelloAck can the client consider". Works for me. > 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 transmi= ssion > plus 2 retransmissions? The latter seems to be meant in section 8.3.1, wh= ich > says "failing after three unacknowledged transmission attempts". Or shoul= d > 8.3.1 also say "retransmission attempts"? I agree there is a discrepancy and the number of transmissions/retransmissi= ons needs to be stated consistently. I have a slight preference for having = the original plus 3 retransmissions. > Section 6.2.2: > The text "and behave accordingly" at the end of the 1st sentence seems > redundant. I am okay with removing it. > Section 11.1: > In the 2nd paragraph, shouldn't "floor participant's identifier" be "flo= or > chair's identifier"? Yes, I think that is more clear. > Section 13, 2nd paragraph: > The second sentence should start "If it is not" (rather than "If it does = not"). Agreed. =20 > 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. Yes, that seems helpful. > Section 13.1.2: > The third paragraph is only true for reliable transport, a 2nd statement > should be added for unreliable transport. Yes, good catch. > Section 13.4, 6th paragraph: > Change "the floors being requested" to "the floors being released". Agreed. =20 > Section 13.5, 1st paragraph: > On the 3rd line, change "FloorRelease message" to "FloorQuery message". Agreed. > 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. Yes. > 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 t= o > send and accept messages over secure connections only? Yes, I agree =20 > Section 15: > Delete "This" from the start of the 1st sentence below the editorial note= . Agreed. Cheers, Charles > Regards, > Ernst > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From internet-drafts@ietf.org Sat Jul 14 07:44: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 00C6B21F8705; Sat, 14 Jul 2012 07:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 TELnNnH-xxYW; Sat, 14 Jul 2012 07:44:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB2B21F8714; Sat, 14 Jul 2012 07:44:21 -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.30p3 Message-ID: <20120714144421.5556.56642.idtracker@ietfa.amsl.com> Date: Sat, 14 Jul 2012 07:44:21 -0700 Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-04.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: Sat, 14 Jul 2012 14:44:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Binary Floor Control Protocol Bis Workin= g Group of the IETF. Title : The Binary Floor Control Protocol (BFCP) Author(s) : Gonzalo Camarillo Keith Drage Tom Kristensen Joerg Ott Charles Eckel Filename : draft-ietf-bfcpbis-rfc4582bis-04.txt Pages : 87 Date : 2012-07-14 Abstract: Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in section 16. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfcpbis-rfc4582bis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sat Jul 14 07:44:36 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 E364F21F8718; Sat, 14 Jul 2012 07:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 Tj17B6dEDrGE; Sat, 14 Jul 2012 07:44:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216A521F8705; Sat, 14 Jul 2012 07:44:35 -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.30p3 Message-ID: <20120714144435.5267.85101.idtracker@ietfa.amsl.com> Date: Sat, 14 Jul 2012 07:44:35 -0700 Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-02.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: Sat, 14 Jul 2012 14:44:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Binary Floor Control Protocol Bis Workin= g Group of the IETF. Title : Session Description Protocol (SDP) Format for Binary Flo= or Control Protocol (BFCP) Streams Author(s) : Gonzalo Camarillo Tom Kristensen Filename : draft-ietf-bfcpbis-rfc4583bis-02.txt Pages : 16 Date : 2012-07-14 Abstract: This document specifies how to describe Binary Floor Control Protocol (BFCP) streams in Session Description Protocol (SDP) descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. This document obsoletes RFC 4583. Changes from RFC 4583 are summarized in section 12. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfcpbis-rfc4583bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tomkrist@cisco.com Sat Jul 14 07:47:34 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 14CC721F8775 for ; Sat, 14 Jul 2012 07:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.407 X-Spam-Level: X-Spam-Status: No, score=-10.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 2bKERiW3165p for ; Sat, 14 Jul 2012 07:47: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 D20D421F8738 for ; Sat, 14 Jul 2012 07:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=1563; q=dns/txt; s=iport; t=1342277290; x=1343486890; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=IL5AV4osJtVx6avlaYifxIWew6oremBHC34dnwxOJ4k=; b=k0+vt5662dDLPdFHLVyMMuRGzLWc1wS7TFO9GNY8jNhbKbVcDRuUqRPH vlHCRX0MIfFlQNHMkmmZGh9FRL8Dmk/wrjbT9N/Ic/q6vpQ52UKKJhNv+ 4fM7BOT3uN6T1qUYDpxaNkcrVNs1OVg3t7wweq9m5pLx7GPT3Mfpem206 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAM6FAVCQ/khM/2dsb2JhbABFuCmBB4IgAQEBBBIBJUABEAsYCRYPCQMCAQIBRRMBBQIBAR6Ha5pCn1qLQBqCTIMcA5U7hVaISoFmgmGBXQ X-IronPort-AV: E=Sophos;i="4.77,584,1336348800"; d="scan'208";a="6640229" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 14 Jul 2012 14:48:09 +0000 Received: from [10.61.83.53] (ams3-vpn-dhcp4918.cisco.com [10.61.83.53]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6EEm8BU018117; Sat, 14 Jul 2012 14:48:09 GMT Message-ID: <500186A8.7050103@cisco.com> Date: Sat, 14 Jul 2012 16:48:08 +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: <20120714144421.5556.56642.idtracker@ietfa.amsl.com> In-Reply-To: <20120714144421.5556.56642.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Horvath, Ernst" , Woo Johnman Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-04.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: Sat, 14 Jul 2012 14:47:34 -0000 On 07/14/2012 04:44 PM, 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-04.txt > Pages : 87 > Date : 2012-07-14 > The changes from the -03 version: 1) Remove ErrorAck primitive. Not needed as the server replies with an Error message and completes that transaction. Input from Ernst Horvath 2012-06-15, cf. mail thread on list. 2) Made the assumption that the one pending/outstanding transaction limitation applies per BFCP connection between a client and a server. Cf. mail thread on list started by Woo Johnman 2012-06-01. Section 6.2, sixth paragraph and Section 6.2.1, third sentence. 3) Reworded and fixed description of Error handling and error codes. Input from Ernst Horvath 2012-06-25, cf. mail thread on list. 4) Shuffled around text to keep the logic separation between client and server specifications in different main sections. Input from Ernst Horvath 2012-06-25, cf. mail thread on list. 5) Misc. smaller but important changes from Ernst Horvath 2012-06-27, cf. mail thread on list. -- Tom From tomkrist@cisco.com Sat Jul 14 07:49:50 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 729B021F877E for ; Sat, 14 Jul 2012 07:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.435 X-Spam-Level: X-Spam-Status: No, score=-10.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 4Jy0CVKRlqXZ for ; Sat, 14 Jul 2012 07:49:50 -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 A1E2321F86D1 for ; Sat, 14 Jul 2012 07:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=906; q=dns/txt; s=iport; t=1342277429; x=1343487029; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wkye+tf6S2Vn2JoAploNblmx/bCC3aWg9z5TTcqLjVQ=; b=kc3Y2gtotQDw5FWYHW0VesKiEvBcHa9kxvEQy3dcuL5qkfBdwFreoonA V0fMh3be7S21n8X842JWWh6GCfddnvvSlwHOqQH5Bl/F4M1GsMSaHNLB5 kNqWcjXNKYPAL9VLnh/rv4WlDFgITSgGTcj8/MMczhj9tmKgToEiaL0Yo k=; X-IronPort-AV: E=Sophos;i="4.77,584,1336348800"; d="scan'208";a="6635830" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 14 Jul 2012 14:50:28 +0000 Received: from [10.61.83.53] (ams3-vpn-dhcp4918.cisco.com [10.61.83.53]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6EEoR1i009052; Sat, 14 Jul 2012 14:50:28 GMT Message-ID: <50018733.4040301@cisco.com> Date: Sat, 14 Jul 2012 16:50: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: bfcpbis@ietf.org References: <20120714144435.5267.85101.idtracker@ietfa.amsl.com> In-Reply-To: <20120714144435.5267.85101.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Charles Eckel \(eckelcu\)" , "Chelliah Sivachelvan \(chelliah\)" Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-02.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: Sat, 14 Jul 2012 14:49:50 -0000 On 07/14/2012 04:44 PM, 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-02.txt > Pages : 16 > Date : 2012-07-14 > The changes from -01 version: 1) Added UDP/TLS example in Section 9. Examples, accompanying the existing TCP/TLS example. Cf. input from Chelliah Sivachelan and Charles Eckels on the list 2012-06-05. 2) White space fix to please the IETF diff tool 3) Changed the wording for the IANA instructions - mainly editorial note -- Tom From aeh@db.org Mon Jul 16 05:50:52 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 D6CCD21F8800 for ; Mon, 16 Jul 2012 05:50:52 -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 LSZPRyor-OSj for ; Mon, 16 Jul 2012 05:50:52 -0700 (PDT) Received: from mailstore05.sysedata.no (mailstore05.sysedata.no [195.159.29.9]) by ietfa.amsl.com (Postfix) with ESMTP id E3F9D21F8810 for ; Mon, 16 Jul 2012 05:50:51 -0700 (PDT) Received: from [64.103.25.233] (helo=[10.54.86.36]) by mailstore05.sysedata.no with esmtpa (Exim 4.72) (envelope-from ) id 1Sqkly-0002RI-J8 for bfcpbis@ietf.org; Mon, 16 Jul 2012 14:51:34 +0200 Message-ID: <50040E56.5000500@db.org> Date: Mon, 16 Jul 2012 14:51:34 +0200 From: "Alfred E. Heggestad" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: bfcpbis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4582bis-04 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, 16 Jul 2012 12:50:53 -0000 Hi, here is my review comments of draft-ietf-bfcpbis-rfc4582bis-04 > Section 5.1 > > R: The Transaction Responder (R) flag-bit has relevance only for use > of BFCP over unreliable transport. When cleared, it indicates that > this message is a request initiating a new transaction, and the > Transaction ID that follows has been generated for this transaction. > When set, it indicates that this message is a response to a previous > request, and the Transaction ID that follows is the one associated > with that request. When BFCP is used over reliable transports, the > flag has no significance and SHOULD be cleared. suggest rewrite to .. "SHALL be cleared by the sender and ignored by the receiver" > 6.2. Unreliable Transport > > > BFCP entities may elect to exchange BFCP messages using UDP > datagrams. UDP is an unreliable transport where neither delivery nor > ordering is assured. Each BFCP UDP datagram MUST contain exactly one > BFCP message. In the event the size of a BFCP message exceeds the > MTU size, the BFCP message will be fragmented at the IP layer. from the wording it is not clear that message fragmentation is handled by BFCP itself.. it can be mis-interpreted to think that the IP layer is responsible for that. perhaps we should reword this part a bit, to make it explicitly clear that BFCP messages above MTU size MUST be fragmented by the BFCP-layer itself. > client MAY discard the message and await retransmission. BFCP > entities receiving an Error message with value 10 SHOULD acknowledge > the error and act accordingly. I believed that it is not possible to acknowledge an Error message anymore, since the ErrorAck primitive was deleted from the spec... (?) > 6.3.2. NAT Traversal > > ... > > In order to facilitate the initial establishment of NAT bindings, and > to maintain those bindings once established, BFCP over UDP entities > are RECOMMENDED to use STUN [11] for keep-alives, as described for > SIP [10]. reference [10] points to sip-outbound, to make this explicitly more clear we could rename the text to "SIP Outbound [10]. using STUN for keepalive in SIP-outbound is done from the SIP-client to the SIP-server, which has an embedded STUN server to reply to STUN messages. it is not very clear to me how this usage is defined in BFCP. for example, what should happen if a STUN Request/Response exchange times out? should we try again or treat it as an implicit Goodbye message ? > This results in each BFCP entity sending a packet, both to > open the pinhole and to learn what IP/port the NAT assigned for the > binding. I think the text about learning IP/port should be deleted, I dont think that this information should be used for anything. I believed that STUN/BFCP is mainly about NAT keepalive, and not about NAT traversal as should be defined outside this document (e.g. ICE). ... NOTE: kudos to the authors for doing a great job! /alfred From palmarti@cisco.com Mon Jul 16 10:46:49 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 EDBA411E826D for ; Mon, 16 Jul 2012 10:46:49 -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 L8bMBHif6SDW for ; Mon, 16 Jul 2012 10:46:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E9FED11E8158 for ; Mon, 16 Jul 2012 10:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=palmarti@cisco.com; l=3728; q=dns/txt; s=iport; t=1342460854; x=1343670454; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/NamZLvR8JP3pg0FYlmGX6gaHTA9ClqRcEtII6b9gi0=; b=W9bd87NH9ZSycg1gqgcin6VLyMWVc3t961W+FHoywnnu4FLGmdtXh3UM RcPhjzl4+3J+NqTd7L1OD/v238Qgwfornw06n5nks9A3j6KmmNdyyNeP1 4y19ss/tws883/RJCOEYC7PLh2fbHh4tK1QNsvea9j2FKVt5hdXgww/hT 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAExTBFCtJV2Z/2dsb2JhbABFuUuBB4IgAQEBAwEBAQEPAVoBCwULAgEIRicLJQIEDgUih2UGC5wmn3UEi0CFZ2ADiBaNJY4ggWaCXw X-IronPort-AV: E=Sophos;i="4.77,594,1336348800"; d="scan'208";a="102314828" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 16 Jul 2012 17:47:34 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6GHlXcH025311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Jul 2012 17:47:33 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.67]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 12:47:33 -0500 From: "Pal Martinsen (palmarti)" To: "Alfred E. Heggestad" Thread-Topic: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4582bis-04 Thread-Index: AQHNY1G+VIRFu76AyUiX5Nf6f8ET/ZcsL4MN Date: Mon, 16 Jul 2012 17:47:50 +0000 Message-ID: References: <50040E56.5000500@db.org> In-Reply-To: <50040E56.5000500@db.org> Accept-Language: en-US Content-Language: nb-NO X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19042.004 x-tm-as-result: No--44.674900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "bfcpbis@ietf.org" Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4582bis-04 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, 16 Jul 2012 17:46:50 -0000 Den 16. juli 2012 kl. 14:51 skrev "Alfred E. Heggestad" : > Hi, >=20 >=20 > here is my review comments of draft-ietf-bfcpbis-rfc4582bis-04 >=20 >=20 >=20 >=20 > > Section 5.1 > > >> R: The Transaction Responder (R) flag-bit has relevance only for use >> of BFCP over unreliable transport. When cleared, it indicates that >> this message is a request initiating a new transaction, and the >> Transaction ID that follows has been generated for this transaction. >> When set, it indicates that this message is a response to a previous >> request, and the Transaction ID that follows is the one associated >> with that request. When BFCP is used over reliable transports, the >> flag has no significance and SHOULD be cleared. >=20 > suggest rewrite to .. "SHALL be cleared by the sender and ignored by > the receiver" >=20 >=20 >=20 >=20 >> 6.2. Unreliable Transport >>=20 >>=20 >> BFCP entities may elect to exchange BFCP messages using UDP >> datagrams. UDP is an unreliable transport where neither delivery nor >> ordering is assured. Each BFCP UDP datagram MUST contain exactly one >> BFCP message. In the event the size of a BFCP message exceeds the >> MTU size, the BFCP message will be fragmented at the IP layer. >=20 > from the wording it is not clear that message fragmentation is handled > by BFCP itself.. it can be mis-interpreted to think that the IP layer > is responsible for that. perhaps we should reword this part a bit, > to make it explicitly clear that BFCP messages above MTU size MUST be > fragmented by the BFCP-layer itself. >=20 >=20 >=20 >=20 >> client MAY discard the message and await retransmission. BFCP >> entities receiving an Error message with value 10 SHOULD acknowledge >> the error and act accordingly. >=20 > I believed that it is not possible to acknowledge an Error message anymor= e, > since the ErrorAck primitive was deleted from the spec... (?) >=20 >=20 >=20 >=20 >=20 >> 6.3.2. NAT Traversal >>=20 > > ... > > >> In order to facilitate the initial establishment of NAT bindings, and >> to maintain those bindings once established, BFCP over UDP entities >> are RECOMMENDED to use STUN [11] for keep-alives, as described for >> SIP [10]. >=20 > reference [10] points to sip-outbound, to make this explicitly more clear > we could rename the text to "SIP Outbound [10]. >=20 > using STUN for keepalive in SIP-outbound is done from the SIP-client to > the SIP-server, which has an embedded STUN server to reply to STUN messag= es. > it is not very clear to me how this usage is defined in BFCP. >=20 > for example, what should happen if a STUN Request/Response exchange times= out? > should we try again or treat it as an implicit Goodbye message ? >=20 >=20 If ICE is not used BFCP must do keep alive with no help. Maybe specify STUN= binding indication? >=20 >=20 >> This results in each BFCP entity sending a packet, both to >> open the pinhole and to learn what IP/port the NAT assigned for the >> binding. >=20 > I think the text about learning IP/port should be deleted, I dont think > that this information should be used for anything. +1 >=20 > I believed that STUN/BFCP is mainly about NAT keepalive, and not about > NAT traversal as should be defined outside this document (e.g. ICE). +2 >=20 >=20 >=20 > ... >=20 >=20 >=20 > NOTE: kudos to the authors for doing a great job! >=20 +10 _._ P=E5l-Erik >From phone... >=20 > /alfred > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From eckelcu@cisco.com Tue Jul 17 10:00:42 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 086D821F86A6 for ; Tue, 17 Jul 2012 10:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.511 X-Spam-Level: X-Spam-Status: No, score=-10.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 PU-ncdzZKemJ for ; Tue, 17 Jul 2012 10:00:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 34F4D21F86B2 for ; Tue, 17 Jul 2012 10:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=261; q=dns/txt; s=iport; t=1342544489; x=1343754089; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=U/GKU8RRfc0SJ4p+bCpaa/maR9unhZsCDvz3Y9YWmvI=; b=DGJGoSMZrGmG84XFPXe9SmrUdXIb3S37QeZTpSXL1gb4EHZ7+S79BXqA qV6GUw6qgnibjDDizM3p4MsgMj0hgTl18WX6b64XQtOkM8sBaaLQyNOUu sVBvb7A57HPQIYBorc9WHesmEQbfrsNyLpOc6keRxUJnXkOqTj0zgvtwr g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABGaBVCtJXG//2dsb2JhbABFuR2BB4IiAQQSASdRASoUQiYBBBsBGYdqAQubYIEooD2RJ2ADo1+BZoJf X-IronPort-AV: E=Sophos;i="4.77,604,1336348800"; d="scan'208";a="102709797" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 17 Jul 2012 17:01:29 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6HH1SnQ000520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Jul 2012 17:01:28 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.205]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 12:01:28 -0500 From: "Charles Eckel (eckelcu)" To: "bfcpbis@ietf.org" Thread-Topic: draft agenda for IETF 84 Thread-Index: Ac1kPc1UrQ34qs8QRLq2Fv+xL06sDQ== Date: Tue, 17 Jul 2012 17:01:27 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882803DD41@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-19046.000 x-tm-as-result: No--27.299200-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] draft agenda 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: Tue, 17 Jul 2012 17:00:42 -0000 The draft agenda for the BFCPBIS WG session at IETF 84 has been posted to t= he proceedings page: http://www.ietf.org/proceedings/84/agenda/agenda-84-bfcpbis Please have a look and share any comments or concerns.=20 Cheers, Charles (BFCPBIS co-chair) From eckelcu@cisco.com Wed Jul 18 11:41: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 A199521F848F for ; Wed, 18 Jul 2012 11:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.522 X-Spam-Level: X-Spam-Status: No, score=-10.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 CpWPkSSUt9Zr for ; Wed, 18 Jul 2012 11:41:14 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id BC3FC21F8494 for ; Wed, 18 Jul 2012 11:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=820; q=dns/txt; s=iport; t=1342636926; x=1343846526; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=1k6Jg0fz8+p9v91CPt2Ilaaygz7/2xGpIFhokEI+sBk=; b=dM/03h/0ZMRkCi8c9CQVmVraq4QLyB3PWm4ewLeKnqQQ0POXuZe2Oip4 pevW99FpodV5d3csfhkiPPlncxLoO8QIdf+AtcGkRsr021+QCqTOIKjki fIbbwyzIPJduzIVwBpg4tnkDYeAvInfgxwi8W/CBPzfiQslWE8fRFdYGs 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAH4CB1CtJXG//2dsb2JhbABFuTSBB4IiAQQSASdRASoUQiYBBBsah2oBC5xPgSigL5EvYAOWV40QgWaCXw X-IronPort-AV: E=Sophos;i="4.77,611,1336348800"; d="scan'208";a="103133970" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 18 Jul 2012 18:42:05 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6IIg5Ij018037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 18 Jul 2012 18:42:05 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.205]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Wed, 18 Jul 2012 13:42:05 -0500 From: "Charles Eckel (eckelcu)" To: "bfcpbis@ietf.org" Thread-Topic: please review drafts prior to IETF 84 Thread-Index: Ac1lFQZxA/rC9LbGSeyVKyp+0985qw== Date: Wed, 18 Jul 2012 18:42:04 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882803F649@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-19050.000 x-tm-as-result: No--31.429400-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] please review drafts prior to 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: Wed, 18 Jul 2012 18:41:15 -0000 I'd like to thank Tom for posting the updated versions of both drafts befor= e the submission deadline: http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis/ Thanks as well to those who have already provided review comments.=20 Please be sure to review and raise any open issues prior to IETF 84. We'd l= ike to be able to address any outstanding areas/issues before and/or during= the IETF 84, such that we can start WGLC on the drafts following IETF 84. Currently, the draft agenda divides the majority of the time between the tw= o drafts. If there are any significant open issues, I'd like to add them ex= plicitly the agenda so as to make sure we make the best use of our working = group session. Cheers, Charles (co-chair) From ernst.horvath@siemens-enterprise.com Tue Jul 24 07:40:13 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 1EA1221F84F3 for ; Tue, 24 Jul 2012 07:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 EMOLdPZNc3Sv for ; Tue, 24 Jul 2012 07:40:12 -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 418D721F84C2 for ; Tue, 24 Jul 2012 07:40:09 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 9966C23F059D for ; Tue, 24 Jul 2012 16:40:07 +0200 (CEST) Received: from MCHP03MSX.global-ad.net ([169.254.2.49]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0309.002; Tue, 24 Jul 2012 16:40:07 +0200 From: "Horvath, Ernst" To: "bfcpbis@ietf.org" Thread-Topic: Out-of-sequence or unexpected FloorRequestSatus messages Thread-Index: AQHNaao3roymu67K0kKtarN2oLY35Q== Date: Tue, 24 Jul 2012 14:40:06 +0000 Message-ID: References: <92B7E61ADAC1BB4F941F943788C0882803F649@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882803F649@xmb-aln-x08.cisco.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [bfcpbis] Out-of-sequence or unexpected FloorRequestSatus messages 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, 24 Jul 2012 14:40:13 -0000 A point still missing from the rfc4582bis draft is the handling of an out-o= f-sequence or unexpected FloorRequestStatus message.=20 An out-of-sequence FloorRequestStatus can occur if a participant has sent a= FloorRequest and the first response from the server is lost or overtaken b= y the next FloorRequestStatus with a different Transaction ID. In this case= the client does not yet know the Floor Request ID assigned by the server a= nd cannot determine whether or not the received status message corresponds = to the pending FloorRequest.=20 The best way to cope with this situation seems to be that the client ignore= s any FloorRequestStatus with an unknown Floor Request ID while still waiti= ng for the first response to a FloorRequest the client has sent. Message re= transmissions from both sides should eventually sort out the situation. If = this is an acceptable solution then corresponding text should be added, e.g= . in section 10.1.3. Another situation is the receipt of an unexpected FloorRequestStatus, i.e. = one that does not fit any Floor Request ID the client is aware of, and the = client has no outstanding FloorRequest transaction waiting for the initial = response. Possible reactions could be to respond with FloorRequestStatusAck= or to send Goodbye. The client could also try to resynchronise its state i= nformation, e.g. via UserQuery or FloorQuery. In any case it seems worthwhi= le to cover this situation in the draft, too. BTW, the other "subscription-like" message pair, FloorQuery and FloorStatus= , shouldn't have this problem. Regards, Ernst From ernst.horvath@siemens-enterprise.com Wed Jul 25 02:51:11 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 A587F21F856D for ; Wed, 25 Jul 2012 02:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 16ltg5hYap15 for ; Wed, 25 Jul 2012 02:51:10 -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 8016121F8567 for ; Wed, 25 Jul 2012 02:51:10 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 1C30923F0646 for ; Wed, 25 Jul 2012 11:51:09 +0200 (CEST) Received: from MCHP03MSX.global-ad.net ([169.254.2.49]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0309.002; Wed, 25 Jul 2012 11:51:08 +0200 From: "Horvath, Ernst" To: "bfcpbis@ietf.org" Thread-Topic: Out-of-sequence or unexpected FloorRequestSatus messages Thread-Index: AQHNaao+emElICJvcUSq8u/gB+u01pc5vs2Q Date: Wed, 25 Jul 2012 09:51:08 +0000 Message-ID: References: <92B7E61ADAC1BB4F941F943788C0882803F649@xmb-aln-x08.cisco.com> 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.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [bfcpbis] Out-of-sequence or unexpected FloorRequestSatus messages 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, 25 Jul 2012 09:51:11 -0000 I just noticed that section 6.2 partially covers the issue I described in m= y previous mail. The second last paragraph says: "A server-initiated request (e.g. a FloorStatus with an update from the floor control server) received by a participant before the initial FloorRequestStatus message that closes the client-initiated transaction that was instigated by the FloorRequest MUST be treated as superseding the information conveyed in any delinquent response." However, this does not resolve the problem of the unknown Floor Request ID = - it may or may not be the one also contained in the late FloorRequestStatu= s that terminates the client-initiaed FloorRequest transaction. If it is th= e same the sentence above is correct, but if it is not then there is some s= tate misalignment between server and client that needs sorting out. Thanks, Ernst > -----Original Message----- > From: bfcpbis-bounces@ietf.org=20 > [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Horvath, Ernst > Sent: Dienstag, 24. Juli 2012 16:40 > To: bfcpbis@ietf.org > Subject: [bfcpbis] Out-of-sequence or unexpected=20 > FloorRequestSatus messages >=20 > A point still missing from the rfc4582bis draft is the=20 > handling of an out-of-sequence or unexpected=20 > FloorRequestStatus message.=20 >=20 > An out-of-sequence FloorRequestStatus can occur if a=20 > participant has sent a FloorRequest and the first response=20 > from the server is lost or overtaken by the next=20 > FloorRequestStatus with a different Transaction ID. In this=20 > case the client does not yet know the Floor Request ID=20 > assigned by the server and cannot determine whether or not=20 > the received status message corresponds to the pending FloorRequest.=20 >=20 > The best way to cope with this situation seems to be that the=20 > client ignores any FloorRequestStatus with an unknown Floor=20 > Request ID while still waiting for the first response to a=20 > FloorRequest the client has sent. Message retransmissions=20 > from both sides should eventually sort out the situation. If=20 > this is an acceptable solution then corresponding text should=20 > be added, e.g. in section 10.1.3. >=20 > Another situation is the receipt of an unexpected=20 > FloorRequestStatus, i.e. one that does not fit any Floor=20 > Request ID the client is aware of, and the client has no=20 > outstanding FloorRequest transaction waiting for the initial=20 > response. Possible reactions could be to respond with=20 > FloorRequestStatusAck or to send Goodbye. The client could=20 > also try to resynchronise its state information, e.g. via=20 > UserQuery or FloorQuery. In any case it seems worthwhile to=20 > cover this situation in the draft, too. >=20 > BTW, the other "subscription-like" message pair, FloorQuery=20 > and FloorStatus, shouldn't have this problem. >=20 > Regards, > Ernst >=20 > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > = From ernst.horvath@siemens-enterprise.com Wed Jul 25 03:16:19 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 10A1E21F8587 for ; Wed, 25 Jul 2012 03:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 NjmkDPRSc3pD for ; Wed, 25 Jul 2012 03:16:18 -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 0194E21F850D for ; Wed, 25 Jul 2012 03:16:18 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id DF9A41EB84D4 for ; Wed, 25 Jul 2012 12:16:16 +0200 (CEST) Received: from MCHP03MSX.global-ad.net ([169.254.2.49]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0309.002; Wed, 25 Jul 2012 12:16:16 +0200 From: "Horvath, Ernst" To: "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4582bis-04 Thread-Index: AQHNY1G/+umJqrkXg0WLFeBM2icTyJc50Aqg Date: Wed, 25 Jul 2012 10:16:16 +0000 Message-ID: References: <50040E56.5000500@db.org> In-Reply-To: <50040E56.5000500@db.org> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4582bis-04 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, 25 Jul 2012 10:16:19 -0000 Comments inline. > -----Original Message----- > From: bfcpbis-bounces@ietf.org=20 > [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Alfred E. Heggestad > Sent: Montag, 16. Juli 2012 14:52 > To: bfcpbis@ietf.org > Subject: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4582bis-04 >=20 > Hi, >=20 >=20 > here is my review comments of draft-ietf-bfcpbis-rfc4582bis-04 >=20 >=20 >=20 >=20 > > Section 5.1 > > > > R: The Transaction Responder (R) flag-bit has relevance=20 > only for use > > of BFCP over unreliable transport. When cleared, it=20 > indicates that > > this message is a request initiating a new transaction, and the > > Transaction ID that follows has been generated for this=20 > transaction. > > When set, it indicates that this message is a response=20 > to a previous > > request, and the Transaction ID that follows is the one=20 > associated > > with that request. When BFCP is used over reliable=20 > transports, the > > flag has no significance and SHOULD be cleared. >=20 > suggest rewrite to .. "SHALL be cleared by the sender and ignored by > the receiver" >=20 >=20 >=20 >=20 > > 6.2. Unreliable Transport > > > > > > BFCP entities may elect to exchange BFCP messages using UDP > > datagrams. UDP is an unreliable transport where neither=20 > delivery nor > > ordering is assured. Each BFCP UDP datagram MUST=20 > contain exactly one > > BFCP message. In the event the size of a BFCP message=20 > exceeds the > > MTU size, the BFCP message will be fragmented at the IP layer. >=20 > from the wording it is not clear that message fragmentation is handled > by BFCP itself.. it can be mis-interpreted to think that the IP layer > is responsible for that. perhaps we should reword this part a bit, > to make it explicitly clear that BFCP messages above MTU size MUST be > fragmented by the BFCP-layer itself. I agree. In addition a BFCP message can in theory also exceed the maximum l= ength of a UDP datagram because BFCP message length is expressed in 4-octet= word units whereas the datagram length is a simple octet count. Should we = say "exactly one BFCP message or message segment per UDP datagram" in order= to allow the theoretical case of a BFCP message being larger than 65,535 o= ctets? =20 >=20 >=20 >=20 >=20 > > client MAY discard the message and await retransmission. BFCP > > entities receiving an Error message with value 10 SHOULD=20 > acknowledge > > the error and act accordingly. >=20 > I believed that it is not possible to acknowledge an Error=20 > message anymore, > since the ErrorAck primitive was deleted from the spec... (?) That's right. I also think the sentence before that: If the message can be parsed to the extent that it is able to discern that it was a response to an outstanding request transaction, the client MAY discard the message and await retransmission. is a problem because the server will not resend the response. Or does it me= an that the client retransmits the request? If so, it should be stated more= clearly. Regards, Ernst >=20 >=20 >=20 >=20 >=20 > > 6.3.2. NAT Traversal > > > > ... > > > > In order to facilitate the initial establishment of NAT=20 > bindings, and > > to maintain those bindings once established, BFCP over=20 > UDP entities > > are RECOMMENDED to use STUN [11] for keep-alives, as=20 > described for > > SIP [10]. >=20 > reference [10] points to sip-outbound, to make this=20 > explicitly more clear > we could rename the text to "SIP Outbound [10]. >=20 > using STUN for keepalive in SIP-outbound is done from the=20 > SIP-client to > the SIP-server, which has an embedded STUN server to reply to=20 > STUN messages. > it is not very clear to me how this usage is defined in BFCP. >=20 > for example, what should happen if a STUN Request/Response=20 > exchange times out? > should we try again or treat it as an implicit Goodbye message ? >=20 >=20 >=20 >=20 > > This results in each BFCP entity sending a packet, both to > > open the pinhole and to learn what IP/port the NAT=20 > assigned for the > > binding. >=20 > I think the text about learning IP/port should be deleted, I=20 > dont think > that this information should be used for anything. >=20 > I believed that STUN/BFCP is mainly about NAT keepalive, and not about > NAT traversal as should be defined outside this document (e.g. ICE). >=20 >=20 >=20 > ... >=20 >=20 >=20 > NOTE: kudos to the authors for doing a great job! >=20 >=20 > /alfred > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > = From keith.drage@alcatel-lucent.com Mon Jul 30 11:09:34 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 775E011E80D5 for ; Mon, 30 Jul 2012 11:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.789 X-Spam-Level: X-Spam-Status: No, score=-109.789 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 V2uBfBkzcDEZ for ; Mon, 30 Jul 2012 11:09:34 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 081CF11E809B for ; Mon, 30 Jul 2012 11:09:33 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6UI9X6i004565 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 30 Jul 2012 20:09:33 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 30 Jul 2012 20:09:33 +0200 From: "DRAGE, Keith (Keith)" To: "bfcpbis@ietf.org" Date: Mon, 30 Jul 2012 20:09:31 +0200 Thread-Topic: Need volunteers for the NomCom Thread-Index: Ac1ucczVR+Gp+86STmyxnCmhm8FSEwADJwfg Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [bfcpbis] FW: Need volunteers for the NomCom 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, 30 Jul 2012 18:09:34 -0000 (As WG cochair) Please take note and volunteer if you are eligible. Regards Keith -----Original Message----- From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behal= f Of NomCom Chair Sent: 30 July 2012 04:23 To: Working Group Chairs Subject: Need volunteers for the NomCom We are currently looking for volunteers to serve on the 2012-2013 NomCom. As you know, the success of the NomCom process depends crucially on=20 having a large pool of volunteers from throughout the IETF community.=20 In particular, it is valuable for the pool of volunteers to have strong=20 representation from all of the technical areas within the IETF.=20 I understand that not all IETF participants read the IETF announce list=20 frequently. Therefore, if you would be willing to inform active participant= s=20 in your working groups about this year's call for NomCom volunteers, I=20 would greatly appreciate it.=20 The NomCom 2012-2013 Call for Volunteers is open until this Sunday,=20 August 5. Details can be found at: https://datatracker.ietf.org/ann/nomcom/= 49851/ Thank you for your help, - Matt Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org