[bfcpbis] Comments on draft-ietf-bfcpbis-rfc4582bis-14

["Paul E. Jones" <[e-mail]>]

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