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

From: "Horvath, Ernst" <[email-masked]>
Date: Wed, 27 Jun 2012 15:20:03 +0000

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

---

From: Tom Kristensen <[email-masked]>
Date: Fri, 29 Jun 2012 15:12:58 +0200

Great; impressing review and feedback!  I have just browsed through your 
comments and will provide feedback as I carefully read through the draft.

-- Tom

On 06/27/2012 05:20 PM, Horvath, Ernst wrote:
> _______________________________________________
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>