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

From: Tom Kristensen <[email-masked]>
Date: Thu, 02 Aug 2012 19:00:28 +0200

On 07/16/2012 02:51 PM, Alfred E. Heggestad wrote:
> Hi,
>
>
> here is my review comments of draft-ietf-bfcpbis-rfc4582bis-04

Great! (I'll split my answers in separate messages per subsection)

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

If I recall correctly, the SHOULD is used since both the Fragmentation 
(F) flag bit and the Transaction Responder (R) flag bit is taken from 
the 5 bit reserved field in RFC4582. When used over reliable transport 
(and version==1), we'd like be backwards compatible and not mandate 
setting these bits to zero. (Even though the sender SHOULD indeed, and 
the receiver MUST ignore the reserved field).

However, I agree that we should append "...[SHOULD be cleared] by the 
sender of the message and MUST be ignored by the receiver" to this 
sentence in question for both the R and F fields.

OK?

-- Tom

---

From: Tom Kristensen <[email-masked]>
Date: Thu, 02 Aug 2012 19:11:27 +0200

On 07/16/2012 07:47 PM, Pal Martinsen (palmarti) wrote:
> Den 16. juli 2012 kl. 14:51 skrev "Alfred E. Heggestad"<[email-masked]>:
>
[...]

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

Will do!

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

The approach taken here was to not add redundant text and not specify 
behaviour when not necessary. However, if the recommendation is unclear 
- as it seems - we may have to add some amount of "advice" regarding this.

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

Fine with me.

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

Yes, I believe that is the approach chosen - althoug not followed as 
cleanly as it should apparently!

-- Tom

---

From: Tom Kristensen <[email-masked]>
Date: Thu, 02 Aug 2012 19:26:49 +0200

On 07/25/2012 12:16 PM, Horvath, Ernst wrote:
> Comments inline.
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alfred E. Heggestad
>> Sent: Montag, 16. Juli 2012 14:52
[...]

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

Yes, the wording needs to be clarified and brushed up here - according 
to the feedback here.  Stating explicitly that fragmentation is handled 
by BFCP itself is good to add.

Stating "one message/segment per datagram" explicitly will also do it 
clearer and avoid any confusion and IP layer fragmentation.

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

Nice spotted, since ErrorAck is gone, so no acknowledge is needed (or 
even possible) here.

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

My interpretation of this is that the client could discard the message 
before it's delivered to the "BFCP state machinery", i.e. the client 
will retransmit due to a missing response. However, do we need this text 
and proposed behaviour at all? Messages that cannot by fully parsed and 
interpreted is not too useful anyway...

-- Tom