Re: [bfcpbis] WGLC for draft-ietf-bfcpbis-rfc4582bis

[Tom Kristensen <[e-mail]>]

On 09/25/2012 12:18 AM, Charles Eckel (eckelcu) wrote:

Reply comments inline.

> (as an individual)
>
> I have reviewed the draft and I think that overall it is in very good shape. The only comment I would consider major is one dealing with section 4's description of server-initiated transactions:
>
> Section 4 reads as follows:
>
>     There are two types of transaction in BFCP: client-initiated
>     transactions and server-initiated transactions.  Client-initiated
>     transactions consist of a message from a client to the floor control
>     server and a response from the floor control server to the client.
>     Correspondingly, server-initiated transactions consist of a message
>     from the floor control server to a client and the associated
>     acknowledgement message from the client to the floor control server.
>     Both messages can be related because they carry the same Transaction
>     ID value in their common headers.
>
> This is accurate when using UDP as the transport, but does not account for the case of using TCP as the transport. A more detailed and accurate description is provided in Section 8, which reads as follows:
>
>     In BFCP, there are two types of transactions: client-initiated
>     transactions and server-initiated transactions (notifications).
>     Client-initiated transactions consist of a request from a client to a
>     floor control server and a response from the floor control server to
>     the client.  The request carries a Transaction ID in its common
>     header, which the floor control server copies into the response.
>     Clients use Transaction ID values to match responses with previously
>     issued requests.
>
>     Server-initiated transactions consist of a single message from a
>     floor control server to a client.  Since they do not trigger any
>     response, their Transaction ID is set to 0 when used over reliable
>     transports, but must be non-zero and unique in the context of
>     outstanding transactions over unreliable transports.
>
> I suggest replacing the section 4 text with the following introductory level text, that currently exists in section 8 .
>
>     In BFCP, there are two types of transactions: client-initiated
>     transactions and server-initiated transactions (notifications).
>
> The rest of the details currently in section 4 can  replaced with a reference to section 8.
>    
I agree. Good catch as well, since the section 4 text is unchanged from 
RFC 4582 - and amusingly enough fits with the semantics of UDP/BFCP!
> I also have the following minor  comments.
>
> 1) Section 5.2.6, note after table 5
> r/is intended being used/is intended to be used
>    
OK.
> 2) Section 5.3.14 current reads as follows:
>
>     Floor participants and chairs acknowledge the receipt of a subsequent
>     FloorRequestStatus message from the floor control server when
>     communicating over unreliable transport.
>
> I suggest the following rewording:
>
>     When communicating over unreliable transport, floor participants and chairs
>     acknowledge the receipt of a subsequent FloorRequestStatus message from
>     the floor control server by sending an FloorRequestStatusAck.
>
> 3) Similar change for section 5.3.15.
>    
OK for 2) and 3). Easier to read and understand.
> 4) Section 6.2, currently contains the following fragment:
>
>     Only allowing exactly one BFCP message or message segment per UDP
>     datagram.
>
> This is covered previously in the paragraph, so this fragment can be removed.
>    
Fine, but I'll add "... or message segment" to the previous sentence, so 
that it reads:
  "Each BFCP UDP datagram MUST contain exactly
    one BFCP message or message segment"
> 5) Section 6.2,
> r/Entities MUST only have at most one/Entities MUST have at most one
>    
Agree, better language!
> 6) Section 6.2.1
> r/attempt, this is identical/attempt. This is identical
OK.


I'll change the upcoming rfc4582bis version accordingly if no objections 
or further comments on these issues are received.

-- Tom