Pete, thanks for your review. Fred, thanks for updating the text. I entered a DISCUSS ballot to chat about Section 6.1.
Alissa > On Jul 6, 2019, at 1:11 AM, Pete Resnick <[email protected]> wrote: > > 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 > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
