On Fri, Sep 07, 2001 at 10:02:48AM -0500, Nathan E Norman wrote:
> Nazis. Hitler. Microsoft rules!
>
> (Die thread die!)
You fool you!
Godwin's law is powerless when deliberately invoked...
('s' a bit like the chronicles of thomas covenant, now I think about it)
Jules
On Fri, Sep 07, 2001 at 12:47:05PM +0200, T.Pospisek's MailLists wrote:
> On Thu, 6 Sep 2001, Alex Pennace wrote:
>
> > On Wed, Sep 05, 2001 at 02:37:06PM +0200, Florian Weimer wrote:
> > > Russell Coker <[EMAIL PROTECTED]> writes:
> > >
> > > > Why should the default configuration be changed to a
On Thu, 6 Sep 2001, Alex Pennace wrote:
> On Wed, Sep 05, 2001 at 02:37:06PM +0200, Florian Weimer wrote:
> > Russell Coker <[EMAIL PROTECTED]> writes:
> >
> > > Why should the default configuration be changed to account for the
> > > diminishing number of broken routers on the net?
> >
> > From a
On 7 Sep 2001, Florian Weimer wrote:
> This knife cuts both sides. Why should someone bother to forward
> non-conformant packages?
"Reserved" bits can have any value. Routers need to _ignore_ them if they
don't know what they mean (that is, if they're too old). They must
_generate_ packages with
* Florian Weimer
| This knife cuts both sides. Why should someone bother to forward
| non-conformant packages?
Because they are reserved and might be used for some useful purpose
one day, which they are now.
--
Tollef Fog Heen
You Can't Win
Dominik Kubla <[EMAIL PROTECTED]> writes:
> On Thu, Sep 06, 2001 at 05:02:19PM +0200, Guillaume Morin wrote:
> >
> > RFC793 says
> >
> > Reserved: 6 bits
> >
> > Reserved for future use. Must be zero.
> >
> >
> > The last statement is the cause of all confusions. s/Must/Should/ would
>
On Wed, Sep 05, 2001 at 02:37:06PM +0200, Florian Weimer wrote:
> Russell Coker <[EMAIL PROTECTED]> writes:
>
> > Why should the default configuration be changed to account for the
> > diminishing number of broken routers on the net?
>
> From a technical behavior, throwing away packets with unkn
> RFC793 says
>
> Reserved: 6 bits
>
> Reserved for future use. Must be zero.
>
>
> The last statement is the cause of all confusions. s/Must/Should/ would
> have been better.
No; to be forward compatible, a TCP must set the bits
to zero. 2481 describes the operation of those bits and
Dans un message du 06 Sep à 16:58, Eric Van Buggenhaut écrivait :
> RFC 793 reserve bits 'for future use'. These bits may not be
> touched by a router or a firewall.
> The buggy hardware we are talking about zeroes those bits.
> Thus they violate RFC793.
RFC793 says
Reserved: 6 bits
Reserv
On Thu, Sep 06, 2001 at 04:43:57PM +0200, Florian Weimer wrote:
> Eric Van Buggenhaut <[EMAIL PROTECTED]> writes:
>
> > On Wed, Sep 05, 2001 at 02:37:28PM +0200, Florian Weimer wrote:
> > > Russell Coker <[EMAIL PROTECTED]> writes:
> > >
> > > > Why should the default configuration be changed to
Eric Van Buggenhaut <[EMAIL PROTECTED]> writes:
> On Wed, Sep 05, 2001 at 02:37:28PM +0200, Florian Weimer wrote:
> > Russell Coker <[EMAIL PROTECTED]> writes:
> >
> > > Why should the default configuration be changed to account for the
> > > diminishing number of broken routers on the net?
> >
On Wed, 05 Sep 2001, Steve Greenland wrote:
> On 05-Sep-01, 16:35 (CDT), Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
> wrote:
> > On Wed, 05 Sep 2001, T.Pospisek's MailLists wrote:
> > > Why is it so hard to change a few lines and have the default be
> > > set to *off* and let whoever fee
Well all of this has been said on this thread here allready, but
I'll repeat it never the less to get the facts straight.
Zitiere Dominik Kubla <[EMAIL PROTECTED]>:
> On Wed, Sep 05, 2001 at 05:30:12PM +0200, T.Pospisek's MailLists wrote:
> But the whole discussion here is folly. The whole thin
On Thu, Sep 06, 2001 at 09:47:05AM +0200, Dominik Kubla wrote:
>
> But the whole discussion here is folly. The whole thing has been discussed
> on linux-kernel by people far more knowlegable in this things than the
> average debian developer. I think we should follow the conclusions
> from that d
* Jaldhar H. Vyas <[EMAIL PROTECTED]> [010905 20:01]:
> whether they can deal with that or not. Debians sole responsibility is to
> see it is properly documented somewhere. If people don't read the
*Please* dont document this in debconf. Do it in a README.Debian or the
release notes.
I *really
On Wed, 5 Sep 2001, T.Pospisek's MailLists wrote:
> > > But tell me, in case there's an IMAP client that has some problems with
> > > the IMAP protocol. Should a Debian box by default *refuse* to talk
> > > to it or should the default be to try to talk to it (provided that it
> > > can)?
> >
> > A
On Wed, 5 Sep 2001, T.Pospisek's MailLists wrote:
> > Yes, quite frankly. Personally, I use only Free Software and software
> > that runs on top of Free OSes. Professionally, I work for an ISP, and
> > we expect our vendors to live up to the promises they make.
> If that's the case then shouldn
On 05-Sep-01, 16:35 (CDT), Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
wrote:
> On Wed, 05 Sep 2001, T.Pospisek's MailLists wrote:
> >
> > But tell me *one* thing:
> >
> > Why is it so hard to change a few lines and have the default be
> > set to *off* and let whoever feels like it
On Wed, 05 Sep 2001, T.Pospisek's MailLists wrote:
> at least not consciously because I doubt anybody who's pro ECN in the
> kernel has had to debug a situtation such as described above.
Don't. You will lose.
> But you can sure tell from my enthusiasm, and I'm no networking idiot,
> that I *do* f
On Wed, 5 Sep 2001, Steve Langasek wrote:
> > Do *you* do that for all the things that don't work as they should?
>
> Yes, quite frankly. Personally, I use only Free Software and software
> that runs on top of Free OSes. Professionally, I work for an ISP, and
> we expect our vendors to live up t
On Wed, 5 Sep 2001, T.Pospisek's MailLists wrote:
>>> The question is only if devices should be programmed in order to know
>>> the future and it's potential proposed stadards by the IETF. Mind you I
>>> don't know if the devices in question (websites, routers etc. droping ECN
>>> packets) *are* v
On Wed, Sep 05, 2001 at 02:37:28PM +0200, Florian Weimer wrote:
> Russell Coker <[EMAIL PROTECTED]> writes:
>
> > Why should the default configuration be changed to account for the
> > diminishing number of broken routers on the net?
>
> >From a technical behavior, throwing away packets with unk
On Wed, 5 Sep 2001, Steve Langasek wrote:
> On Wed, 5 Sep 2001, T.Pospisek's MailLists wrote:
>
> > On Wed, 5 Sep 2001, Guillaume Morin wrote:
>
> > > Dans un message du 05 sep à 14:37, Florian Weimer écrivait :
> > > > From a technical behavior, throwing away packets with unknown protocol
> > > >
On Wed, 5 Sep 2001, T.Pospisek's MailLists wrote:
> On Wed, 5 Sep 2001, Guillaume Morin wrote:
> > Dans un message du 05 sep à 14:37, Florian Weimer écrivait :
> > > From a technical behavior, throwing away packets with unknown protocol
> > > flags is perfectly acceptable in any case and even rea
On Wed, 5 Sep 2001, Guillaume Morin wrote:
> Dans un message du 05 sep à 17:30, T.Pospisek's MailLists écrivait :
> > The question is only if devices should be programmed in order to know
> > the future and it's potential proposed stadards by the IETF. Mind you I
> > don't know if the devices in q
Dans un message du 05 sep à 17:30, T.Pospisek's MailLists écrivait :
> The question is only if devices should be programmed in order to know
> the future and it's potential proposed stadards by the IETF. Mind you I
> don't know if the devices in question (websites, routers etc. droping ECN
> packet
> ECN is RFC2481
>
> http://www.ietf.org/rfc/rfc2481.txt?number=2481
the internet draft by the same authors that supercedes
rfc2481 and is a "Proposed Standard" instead of an
"Experimental Standard" is draft-ietf-tsvwg-ecn-04.
It is listed under "working group standards track" at
http://www.rfc-e
On Wed, 5 Sep 2001, Eric Van Buggenhaut wrote:
> On Sun, Sep 02, 2001 at 12:56:18AM +0200, Tomas Pospisek wrote:
> >
> > It's not only *sites* that do not work with ECN. It's also *routers*. That
> > means if you have *one* router between you and your destination, that does
> > not
> > support EC
On Wed, 5 Sep 2001, Guillaume Morin wrote:
> Dans un message du 05 sep à 14:37, Florian Weimer écrivait :
> > From a technical behavior, throwing away packets with unknown protocol
> > flags is perfectly acceptable in any case and even reasonable in some
> > environments.
>
> I would not call reas
On Sun, Sep 02, 2001 at 12:56:18AM +0200, Tomas Pospisek wrote:
>
> Zitiere Eduard Bloch <[EMAIL PROTECTED]>:
>
> > Neil Spring wrote on Sat Sep 01, 2001 um 12:34:40PM:
> >
> > > being turned off behind my back. ECN doesn't need any
> > > more inertia slowing its deployment. It's already an
>
On Sat, Sep 01, 2001 at 04:39:30PM -0700, Neil Spring wrote:
> > Incidentaly I'd today filled a *critical* bugreport against
> > kernel-image-2.4.8 just because of that.
>
> It lists as "Done"; perhaps you're expected to file it
> someplace else?
>
> > The first *experimental* rfc for ECN dates f
Dans un message du 05 sep à 14:37, Florian Weimer écrivait :
> From a technical behavior, throwing away packets with unknown protocol
> flags is perfectly acceptable in any case and even reasonable in some
> environments.
I would not call reasonable dropping packets carrying bits of a protocol
rat
Russell Coker <[EMAIL PROTECTED]> writes:
> Why should the default configuration be changed to account for the
> diminishing number of broken routers on the net?
>From a technical behavior, throwing away packets with unknown protocol
flags is perfectly acceptable in any case and even reasonable
On Sat, Sep 01, 2001 at 04:04:12PM +0200, Eduard Bloch wrote:
> I suggest to disable ECN? in the default network configuration.
> This should be done in Woody since we don't like our users to be
> confused just because of the ECN support in kernel is turned on.
This would be an abuse of the procps
On Mon, Sep 03, 2001 at 07:44:19AM +1000, Herbert Xu wrote:
> 1. CONFIG_INET_ECN must be turned on, otherwise the user will have to
> recompile the kernel to use it.
yes, that is correct.
if the user wants ECN, they should compile the kernel to enable it.
>[...]
> So do whatever you want, but pl
> > (*) wha? no kernel patch is required. The default
>
> Not really true.
After reading Herbert's mail, I understand what you were
trying to do now with the patch.
Thanks for explaining the baseconfig / postinst issues.
What a mess.
-neil
On Sun, Sep 02, 2001 at 05:56:45PM +0200, Goswin Brederlow wrote:
> I think that should be refiled against kernel-image-2.4.x. Those,
> since they have the flag enabled, should warn about it and turn it off
> in /etc/sysctl.conf upon first install (not on update, so you can
> delete the option).
>
Zitiere Eduard Bloch <[EMAIL PROTECTED]>:
> > Can we just choose option (a) and be done with it?
> > If Debian isn't going to choose option (a), why are we
> > talking about option (c)?
>
> See Herbert's mail. IMHO we need a good place to disable it and notify
> the user.
Since the beginning of
#include
Neil Spring wrote on Sun Sep 02, 2001 um 02:05:57PM:
> Summary:
>
> 1) why not disable ECN in kernel-image? it would be cleaner.
See mail from Herbert.
> 2) why not disable ECN in /etc/network/options? it would be
> more relevant and visible than sysctl.conf.
Another good idea.
> (*
On Mon, 3 Sep 2001, Herbert Xu wrote:
> 3. The kernel-image postinst is not a good place to do this as installing
> a kernel does not mean that you will boot it.
the postinst would be the worst place, as you can't be using that kernel
already at the moment postinst is ran for the first time...
-
Goswin Brederlow <[EMAIL PROTECTED]> wrote:
>
> I think that should be refiled against kernel-image-2.4.x. Those,
> since they have the flag enabled, should warn about it and turn it off
> in /etc/sysctl.conf upon first install (not on update, so you can
> delete the option).
> Or just ask via deb
Summary:
1) why not disable ECN in kernel-image? it would be cleaner.
2) why not disable ECN in /etc/network/options? it would be
more relevant and visible than sysctl.conf.
3) can we disable ECN for joe user with the default kernel
while permitting joe custom-kernel-user to enable ECN with
one c
Eduard Bloch <[EMAIL PROTECTED]> writes:
> Package: procps
> Version: 1:2.0.7-6
> Severity: wishlist
> Tags: woody
>
> I suggest to disable ECN¹ in the default network configuration.
> This should be done in Woody since we don't like our users to be
> confused just because of the ECN support in k
#include
Neil Spring wrote on Sat Sep 01, 2001 um 06:39:58PM:
> http://uwsg.iu.edu/hypermail/linux/kernel/0105.1/0145.html
>
> As David noted, I'm in favor of turning ECN off-as-default.
Good. The problem - it is on by default in our precompiled kernel-image
packages. To disable (by default), y
IP is a very old standard. I don't assume that all
chipsets are bug free, nor do I assume that all IP
implementations are bug free. I'm going to place blame
where it belongs, and be honest about whose bug this is.
This is not a problem with two year old equipment.
It is not the case that all IP
On Sun, Sep 02, 2001 at 02:17:43AM +0200, Eduard Bloch wrote:
> #include
> Neil Spring wrote on Sat Sep 01, 2001 um 04:39:30PM:
>
> > Blaming ECN for faulty IP implementations is wrong.
>
> Come back to reality please. Or stay in your dream and (for example)
> and remove all workarounds in the k
46 matches
Mail list logo
