[bfcpbis] Comments on Appendix B of RFC 4582bis

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Mon, 16 April 2012 11:38 UTC

Return-Path: <gonzalo.camarillo@ericsson.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 BEF3421F867F for <bfcpbis@ietfa.amsl.com>; 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 <bfcpbis@ietfa.amsl.com>; 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 <bfcpbis@ietf.org>; 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 <Gonzalo.Camarillo@ericsson.com>
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" <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 <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bfcpbis>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=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