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

From: [email-masked]
Date: Mon, 04 Nov 2013 02:44:54 -0800

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-10.txt
	Pages           : 90
	Date            : 2013-11-04

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-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-rfc4582bis-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tom Kristensen <[email-masked]>
Date: Mon, 04 Nov 2013 11:50:47 +0100

> 	Filename        : draft-ietf-bfcpbis-rfc4582bis-10.txt

Pure keep-alive version. Only changes are rfc4582bis and rfc4583bis 
(reference to) version numbers and dates.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 25 Nov 2013 13:24:51 +0100

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