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

[Julien Laganier <[e-mail]>]

Hi Fred,

With WG Co-chair hat on,

Changing MSL to Maximum Datagram Lifetime is a minor and almost
editorial change that I recommend we make since the use of MSL and
possible reference to RFC793 could implicitly restrict the scope of
the document to TCP, which is not the case -- this doc applies to IP
irrespective of the transport protocol in use.

As to the other change about the reassembly timeout, I agree with Joe
that this is out-of-scope of this document in its current form, and I
do not think it is appropriate to use a document as a vehicle for
changes that are out-of-scope. Furthermore, this document as been in
the hands of the Intarea WG for a fair amount of time during which the
consensus has been that no changes should be made to the core IP
specifications unless something is broken. Your proposal to include
considerations on reassembly timeouts does not seem to fix something
that is broken in IP and as such is against the consensus of that WG.
With both these in mind I recommend against it.

That being said it is up to our AD and the IESG to consider your IETF
Last Call comments as well as my recommendation on a disposition.

Regards,

--julien

On Thu, May 31, 2012 at 1:34 PM, Joe Touch <[e-mail]> wrote:
> 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
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area