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

From: "Alfred E. Heggestad" <[email-masked]>
Date: Mon, 16 Jul 2012 14:51:34 +0200

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

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 16 Jul 2012 17:47:50 +0000

> should we try again or treat it as an implicit Goodbye message ?

If ICE is not used BFCP must do keep alive with no help. Maybe specify STUN      binding indication?

> that this information should be used for anything.

+1
> NAT traversal as should be defined outside this document (e.g. ICE).

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

+10

_._
Pål-Erik
>From phone...

> 
> /alfred
> _______________________________________________
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis

---

From: "Horvath, Ernst" <[email-masked]>
Date: Wed, 25 Jul 2012 10:16:16 +0000

Comments inline.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alfred E. Heggestad
> Sent: Montag, 16. Juli 2012 14:52
> To: [email-masked]
> Subject: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4582bis-04
> 
> Hi,
> 
> 

I agree. In addition a BFCP message can in theory also exceed the maximum length of a UDP datagram because BFCP message length is expressed in 4-octet word units whereas the datagram length is a simple octet count. Should we say "exactly one BFCP message or message segment per UDP datagram" in order to allow the theoretical case of a BFCP message being larger than 65,535 octets?
 
> since the ErrorAck primitive was deleted from the spec... (?)

That's right. I also think the sentence before that:
   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 and await retransmission.
is a problem because the server will not resend the response. Or does it mean that the client retransmits the request? If so, it should be stated more clearly.

Regards,
Ernst