[bfcpbis] More comments on draft-ietf-bfcpbis-rfc4582bis-03

["Horvath, Ernst" <[e-mail]>]

Tom,

Here is the rest of (mostly minor) things I noticed during my review of the -03 draft:

Section 5.20.10:
The explanation of Padding below Table 17 says "Two octets of padding...". Why not one or three octets as well, as in other similar caeses?

Section 5.3.14:
Should the 1st sentence read "... on receipt of a _subsequent_ FloorRequestStatus message ..." since the first FlooRequestStatus is itself an acknowledgement and needs no further acknowledgment?

Section 5.3.16:
Similar to previous comment, should it be "... of a subsequent FloorStatus message ..."?

Section 6.1:
Why was the final paragraph of RFC 4582 section 6 omitted from the -bis draft? I assume it's an editorial slip.

Section 6.2, 2nd paragraph:
Change "only upon receipt can the client consider" to "only upon receipt of HelloAck can the client consider".

Section 6.2.1:
"... the message is retransmitted up to three times." Does that mean 3 retransmissions (i.e. 4 transmissions altogether) or the original transmission plus 2 retransmissions? The latter seems to be meant in section 8.3.1, which says "failing after three unacknowledged transmission attempts". Or should 8.3.1 also say "retransmission attempts"?

Section 6.2.2:
The text "and behave accordingly" at the end of the 1st sentence seems redundant.

Section 11.1:
In the 2nd paragraph, shouldn't "floor participant's  identifier" be "floor chair's identifier"?

Section 13, 2nd paragraph:
The second sentence should start "If it is not" (rather than "If it does not").

Section 13.1.1, 1st paragraph:
"... the first of which SHOULD be generated as soon as possible" could be made more specific with a hint to the retransmision window in case of an unreliable transport. Similarly in later subsections of 13.

Section 13.1.2:
The third paragraph is only true for reliable transport, a 2nd statement should be added for unreliable transport.

Section 13.4, 6th paragraph:
Change "the floors being requested" to "the floors being released".

Section 13.5, 1st paragraph:
On the 3rd line, change "FloorRelease message" to "FloorQuery message".

Section 13.5.2, end of 1st paragraph:
"but their Transaction ID is 0" is true for reliable transport only. Add a statement for unreliable transport. Similarly at the end of the 2nd paragraph.

Section 14, 4th paragraph:
I am not sure whether "Floor control server impersonation is avoided by having servers only accept BFCP messages over authenticated TLS/DTLS connections" is sufficient. Shouldn't there also be an onus on a client to send and accept messages over secure connections only?

Section 15:
Delete "This" from the start of the 1st sentence below the editorial note.

Regards,
Ernst