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

Thanks for your answers, Tom.

Gonzalo

On 12/11/2012 4:04 PM, Tom Kristensen wrote:
> 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
>> bfcpbis@ietf.org
>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>
> 