Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-05.txt

[Joe Touch <[e-mail]>]

Hi, Fred,

On 5/31/2012 12:13 PM, Templin, Fred L wrote:
> Hi Joe,
...
> As you know, the bar for documents that would update
> bedrock specifications such as RFC791 and RFC1122 is
> set very high indeed. That your document has made it
> to this level of maturation is a tribute to your many
> years of concerted effort, which would best be amortized
> if this useful addition can also be applied.

As you note, this doc has taken a lot to get to its current state.

Nothing should be added that isn't core to its purpose AND agreed by the 
community. Your proposed change doesn't meet either criteria - your only 
reason for adding it is to get a "free ride", and I don't think that's 
an appropriate suggestion for *any* doc.

>>>> - reducing the timeout is not current practice AFAIK
>>>> 	so we'd be adding a new recommendation, rather
>>>> 	than even documenting existing practice
>>>>
>>>> - my conclusion, based on "keep it simple", is to not include this
>>>> recommendation in this document
>>>
>>> Let me ask, do you know of any implementations that have
>>> ever benefitted from keeping the fragments of an incomplete
>>> reassembly for longer than 60sec? (Linux for example only
>>> waits 30sec before discarding fragments.)
>>
>> I don't, but that's a discussion that should happen - as you note below
>> - involving those on a different list as well, for a different reason.
>> Linux does a lot of things that are not standard, but that alone is not
>> necessarily a reason to document it as best practice - e.g., why are you
>> not suggesting 30 sec?
>
> 60sec is consistent with both RFC1122 and RFC2460.

RFC2460 isn't relevant to the reassembly requirements of IPv4; if it 
were, it would be 120 seconds, or would have updated RFC1122 itself.

...
> If you want to call it MSL you need to cite RFC793. If
> you want to change all occurrences of MSL to something
> else, then you could get away with citing only RFC1122.
> My preference would be to keep it as MSL and cite RFC793.

It's only MSL in that one place in this doc, but it's intended to refer 
to maximum datagram lifetime since this doc has no other reference to 
transport protocols.

Joe