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 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@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
