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
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
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.
[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?
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 to
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?
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 change
in
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
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 prefix is
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 purview,
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 area
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
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 TCP
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 with governance
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 synonymous with
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
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
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 they
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 Yahoo
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 valid
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.
http://www.icir.org/floyd/ecn.html
The above page seems to indicate that there was a lot of thought
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
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 way
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?
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
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 statements
are in
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
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
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
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
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
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
32 matches
Mail list logo
