from Vince Fuller [off-list ref]
This set of diffs modify the 2.6.20 kernel to enable use of the 240/4
(aka "class-E") address space as consistent with the Internet Draft
draft-fuller-240space-00.txt.
Wouldn't it be wise to at least wait for it becoming an RFC first?
-Andi
In article [off-list ref] (at Fri, 11 Jan 2008 12:17:02 +0100), Andi Kleen [off-list ref] says:
Vince Fuller [off-list ref] writes:
quoted
from Vince Fuller [off-list ref]
This set of diffs modify the 2.6.20 kernel to enable use of the 240/4
(aka "class-E") address space as consistent with the Internet Draft
draft-fuller-240space-00.txt.
Wouldn't it be wise to at least wait for it becoming an RFC first?
I do think so, too.
There is no positive consesus on this draft
at the intarea meeting in Vancouver, right?
We cannot / should not enable that space until we have reached
a consensus on it.
--yoshfuji
On Fri, Jan 11, 2008 at 12:17:02PM +0100, Andi Kleen wrote:
Vince Fuller [off-list ref] writes:
quoted
from Vince Fuller [off-list ref]
This set of diffs modify the 2.6.20 kernel to enable use of the 240/4
(aka "class-E") address space as consistent with the Internet Draft
draft-fuller-240space-00.txt.
Wouldn't it be wise to at least wait for it becoming an RFC first?
There is reasonable consensus on making use of 240/4; some applications,
such as ISAKMP and automatic ipv6-to-IPv4 tunneling, still need to determine
if they should treat the space as "public" or "private" but that shouldn't
affect whether kernel support is added.
Solaris recently added support for 240/4 and OSX already has it. I thought
the Linux kernel developers might appreciate having patches to do likewise.
I leave it up to you, the developers, to decide if you want to use these
patches.
--Vince
There is no positive consesus on this draft
at the intarea meeting in Vancouver, right?
We cannot / should not enable that space until we have reached
a consensus on it.
This is so incredibly incorrect.
There is consensus on making network stacks able to use this
address space. And that is all that the patch does.
The consensus is only missing on whether to make the address
space public or private.
This is also clearly spelled out in the draft.
It is important to get as large of a head start on this as
possible because of how long it takes to deploy something
like this.
I leave it up to you, the developers, to decide if you want to use these
patches.
Vince, please just ignore these turkeys who are dismissing
your patch and respin it against current sources as I asked
of you.
I'll apply it, immediately, because it is the only correct
course of action.
Thanks a lot.
There is no positive consesus on this draft
at the intarea meeting in Vancouver, right?
We cannot / should not enable that space until we have reached
a consensus on it.
This is so incredibly incorrect.
There is consensus on making network stacks able to use this
address space. And that is all that the patch does.
No, we did never make consensus on it.
The consensus is only missing on whether to make the address
space public or private.
This is also clearly spelled out in the draft.
It is important to get as large of a head start on this as
possible because of how long it takes to deploy something
like this.
Okay, though I am afraid this space will not be used widely,
we should be ready for it.
I'll make some more comments on the patch itself from
another point view.
--yoshfuji
I leave it up to you, the developers, to decide if you want to use these
patches.
Vince, please just ignore these turkeys who are dismissing
your patch and respin it against current sources as I asked
of you.
I'll apply it, immediately, because it is the only correct
course of action.
I strongly agree. Linux should set standards, or at least help them
become one.