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

From: Pete Resnick via Datatracker <[email-masked]>
Date: Thu, 04 Jul 2019 13:47:52 -0700

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.

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

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.

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.

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.

---

From: Fred Baker <[email-masked]>
Date: Fri, 5 Jul 2019 10:00:51 -0700

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 <[email-masked]> wrote:
> 
> Reviewer: Pete Resnick

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

Moved to section 1.

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

> reproducible" to "do not occur as frequently"; I think it reads better.

Ack

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

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 05 Jul 2019 22:11:00 -0700

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

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

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

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

> 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

---

From: Fred Baker <[email-masked]>
Date: Fri, 5 Jul 2019 18:08:50 -0700

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

Following Don Eastlake's comment, the authors held a powwow on the use of parentheses. We do not find "(0)" more readable than "0" or "zero", and the general sense was that a number of things were parenthesized, such as IPv6 prefixes, that didn't follow usual practice. So I have pulled the parentheses.

See attached.

I'm also posting the new .txt and .xml, in view of the deadline Monday and my own plans this weekend. I can deal with further commentary when the repository re-opens in a few weeks.