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

[Alissa Cooper <[e-mail]>]

Adding Paul to this thread as he will be helping resolve comments on this draft.


> On Aug 24, 2015, at 12:58 PM, Suresh Krishnan <[e-mail]> wrote:
> 
> 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
>