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

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:
> 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
> _______________________________________________
> bfcpbis mailing list
> bfcpbis@ietf.org
> https://www.ietf.org/mailman/listinfo/bfcpbis
>    