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

["Charles Eckel (eckelcu)" <[e-mail]>]

Hi Gonzalo,

I was looking through the archives and did not see any response to you
comments. Sorry for the delay. Please see inline.

On 11/25/13 4:24 AM, "Gonzalo Camarillo" <[e-mail]>
wrote:

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

In practice I have typically seen this configured as either use TCP first
and fallback to UDP or vice versa. Depending on the product and
environment, the choose of defaulting to TCP vs. UDP is made. The text in
Appendix B describes the challenges with using TCP in some environments.
In such environments, UDP would be typically be configured as the default.
 
>
>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.

How about:
Concordantly, messages sent by the floor control server that initiate new
transactions (e.g., FloorStatus announcements as part of a FloorQuery
subscription) require acknowledgement messages from the floor participant
and chair entities to which they were sent.


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

RFC 4582 stated the following, "If a BFCP entity (a client or a floor
control server) receives data from TCP that cannot be parsed, the entity
MUST close the TCP connection, and the connection SHOULD be reestablished."
As there is no concept of a connection with UDP, we decided to handle by
defining the new error code.

>
>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 normative language for this situation is in section 10.1.3, "When
communicating over an unreliable transport and upon receiving a
   FloorRequestStatus message from a floor control server, the
   participant MUST respond with a FloorRequestStatusAck message within
   the transaction failure window to complete the transaction."
I think replacing "shall be" with "is" is fine.

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

I cannot think of good reason for not sending a Goodbye. It may be that
the Goodbye fails, and I think there may be existing implementations that
do not send the Goodbye, but from a protocol perspective MUST/REQUIRED
strength seems appropriate.

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

I think it needs to read as follows, "When a BFCP implementation receives
a BFCP message fragment, it MUST buffer the fragment until either it has
received the entire BFCP message, or until the Response Retransmission
Timer expires."
There is also a "must" that should be changed to "MUST" in the paragraph
describing the retransmission timer.

Cheers,
Charles


>
>Cheers,
>
>Gonzalo
>
>_______________________________________________
>bfcpbis mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/bfcpbis