Subject: Re: [bfcpbis] Gen-ART Telechat review of draft-ietf-bfcpbis-rfc4582bis-13.txt

From: Tom Kristensen <[email-masked]>
Date: Thu, 20 Aug 2015 14:29:26 +0200

Thanks for the Gen-ART review. Response and hopefully a resolution inline
below.

On 2 March 2015 at 18:19, Suresh Krishnan <[email-masked]>
wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>
> Please wait for direction from your document shepherd or AD before
> posting a new version of the draft.
>
> Document: draft-ietf-bfcpbis-rfc4582bis-13.txt
> Reviewer: Suresh Krishnan
> Review Date: 2015/03/02
> IESG Telechat date: 2015/03/05
>
> Summary: This draft has significant issues that needs to be fixed before
> it is ready for publication as a Proposed Standard.
>
> Major:
>
> * Section 5.1:
>
> This section mandates the receiver to ignore the F bit if it is set
> while running over reliable transport. In my opinion this is not
> sufficient as the length of the header is determined by the bit being
> set. I strongly believe that this is an error condition and the packet
> should not be processed further. At the bare minimum, the draft needs to
> specify if the receiver should process the COMMON-HEADER as having 12
> octets or 16 octets in this case.
>

A problem here as for other fields is coping with senders implementeing the
RFC4582 subset only and not the extensions. I can see the problem, but
suggest that we keep the text and solution more or less as is. However, I
think it is a good idea to tell the receiver to process the received packet
as having 12 octets to definitely ignore the F bit in this case.

> * Section 6.2.3:
>
> This section does not explicitly state that each of the fragments needs
> to have the COMMON-HEADER included, but it can be inferred since that is
> the most logical thing to do. I would prefer that it be explicitly
> stated though.
>
> If my interpretation is correct, then the formula for calculating the
> number of fragments is wrong. Instead of
>
> N=ceil(message size / MTU size)
>
> it needs to be
>
> N = ceil( (message size - X) / (MTU size - X) )
>
> where X is the size of the COMMON-HEADER with fragment fields (i.e. 16)
> if the MTU size is the MTU for UDP. This is needed because the common
> header will be repeated on all the fragments.
>
> e.g. Assume MTU size=1280 and message size=2560 (COMMON-HEADER 16 + 2544
> message) the current formula will yield N=2, while N should in fact be 3
> as the message will not fit in 2 fragments.
>

Good catch! Yes, we have to adjust the formula and take into the account
the added COMMON-HEADER. I'll also add a clarifying text stating that all
the fragments indeed need the COMMON-HEADER (of 16 octets length).

-- Tom

-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## [email-masked]  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/