From eckelcu@cisco.com Tue Apr 10 11:06: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 176FD11E8117 for ; Tue, 10 Apr 2012 11:06:39 -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 Sr0QNThlb84K for ; Tue, 10 Apr 2012 11:06:38 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 86F6311E810C for ; Tue, 10 Apr 2012 11:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=273; q=dns/txt; s=iport; t=1334081198; x=1335290798; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=96lsyPCIZwhpwGluLV/IE9kpJu/E0Z6X8HFvlmxGs5o=; b=DCougVgr6+iVQxhF66g8xt8V2cxV4WXBm/NyCZ4xiNXApvg8qUjKVBXA 0DD8dr/3hGH+hZhW3aNZz1ZipYI0unzvCRD+bIZomY74bqLmPw+PgT+Vq cFaQOyySsCHSaw+smszjMO7L/hOkBOJ4RQGul5F1DjthxsbjKtGuV9FgD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPt1hE+rRDoH/2dsb2JhbABEuS6BB4ILAQQSAR0KUQEqBhgHVwEEGwEZh2sBC5k8gSegQI09gkFjBIham1+BaYMH X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="37311249" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 10 Apr 2012 18:06:38 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3AI6cTo020497 for ; Tue, 10 Apr 2012 18:06:38 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 11:06:37 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Apr 2012 11:06:37 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meeting minutes for BFCPBIS from IETF 83 Thread-Index: Ac0XRKvo1nutnPt6SmGE+M67Za9kBg== From: "Charles Eckel (eckelcu)" To: X-OriginalArrivalTime: 10 Apr 2012 18:06:38.0080 (UTC) FILETIME=[AC600000:01CD1744] Subject: [bfcpbis] Meeting minutes for BFCPBIS from IETF 83 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, 10 Apr 2012 18:06:39 -0000 The minutes have been posted. http://www.ietf.org/proceedings/83/minutes/minutes-83-bfcpbis.txt Thanks to those who participated, and especially to the note takers (Alan Johnston, Adam Roach). Please contact the chairs regarding any corrections. Cheers, Charles From gonzalo.camarillo@ericsson.com Mon Apr 16 03:55: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 D851021F873E for ; Mon, 16 Apr 2012 03:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 bHN-wT6WByz0 for ; Mon, 16 Apr 2012 03:55:52 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id F00B321F872E for ; Mon, 16 Apr 2012 03:55:51 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-25-4f8bfab68094 Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E5.0C.26681.6BAFB8F4; Mon, 16 Apr 2012 12:55:51 +0200 (CEST) Received: from [131.160.36.128] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 12:55:50 +0200 Message-ID: <4F8BFAB6.2050900@ericsson.com> Date: Mon, 16 Apr 2012 13:55:50 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "bfcpbis@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [bfcpbis] Old comments on RFC 4582 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 10:55:53 -0000 Hi, below you can find an old thread with comments on RFC 4582 that should be fixed in the new revision of the spec. Cheers, Gonzalo -------- Original Message -------- Subject: Re: RFC 4582 additional note Date: Tue, 23 Jan 2007 13:55:14 +0200 From: Gonzalo Camarillo To: Alfred ? CC: jo@netlab.hut.fi, drage@lucent.com References: <200612301007.LAA23236@TR-Sys.de> <200612301044.LAA23279@TR-Sys.de> Hi, good catch. I will also log this comment. Thanks, Gonzalo Alfred ? wrote: > Hello, > in my first note on RFC 4582, by accident I have omitted an item > initially intended to be included there. > Here we go with it: > > > (3) duplicate text > > Section 13.1.1 of RFC 4582 contains two instances of the same > paragraph: the last paragraph on page 49 -- up to line formatting / > hyphenation -- is a replication of the third-to-last paragraph on > the same page. > > > Best regards, > Alfred. -------- Original Message -------- Subject: Re: RFC 4582 (BFCP) ABNF issues Date: Tue, 23 Jan 2007 13:50:27 +0200 From: Gonzalo Camarillo To: Alfred ? CC: jo@netlab.hut.fi, drage@lucent.com References: <200612301007.LAA23236@TR-Sys.de> Hi Alfred, regarding 1), I agree with you that it is a formally-allowed slight abuse of ABNF. I will log your comments so that, if we need to revise the spec at some point, we fix it. Regarding 2), it is just a variation of [FLOOR-ID]. As you point out in 1), we could have used either [xxx] or *1(xxx) throughout the spec. It is unfortunate that we have used both in the same spec. However, even if this can be confusing, it is still correct. I will also log this comment for a potential future revision. Thanks a lot for your comments. Best regards, Gonzalo Alfred ? wrote: > Hello, > after studying the recently published RFC 4582 (BFCP) authored > by you, I'd like to report some concerns related to the ABNF > found in that memo. > > > (1) general concern > > In ABNF, the notation [ ] is a shorthand for: > 0*1( ) or shortly: > *1( ) , i.e. zero or one of . > > RFC 4582 repeatedly uses the ABNF notation, > "*[ ]" , > literally meaning: > "any number of { zero or one occurrences of }". > > Although formally allowed by the ABNF RFC 4234, IMHO this is > some sort of slight abuse of ABNF; > as in other places, RFC 4582 better should have used > "*( )" > instead of the above notation (maybe even omitting the > parentheses -- but I do not recommend that, for clarity). > > This issue occurs in Figures 22, 24, 26, 28, 30, and 31..43 . > > > (2) (potential) specific issue > > RFC 4582 pervasively uses the "optional" ABNF, "[]" , > to denote optional syntax elements. But there is one exception; > in Section 5.3.8, on page 33, Figure 38 contains the line: > > *1(FLOOR-ID) > > It is not evident from the context whether this is just an > accidential variation in the use of ABNF, i.e. intended to say: > > [FLOOR-ID] > > or if in fact it was intended to say: > > 1*(FLOOR-ID) > > If the latter is true, the line in the RFC is in error and > I strongly recommend that you submit, as soon as possible, > an Author's Errata Note to the RFC Editor's RFC Errata web > pages, to correct this issue. > > Please comment. > > > Best regards, > Alfred H?nes. > From gonzalo.camarillo@ericsson.com Mon Apr 16 03:58:08 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 1239521F86FA for ; Mon, 16 Apr 2012 03:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.189 X-Spam-Level: X-Spam-Status: No, score=-106.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 4wVC0eooRltn for ; Mon, 16 Apr 2012 03:58:07 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DA2AB21F873E for ; Mon, 16 Apr 2012 03:58:06 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-86-4f8bfb3d70e7 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0237"; auth=fail (cipher=AES128-SHA) Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0237", Issuer "esessmw0237" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3B.BC.25560.D3BFB8F4; Mon, 16 Apr 2012 12:58:05 +0200 (CEST) Received: from [131.160.36.128] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 12:58:05 +0200 Message-ID: <4F8BFB3C.7040207@ericsson.com> Date: Mon, 16 Apr 2012 13:58:04 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "bfcpbis@ietf.org" References: <49DD8DED.3010908@ericsson.com> In-Reply-To: <49DD8DED.3010908@ericsson.com> X-Enigmail-Version: 1.4 X-Forwarded-Message-Id: <49DD8DED.3010908@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [bfcpbis] More comments on RFC 4582 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 10:58:08 -0000 Hi, below you can find another old email with more comments on RFC 4582. Cheers, Gonzalo -------- Original Message -------- Subject: BFCP over UDP Date: Thu, 09 Apr 2009 08:55:57 +0300 From: Gonzalo Camarillo To: XCON CC: xcon-chairs@tools.ietf.org, Geir Arne Sandbakken Hi, the following (expired) draft was presented in the XCON session in San Francisco: http://www.watersprings.org/pub/id/draft-sandbakken-xcon-bfcp-udp-00.txt The agreement was that given the problems TCP has with NATs (the P2PSIP WG is currently discussing the same issue) it would be a good idea to define a more NAT-friendly transport for BFCP. The proposal was to simply use UDP (this is what existing deployments do). Since BFCP messages can be rather long, we would need an applicability statement saying which types of messages cannot be used over UDP. In order to specify the new UDP-based transport we can either put together a new draft or revise the BFCP specification. I got the action point to list the things that could be fixed in a potential revised BFCP spec. These are the contents of my notes. Of course, if someone knows of more issues, please let us know: o When a user performs a third-party floor request the beneficiary of the floor is not informed when the floor is granted. This may not be a problem because endpoints using third-party floor requests probably have different means to get in synch but we may want to add some text about this. o We do not have errors for an unsupported version of the protocol or for wrong message length. We do not have a general error either. o When we get more experience on queue management from real deployments, it would be nice to explaining it further in the spec. o UserStatus UserStatus = (COMMON-HEADER) [BENEFICIARY-INFORMATION] 1*(FLOOR-REQUEST-INFORMATION) -> remove the 1 *[EXTENSION-ATTRIBUTE] o A message may need to be longer than the maximum message length supported by the protocol o A rather small number of typos As you can see, at this point there are not so many things to fix... so, the simplest way forward may be to simply specify a new UDP-based transport for BFCP. In any case, I would like to get feedback from folks operating BFCP deployments. A different alternative (the one the P2PSIP WG is looking at) would be to either use a UDP encapsulation for TCP or to specify a new transport protocol... but these alternatives may be more complex than just using UDP. Comments? Thanks, Gonzalo From gonzalo.camarillo@ericsson.com Mon Apr 16 04:38:46 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 BEF3421F867F for ; Mon, 16 Apr 2012 04:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 1lCr2pTJCQ6X for ; Mon, 16 Apr 2012 04:38:46 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DF65621F867C for ; Mon, 16 Apr 2012 04:38:45 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-9a-4f8c04c4eee0 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0B.49.03534.4C40C8F4; Mon, 16 Apr 2012 13:38:45 +0200 (CEST) Received: from [131.160.36.128] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 13:38:44 +0200 Message-ID: <4F8C04C4.40607@ericsson.com> Date: Mon, 16 Apr 2012 14:38:44 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "bfcpbis@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [bfcpbis] Comments on Appendix B of RFC 4582bis 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 Apr 2012 11:38:46 -0000 Hi, during our last face-to-face meeting, I agreed to have a look at Appendix B of the bis draft: http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-02#appendix-B I think it is a good idea to have that type of appendix because when people (e.g., the IESG) review the draft, the first question we will get is why have we defined an application-layer UDP-based mechanism instead of reusing an off-the-self transport mechanism... and that is indeed a good and very natural question. The Motivation section is good. It could stress a bit more that BFCP over UDP was already out there in real deployments and that specifying a common way to exchange BFCP messages where TCP was not appropriate was needed in order to avoid the existence of many different ways to do that in the market. In that way, the text will flow well into the next section (alternatives considered). I would move the description of the UDP-based approach in the draft from the introduction (B.1) to the Alternative Considered Section as *the* alternative that was finally chosen. Also, that section needs to explain that we asked the transport area for ways to tunnel TCP over UDP but that, at that point, there was no consensus on how to do that. Another alternative that should be described in the Appendix is the SCTP over UDP approach ala RTCWeb. The text should say that such an approach was not mature enough (not even fully specified) at that point, unfortunately. Cheers, Gonzalo From tomkrist@cisco.com Mon Apr 16 04:49:25 2012 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F31D21F86A4 for ; Mon, 16 Apr 2012 04:49:25 -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 fsSVTbGXTJyn for ; Mon, 16 Apr 2012 04:49:24 -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 971B821F8692 for ; Mon, 16 Apr 2012 04:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tomkrist@cisco.com; l=1984; q=dns/txt; s=iport; t=1334576964; x=1335786564; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ORtofJH+1ttiMiTG6bT/xodTnVQqkPdpyqFbD1OI+vY=; b=PWfpCitD25daa3KtJnJipWha1douviFt8s4PrzEEcBoqxCGAgYUkZDjV zhxNqCmKX5HgAqZ2eXhtDqhnkcIdq6RM8QFBRGEpglQtihcEmsLjVe9TY qLoCVu7WrIVPiQ4XVhDuekbVG4qvTeeI7AxNYIiNNfSYwWqi7mxyWYktq A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4FAMgGjE+Q/khR/2dsb2JhbABEgxywGoEHggkBAQEEAQEBDwElNgoRCxgJFg8JAwIBAgEVMBMGAgEBHodsC5knnyKLN4JugyQElW2BEYRhiFqBaYJpgVo X-IronPort-AV: E=Sophos;i="4.75,427,1330905600"; d="scan'208";a="70960523" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 16 Apr 2012 11:49:23 +0000 Received: from [10.55.81.41] (dhcp-10-55-81-41.cisco.com [10.55.81.41]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3GBnN3N024532 for ; Mon, 16 Apr 2012 11:49:23 GMT Message-ID: <4F8C0743.8000900@cisco.com> Date: Mon, 16 Apr 2012 13:49:23 +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: <4F8C04C4.40607@ericsson.com> In-Reply-To: <4F8C04C4.40607@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [bfcpbis] Comments on Appendix B of RFC 4582bis 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 Apr 2012 11:49:25 -0000 Thanks for this input and guidance. I'll do my very best to do the suggested modifications to the existing text. Thanks also for digging up the old mail threads with comments on the RFC 4582 text. -- Tom On 04/16/2012 01:38 PM, Gonzalo Camarillo wrote: > Hi, > > during our last face-to-face meeting, I agreed to have a look at > Appendix B of the bis draft: > > http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-02#appendix-B > > I think it is a good idea to have that type of appendix because when > people (e.g., the IESG) review the draft, the first question we will get > is why have we defined an application-layer UDP-based mechanism instead > of reusing an off-the-self transport mechanism... and that is indeed a > good and very natural question. > > The Motivation section is good. It could stress a bit more that BFCP > over UDP was already out there in real deployments and that specifying a > common way to exchange BFCP messages where TCP was not appropriate was > needed in order to avoid the existence of many different ways to do that > in the market. In that way, the text will flow well into the next > section (alternatives considered). > > I would move the description of the UDP-based approach in the draft from > the introduction (B.1) to the Alternative Considered Section as *the* > alternative that was finally chosen. Also, that section needs to explain > that we asked the transport area for ways to tunnel TCP over UDP but > that, at that point, there was no consensus on how to do that. > > Another alternative that should be described in the Appendix is the SCTP > over UDP approach ala RTCWeb. The text should say that such an approach > was not mature enough (not even fully specified) at that point, > unfortunately. > > Cheers, > > Gonzalo > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis >