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

["Horvath, Ernst" <[e-mail]>]

Comments inline.

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Alfred E. Heggestad
> Sent: Montag, 16. Juli 2012 14:52
> To: [e-mail]
> Subject: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4582bis-04
> 
> 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.

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?
 
> 
> 
> 
> 
> >    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... (?)

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

> 
> 
> 
> 
> 
> > 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
> _______________________________________________
> bfcpbis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>