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

(as an individual)

Thanks again for the thorough review and comments!
Please see comments inline.

> -----Original Message-----
> From: bfcpbis-bounces@ietf.org [mailto:bfcpbis-bounces@ietf.org] On
> Behalf Of Horvath, Ernst
> Sent: Wednesday, June 27, 2012 8:20 AM
> To: Tom Kristensen (tomkrist)
> Cc: bfcpbis@ietf.org
> Subject: [bfcpbis] More comments on draft-ietf-bfcpbis-rfc4582bis-03
> 
> 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?

This is a carryover from RFC 4582, and should be corrected. The table and text should be modified. The following wording is used for similar scenarios elsewhere:
   Padding: One, two, or three octets of padding added so that the
   contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit
   aligned.  The Padding bits SHOULD be set to zero by the sender and
   MUST be ignored by the receiver.  If the attribute is already 32-bit
   aligned, no padding is needed.

> 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?

I agree that the first  FloorRequestStatus for a FloorRequest or FloorRelease does not require a FloorRequestStatusAck, and that clarification should be added here.

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

I agree that the first  FloorStatus for a FloorQuery does not require a FloorStatusAck, and that clarification should be added here.

> 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.

Yes, I think so as well. We do have the corresponding text in section 6.2 for when using UDP.

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

Works for me.

> 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"?

I agree there is a discrepancy and the number of transmissions/retransmissions needs to be stated consistently. I have a slight preference for having the original plus 3 retransmissions.

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

I am okay with removing it.

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

Yes, I think that is more clear.

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

Agreed.

> 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.

Yes, that seems helpful.

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

Yes, good catch.

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

Agreed.

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

Agreed.

> 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.

Yes.

> 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?

Yes, I agree

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

Agreed.

Cheers,
Charles

> Regards,
> Ernst
> _______________________________________________
> bfcpbis mailing list
> bfcpbis@ietf.org
> https://www.ietf.org/mailman/listinfo/bfcpbis