From 2mkristensen@gmail.com Thu Aug 2 09:24:27 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 7289211E80F1 for ; Thu, 2 Aug 2012 09:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 Fgj+U6KYyef4 for ; Thu, 2 Aug 2012 09:24:24 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D76D311E808E for ; Thu, 2 Aug 2012 09:24:23 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so15986702obb.31 for ; Thu, 02 Aug 2012 09:24:23 -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=/qeNWgw2UlYU3F7fp30TyLtW1rACO/oHCwNY++ty9Pc=; b=TvcQYnLaRfyeBq2wYXgTNEEAO3LD3J+sCSTg9xDYdy3MjluOl3mR6eRmzjCqeWdkVd jKcLsse/p2XgS4v60tM2D2wJrOyEaiLrtpNtN4kDJUQmbKnuLY0iM6knv8OxVtE0/rqy CPZ51RJjn6c4sEYQGql/qSLIM5c0XQ3a4wktZdLuZucHnH4bMB3/v5cV6UBhyqnV3/5s TbyOUI/lBlOgeuzlblLGpEFnub8vepPQYZP6MN4j6Ppol062m2mO113ND+yMqLwztnFk 4gY6uY6qOiLNucGd+WsfVc2LPmh760cIdCInTMRGqksHiaepS1Ik6IGJ1BoMFyaH6K3C CyyQ== MIME-Version: 1.0 Received: by 10.182.74.68 with SMTP id r4mr38344543obv.31.1343924663244; Thu, 02 Aug 2012 09:24:23 -0700 (PDT) Received: by 10.182.53.170 with HTTP; Thu, 2 Aug 2012 09:24:22 -0700 (PDT) In-Reply-To: References: <92B7E61ADAC1BB4F941F943788C0882803F649@xmb-aln-x08.cisco.com> Date: Thu, 2 Aug 2012 18:24:22 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Horvath, Ernst" Content-Type: text/plain; charset=ISO-8859-1 Cc: "bfcpbis@ietf.org" 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: Thu, 02 Aug 2012 16:24:27 -0000 Thanks for spotting this. I agree that the remaining issue deserves a portion of text in the spec. It seems to me that acking the unexpected FloorRequestStatus and recommend that the client issues a UserQuery/FloorQuery to get in sync in case the Floor Request ID is not the one known and expected. I'll raise this issue in the BFCPbis session here at IETF-84 tomorrow. -- Tom On 25/07/2012, Horvath, Ernst wrote: > I just noticed that section 6.2 partially covers the issue I described in my > 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 FloorRequestStatus > that terminates the client-initiaed FloorRequest transaction. If it is the > same the sentence above is correct, but if it is not then there is some > state misalignment between server and client that needs sorting out. > > Thanks, > Ernst > >> -----Original Message----- >> From: bfcpbis-bounces@ietf.org >> [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 >> FloorRequestSatus messages >> >> A point still missing from the rfc4582bis draft is the >> handling of an out-of-sequence or unexpected >> FloorRequestStatus message. >> >> 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 by 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 and cannot determine whether or not >> the received status message corresponds to the pending FloorRequest. >> >> The best way to cope with this situation seems to be that the >> client ignores any FloorRequestStatus with an unknown Floor >> Request ID while still waiting for the first response to a >> FloorRequest the client has sent. Message retransmissions >> 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 information, e.g. via >> UserQuery or FloorQuery. In any case it seems worthwhile 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 >> >> _______________________________________________ >> 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 Thu Aug 2 10:00:31 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 4237921E80E0 for ; Thu, 2 Aug 2012 10:00:31 -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 0CgU68ue+26I for ; Thu, 2 Aug 2012 10:00:31 -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 AD56621E80DB for ; Thu, 2 Aug 2012 10:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=1492; q=dns/txt; s=iport; t=1343926830; x=1345136430; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=8rTCL8pwSYzU8OOhAfevVeglx01Cm4RE3EhDU6rptiw=; b=HXrwiEMYPsRLUyZW4Ht07lX98hAf7rkooWCRwt7eZklwjrdIQO+pcCsM HART+EWltbHWLRt6JBA1nvnoNtv7DYxkRVib3WiJ3ivjH7oRSqVjO11ha VnRvz3gDG6tneDub8UkbNlN8lVMElhwIhVG4Gl5hfU81OgebdyZ05t9og Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAAGxGlCQ/khN/2dsb2JhbABFtV+DOYEHgiABAQEDARIBJUEQCxgJJQ8CRgYNAQcBAR6HZQacbKBTi0qHBAOVR4VbiEyBZoJh X-IronPort-AV: E=Sophos;i="4.77,702,1336348800"; d="scan'208";a="7088459" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 02 Aug 2012 17:00:29 +0000 Received: from [10.55.95.85] (dhcp-10-55-95-85.cisco.com [10.55.95.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q72H0S5k019394; Thu, 2 Aug 2012 17:00:29 GMT Message-ID: <501AB22C.60501@cisco.com> Date: Thu, 02 Aug 2012 19:00:28 +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: "Alfred E. Heggestad" References: <50040E56.5000500@db.org> In-Reply-To: <50040E56.5000500@db.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 02 Aug 2012 17:00:31 -0000 On 07/16/2012 02:51 PM, Alfred E. Heggestad wrote: > Hi, > > > here is my review comments of draft-ietf-bfcpbis-rfc4582bis-04 Great! (I'll split my answers in separate messages per subsection) > > 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" If I recall correctly, the SHOULD is used since both the Fragmentation (F) flag bit and the Transaction Responder (R) flag bit is taken from the 5 bit reserved field in RFC4582. When used over reliable transport (and version==1), we'd like be backwards compatible and not mandate setting these bits to zero. (Even though the sender SHOULD indeed, and the receiver MUST ignore the reserved field). However, I agree that we should append "...[SHOULD be cleared] by the sender of the message and MUST be ignored by the receiver" to this sentence in question for both the R and F fields. OK? -- Tom From tomkrist@cisco.com Thu Aug 2 10:11:32 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 3543211E80A6 for ; Thu, 2 Aug 2012 10:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.455 X-Spam-Level: X-Spam-Status: No, score=-10.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 f+E5NdPntTdE for ; Thu, 2 Aug 2012 10:11:31 -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 A689511E8091 for ; Thu, 2 Aug 2012 10:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=1892; q=dns/txt; s=iport; t=1343927489; x=1345137089; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZyHl7tZTKCVszTiUsRgDU2iaxi5Hi90Z3nxajWKPl3c=; b=ASdjcJtR2jPA72hFj2qjeOfA1m87qceWM+7rS589EuWyyjWQBx4w49ja gghjM9h2s9XbgTEvxkZJ/KnTJsUdCMveFYRKK0Gq14lkCTXh6Y+yovyHB qFHThZng0vGwR7/6zZf9hAuLurgvoXyPtxidI5rLoCW4HNOQDKBuhXLWm 0=; X-IronPort-AV: E=Sophos;i="4.77,702,1336348800"; d="scan'208";a="141945956" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 02 Aug 2012 17:11:28 +0000 Received: from [10.55.95.85] (dhcp-10-55-95-85.cisco.com [10.55.95.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q72HBRg8021537; Thu, 2 Aug 2012 17:11:28 GMT Message-ID: <501AB4BF.1090202@cisco.com> Date: Thu, 02 Aug 2012 19:11: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: "Pal Martinsen (palmarti)" References: <50040E56.5000500@db.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Alfred E. Heggestad" , "bfcpbis@ietf.org" Subject: [bfcpbis] Section 6.3.2 issue - Re: 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: Thu, 02 Aug 2012 17:11:32 -0000 On 07/16/2012 07:47 PM, Pal Martinsen (palmarti) wrote: > Den 16. juli 2012 kl. 14:51 skrev "Alfred E. Heggestad": > [...] >>> 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]. Will do! >> 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 ? > > If ICE is not used BFCP must do keep alive with no help. Maybe specify STUN binding indication? The approach taken here was to not add redundant text and not specify behaviour when not necessary. However, if the recommendation is unclear - as it seems - we may have to add some amount of "advice" regarding this. >>> 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. > > +1 Fine with me. >> 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 Yes, I believe that is the approach chosen - althoug not followed as cleanly as it should apparently! -- Tom From tomkrist@cisco.com Thu Aug 2 10:26: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 0128D11E8190 for ; Thu, 2 Aug 2012 10:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.471 X-Spam-Level: X-Spam-Status: No, score=-10.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 Hkh5wn96lLwS for ; Thu, 2 Aug 2012 10:26:52 -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 852BC11E817C for ; Thu, 2 Aug 2012 10:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=2967; q=dns/txt; s=iport; t=1343928411; x=1345138011; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=GVdm9l3FYBChe0j16/fgil7n5dOiN/wf+OdyNMQvdIA=; b=Aj/qCPzkjzfMvSnRRZtEs62ZQ42JHZ8yPCKLVN/6jN85MkdeYea/Hhcm 5t/s6ZhEZj+zU5vjJNYXH7gJSi5zahIFN7u+BhtVx9uPmjFQx+mv2GfAS H+YmwxR/Gf73Y7jngbkteUJZEZuOqY5xP/iksGz27WrqsMXBzDAHg2jS/ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFq3GlCQ/khN/2dsb2JhbABFuRmBB4IgAQEBAwESASVAAQUHBCABAgkWCAcJAwIBAgE0EQYNAQUCAQEeh2UGnHKgVotKhwQDlUeFW4hMgWaCYQ X-IronPort-AV: E=Sophos;i="4.77,702,1336348800"; d="scan'208";a="75746455" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 02 Aug 2012 17:26:50 +0000 Received: from [10.55.95.85] (dhcp-10-55-95-85.cisco.com [10.55.95.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q72HQnE1024569; Thu, 2 Aug 2012 17:26:49 GMT Message-ID: <501AB859.7030009@cisco.com> Date: Thu, 02 Aug 2012 19:26:49 +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: <50040E56.5000500@db.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bfcpbis@ietf.org" Subject: [bfcpbis] Section 6.2 issue - Re: 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: Thu, 02 Aug 2012 17:26:53 -0000 On 07/25/2012 12:16 PM, Horvath, Ernst wrote: > Comments inline. > >> -----Original Message----- >> From: bfcpbis-bounces@ietf.org >> [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Alfred E. Heggestad >> Sent: Montag, 16. Juli 2012 14:52 [...] >>> 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. > > I agree. In addition a BFCP message can in theory also exceed the maximum > length 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 octets? Yes, the wording needs to be clarified and brushed up here - according to the feedback here. Stating explicitly that fragmentation is handled by BFCP itself is good to add. Stating "one message/segment per datagram" explicitly will also do it clearer and avoid any confusion and IP layer fragmentation. >>> 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... (?) Nice spotted, since ErrorAck is gone, so no acknowledge is needed (or even possible) here. > 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 mean > that the client retransmits the request? If so, it should be stated more clearly. My interpretation of this is that the client could discard the message before it's delivered to the "BFCP state machinery", i.e. the client will retransmit due to a missing response. However, do we need this text and proposed behaviour at all? Messages that cannot by fully parsed and interpreted is not too useful anyway... -- Tom From eckelcu@cisco.com Thu Aug 2 16:28: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 0984411E81BD for ; Thu, 2 Aug 2012 16:28: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=[AWL=0.000, 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 OECPba4dAeXn for ; Thu, 2 Aug 2012 16:28:14 -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 5D84A21F8BC3 for ; Thu, 2 Aug 2012 16:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=253; q=dns/txt; s=iport; t=1343950094; x=1345159694; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=D71dOejlBAUOG+8izIxWJx/aoVqzn6ZWaEfFV1A3GXY=; b=T+Wa7kCSfxV6HppqjLkc0zFaASsHIWsjzVbWL2nbYhdaiEl9NhqF9yby 3kAWVoHaN2EMvsecaDkZzCPq+4aqo+1l5BVGdymIs79DctNt/uWlNnIZU 6s1ur34C2xavB74hrz+TpZE4pjjlOn1qVFCxQXb1zcWeSK9EGgXgXfGm/ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFADEMG1CtJV2Y/2dsb2JhbABFhTSzZ4EHgiIBBBIBJ1EBKhRCHwcBBBsah2sLm1aBKKBLkW5gA5ZbjROBZoJf X-IronPort-AV: E=Sophos;i="4.77,704,1336348800"; d="scan'208";a="108040840" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 02 Aug 2012 23:28:14 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q72NSEs9000959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 2 Aug 2012 23:28:14 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.143]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 18:28:13 -0500 From: "Charles Eckel (eckelcu)" To: "bfcpbis@ietf.org" Thread-Topic: slides for bfcpbis session Thread-Index: Ac1xBnsSJLK5aUagTuqtMYtQZkkfOg== Date: Thu, 2 Aug 2012 23:28:12 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828066DEC@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.118.131] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.004 x-tm-as-result: No--21.942000-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] slides for bfcpbis session 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, 02 Aug 2012 23:28:17 -0000 The slides are available at http://tools.ietf.org/wg/bfcpbis/agenda for you= r review and preparation. We have the good fortune of being the last session of IETF 84. Obviously th= e schedulers saved the best for last. Cheers, Charles (co-chair) From keith.drage@alcatel-lucent.com Sat Aug 4 11:12:26 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 2423921F87D5 for ; Sat, 4 Aug 2012 11:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.69 X-Spam-Level: X-Spam-Status: No, score=-108.69 tagged_above=-999 required=5 tests=[AWL=-0.741, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_TOOL=2.3, 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 rVvxQfXl8Xxj for ; Sat, 4 Aug 2012 11:12:25 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 36A9421F86DF for ; Sat, 4 Aug 2012 11:12:25 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q74ICN9X028115 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 4 Aug 2012 20:12:23 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sat, 4 Aug 2012 20:12:23 +0200 From: "DRAGE, Keith (Keith)" To: "bfcpbis@ietf.org" Date: Sat, 4 Aug 2012 20:12:22 +0200 Thread-Topic: Proceedings for BFCPBIS WG meeting Thread-Index: Ac1yaql4Z+zzGwAoRpKBuLvlYL9Ibw== 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] Proceedings for BFCPBIS WG meeting 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, 04 Aug 2012 18:12:26 -0000 (As WG cochair) Following find the consolidated proceedings for the session. Thanks to note takers Shida Schubert and Alan Ford. Comments welcome, particularly if you said something that you think should = be recorded. Regards Keith BFCPBIS working group Friday 3rd August 2012 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Room: Regency B (http://tools.ietf.org/agenda/84/venue/?room=3Dregency-b) Meeting started 12:30 pm Agenda Bash and Status Update =20 ----------------------------------------------------------------------- Chairs presenting. Slides: http://www.ietf.org/proceedings/84/slides/slides-84-bfcpbis-0.ppt Note well presented. Notetakers were Shida Schubert and Alan Ford. Jabber scribe Jonathan Lennox= . No changes were made to the agenda. draft-ietf-bfcpbis-rfc4582bis-04 ----------------------------------------------------------------------- http://tools.ietf.org/wg/bfcpbis/draft-ietf-bfcpbis-rfc4582bis/ Tom Kristensen presenting Slides: http://www.ietf.org/proceedings/84/slides/slides-84-bfcpbis-1.pdf - Changes since IETF83. Small fixes - editorial etc. Motivational appendix and DTLS issue (referenc= e) also fixed. -04 bigger changes after serious reviews, notably from Ernst Horvath and Al= fred Heggestad. * Removed ErrorAck * Clarified transactions/connections * Error handling clarified * Client/server logic separated * Reliable transport and R/F flags. Jonathan Lennox in room questioned SHOULD for Tx, but pointed out (by Keith= D, TomK, AlanF) that is the spirit of 4582 and there's not a bug to fix. * Clarified NAT traversal. Need STUN input. * and many more editorials Gonzalo - When will you take it through WGLC?=20 Keith - Will put both drafts through WGLC together, and therefore discuss t= he two together at end of the session.=20 draft-ietf-bfcpbis-rfc4583bis-02 ----------------------------------------------------------------------- http://tools.ietf.org/wg/bfcpbis/draft-ietf-bfcpbis-rfc4583bis/ Tom Kristensen presenting Slides: http://www.ietf.org/proceedings/84/slides/slides-84-bfcpbis-1.pdf - Changes since IETF83. Update from -00 to -01, ixed an interpretation of m-stream bug. Update from -01 to -02, added UDP/TLS example to complement TCP/TLS example= . No remaining issues - ready for WGLC. Jonathan Lennox: How does BFCP over UDP/TLS play with ICE? TomK: Do not feel there is need to mention it - a reference to ICE is as fa= r as it goes in 4583 and there's no need to change that. Jonathan seemed okay about just having reference.=20 Next Steps =20 ----------------------------------------------------------------------- Chairs presenting Slides: http://www.ietf.org/proceedings/84/slides/slides-84-bfcpbis-0.ppt 4582bis ready for WGLC (after small text clarification due from TomK and th= erefore update of the draft). Already ready by a significant number of revi= ewers. 4583bis Small number of review comments received. On a call in the room 3 or 4 of people indicated that they has read the dra= ft. Meeting agreed this document was ready for WGLC.=20 Chairs: Wait for the update rfc4582bis and then put both drafts through WGL= C together, hopefully fairly shortly after this meeting. Gonzalo: So aim to have the publication request in September (Gonzalo) Meeting closed at 12:51 pm From ietf@meetecho.com Tue Aug 7 15:38: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 B7E6421F86EC for ; Tue, 7 Aug 2012 15:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.261 X-Spam-Level: X-Spam-Status: No, score=0.261 tagged_above=-999 required=5 tests=[AWL=0.980, 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 jpie6hGapvS0 for ; Tue, 7 Aug 2012 15:38:23 -0700 (PDT) Received: from smtplq01.aruba.it (smtplqs-out19.aruba.it [62.149.158.59]) by ietfa.amsl.com (Postfix) with SMTP id BE8F021F86EB for ; Tue, 7 Aug 2012 15:38:22 -0700 (PDT) Received: (qmail 27080 invoked by uid 89); 7 Aug 2012 22:38:19 -0000 Received: from unknown (HELO smtp2.aruba.it) (62.149.158.222) by smtplq01.aruba.it with SMTP; 7 Aug 2012 22:38:19 -0000 Received: (qmail 1233 invoked by uid 89); 7 Aug 2012 22:38:19 -0000 Received: from unknown (HELO ?192.168.1.154?) (alex@meetecho.com@87.11.150.210) by smtp2.ad.aruba.it with ESMTPA; 7 Aug 2012 22:38:19 -0000 Message-ID: <502198CC.6020302@meetecho.com> Date: Wed, 08 Aug 2012 00:38:04 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: bfcpbis@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N Subject: [bfcpbis] Meetecho session recording available 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, 07 Aug 2012 22:38:23 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of BFCPBIS session at IETF-84 is available. You can watch it by accessing the following URL: http://ietf84.conf.meetecho.com/index.php/Recorded_Sessions#IETF84_BFCPBIS For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From internet-drafts@ietf.org Wed Aug 29 00:38:39 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 9DC9E21F84D8; Wed, 29 Aug 2012 00:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crFGVsyWCNPu; Wed, 29 Aug 2012 00:38:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158C721F84DA; Wed, 29 Aug 2012 00:38:39 -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.34 Message-ID: <20120829073839.15316.16116.idtracker@ietfa.amsl.com> Date: Wed, 29 Aug 2012 00:38:39 -0700 Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-05.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: Wed, 29 Aug 2012 07:38:39 -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-05.txt Pages : 87 Date : 2012-08-29 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-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfcpbis-rfc4582bis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tomkrist@cisco.com Wed Aug 29 00:45:44 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 1137121F853D for ; Wed, 29 Aug 2012 00:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.484 X-Spam-Level: X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qw8VEAD7hW4 for ; Wed, 29 Aug 2012 00:45:43 -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 05EC321F8535 for ; Wed, 29 Aug 2012 00:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=1401; q=dns/txt; s=iport; t=1346226343; x=1347435943; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ccbsK2GRz/YxsjNhBeAxjoyrFAHxRDvdwZ7Dl4CueGU=; b=Qz5HyuNkHSNGCNZIhU/5kojEwlDm0AG3r74Nn2ikezooMqxyqC9hgwPz 3NHr/KWqqHNYWbmsCl+tBbGvmO4KOVX+9LADTEQrnZqLZRDlByDCCaqS4 0Y6QB8Oj2zP/FupIbIrPEpQMhh2WhsO62nVe+J5pI0cXQ9NuysCaqv46Q k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAN3HPVCQ/khL/2dsb2JhbABFumyBB4IgAQEBBBIBJUARCxgJFg8JAwIBAgFFEwYCAQEeh2ubKKBIiwgagyODHAOVVoVciFKBZ4JlgV8 X-IronPort-AV: E=Sophos;i="4.80,332,1344211200"; d="scan'208";a="76315154" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 29 Aug 2012 07:45:38 +0000 Received: from [10.61.100.131] (dhcp-10-61-100-131.cisco.com [10.61.100.131]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7T7jclF015527 for ; Wed, 29 Aug 2012 07:45:38 GMT Message-ID: <503DC8A2.3080003@cisco.com> Date: Wed, 29 Aug 2012 09:45:38 +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: <20120829073839.15316.16116.idtracker@ietfa.amsl.com> In-Reply-To: <20120829073839.15316.16116.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-05.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: Wed, 29 Aug 2012 07:45:44 -0000 On 08/29/2012 09:38 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Binary Floor Control Protocol Bis Working Group of the IETF. > > Title : The Binary Floor Control Protocol (BFCP) > Author(s) : Gonzalo Camarillo > Keith Drage > Tom Kristensen > Joerg Ott > Charles Eckel > Filename : draft-ietf-bfcpbis-rfc4582bis-05.txt > Pages : 87 > Date : 2012-08-29 > [...] Updated according to agreement in BFCPbis WG session at IETF-84, Vancouver, i.e. fixed comments and issues raised by Alfred Heggestad's review posted on list 2012-07-16 and the discussion in that e-mail thread: - Keep SHOULD clear R and F flags for senders (over reliable transports). Add "MUST be ignored by receivers". No functional changes. - Clarify text regarding fragmentation. No functional changes. - Remove remains of ErrorAck behaviour. Clarify text. No functional changes. - Clarify and focus text for NAT traversal/keepalive. No functional changes. . mention usage of STUN Binding Indication for keepalives . point to ICE for how to use it Should be ready for WGLC - as was the conclusion at IETF-84! -- Tom From 2mkristensen@gmail.com Wed Aug 29 00:51:00 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 7A0CE21F855A for ; Wed, 29 Aug 2012 00:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnPaJiQCwM-1 for ; Wed, 29 Aug 2012 00:50:56 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB38A21F8557 for ; Wed, 29 Aug 2012 00:50:55 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so514585obb.31 for ; Wed, 29 Aug 2012 00:50:55 -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=hhO2fkJ1A/7R5BMH3PZsNrPss+vv3sLDLQ9QLXGPhvM=; b=DD1B+lDZ50EcKrasC5KQWDqddRC6RbamlaogevS+t08o8y/WhWadkWIvm2TsCburMM K6m0eAiiEuV9Fi9/BNBuDnIHHjefc2TKMjqtGX04pL/rv/B3tB36+dTvE7pSSJQfPSQ2 KjehVAmzaMGB/m2YSUH4N2sqeEr/kDNbWajdxBaDfsAKoxsv4qVW0i5/iceazXik0xJs j8jINvxj+F7DmWcpLFrclhPzNvsaQDaWEDsJWEDO5pDHX2ysZ4jMC9N4AkH0//mt+CV4 Y4Wkz1ZG03Hevpikc7e3rrWgz9o7VExxTbBQwkWG76psoq1ny4rYmyyYcgVyxB9wY5/Y YQ0w== MIME-Version: 1.0 Received: by 10.60.169.100 with SMTP id ad4mr541851oec.21.1346226655463; Wed, 29 Aug 2012 00:50:55 -0700 (PDT) Received: by 10.182.193.105 with HTTP; Wed, 29 Aug 2012 00:50:55 -0700 (PDT) In-Reply-To: <503DC8A2.3080003@cisco.com> References: <20120829073839.15316.16116.idtracker@ietfa.amsl.com> <503DC8A2.3080003@cisco.com> Date: Wed, 29 Aug 2012 09:50:55 +0200 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: Tom Kristensen Content-Type: text/plain; charset=ISO-8859-1 Cc: bfcpbis@ietf.org Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-05.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: Wed, 29 Aug 2012 07:51:01 -0000 ... and you may want the side-by-side diff between -04 and -05: http://bit.ly/UaeXvE -- Tom On 29/08/2012, Tom Kristensen wrote: > On 08/29/2012 09:38 AM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Binary Floor Control Protocol Bis >> Working Group of the IETF. >> >> Title : The Binary Floor Control Protocol (BFCP) >> Author(s) : Gonzalo Camarillo >> Keith Drage >> Tom Kristensen >> Joerg Ott >> Charles Eckel >> Filename : draft-ietf-bfcpbis-rfc4582bis-05.txt >> Pages : 87 >> Date : 2012-08-29 >> > [...] > > Updated according to agreement in BFCPbis WG session at IETF-84, > Vancouver, i.e. fixed comments and issues raised by Alfred Heggestad's > review posted on list 2012-07-16 and the discussion in that e-mail thread: > > - Keep SHOULD clear R and F flags for senders (over reliable > transports). Add "MUST be ignored by receivers". No functional changes. > - Clarify text regarding fragmentation. No functional changes. > - Remove remains of ErrorAck behaviour. Clarify text. No functional > changes. > - Clarify and focus text for NAT traversal/keepalive. No functional > changes. > . mention usage of STUN Binding Indication for keepalives > . point to ICE for how to use it > > Should be ready for WGLC - as was the conclusion at IETF-84! > > -- Tom > _______________________________________________ > 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/