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

Tom Kristensen <> Fri, 14 February 2014 21:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 657721A03ED for <>; Fri, 14 Feb 2014 13:38:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1UP_uYSqElRA for <>; Fri, 14 Feb 2014 13:38:24 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c01::22b]) by (Postfix) with ESMTP id 7D6B21A03C8 for <>; Fri, 14 Feb 2014 13:38:24 -0800 (PST)
Received: by with SMTP id n7so21347870qcx.30 for <>; Fri, 14 Feb 2014 13:38:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mmj6dFnINeM3TPmseBAwf1I40lTS0sK8SekMnY3Q0b4=; b=G8To8nk/eK6EsyFTekWcRFZ89QuZK2PPfm2H0iEzScd0xPlrMsRgv486c60jrkuzHb T+aInLKy0QMOwW7GnGzGQI/Ks9my5mK7XShprSx9z/fqR+NBq8YMcGM0S9wYnNVXfCLn 1EXXr5l6pDHLrSDqQQWnJdEvNaK498O9xGrO6BtvUAg+YRpKiLxPwVpkZ4pK345rxq7w y54ej1pkhf0X4FDswiJ6LNuQFuGh+s617AaLGacvXJnmEc0wuB9wbBzUl0buy3hX5drC zeyhqxYXtAx34nhwKjdZpc3CMpgFsLJKFN0nd85xjeTsWtQTfCDHyiIeAy7hD4XpB2Ur LBaw==
MIME-Version: 1.0
X-Received: by with SMTP id a3mr17725291qam.34.1392413902718; Fri, 14 Feb 2014 13:38:22 -0800 (PST)
Received: by with HTTP; Fri, 14 Feb 2014 13:38:22 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 14 Feb 2014 22:38:22 +0100
Message-ID: <>
From: Tom Kristensen <>
To: "Charles Eckel (eckelcu)" <>
Content-Type: multipart/alternative; boundary="001a11c2dac00d4b9204f264a0c3"
Cc: "" <>, Gonzalo Camarillo <>, "Tom Kristensen (tomkrist)" <>
Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-10.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BFCPBIS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Feb 2014 21:38:28 -0000

On 14 January 2014 20:03, Charles Eckel (eckelcu) <> wrote:

> 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" <>
> wrote:
> >Hi Tom,
> >
> >thanks for keeping the draft alive. I have had q quick look at Section 6
> >and I have a few comments.
> >
> >
> >
> >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.

I have added an informational note in Section 6, it reads as follows:

     "Informational note: In practice products is configured to try one
      transport initially and use the other one as a fallback.  Whether
      TCP or UDP is chosen as underlying transport depends on type of
      product and the nature of the environment it is deployed, here the
      considerations in Appendix B is an important input."

> >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 ICMP behaviour is defined in 6.2.2. Also, the behaviour when timers
fire are described in Section 8.

>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

A better explanation and we avoid introducing a term
(transaction-completing), that is not defined or even needed.

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

Right. And there's no need for an explanation of that rationale in the
draft I assume.

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

Yes, fixed to avoid "confusion" as normative statements are provided for
this elsewhere.

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

I agree. I'm not quite sure, but it might be that the SHOULD level stems
from earlier versions where Goodbye also was an option specified for TCP in
a common section. Will change to REQUIRED in that paragraph.

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

Yes, fixed accordingly.

-- Tom

# Cisco                         |
##  |
###                               |