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

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Sun, 16 February 2014 09:16 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 038CB1A03A7 for <bfcpbis@ietfa.amsl.com>; Sun, 16 Feb 2014 01:16:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.851
X-Spam-Level:
X-Spam-Status: No, score=-103.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 n-sVQcu7bj1D for <bfcpbis@ietfa.amsl.com>; Sun, 16 Feb 2014 01:16:07 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7D61A013A for <bfcpbis@ietf.org>; Sun, 16 Feb 2014 01:15:53 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-48-530081c019f0
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 32.69.23809.0C180035; Sun, 16 Feb 2014 10:15:45 +0100 (CET)
Received: from [131.160.126.48] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.2.347.0; Sun, 16 Feb 2014 10:15:44 +0100
Message-ID: <530081BE.6060706@ericsson.com>
Date: Sun, 16 Feb 2014 11:15:42 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Tom Kristensen <2mkristensen@gmail.com>, "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
References: <20131104104454.10115.16900.idtracker@ietfa.amsl.com> <52777C07.1080403@cisco.com> <52934193.5050304@ericsson.com> <CEFAC2B1.1A751%eckelcu@cisco.com> <CAFHv=r8WN4Nj6ZDHdSNeK194peHWdOZxpJhwePyvpaETgY8-hg@mail.gmail.com> <CF23D77E.1F021%eckelcu@cisco.com> <CAFHv=r8Ggyvq91xwZBNu6_kW-_sgs8+Ps+yToGeZtLXaj7rtHg@mail.gmail.com>
In-Reply-To: <CAFHv=r8Ggyvq91xwZBNu6_kW-_sgs8+Ps+yToGeZtLXaj7rtHg@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+Jvje7BRoZgg9dnOCy2HH/HYvFv3VEm i02zvrBZXDnyi82BxWPK742sHjtn3WX3WLLkJ1MAcxSXTUpqTmZZapG+XQJXxqSlU1kK5kVW fGj7zdrAeM+yi5GTQ0LARKJ9ehszhC0mceHeerYuRi4OIYFDjBInD/9kh3DWMEo8WH6aDaSK V0BbYv3yHWAdLAKqEv3T17OC2GwCFhJbbt1nAbFFBaIkfl5ZwA5RLyhxcuYTsLiIQIzEygMN YDazQKxE19RjTCC2sIC7xJ9rrWC2kMA5Jome7dFdjBwcnAKBEg/nBIOYEgLiEj2NQRCdBhJH Fs1hhbDlJZq3zmaG6NSWWP6shWUCo9AsJItnIWmZhaRlASPzKkb23MTMnPRyo02MwDA+uOW3 6g7GO+dEDjFKc7AoifN+eOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGx+J3d5Wfn5Yt+ arxdPu0KO7OI5yujWSv4eL64NyfOlkgoLNnu1ODqWWQruqm3oDr63rvAowJPiyO+bdEqm1Dq rnTvetzuNO4cffsz6Ss5TJ34D27OfHxqpV798tC9NnoPT62U8fqZkL1pNVfg3va2pZ0O1n9P hufmd04sd5NhS91xY8PHZVOUWIozEg21mIuKEwFVy55QMQIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/6YJHVWc4irElo0azecU8TTNh3MI
Cc: "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "Tom Kristensen (tomkrist)" <tomkrist@cisco.com>
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: Sun, 16 Feb 2014 09:16:10 -0000

Thanks!

Gonzalo

On 15/02/2014 1:24 AM, Tom Kristensen wrote:
> Thanks, a bit hasty there. Fixed now, time to submit just-in-time.
> 
> -- Tom
> 
> 
> On 14 February 2014 23:28, Charles Eckel (eckelcu) <eckelcu@cisco.com
> <mailto:eckelcu@cisco.com>> wrote:
> 
>     Editorial nits inline in case you have not submitted yet.
> 
>     From: Tom Kristensen <2mkristensen@gmail.com
>     <mailto:2mkristensen@gmail.com>>
>     Date: Friday, February 14, 2014 1:38 PM
>     To: Charles Eckel <eckelcu@cisco.com <mailto:eckelcu@cisco.com>>
>     Cc: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com
>     <mailto:Gonzalo.Camarillo@ericsson.com>>, Tom Kristensen
>     <tomkrist@cisco.com <mailto:tomkrist@cisco.com>>, "bfcpbis@ietf.org
>     <mailto:bfcpbis@ietf.org>" <bfcpbis@ietf.org <mailto:bfcpbis@ietf.org>>
>     Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-10.txt
> 
>         On 14 January 2014 20:03, Charles Eckel (eckelcu)
>         <eckelcu@cisco.com <mailto:eckelcu@cisco.com>> 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"
>             <Gonzalo.Camarillo@ericsson.com
>             <mailto:Gonzalo.Camarillo@ericsson.com>>
>             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.
> 
> 
>         I have added an informational note in Section 6, it reads as
>         follows:
> 
>              "Informational note: In practice products is configured to
>         try one
> 
> 
>     In practice, products are …
> 
>               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
> 
> 
>     deployed. Here …
> 
>               considerations in Appendix B is an important input."'
> 
> 
>     … Appendix B are important to consider.
> 
>          
> 
>             >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.
> 
> 
>     are described -> is described
> 
>     Cheers,
>     Charles
> 
> 
>             >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                         |
>          http://www.cisco.com/telepresence/
>         ## tomkrist@cisco.com <mailto:tomkrist@cisco.com>  |
>          http://www.tandberg.com
>         ###                               |  http://folk.uio.no/tomkri/
> 
> 
> 
> 
> -- 
> # Cisco                         |  http://www.cisco.com/telepresence/
> ## tomkrist@cisco.com <mailto:tomkrist@cisco.com>  |
>  http://www.tandberg.com
> ###                               |  http://folk.uio.no/tomkri/