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

[Gonzalo Camarillo <[e-mail]>]

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