Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4582bis-06

[Tom Kristensen <[e-mail]>]

Commments and proposed solutions to the issues and questions raised by 
Gonzalo below. Prefixed with "TK:".

Note: There's five issues with a TBD (To be done). I'll initiate a 
separate mail to discuss these unresolved issues.

The other issues may be handled in this mail thread.

-- Tom

On 10/24/2012 12:21 PM, Gonzalo Camarillo wrote:
 > Folks,
 >
 > here you have some comments on the following draft:
 >
 > http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-06
 >
 > Cheers,
 >
 > Gonzalo
 >
 >
 > Comments on draft-ietf-bfcpbis-rfc4582bis-06
 >
 > In the whole document: when referring to a reliable or to an unreliable
 > transport, the indefinite article (i.e., "a" or "an") needs to be
 > used. For example:
 >
 > OLD:
 >
 > When communicating over unreliable transport...
 >
 > NEW:
 >
 > When communicating over an unreliable transport...

--
TK: Changed all occurrences with transport in singular.
--


 > Abstract:
 >
 > OLD:
 >
 > Changes from RFC 4582 are summarized in section 16.
 >
 > NEW:
 >
 > Changes from RFC 4582 are summarized in Section 16.

--
TK: Fixed.
--


 > Sections 3.1 and 3.3
 >
 > The document needs to reference the XCON documents (which were
 > published after RFC 4582) that deal with floor creation, termination,
 > and floor-resource association (e.g., RFC 6503). Roberta wrote the
 > following text. You can use it as a base, edit it as you wish, and add
 > a paragraph to each of the sections (3.1 and 3.3).
 >
 > "As to the XCON framework, floor settings such as floor identifiers,
 > associated resources, moderator identifier, etc., are held in the
 > <floor-information> section of conference objects. Conference control
 > clients using CCMP (RFC 6505) can specify such floor-related settings
 > by editing the floor-information section of the to-be created
 > conference object provided in the body of a CCMP confRequest/create
 > message issued to the conference control server. According to the
 > conferencing system policies, conference control clients can modify
 > the floor settings of a conference by issuing CCMP confRequest/update
 > messages providing the specific updates to the <floor-information>
 > section of the target conference object. More information about CCMP
 > and BFCP interaction can be found in RFC6504."

--
TK: Thanks for the input. Since CCMP is finished and the outcome of 
XCON, this is natural. Split the text in two and used some of it in the 
two sections.
--


 > Section 3.2:
 >
 > Add a reference to RFC 5018.

--
TK: Sentence with reference added.
--


 > Section 4:
 >
 > OLD:
 >
 > There are two types of transactions in BFCP: client-initiated
 > transactions and server-initiated transactions (notifications),
 > further details in Section 8.
 >
 > NEW:
 >
 > There are two types of transactions in BFCP: client-initiated
 > transactions and server-initiated transactions
 > (notifications). Section 8 describes both types of transactions in
 > detail.

--
TK: Adopted.
--


 > Section 4.1:
 >
 > OLD:
 >
 > Figures 2 and 3 below show call flows for two sample BFCP interactions
 > when used over reliable transport.  Appendix A shows the same sample
 > interactions but over an unreliable transport.
 >
 > NEW:
 >
 > Figures 2 and 3 below show examples of call flows where BFCP is used
 > over a reliable transport.  Appendix A shows the same call flow
 > examples using an unreliable transport instead.

--
TK: Adopted.
--


 > Sections 5.3.14 and 5.3.15 talk about acknowledging a "subsequent"
 > message. Why is it a subsequent message? Maybe we can delete that
 > word.

--
TK: It is subsequent in that it's not the initial FloorRequestStatus 
acknowleding the associated FloorRequest. The word might not be needed 
in Sections 5.3.14 and 5.3.15, but I'll remove it just if it is really 
confusing!?!

TBD #1.
--


 > Section 5.3.14.
 >
 > OLD:
 >
 > FloorRequestStatus message from the floor control server by sending an
 > FloorRequestStatusAck.
 >
 > NEW:
 >
 > FloorRequestStatus message from the floor control server by sending a
 > FloorRequestStatusAck message.
 >

 > Do a similar fix to the above across the document so that it is
 > consistent. For example, the same issue appears in Sections 5.3.15 and
 > 5.3.16.

--
TK: Done.
--


 > Section 6 says:
 >
 > "(e.g., using an SDP offer/answer exchange [7])"
 >
 > We should also add a reference to RFC 5018. Additionally, the document
 > could discuss at some point what happens when the mechanism in RFC
 > 5018 is used.

--
TK: RFC 5018 added.

Further discussion TBD #2.
--


 > Section 6:
 >
 > OLD:
 >
 > TCP, appropriate where entities can be sure that their connectivity is
 > not impeded by NAT devices, media relays or firewalls;
 >
 > NEW:
 >
 > TCP, appropriate where connectivity is not impeded by network elements
 > such as NAT devices or media relays;

--
TK: Adopted.
--


 > Section 6.1
 >
 > OLD:
 >
 > Consequently, message framing is implemented in the application
 > layer.
 >
 > NEW:
 >
 > Consequently, message framing needs to be implemented in the
 > application layer.

--
TK: Adopted.
--


 > Section 6.2
 >
 > OLD:
 >
 > To avoid BFCP messages being fragmented at the IP layer, in the event
 > the size of a BFCP message exceeds the MTU size, the fragmentation
 > will be handled by the BFCP protocol.
 >
 > NEW:
 >
 > To keep large BFCP messages from being fragmented at the IP layer, the
 > fragmentation of BFCP messages that exceeding the MTU size is
 > performed at the BFCP level.

--
TK: Adopted.
--


 > OLD:
 >
 > The message format for exchange of BFCP in UDP datagrams is the same
 > as for a TCP stream above.
 >
 > NEW:
 >
 > The message format for BFCP messages is the same regardless of whether
 > the messages are sent in UDP datagrams or over a TCP stream.

--
TK: Adopted.
--


 > In the following paragraph, I have removed the MUST because the floor
 > control server could respond with, for example, an error message
 > instead.
 >
 > OLD:
 >
 > Clients MUST announce their presence to the floor control server by
 > transmission of a Hello message.  This Hello message MUST be responded
 > to with a HelloAck message and only upon receipt of HelloAck can the
 > client consider the floor control service as present and available.
 >
 > NEW:
 >
 > Clients MUST announce their presence to the floor control server by
 > sending a Hello message. The floor control server responds to the
 > Hello message with a HelloAck message. The client considers the floor
 > control service as present and available only upon receiving the
 > HelloAck message.

--
TK: Nicely crafted. Adopted.
--


 > The following paragraph (the second sentence in particular) needs to
 > be clarified. The paragraph starts talking about a floor control
 > server receiving a message and then talks about a client discarding
 > the message. Also, why would an entity discard a message only to
 > receive a retransmission of the *same* message later? It is not clear
 > what the paragraph means.
 >
 > "If a Floor Control Server receives data that cannot be parsed, the
 > receiving server SHOULD send an Error message with parameter value 10
 > (Unable to parse message) indicating receipt of a malformed message.
 > If the message can be parsed to the extent that it is able to discern
 > that it was a response to an outstanding request transaction, the
 > client MAY discard the message as the client will retransmit the
 > message when the retransmit timer T1 specified in Section 8.3.1
 > fires."

--
TK: My understanding is that one might skip sending the Error message 
and just wait for the retransmission, that will come. However, this sort 
of optimization might be removed. Not needed and even mentioned just as 
a MAY.

Removal TBD #3.
--


 > The document says: " Transaction ID values are non-sequential and
 > entities are at liberty to select values at random."
 >
 > The document needs to make it clear what is the requirement and the
 > level of randomness required. For example, what happens if the same
 > transaction ID is reused and a retransmission of the message that
 > first used that transaction ID arrives?

--
TK: No real random numbers are needed. Might change the word 'random' to 
something else. What is important, is that the Transaction ID chosen is 
unique amongst the outstanding transactions. And over UDP only one 
outstanding transaction is allowed.  Will rework the text:

From:
"Transaction ID values are non-sequential and entities are at liberty to 
select values at random"
To:
"Transaction ID values are non-sequential and entities are at liberty to 
select arbitrary values, as long as the values are unique in the context 
of outstanding transactions."

Safer scheme to pick sequence number TBD #4. (To avoid late arriving 
retransmissions cause confusion).
--


 > What is a "delinquent" response?

--
TK: "Not-behaving" response?! In Section 6.2. Well, we may rename it to 
"conveyed in any such late arriving response" or "conveyed in any such 
late out-of-sequence sequence arriving response".  I prefer the first 
version; added to upcoming version of the draft.
--


 > Section 6.2.2 deals with ICMP errors for UDP. We should also specify
 > how to handle ICMP errors for TCP, for consistency.

--
TK: The main idea is to not change any TCP/BFCP semantics. However, we 
may add an ICMP part to the sentence of interest in Section 6.1, so that 
it reads:

"Similarly, if a TCP connection cannot deliver a BFCP message and times 
out or receives an ICMP port unreachable message mid-conversation, the 
TCP connection SHOULD be reestablished."
--


 > Also in Section 6.2.2, the following sentences talk about a
 > "conversation" and a "connection" in the context of UDP. What do those
 > terms mean?
 >
 > "The entity MAY attempt to re-establish the conversation afresh.  The
 > new connection will appear as a wholly new floor participant, chair or
 > floor control server with all state previously held about that
 > participant lost."

--
TK: Defined the term "BFCP connection" in Section 2, used regardless of 
transport. Changing "conversation" and "connection" to this term.
--


 > Section 6.2.2 also says:
 >
 > "Note: This is because the peer entities cannot rely on IP and port
 > tuple to uniquely identify the participant, nor would extending Hello
 > to include an attribute that advertised what the entity previously was
 > assigned as a User ID be acceptable due to session hijacking."
 >
 > This paragraph in unclear as well... it needs to be clarified together
 > with the previous one so that both are easier to understand.

--
TK: First two paragraphs of Section 6.2.2 rewritten, and read as follows:

     "Informational note: The recommendation to treat the connection as 
closed in this case, stems from the fact that the peer entities cannot 
rely on IP and port tuple to uniquely identify the participant, nor 
would extending Hello to include an attribute that advertised what 
identity the entity previously was assigned (i.e., a User ID) be 
acceptable due to session hijacking."
--


 > Also in Section 6.2.2, per one of my comments above, remove the
 > reference to firewalls. In general, remove references to firewalls
 > across the document (e.g., they also appear in Appendix A).

--
TK: Done. The word "firewall" now present only in a reference title and 
to describe IPv6 firewalls discarding ICMP (in the context of Teredo 
requiring ICMP6).
--


 > Section 6.2.3 says: "The size of a BFCP message is limited by the
 > 16-bit Payload Length field of the COMMON-HEADER." This is applicable
 > to BFCP messages in general whether they are sent over TCP or
 > UDP. However, Section 6.2.3 is under Section 6.2, which deals with
 > unreliable transports. The document needs to make it clear that this
 > is also applicable to TCP. Also, what is the implication of that
 > limit? What happens if a message would need to be larger than that?
 > What does the floor control server do in that case?

--
TK: Indeed. Moving the mentioned sentence to Section . And adding the 
following note for the Payload Length field specification:

            "Note: BFCP is designed to a achieve small message size, as 
explained in Section 1 and BFCP entities are REQUIRED to keep the BFCP 
message size smaller than the size limited by the 16-bit Payload Length 
field. To convey information not strictly related to floor control, 
other protocols should be used such as the XCON framework (cf. Section 3)."
--

 > Also in Section 6.2.3:
 >
 > "When using UDP, a single BFCP message may be fragmented at the IP
 > layer if its overall size exceeds the MTU threshold of the network."
 >
 > Use "path MTU" instead of "MTU threshold". Also, the sentence should
 > be clear that we are simply talking hypothetically, since BFCP
 > entities will not send such large messages; they will fragment them
 > instead following the steps that are described right after that
 > sentence.
 >
 > Across the document, always use "path MTU". Not "MTU" on any other
 > term.

--
TK: Done.
Added the sentence "To avoid this happening at the IP layer, a 
fragmentation scheme for BFCP is defined below" in the first paragraph 
of Section 6.2.3.
Using "path MTU" across the draft.
--


 > Also in Section 6.2.3:
 >
 > "When transmitting a BFCP message with size greater than the MTU, the
 > sender should fragment the message into a series of N contiguous data
 > ranges."
 >
 > We need to add a normative word. A MUST probably.

--
TK: Yes, MUST added.
--


 > Where does the document talk about path MTU discovery? How do BFCP
 > entities discover what is the path MTU?

--
TK: Path MTU discovery is not mentioned. Will add a sentence pointing to 
RFC 4821, RFC 1981 and RFC 1191 if appropriate.  (However, in practice 
most vendors will use the same simplistic approach as for RTP. And 
discovery not mentioned in RFC 3550 and only mentioned as "SHOULD run 
MTU discovery for this purpose" in RFC 6184, as examples.)

Adding:
   "BFCP entities should consider the MTU size available between the
    sender and the receiver and MAY run MTU discovery, such as
    [20][21][22], for this purpose."
--


 > Also in Section 6.2.3:
 >
 > "When a BFCP implementation receives a BFCP message fragment, it MUST
 > buffer the fragment until it has received the entire BFCP message."
 >
 > When dealing with fragmentation and especially with the buffering of
 > unauthenticated fragments one always thinks about DoS attacks. Could a
 > client perform a resource attack on a server by using this
 > fragmentation mechanism?  We should probably discuss this somewhere in
 > the document, explaining that the time this state is kept is limited
 > by a timer and what role DTLS plays into this.

--
TK: Adding the following text:

       "A Denial of Service (DoS) attacks utilizing the fragmentation
        scheme described above is mitigated by the fact that the
        Response Retransmission Timer is started after receipt of the
        first BFCP message fragment. In addition, the Payload Length
        field may be compared with the Fragment Offset and Fragment
        Length fields to verify the message fragments as they arrive.
        To make DoS attacks with spoofed IP addresses difficult,
        BFCP entities should use the cookie exchange mechanism in
        DTLS [RFC6347]"

A verification using Payload Length and so on might be hard to do right, 
but might be worth considering for implementers. Right?!
--


 > Also in Section 6.2.3:
 >
 > "The receiver MUST then retransmit the ACK.  The receiver can discard
 > an incomplete buffer utilizing the Response Retransmission Timer,
 > starting the timer after the receipt of the first fragment."
 >
 > The first sentence should not contain a normative statement, since
 > sending an ACK on receiving a message is specified somewhere
 > else. Also, the term "ACK" has not been defined in the document. It
 > should if we want to use it in this section.
 >
 > The second sentence should have a normative statement.

--
TK: s/ACK/acknowledgement/ or s/ACK/acknowledgement message/.

Normative statements changed/fixed; s/MUST/must/ + s/can/MAY/
--


 > Section 6.2.3 needs to briefly discuss (at the beginning of the
 > section) that BFCP acknowledges the reception of whole messages, not
 > of fragments. That is why the loss of a fragment implies the
 > retransmission of the whole message. The document can talk about how
 > inefficient that is and why we have decided to do it anyway (e.g.,
 > for simplicity reasons).

--
TK: Added the following:

     "BFCP is designed for achieveing small message size, due to
      the binary encoding as described in <xref target="intro"/>.
      The fragmentation scheme is therefore deliberately kept
      simple and straightforward, since the probability of
      fragmentation of BFCP messages being required is small.
      By design, the fragmentation scheme does not acknowledge
      individual BFCP message fragments. The whole BFCP message
      is acknowledged if received completely."
--


 > Section 6.2.3 needs to talk about the interactions of using DTLS and
 > fragmentation.

--
TK: Fragments are exchanged as datagrams over DTLS, just as ordinary 
unfragmented BFCP messages - right? However, I'll add a sentence about 
the path MTU considerations wrt. the overhead added by DTLS. Adding:

     "When deciding message fragment size based on path MTU, the BFCP
      fragmentation handling should take into account how the DTLS
      record framing expands the datagram size as described in
      Section 4.1.1.1 of RFC6347."
--


 > Section 6.2.4 talks (in a couple of places) about BFCP over UDP
 > entities. However, the rest of the document talks about entities using
 > unreliable transports. The terminology needs to be consistent.

--
TK: Fixed.
--


 > Section 8:
 >
 > "Server-initiated transactions consist of a single message from a
 > floor control server to a client.  Since they do not trigger any
 > response, their Transaction ID is set to 0 when used over reliable
 > transports, but must be non-zero and unique in the context of
 > outstanding transactions over unreliable transports."
 >
 > This paragraph needs to be rephrased so that it is clear how this
 > works for TCP and for UDP. For example, with UDP the transaction will
 > not be a single message.

--
TK: Clarified for the different transports. (A bit of text duplication, 
since the behaviour of the client-initiated trans. and the 
server-initiated trans. over unreliable transport is the same.)

      "When using reliable transport, server-initiated transactions 
consist of a single message from a floor control server to a client. And 
since they do not trigger any response, their Transaction ID is set to 0 
when used over reliable transports.
       When using unreliable transport, server-initiated transactions 
consist of a request from a floor control server to a client and a 
response from the client to the floor control server. The Transaction ID 
must be non-zero and unique in the context of outstanding transactions 
over unreliable transports. The client copies the Transaction ID into 
the response and the floor control server use Transaction ID values to 
match responses with previously issued requests."
--


 > Also in Section 8:
 >
 > "When using BFCP over unreliable transports, all requests will use
 > retransmit timer T1 (see Section 8.3) until the transaction is
 > completed."
 >
 > Use "retransmission timer" instead.

--
TK: Fixed.
--


 > Section 8.1
 >
 > "The client MUST set the Transaction ID value in the common header to
 > a number that is different from 0 and that MUST NOT be reused in
 > another message from the client until a response from the server is
 > received for the transaction."
 >
 > See my comment above about reusing transaction ID values and the risk
 > of receiving retransmissions of the original message.

--
TK: OK. This is kept from RFC 4582 using TCP (and no retransmissions). 
So, the idea should be to keep the RFC 4582 semantics for TCP transport 
and introduce some sort of "sliding window sequence number" reuse or 
simply add a sequential/wrapping sequence numbering for UDP as transport.

TBD #5. What do people think?
--


 > Section 8.3.1
 >
 > We probably want to remove the following statement:
 >
 > "Alternatively, they MAY continue without BFCP and therefore not be
 > participant in any floor control actions."

--
TK: Agree. No reason mentioning this.
--


 > Section 8.3.2
 >
 > "T2 shall be set such that it encompasses all legal retransmissions
 > per T1 plus a factor to accommodate network latency between BFCP
 > entities."
 >
 > This sentence probably belongs to Section 8.3.3, together with a
 > discussion on the default value that has been chosen for T2. Note that
 > whole Section 8.3.3 contains such a discussion for T1, it does not
 > contain one for T2.

--
TK: Sentence moved. Adding a description of why 10 sec default for T2 
was choosed, the resulting paragraph in 8.3.3 reads something like:

     "T2 SHALL be set such that it encompasses all legal retransmissions 
per T1 plus a factor to accommodate network latency between BFCP 
entities. The default value is based on the sum of the three 
retransmissions related to T1 using its default value (7.5s) and an 
extra 2.5s is added to take into account potential messages in transit 
due to latency."
--





>
> Comments on draft-ietf-bfcpbis-rfc4582bis-06
>
> In the whole document: when referring to a reliable or to an unreliable
> transport, the indefinite article (i.e., "a" or "an") needs to be
> used. For example:
>
> OLD:
>
> When communicating over unreliable transport...
>
> NEW:
>
> When communicating over an unreliable transport...
>
>
> Abstract:
>
> OLD:
>
> Changes from RFC 4582 are summarized in section 16.
>
> NEW:
>
> Changes from RFC 4582 are summarized in Section 16.
>
> Sections 3.1 and 3.3
>
> The document needs to reference the XCON documents (which were
> published after RFC 4582) that deal with floor creation, termination,
> and floor-resource association (e.g., RFC 6503). Roberta wrote the
> following text. You can use it as a base, edit it as you wish, and add
> a paragraph to each of the sections (3.1 and 3.3).
>
> "As to the XCON framework, floor settings such as floor identifiers,
> associated resources, moderator identifier, etc., are held in the
> <floor-information>  section of conference objects. Conference control
> clients using CCMP (RFC 6505) can specify such floor-related settings
> by editing the floor-information section of the to-be created
> conference object provided in the body of a CCMP confRequest/create
> message issued to the conference control server. According to the
> conferencing system policies, conference control clients can modify
> the floor settings of a conference by issuing CCMP confRequest/update
> messages providing the specific updates to the<floor-information>
> section of the target conference object. More information about CCMP
> and BFCP interaction can be found in RFC6504."
>
>
> Section 3.2:
>
> Add a reference to RFC 5018.
>
>
> Section 4:
>
> OLD:
>
> There are two types of transactions in BFCP: client-initiated
> transactions and server-initiated transactions (notifications),
> further details in Section 8.
>
> NEW:
>
> There are two types of transactions in BFCP: client-initiated
> transactions and server-initiated transactions
> (notifications). Section 8 describes both types of transactions in
> detail.
>
>
>
> Section 4.1:
>
> OLD:
>
> Figures 2 and 3 below show call flows for two sample BFCP interactions
> when used over reliable transport.  Appendix A shows the same sample
> interactions but over an unreliable transport.
>
> NEW:
>
> Figures 2 and 3 below show examples of call flows where BFCP is used
> over a reliable transport.  Appendix A shows the same call flow
> examples using an unreliable transport instead.
>
>
> Sections 5.3.14 and 5.3.15 talk about acknowledging a "subsequent"
> message. Why is it a subsequent message? Maybe we can delete that
> word.
>
>
> Section 5.3.14.
>
> OLD:
>
> FloorRequestStatus message from the floor control server by sending an
> FloorRequestStatusAck.
>
> NEW:
>
> FloorRequestStatus message from the floor control server by sending a
> FloorRequestStatusAck message.
>
>
> Do a similar fix to the above across the document so that it is
> consistent. For example, the same issue appears in Sections 5.3.15 and
> 5.3.16.
>
>
> Section 6 says:
>
> "(e.g., using an SDP offer/answer exchange [7])"
>
> We should also add a reference to RFC 5018. Additionally, the document
> could discuss at some point what happens when the mechanism in RFC
> 5018 is used.
>
>
> Section 6:
>
> OLD:
>
> TCP, appropriate where entities can be sure that their connectivity is
> not impeded by NAT devices, media relays or firewalls;
>
> NEW:
>
> TCP, appropriate where connectivity is not impeded by network elements
> such as NAT devices or media relays;
>
> Section 6.1
>
> OLD:
>
> Consequently, message framing is implemented in the application
> layer.
>
> NEW:
>
> Consequently, message framing needs to be implemented in the
> application layer.
>
> Section 6.2
>
> OLD:
>
> To avoid BFCP messages being fragmented at the IP layer, in the event
> the size of a BFCP message exceeds the MTU size, the fragmentation
> will be handled by the BFCP protocol.
>
> NEW:
>
> To keep large BFCP messages from being fragmented at the IP layer, the
> fragmentation of BFCP messages that exceeding the MTU size is
> performed at the BFCP level.
>
>
> OLD:
>
> The message format for exchange of BFCP in UDP datagrams is the same
> as for a TCP stream above.
>
> NEW:
>
> The message format for BFCP messages is the same regardless of whether
> the messages are sent in UDP datagrams or over a TCP stream.
>
>
> In the following paragraph, I have removed the MUST because the floor
> control server could respond with, for example, an error message
> instead.
>
> OLD:
>
> Clients MUST announce their presence to the floor control server by
> transmission of a Hello message.  This Hello message MUST be responded
> to with a HelloAck message and only upon receipt of HelloAck can the
> client consider the floor control service as present and available.
>
> NEW:
>
> Clients MUST announce their presence to the floor control server by
> sending a Hello message. The floor control server responds to the
> Hello message with a HelloAck message. The client considers the floor
> control service as present and available only upon receiving the
> HelloAck message.
>
>
> The following paragraph (the second sentence in particular) needs to
> be clarified. The paragraph starts talking about a floor control
> server receiving a message and then talks about a client discarding
> the message. Also, why would an entity discard a message only to
> receive a retransmission of the *same* message later? It is not clear
> what the paragraph means.
>
> "If a Floor Control Server receives data that cannot be parsed, the
> receiving server SHOULD send an Error message with parameter value 10
> (Unable to parse message) indicating receipt of a malformed message.
> If the message can be parsed to the extent that it is able to discern
> that it was a response to an outstanding request transaction, the
> client MAY discard the message as the client will retransmit the
> message when the retransmit timer T1 specified in Section 8.3.1
> fires."
>
>
> The document says: " Transaction ID values are non-sequential and
> entities are at liberty to select values at random."
>
> The document needs to make it clear what is the requirement and the
> level of randomness required. For example, what happens if the same
> transaction ID is reused and a retransmission of the message that
> first used that transaction ID arrives?
>
>
> What is a "delinquent" response?
>
>
> Section 6.2.2 deals with ICMP errors for UDP. We should also specify
> how to handle ICMP errors for TCP, for consistency.
>
> Also in Section 6.2.2, the following sentences talk about a
> "conversation" and a "connection" in the context of UDP. What do those
> terms mean?
>
> "The entity MAY attempt to re-establish the conversation afresh.  The
> new connection will appear as a wholly new floor participant, chair or
> floor control server with all state previously held about that
> participant lost."
>
>
> Section 6.2.2 also says:
>
> "Note: This is because the peer entities cannot rely on IP and port
> tuple to uniquely identify the participant, nor would extending Hello
> to include an attribute that advertised what the entity previously was
> assigned as a User ID be acceptable due to session hijacking."
>
> This paragraph in unclear as well... it needs to be clarified together
> with the previous one so that both are easier to understand.
>
>
> Also in Section 6.2.2, per one of my comments above, remove the
> reference to firewalls. In general, remove references to firewalls
> across the document (e.g., they also appear in Appendix A).
>
> Section 6.2.3 says: "The size of a BFCP message is limited by the
> 16-bit Payload Length field of the COMMON-HEADER." This is applicable
> to BFCP messages in general whether they are sent over TCP or
> UDP. However, Section 6.2.3 is under Section 6.2, which deals with
> unreliable transports. The document needs to make it clear that this
> is also applicable to TCP. Also, what is the implication of that
> limit? What happens if a message would need to be larger than that?
> What does the floor control server do in that case?
>
>
> Also in Section 6.2.3:
>
> "When using UDP, a single BFCP message may be fragmented at the IP
> layer if its overall size exceeds the MTU threshold of the network."
>
> Use "path MTU" instead of "MTU threshold". Also, the sentence should
> be clear that we are simply talking hypothetically, since BFCP
> entities will not send such large messages; they will fragment them
> instead following the steps that are described right after that
> sentence.
>
>
> Across the document, always use "path MTU". Not "MTU" on any other
> term.
>
>
> Also in Section 6.2.3:
>
> "When transmitting a BFCP message with size greater than the MTU, the
> sender should fragment the message into a series of N contiguous data
> ranges."
>
> We need to add a normative word. A MUST probably.
>
>
> Where does the document talk about path MTU discovery? How do BFCP
> entities discover what is the path MTU?
>
>
> Also in Section 6.2.3:
>
> "When a BFCP implementation receives a BFCP message fragment, it MUST
> buffer the fragment until it has received the entire BFCP message."
>
> When dealing with fragmentation and especially with the buffering of
> unauthenticated fragments one always thinks about DoS attacks. Could a
> client perform a resource attack on a server by using this
> fragmentation mechanism?  We should probably discuss this somewhere in
> the document, explaining that the time this state is kept is limited
> by a timer and what role DTLS plays into this.
>
>
> Also in Section 6.2.3:
>
> "The receiver MUST then retransmit the ACK.  The receiver can discard
> an incomplete buffer utilizing the Response Retransmission Timer,
> starting the timer after the receipt of the first fragment."
>
> The first sentence should not contain a normative statement, since
> sending an ACK on receiving a message is specified somewhere
> else. Also, the term "ACK" has not been defined in the document. It
> should if we want to use it in this section.
>
> The second sentence should have a normative statement.
>
>
> Section 6.2.3 needs to briefly discuss (at the beginning of the
> section) that BFCP acknowledges the reception of whole messages, not
> of fragments. That is why the loss of a fragment implies the
> retransmission of the whole message. The document can talk about how
> inefficient that is and why we have decided to do it anyway (e.g.,
> for simplicity reasons).
>
>
> Section 6.2.3 needs to talk about the interactions of using DTLS and
> fragmentation.
>
>
> Section 6.2.4 talks (in a couple of places) about BFCP over UDP
> entities. However, the rest of the document talks about entities using
> unreliable transports. The terminology needs to be consistent.
>
>
> Section 8:
>
> "Server-initiated transactions consist of a single message from a
> floor control server to a client.  Since they do not trigger any
> response, their Transaction ID is set to 0 when used over reliable
> transports, but must be non-zero and unique in the context of
> outstanding transactions over unreliable transports."
>
> This paragraph needs to be rephrased so that it is clear how this
> works for TCP and for UDP. For example, with UDP the transaction will
> not be a single message.
>
>
> Also in Section 8:
>
> "When using BFCP over unreliable transports, all requests will use
> retransmit timer T1 (see Section 8.3) until the transaction is
> completed."
>
> Use "retransmission timer" instead.
>
>
> Section 8.1
>
> "The client MUST set the Transaction ID value in the common header to
> a number that is different from 0 and that MUST NOT be reused in
> another message from the client until a response from the server is
> received for the transaction."
>
> See my comment above about reusing transaction ID values and the risk
> of receiving retransmissions of the original message.
>
> Section 8.3.1
>
> We probably want to remove the following statement:
>
> "Alternatively, they MAY continue without BFCP and therefore not be
> participant in any floor control actions."
>
>
> Section 8.3.2
>
> "T2 shall be set such that it encompasses all legal retransmissions
> per T1 plus a factor to accommodate network latency between BFCP
> entities."
>
> This sentence probably belongs to Section 8.3.3, together with a
> discussion on the default value that has been chosen for T2. Note that
> whole Section 8.3.3 contains such a discussion for T1, it does not
> contain one for T2.
>
>
>
>
>
> _______________________________________________
> bfcpbis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>