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

[Suresh Krishnan <[e-mail]>]

Hi Tom,

On 08/20/2015 08:29 AM, Tom Kristensen wrote:
> Thanks for the Gen-ART review. Response and hopefully a resolution
> inline below.
>
>
> On 2 March 2015 at 18:19, Suresh Krishnan <[e-mail]
> <mailto:[e-mail]>> 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.

OK. I have an uneasy feeling about this, but that clarification is 
certainly better than the current state where there is no guidance at 
all. I leave it up to your discretion.

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

Great.

Cheers
Suresh