[bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Wed, 24 October 2012 14:27 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 BBE7F21F8A8C for <bfcpbis@ietfa.amsl.com>; Wed, 24 Oct 2012 07:27:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.218
X-Spam-Level:
X-Spam-Status: No, score=-106.218 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 DN53RUR2BtKR for <bfcpbis@ietfa.amsl.com>; Wed, 24 Oct 2012 07:27:50 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 39B7C21F8A89 for <bfcpbis@ietf.org>; Wed, 24 Oct 2012 07:27:50 -0700 (PDT)
X-AuditID: c1b4fb25-b7f956d0000011c3-fb-5087fae4c21a
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FB.91.04547.4EAF7805; Wed, 24 Oct 2012 16:27:49 +0200 (CEST)
Received: from [131.160.126.188] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Wed, 24 Oct 2012 16:27:48 +0200
Message-ID: <5087FAE4.5010900@ericsson.com>
Date: Wed, 24 Oct 2012 17:27:48 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: bfcpbis@ietf.org
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+Jvre7TX+0BBvsOMlr8W3eUyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGSuOahW846o48/UOcwPjS44uRk4OCQETiY/rPrBB2GISF+6t B7K5OIQETjFKbJjwjAXCWcsocerwPSaQKl4BbYkrr76xgNgsAqoSuy7sBYuzCVhIbLl1Hywu KhAscW7jNjaIekGJkzOfgMVFBEQkdsy6yApiCwuYSny7fIMFYrOkxJvJN8FsZgE9iSlXWxgh bHmJ7W/nMIPYQkB7lz9rYZnAyD8LydhZSFpmIWlZwMi8ilE4NzEzJ73cSC+1KDO5uDg/T684 dRMjMMwObvmtuoPxzjmRQ4zSHCxK4rzWW/f4CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDc M61Mc/dH1r8+ihqzfebczy+vTdeab7DJZ+mEox+/tYl7tu6LkOHLv+Jn/C8gVmg5z1TXL50L txuwvVv56/3cLRKLl7x+6rySITqHNbG6o1Pmky+raPOehw+js125zDTmRc45+/Hg3T9i7Dfm rev/tiwh//sssfM54mvWOXBdWjmxzrS5atljJZbijERDLeai4kQA/ZhPpgECAAA=
Subject: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-03
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: Wed, 24 Oct 2012 14:27:51 -0000

Folks,

here you have some comments on the following draft:

http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-03

Cheers,

Gonzalo


Comments on draft-ietf-bfcpbis-rfc4583bis-03

Section 3 includes a discussion about how to set the port field. That
discussion is only relevant to TCP. The new draft needs to explain that
and add a discussion about port handling in UDP.

Also, the document needs to discuss what is the equivalent of
establishing a TCP connection (i.e., it allows endpoints to start
exchanging BFCP messages) in UDP.

Section 6 contains the following new paragraph:

" Note: In [15] 'm-stream' was erroneously used in Section 9.  Although
  the example was non-normative, it is implemented by some vendors.
  Therefore, it is RECOMMENDED to support parsing and interpreting
  'm-stream' the same way as 'mstrm' when receiving."

The text should clarify (or be more explicit about) whether existing
implementations are floor control server implementations or client
implementations. The idea is that new implementers know clearly what
exactly they need to support in order to be backwards compatible with
those legacy implementations (whose implementers did not read RFCs but
only the examples :-) ).

The last paragraph of Section 8 discusses which entity behaves as the
TLS server. Do we need a similar discussion for DTLS?