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
