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 <[email protected]> > 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 <[email protected] >> <mailto:[email protected]>> 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 > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
