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

["Pal Martinsen (palmarti)" <[e-mail]>]

Den 16. juli 2012 kl. 14:51 skrev "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 ?
> 
> 

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

> 
> 
>>   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.

+1
> 
> 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).

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

+10


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


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