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

[Tom Kristensen <[e-mail]>]

On 07/25/2012 12:16 PM, Horvath, Ernst wrote:
> Comments inline.
>
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] 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