On 1-okt-2007, at 19:50, Sam Hartman wrote:
This is annoying because glibc's source address selection algorithm
seems to prefer teredo addresses to v4 addresses. So, I get really
bad response times to www.ietf.org when using teredo.
It would help if vendors implemented the RFC 3484 policy
On Oct 1, 2007, at 9:24 PM, Mark Andrews wrote:
Note that in real deployments just this behavior has broken things
on occasion, as many firewall and other such policy application
points
assume things like DNS resolution will only be UDP/53 transactions.
That assumption has always
On Oct 1, 2007, at 8:55 PM, Mark Andrews wrote:
I'm not blaming the victim, I'm pointing out the contributory
negligence on behalf of the ISP that is supplying the
attacker bandwidth.
BCP 38 is over 7 years old now. The time has past where you can
On Oct 1, 2007, at 9:24 PM, Mark Andrews wrote:
Note that in real deployments just this behavior has broken things
on occasion, as many firewall and other such policy application =20
points
assume things like DNS resolution will only be UDP/53 transactions.
That assumption
On Oct 2, 2007, at 1:41 AM, Mark Andrews wrote:
Someone should talk to ucdavis.edu and get this idiocy pulled.
And NIST, and many many others..
Because there are lots of recursive and authoritative
nameservers out there behind firewalls that get it right.
On Oct 1, 2007, at 8:55 PM, Mark Andrews wrote:
I'm not blaming the victim, I'm pointing out the contributory
negligence on behalf of the ISP that is supplying the
attacker bandwidth.
BCP 38 is over 7 years old now. The time has past where you can
blame the
Hi Lakshminath,
your comments solve my concerns, mostly.
I understand your reasons and actually am not sure I have a really better idea.
So please consider my comments rather as personal concerns, not comments that
need to be resolved:
#2: I still do not feel 100% comfortable with the fact
Hi All
Just an input about the NAT issue handled here. The 'war' against NAT is
senseless before succeeding the one against IPv4. I mean, as far as the v4
protocol runs on our networks, NAT will remain as a useful tool for those
who need it, of course for specific applications. In
On Tue, 2 Oct 2007 01:48:36 -0600
Danny McPherson [EMAIL PROTECTED] wrote:
Again, any pointers empirical data along these lines would
be appreciated.
I said this awhile back:
http://www.merit.edu/mail.archives/nanog/msg02196.html
As a datapoint I ran some tests against a reasonably
The shortage of IPv4 addresses in developing countries in a red herring. All
one has to do is apply for them from the RIR. Getting a service provider to
route them is a different problem, especially when they profit from running
your traffic through their NAT.
Ray
-Original Message-
Ray Plzak wrote:
The shortage of IPv4 addresses in developing countries in a red herring.
that has to rank as one of the most bizarre statements that's ever been
made on the ietf list.
___
Ietf mailing list
Ietf@ietf.org
On 2-okt-2007, at 15:05, Keith Moore wrote:
Ray Plzak wrote:
The shortage of IPv4 addresses in developing countries in a red
herring.
that has to rank as one of the most bizarre statements that's ever
been
made on the ietf list.
Yellow herring?
There are five RIRs that serve different
On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote:
Ray Plzak wrote:
The shortage of IPv4 addresses in developing countries in a red herring.
that has to rank as one of the most bizarre statements that's ever been
made on the ietf list.
More of an ostrich than a herring?
.==._
Head in the sand is substituting the statement shortage of IP addresses for
the condition of the inability to use the addresses (take your pick when it
comes to infrastructure deficiencies).
Ray
-Original Message-
From: Tim Chown [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 02,
should have been is
-Original Message-
From: Keith Moore [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 02, 2007 9:06 AM
To: Ray Plzak
Cc: philemon; Hannes Tschofenig; Stephen Sprunk; ietf@ietf.org; Paul
Hoffman
Subject: Re: IPv4 to IPv6 transition
Ray Plzak wrote:
The
On Mon, 1 Oct 2007, The IESG wrote:
The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document:
- 'Aggregation of DiffServ Service Classes '
draft-ietf-tsvwg-diffserv-class-aggr-04.txt as an Informational RFC
DiffServ Pool 1
On Oct 2, 2007, at 10:11 AM, Pekka Savola wrote:
It is not clear that consensus in the IETF and deployments is
strong enough to approve/recommend any specific treatment for
standards track DSCP values.
could you expand on this observation?
-ken
It seems that policy should be scenario / use case / mission dependent,
and consequently apply to a number of applications. (And thus be
application independent).
Bonnie L. Gorsic
Technical Fellow
SoS Architecture Engineering
714-762-4906 (desk)
-Original Message-
From: Keith Moore
Le Monday 01 October 2007 20:50:00 ext Sam Hartman, vous avez écrit:
Hi. I opened a ticket with the secretariat a few weeks ago
complaining that I cannot reach www.ietf.org using a teredo address
either allocated through the Microsoft Teredo server or the Debian
teredo server.
This
From: Danny McPherson [EMAIL PROTECTED]
where's the authoritative source for who owns what prefixes
This, one could imagining putting together.
and who's permitted to originate/transit what prefixes?
This is a whole different kettle of bits.
For one thing, there's no
Joao == Joao Damas [EMAIL PROTECTED] writes:
Joao It does indeed as Stephane pointed out. Opening up your
Joao resolver so you can server roaming users, without further
Joao protection, is, at best, naive.
I'd appreciate it if you took Paul's comments a lot more seriously and
Gorsic, Bonnie L wrote:
It seems that policy should be scenario / use case / mission dependent,
and consequently apply to a number of applications. (And thus be
application independent).
it's normal for policy to be different from one application to another.
some applications are
do not try to implement policy into applications. you will end up
forced to (?) rewrite every existing applications.
I would expect most applications to use only AI_SECURE_CANONNAME or
AI_CANONNAME_SEARCH_DEFAULT.
AI_CANONNAME_SEARCH_DEFAULT would come with a system-wide knob
Ray,
I don't think it's quite fair to refer to ostriches
when ARIN is already on record:
http://www.arin.net/v6/v6-resolution.html
Also, for those who like to see things in real time,
there's always http://penrose.uk6x.com/
Regards
Brian Carpenter
University of Auckland
On 2007-10-03
Pekka,
[FYI I've already indicated my support for this draft
in a message sent to the IESG.]
On 2007-10-03 03:11, Pekka Savola wrote:
On Mon, 1 Oct 2007, The IESG wrote:
The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document:
-
The Secretariat tells me that Spammers are responding to TDMA queries
so that their mail goes through. They have made the suggestion that
we clear the list of people once per year. This would mean that a
legitimate user of a list that uses TDMA would get a TDMA query once
a year if they are
At 6:49 PM -0400 10/2/07, Russ Housley wrote:
1025 mail addresses have confirmed their address. I would bet that
at least 20% of the confirmed are spam addresses (or autoconfirmed
addresses)
Thoughts?
How was that 20% number guessed at?. If 200 spammers (or even 20!)
were on the TDMA list,
On Tuesday 02 October 2007 18:49, Russ Housley wrote:
The Secretariat tells me that Spammers are responding to TDMA queries
so that their mail goes through. They have made the suggestion that
we clear the list of people once per year. This would mean that a
legitimate user of a list that
Sounds reasonable to me.
Tdma for personal email protection is rude and unacceptable. For mailing lists
it is entirely acceptable. Cost far outweighs benefit as the inconvenience to
the single sender is much less than the benefit to the community.
Should also consider if spf or dkim checks
Paul Hoffman wrote:
At 6:49 PM -0400 10/2/07, Russ Housley wrote:
1025 mail addresses have confirmed their address. I would bet that
at least 20% of the confirmed are spam addresses (or autoconfirmed
addresses)
Thoughts?
How was that 20% number guessed at?. If 200 spammers (or even 20!)
The Secretariat tells me that Spammers are responding to TDMA
queries so that their mail goes through. They have made the
suggestion that we clear the list of people once per year.
Isn't there an engineering principle that if something is broken,
you don't fix it by breaking it even worse?
On Oct 2, 2007, at 6:14 PM, John Levine wrote:
The Secretariat tells me that Spammers are responding to TDMA
queries so that their mail goes through. They have made the
suggestion that we clear the list of people once per year.
Isn't there an engineering principle that if something is
On 2007-10-03 11:49, Russ Housley wrote:
The Secretariat tells me that Spammers are responding to TDMA queries so
that their mail goes through. They have made the suggestion that we
clear the list of people once per year. This would mean that a
legitimate user of a list that uses TDMA would
dedicate to ostriches...
http://www.apple.com/en/downloads/dashboard/networking_security/
ipv420.html
On 2007/10/02, at 22:32, Tim Chown wrote:
On Tue, Oct 02, 2007 at 09:05:39AM -0400, Keith Moore wrote:
Ray Plzak wrote:
The shortage of IPv4 addresses in developing countries in a red
IESG list. The chain:
Spamassassin - TMDA - mailman moderation
basically does the job just fine.
Oh, I hadn't realized that Spamassassin was in front. Yes, that should
help a lot, since I expect that the contents of legit mail to IETF lists
is rather unlike the contents of most spam.
On
On 2007-10-03 14:14, John Levine wrote:
The Secretariat tells me that Spammers are responding to TDMA
queries so that their mail goes through. They have made the
suggestion that we clear the list of people once per year.
Isn't there an engineering principle that if something is broken,
you
Ray Plzak wrote:
The shortage of IPv4 addresses in developing countries in a red
herring. All one has to do is apply for them from the RIR. Getting
a service provider to route them is a different problem, especially
when they profit from running your traffic through their NAT.
..or
37 matches
Mail list logo
