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 <resnick@xxxxxxxxxxxx> 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 > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
