Re: Re[10]: www.isoc.org unreachable when ECN is used

The IETF ones... not supporting ECN read previous e-mails... Cheers On Fri, 2003-12-12 at 18:46, Anthony G. Atkielski wrote: Franck Martin writes: > The problem is that ISOC firewalls are not up to standards. Whose standards? Franck Martin [EMAIL PROTECTED] SOPAC, Fiji GPG Key f

Re: www.isoc.org unreachable when ECN is used

On Fri, Dec 12, 2003 at 06:23:48AM +0100, Anthony G. Atkielski wrote: > But since ISOC's firewalls have not been updated, you won't be able to > get to their site from Linux. Nonsense. I'm running Linux, several versions. I can get to the ISOC site from all of them. -- Kent Crispin

Re[12]: www.isoc.org unreachable when ECN is used

Franck Martin writes: > The IETF ones... > > not supporting ECN But ECN has not always been a standard. If all RFCs had been simultaneously written forty years ago, it would be reasonable to speak of one organization or another not respecting standards because it did not adhere to a given RFC.

Re[2]: www.isoc.org unreachable when ECN is used

[EMAIL PROTECTED] writes: > Nonsense. I'm running Linux, several versions. I can > get to the ISOC site from all of them. Then what is preventing others from doing so?

Re: www.isoc.org unreachable when ECN is used

It all depends if ECN is turned on on linux. Some distro do it by default, some don't... On Fri, 2003-12-12 at 19:03, [EMAIL PROTECTED] wrote: On Fri, Dec 12, 2003 at 06:23:48AM +0100, Anthony G. Atkielski wrote: > But since ISOC's firewalls have not been updated, you won't be able to > get t

Re: Eating the canned from the new information society

At 00:19 12/12/03, Dan Kolis wrote: Site barely moves. We have good bandwidth and its 400 bit/S, says my browser. may be are there more people accessing world submit sites than dogs food sites?

Re: Re[8]: www.isoc.org unreachable when ECN is used

> > Except that a change from default values can be an excellent indicator > that you are dealing with a software version different from what you > expected (and possibly incompatible). > > > I can't remember exactly where I saw the > > definition, I've understood reserved fields to mean "could cha

Re: Re[8]: www.isoc.org unreachable when ECN is used

On Fri, 12 Dec 2003, Franck Martin wrote: The problem is that ISOC firewalls are not up to standards. Can someone go to knock on ISOC door in Virginia and propose to help them to solve this particular problem. And take some pictures too, I'm curious to see what they really have...

Re: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security

Hay, On Mon, Dec 08, 2003 at 10:16:03PM +0100, Gert Doering wrote: > Hi, > > On Mon, Dec 08, 2003 at 10:01:53PM +0100, Jeroen Massar wrote: > > There are currently quite some ISP's who filter anything >/35. > > Generally ISP's should be filtering on allocation boundaries. > > Thus if a certain pr

RE: ITU takes over?

vinton g. cerf wrote: > ... > Unfortunately, the discussion has tended to center on ICANN as the only > really visible example of an organization attempting to develop policy > (which is being treated as synonymous with "governance" To further your point, an area completely outside of ICANN's purv

RE: ITU takes over?

At 8:39 -0800 12/12/03, Tony Hain wrote: vinton g. cerf wrote: ... Unfortunately, the discussion has tended to center on ICANN as the only really visible example of an organization attempting to develop policy (which is being treated as synonymous with "governance" To further your point, an are

RE: ITU takes over?

At 8:39 AM -0800 12/12/03, Tony Hain wrote: vinton g. cerf wrote: ... Unfortunately, the discussion has tended to center on ICANN as the only really visible example of an organization attempting to develop policy (which is being treated as synonymous with "governance" To further your point, an

Re: Re[2]: www.isoc.org unreachable when ECN is used

On Thu, Dec 11, 2003 at 01:05:15PM -0800, Sally Floyd wrote: >A work-around for maintaining connectivity in the face of the broken >equipment was described in [Floyd00], and has been specified in RFC >3168 as a procedure that may be included in TCP implementations. >... >Some TC

RE: ITU takes over?

Stephen Kent wrote: > At 8:39 -0800 12/12/03, Tony Hain wrote: > >vinton g. cerf wrote: > >> ... > >> Unfortunately, the discussion has tended to center on ICANN as the > only > >> really visible example of an organization attempting to develop policy > >> (which is being treated as synonymous

RE: ITU takes over?

Paul Hoffman wrote: > At 8:39 AM -0800 12/12/03, Tony Hain wrote: > >vinton g. cerf wrote: > >> ... > >> Unfortunately, the discussion has tended to center on ICANN as the > only > >> really visible example of an organization attempting to develop policy > >> (which is being treated as synonymo

Re: Eating the canned from the new information society

Working assumption: When the self annointed intelligentsia about to make all these unrequested experiments with Internet can achieve the real world performance of a dog food company, they will have made "progress". Working assumption: Technology doesn't automatically trump *everything*. It is t

Re: Non terminated traffic...

Obsession with security has broken a lot of things. In ICMP there are defined responses for "Network Unreachable" and "Host Unreachable". Of course, today those responses are blocked and ignored - even pings don't make it across some ISPs - like Earthlink! I suspect pings are blocked to prevent t

Re[2]: ITU takes over?

Tony Hain writes: > FWIW: I specifically left out the business community because they always > find a way to make money in whatever context the politicians create (even if > it takes influencing the politicians to create a favorable context). You should leave out politicians, too, then, since the

Re[2]: ITU takes over?

Paul Hoffman / IMC writes: > Absolutely agree with this sentiment. Anyone who starts an anti-spam > proposal with "All we need to do is digitally sign the {messages|SMTP > transmissions}..." is completely unclear on how little governance > there is in this area. I agree, but isn't this what Yah

Re[4]: www.isoc.org unreachable when ECN is used

Theodore Ts'o writes: > To continue quoting from RFC 3360, there were some good reasons stated > in that document for why reasonable implementors might not choose to > implement the workaround: > >* The work-arounds would result in ECN-capable hosts not responding > properly to the first

Re: www.isoc.org unreachable when ECN is used

On Fri, 12 Dec 2003 21:01:09 +0100 "Anthony G. Atkielski" <[EMAIL PROTECTED]> wrote: > It sounds like ECN is pretty badly designed; I'm glad it wasn't my > idea. Those are pretty bold statements. The above page seems to indicate that there was a lot of tho

Re[2]: www.isoc.org unreachable when ECN is used

John Kristoff writes: > Those are pretty bold statements. Well, when something pops up in software I use that adds functionality that I never wanted and breaks things that used to work, bold statements are in order. If Microsoft had done this, someone would be calling for a Constitutional amendm

Re: Re[4]: www.isoc.org unreachable when ECN is used

On Fri, Dec 12, 2003 at 09:01:09PM +0100, Anthony G. Atkielski wrote: > The problem is that RFC 3168 postdates all the RFCs that came before it, > and when something needs to be compatible with real-world systems that > are not all instantly and simultaneously upgraded, it needs to behave in > a wa

Re[6]: www.isoc.org unreachable when ECN is used

Theodore Ts'o writes: > But in the case of ECN, most of the major sites on the > net have fixed their broken firewalls. Why is ECN being deployed by default? Does it fix some problem that is worse than rendering thousands of hosts inaccessible?

Re: Re[4]: www.isoc.org unreachable when ECN is used

On 12-dec-03, at 22:24, Theodore Ts'o wrote: Does that mean that Path MTU was badly designed, because it failed to take into account stupid firewalls? Path MTU disovery was implemented very poorly because implementations tend expect certain functionality in routers, and usually don't recover whe

Re: Re[2]: www.isoc.org unreachable when ECN is used

On Fri, 12 Dec 2003 22:19:49 +0100 "Anthony G. Atkielski" <[EMAIL PROTECTED]> wrote: > John Kristoff writes: > > > Those are pretty bold statements. > > Well, when something pops up in software I use that adds functionality > that I never wanted and breaks things that used to work, bold statemen

Re: www.isoc.org unreachable when ECN is used

Iljitsch; On 12-dec-03, at 22:24, Theodore Ts'o wrote: Does that mean that Path MTU was badly designed, because it failed to take into account stupid firewalls? Yes, PMTUD was badly designed. Path MTU disovery was implemented very poorly because implementations tend expect certain functionality

Re[4]: www.isoc.org unreachable when ECN is used

Mark Smith writes: > I think you might be missing the point. ECN only breaks when used > with previous *bad* implementations of the relevant RFCs. Perhaps my point isn't clear: ECN implementations prevent communication, rather than enhance it. I don't see what advantage ECN provides, but it has b

Re: Re[4]: www.isoc.org unreachable when ECN is used

> If I have a system that does everything I require, I don't need > improvements. So your currently requirements are exactly the same as all the other users of the Internet ? I find it hard to believe that your requirements are exactly the same as mine, and I'm only one of the other approxima

Re[6]: www.isoc.org unreachable when ECN is used

Mark Smith writes: > So your currently requirements are exactly the same as all the > other users of the Internet? No, but my situation is similar to theirs. They don't require improvements if their systems do all they require, either. > I find it hard to believe that your requirements are exac

Re: www.isoc.org unreachable when ECN is used

Masataka Ohta wrote: Iljitsch; On 12-dec-03, at 22:24, Theodore Ts'o wrote: Does that mean that Path MTU was badly designed, because it failed to take into account stupid firewalls? Yes, PMTUD was badly designed. No disagreement here. Path MTU disovery was implemented very poorly because i

Re: www.isoc.org unreachable when ECN is used

Fred Templin; It should have been designed into TCP over IPv4 and should have never set don't fragment bit. TCP should be able to know that packets are reassembled at the IP layer. Yes - it would have been great if this was designed into the architecture way back when. But it wasn't, so it would