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

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 22 Sep 2015 20:49:36 +0000

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

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 24 Sep 2015 02:53:33 +0000

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:
>   * 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:
>     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
>     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