Re: [Int-area] Genart last call review of draft-ietf-intarea-frag-fragile-13

["Pete Resnick" <[e-mail]>]

On 5 Jul 2019, at 10:00, Fred Baker wrote:

>> In Section 2.1 and 2.2, Instead of "set to one" and "set to zero", it 
>> would
>> read easier with "set to (1)" and "set to (0)", or some similar 
>> construction.
>
> That seems to me to be stylistic - I'm not at all sure what makes 
> "(1)" more readable than "one". I'm making the change, but I can't 
> begin to fathom how it improves the document.

Yes, it is completely stylistic and I'm sorry I was not more explicit 
about that earlier: It was mostly that it was inconsistent (sometimes 
using the digit in parens, sometimes using the word), but in at least 
one instance I read "set to one" too quickly and parsed it as "set to 
one of" something or other. Just using the digit as you had in your 
second message is perfectly fine.

>> Section 3 is in an odd place. I'd say either move it up to the top, 
>> or put it
>> down in section 7.
>
> Moved to section 1.

Yeah, that's fine. Again, just a stylistic thing.

>> 4.2 mentions virtual reassembly. Virtual reassembly applies to 4.1, 
>> 4.3, and
>> 4.4 as well. Perhaps moving the discussion of virtual reassembly up 
>> to the top
>> of 4 would make more sense.
>
> I think you're inferring the applications to 4.1, 4.3, and 4.4. 4.1, 
> for example, makes rather a point that in the absence of virtual 
> reassembly the router will make different routing decision. (I could 
> say "incorrect", but the issue is that it is in fact making a correct 
> decision in what could be argued to be the wrong context). I'll see 
> what I can do with this, but I'm going to have to ask you to look at 
> the diff and see whether you agree with the change.

Yeah, that's exactly what I was thinking of. I like the new 3.1, though 
I would change "It can be useful in" to "It could be useful to address 
the problems in". That is, it doesn't really address those problems, 
because you couldn't really use it in those contexts.

>> In 4.5, insert "duplicate IDs resulting in" after prevent. It took me 
>> a bit to
>> figure out what this was referring to. Also, change "are not easily
>> reproducible" to "do not occur as frequently"; I think it reads 
>> better.
>
> Ack
>
>> And just to yell into the wind: Section 7.3 seemed a little wimpy to 
>> me, but I
>> can't for the life of me figure out how to make it any stronger or 
>> more likely
>> to be listened to. End of pointless yelling.
>
> Ron started out with "let's just deprecate Internet Layer 
> Fragmentation entirely." Good luck, great way to create an RFC that 
> will be completely ignored. Ain't Gonna Happen In Practice. We backed 
> off to this in a quest for comments that could actually have an 
> impact. Agree that they don't have teeth.

Yep, what I figured.

> Would you kindly review the attached diff and comment on the changes? 
> I'll wait for your comments before uploading.

Yep, looks pretty good to me. Thanks.

pr
-- 
Pete Resnick http://www.episteme.net/
All connections to the world are tenuous at best