Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-10.txt

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Mon, 25 November 2013 12:24 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B9C1AD8F1 for <bfcpbis@ietfa.amsl.com>; Mon, 25 Nov 2013 04:24:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.901
X-Spam-Level:
X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWgbUAucL1rh for <bfcpbis@ietfa.amsl.com>; Mon, 25 Nov 2013 04:24:52 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 35FDE1AD8F9 for <bfcpbis@ietf.org>; Mon, 25 Nov 2013 04:24:52 -0800 (PST)
X-AuditID: c1b4fb38-b7f2c8e000006d25-7e-52934193c43f
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id CA.5F.27941.39143925; Mon, 25 Nov 2013 13:24:51 +0100 (CET)
Received: from [147.214.22.133] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.328.9; Mon, 25 Nov 2013 13:24:51 +0100
Message-ID: <52934193.5050304@ericsson.com>
Date: Mon, 25 Nov 2013 13:24:51 +0100
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Tom Kristensen <tomkrist@cisco.com>, <bfcpbis@ietf.org>
References: <20131104104454.10115.16900.idtracker@ietfa.amsl.com> <52777C07.1080403@cisco.com>
In-Reply-To: <52777C07.1080403@cisco.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkluLIzCtJLcpLzFFi42KZGfG3Vney4+Qgg2m/TC3+rTvKZHHlyC82 ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvj39Pwgn75ipZXXxkbGD9JdDFycEgImEis 2J7RxcgJZIpJXLi3nq2LkYtDSOAIo8TjH7eZIJw1jBJHTh5nA6niFdCW+Pj1IztIM4uAqsT0 ObogYTYBC4ktt+6zgNiiAlES58+9ZIIoF5Q4OfMJC0i5iIC1xMt//CBhYQF3iT/XWsFKhATi JJoaDoBN5xTQlHh5o5sZ4jRxiZ7GIJAws4CexJSrLYwQtrzE9rdzmCFatSWWP2thmcAoOAvJ sllIWmYhaVnAyLyKkaM4tTgpN93IYBMjMBgPbvltsYPx8l+bQ4zSHCxK4rwf3zoHCQmkJ5ak ZqemFqQWxReV5qQWH2Jk4uCUamBs/txt8Zc38XVJtQCDs4Z1RNj6WItzc75PVanOzrHwFZ/U WDL9pWbqsto3egsDb5/w3Mn0kNHF3L+tokbsv+XKZRdXqOhlb58qrVmeIXnxyP5p059suLiQ X1LCnDHAbd57tvQzm7Sn+Vo2MUwqrVoXKFey5GPTxMYFtWnsDrZLy6dqu3qt2KrEUpyRaKjF XFScCAD6dk7IFAIAAA==
Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-10.txt
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Nov 2013 12:24:55 -0000

Hi Tom,

thanks for keeping the draft alive. I have had q quick look at Section 6
and I have a few comments.

http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-10#section-6

The first paragraph of Section 6 states that an entity can choose TCP or
UDP depending on the environment. Lately, the IESG is asking authors to
be a bit more explicit about operational issues. So, I think we should
add a few sentences explaining (briefly) who makes that decision. Is it
the implementation that first tries TCP and, if it does not work, it
falls back to UDP? Or do we expect administrators to configure this
depending on the environment? We can describe several potential
different deployment scenarios as well.

The second paragraph of Section 6.2 explains that the floor control
server is considered present and available upon receiving a HelloAck
message. We should also explain the circumstances in which the service
is considered to have become unavailable (e.g., ICMP messages or
timeouts).

The following is the last sentence of the 3rd paragraph of Section 6.2:

>    Concordantly, messages sent by the floor
>    control server that are not transaction-completing (e.g., FloorStatus
>    announcements as part of a FloorQuery subscription) are server-
>    initiated transactions that require acknowledgement messages from the
>    floor participant and chair entities to which they were sent.


I do not think the term "transaction-completing" have been defined in
the document. We should use a different term or, even better, explain
explicitly what we mean. Also, I do not understand the point the
sentence is intended to make. We should rephrase.

The 4th paragraph of Section 6.2 talks about the "Unable to parse"
message in the context of unreliable transports. Why don't we use that
with TCP as well? Is it because of backward compatibility issues? If so,
we should add a clarifying note.

The following sentence appears in the first paragraph of page 41:

>    The subsequent changes in state for
>    the request are new transactions whose Transaction ID is determined
>    by the floor control server and whose receipt by the client
>    participant shall be acknowledged with a FloorRequestStatusAck
>    message.

Instead of "shall be", we should write "MUST be" if this behavior has
not been normatively defined anywhere else, or "is" if the behavior has
been normatively defined somewhere else.

The following paragraph appears later in Section 6.2:

>    If a client wishes to end its BFCP connection with a floor control
>    server, it is RECOMMENDED that the client send a Goodbye message to
>    dissociate itself from any allocated resources.  If a floor control
>    server wishes to end its BFCP connection with a client (e.g., the
>    Focus of the conference informs the floor control server that the
>    client has been kicked out from the conference), it is RECOMMENDED
>    that the floor control server send a Goodbye message towards the
>    client.

Why is it RECOMMENDED (i.e., SHOULD level) instead of REQUIRED (i.e.,
MUST level)? This comment is also somewhat related to my first comment
above about BFCP entities considering other entities gone. Have we
defined at which point can they forget their state information? This
also relates to the last paragraph of Section 6.2.2 that talks about
using STUN connectivity checks for this. We should probably talk about
all this somewhere.

The following paragraph appears in Section 6.2.3:

>    When a BFCP implementation receives a BFCP message fragment, it MUST
>    buffer the fragment until it has received the entire BFCP message.
>    The state machine should handle the BFCP message only after all the
>    fragments for the message have been received.

However, the paragraph after that seems to contradict the "MUST" above
because it allows receivers to discard incomplete buffers.

Cheers,

Gonzalo