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

[Tom Kristensen <[e-mail]>]

Thanks, a bit hasty there. Fixed now, time to submit just-in-time.

-- Tom


On 14 February 2014 23:28, Charles Eckel (eckelcu) <[e-mail]>wrote:

>  Editorial nits inline in case you have not submitted yet.
>
>   From: Tom Kristensen <[e-mail]>
> Date: Friday, February 14, 2014 1:38 PM
> To: Charles Eckel <[e-mail]>
> Cc: Gonzalo Camarillo <[e-mail]>, Tom Kristensen <
> [e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-10.txt
>
>   On 14 January 2014 20:03, Charles Eckel (eckelcu) <[e-mail]>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" <[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.
>
>
>  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/
> ## [e-mail]  |  http://www.tandberg.com
> ###                               |  http://folk.uio.no/tomkri/
>
>


-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## [e-mail]  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/