On Sun, 2003-12-14 at 23:34, Anthony G. Atkielski wrote:
jamal writes:
So the Linux decision was infact a very good one. An award of some form
is in order.
Maybe Microsoft will be inspired to do things the same way: it can
change its implementations in order to break 10% of all sites
- Original Message -
From: jamal [EMAIL PROTECTED]
To: Anthony G. Atkielski [EMAIL PROTECTED]
Cc: IETF Discussion [EMAIL PROTECTED]
Sent: Monday, December 15, 2003 6:12 AM
Subject: Re: Re[4]: www.isoc.org unreachable when ECN is used
On Sun, 2003-12-14 at 23:34, Anthony G. Atkielski
On 15-dec-03, at 14:03, Spencer Dawkins wrote:
Your definition of broken is a little off. I would think the broken
implementation is the one that misunderstood the definition.
reserved as i have been enlightened privately has been clearly
defined at IETF as:
a) Must be set to zero on
jamal writes:
So the Linux decision was infact a very good one. An award of some form
is in order.
Maybe Microsoft will be inspired to do things the same way: it can
change its implementations in order to break 10% of all sites around the
world, and when anyone complains, it can say that it
On Mon, 15 Dec 2003 05:34:53 +0100, Anthony G. Atkielski [EMAIL PROTECTED] said:
The main contention seems to be the system with the problem. If it's
Linux, it's not a bug, it's feature. If it's Microsoft, it's not a
feature, it's a bug.
Linux could at least stand on the claim that it was
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, 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
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
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
[EMAIL PROTECTED] writes:
The problem is that the most common failure mode is *not*
getting an RST back, but getting NOTHING back because
some squirrely firewall between here and there is silently
dropping packets with bits it doesn't understand.
Ah ... that would definitely be a bug with
Scott Bradner writes:
woe be to new applications through such a firewall
It's important to understand that the Internet is not monolithic, and no
matter what the latest and greatest standards may be, there will always
be parts of the Net that run older software. Expecting the entire Net
to
On Thu, Dec 11, 2003 at 09:06:06PM +0100, Anthony G. Atkielski wrote:
I also don't see why a firewall would drop packets just because reserved
bits are set, although I can see why it might be a configurable option
for the most paranoid users.
There are a lot of really dumb, dumb, dumb firewall
13 matches
Mail list logo
