Re: [Gen-art] Comments on draft-ietf-bfcpbis-rfc4582bis-14

[Suresh Krishnan <[e-mail]>]

Hi Paul,
   Your proposed changes completely resolve my concerns on -13. Thanks 
for taking care of this.

Cheers
Suresh

On 09/22/2015 04:50 PM, Paul E. Jones wrote:
> Folks,
> Alissa asked me to review the current text, provide input, and help
> address some of the current DISCUSS points.
> Here are some suggested improvements:
> Editorial:
>
>   * In Section 4.1, it says "Subsequent FloorStatus messages consist of
>     server-initiated transactions, and therefore their Transaction ID is
>     0."  This is true since the transport in these examples is
>     reliable.  While perhaps minor, I think it might be worth explicitly
>     stating that be appending "given the example uses a reliable
>     transport", otherwise the reader may miss that there is a difference
>     in behavior when communicating over unreliable transports.
>   * In 5.3.7, it says "the following is the format of the FloorRequest
>     message".  That should be "FloorQuery message"
>   * In 6.2.3, the equation:
>       (message size - COMMON-HEADER size / MTU size - COMMON-HEADER size)
>     for better readability should say:
>       ((message size - COMMON-HEADER size) / (MTU size - COMMON-HEADER
>     size))
>   * In 10.2.2, it reads "A message from the floor control server is
>     considered a response to the *FloorRelease *message if the message
>     from the floor control server has the same Conference ID,
>     Transaction ID, and User ID as the *FloorRequest* message."  I
>     believe "FloorRequest" should be "FloorRelease".
>   * A similar copy/paste error as above was noted in 12.1.2.
>   * I think it would be beneficial in Appendix A to explicitly show what
>     the "R" value is.  It is possible for a floor participant and a
>     floor control server to each initiate a transaction at the same time
>     with Transaction ID == 124, for example.  The "R" bit is what helps
>     to differentiate transactions and their responses, and I think that
>     would be helpful here.
>
> Technical:
>
>   * Section 10.1.1 says the "User ID will be used by the floor control
>     server to authenticate and authorize the request."  TLS/DTLS is used
>     for authentication/authorization presently.  Further, the draft more
>     than once that other mechanisms might be developed in the
>     future.  Merely looking at this field in a message, though, is not
>     sufficient to authenticate or authorize a request.  This existed in
>     the original RFC, but I propose we strike the sentence.
>
> Paul