[bfcpbis] Comments on draft-ietf-bfcpbis-rfc4582bis-04

["Alfred E. Heggestad" <[e-mail]>]

Hi,


here is my review comments of draft-ietf-bfcpbis-rfc4582bis-04




 > Section 5.1
 >
>    R: The Transaction Responder (R) flag-bit has relevance only for use
>    of BFCP over unreliable transport.  When cleared, it indicates that
>    this message is a request initiating a new transaction, and the
>    Transaction ID that follows has been generated for this transaction.
>    When set, it indicates that this message is a response to a previous
>    request, and the Transaction ID that follows is the one associated
>    with that request.  When BFCP is used over reliable transports, the
>    flag has no significance and SHOULD be cleared.

suggest rewrite to .. "SHALL be cleared by the sender and ignored by
the receiver"




> 6.2. Unreliable Transport
>
>
>    BFCP entities may elect to exchange BFCP messages using UDP
>    datagrams.  UDP is an unreliable transport where neither delivery nor
>    ordering is assured.  Each BFCP UDP datagram MUST contain exactly one
>    BFCP message.  In the event the size of a BFCP message exceeds the
>    MTU size, the BFCP message will be fragmented at the IP layer.

from the wording it is not clear that message fragmentation is handled
by BFCP itself.. it can be mis-interpreted to think that the IP layer
is responsible for that. perhaps we should reword this part a bit,
to make it explicitly clear that BFCP messages above MTU size MUST be
fragmented by the BFCP-layer itself.




>    client MAY discard the message and await retransmission.  BFCP
>    entities receiving an Error message with value 10 SHOULD acknowledge
>    the error and act accordingly.

I believed that it is not possible to acknowledge an Error message anymore,
since the ErrorAck primitive was deleted from the spec... (?)





> 6.3.2. NAT Traversal
>
 > ...
 >
>    In order to facilitate the initial establishment of NAT bindings, and
>    to maintain those bindings once established, BFCP over UDP entities
>    are RECOMMENDED to use STUN [11] for keep-alives, as described for
>    SIP [10].

reference [10] points to sip-outbound, to make this explicitly more clear
we could rename the text to "SIP Outbound [10].

using STUN for keepalive in SIP-outbound is done from the SIP-client to
the SIP-server, which has an embedded STUN server to reply to STUN messages.
it is not very clear to me how this usage is defined in BFCP.

for example, what should happen if a STUN Request/Response exchange times out?
should we try again or treat it as an implicit Goodbye message ?




>    This results in each BFCP entity sending a packet, both to
>    open the pinhole and to learn what IP/port the NAT assigned for the
>    binding.

I think the text about learning IP/port should be deleted, I dont think
that this information should be used for anything.

I believed that STUN/BFCP is mainly about NAT keepalive, and not about
NAT traversal as should be defined outside this document (e.g. ICE).



...



NOTE: kudos to the authors for doing a great job!


/alfred