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

[Fred Baker <[e-mail]>]

Thanks for your review. I have some points I'd like to discuss in order to understand better how to fix them.

> On Jul 4, 2019, at 1:47 PM, Pete Resnick via Datatracker <[e-mail]> wrote:
> 
> Reviewer: Pete Resnick
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-intarea-frag-fragile-13
> Reviewer: Pete Resnick
> Review Date: 2019-07-04
> IETF LC End Date: 2019-07-04
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: A document so well-written that even this application-layer idiot
> could follow along easily. Thanks for that. I see no significant issues with
> this document going forward as a BCP; just a few editorial bits.
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments:
> 
> 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.

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

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

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

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

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...