every technology based business?
We all learned our lessons in 2000-2001, right? Oh, wait
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
A from a different non-Bell-rooted
provider, because I just can't give up the interchangeability of SIM
cards. ;)
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
On 3/13/07, Todd Vierling <[EMAIL PROTECTED]> wrote:
On 3/13/07, Sean Donelan <[EMAIL PROTECTED]> wrote:
> If many of US consumers were already buying the biggest pipe and were
> willing to pay even more for even higher speeds; would we be having
> this discussion? Or i
even puts that price past a
typical (bidirectional 95p, not rate-capped) Mbit/s cost of a real
fiber connection to a Tier-[123] type carrier. The only remaining
difference skewing away from direct connection is the cost of the
loop.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
mention cell-based wireless technologies, because the
providers in that market space haven't truly awakened to the
possibility of fixed cell termination sites for broadband-type access.
That is generally seen as a congestion threat, not an opportunity, by
the carriers.)
--
-- Todd Vierling <
ssentially zero traffic collision. On
the upstream, the talkers are more like 802.11* wireless clients
engaged in a babblefest.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
er should indicate that we're
getting close to the proverbial wall.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
hnology
and infrastructure to offset the inevitable.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
On 2/22/07, Sean Donelan <[EMAIL PROTECTED]> wrote:
On Wed, 21 Feb 2007, Todd Vierling wrote:
> I'd say it's severely biased in the overestimation direction -- but
> that's not to say it isn't a problem, because zombies Suck.
People with access to the ppp, dhcp
x27;ve seen
plenty of wireless routers installed for the sole purpose of making it
easier for a single computer to reach the DSL connection at the wall
jack.
I'd say it's severely biased in the overestimation direction -- but
that's not to say it isn't a problem, because zombie
will be earmarked for use in all three bands
(2.4GHz and both 5GHz ranges).
I'll just hope that my residential neighbors stay out of my 5GHz space
a little while longer. 8-)
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
last decade. ;)
(The 802.11[bgn] density where I live is so high that I resorted to
installing 802.11a throughout my house. Zero contention for airwaves
and I can actually get close to rated speed for data transmission.)
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
en, is unlikely to see deployment outside
of an organiation's own garden network, and you have near zero uptake.
Follow the money, as always. :)
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
to
arbitration; one pretty major such settlement was made into a movie
about a large energy company)
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
to get some lunch before the office cafeteria closes.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
As [unfortunately] usual with this sort of thing, the front line
support staff doesn't recognize when a user actually knows what
she's/he's saying. Blow-offs ahoy! ;)
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
t configuration for dual-format output is
"ask me" based on whether all addresses are in the address book with
the HTML option enabled, rather than simply always sending multipart
by default.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ncryption is
that it often doesn't support "hibernation" -- but if the hardware has
a standby power save mode that is low enough on power consumption (S3
or similar), that shouldn't be a problem.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
is it? Based on
earlier statements of yours, I would give you the benefit of the doubt
and assume the former. However, you just had to pull out the "defame"
word in a completely invalid grammatical and legal context, so I'm
starting to hedge bets on the latter.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
o this. They do work in spite of the
moanings of the few who have been mistakenly blocked. In the meantime
my patience with email "lost" in the sea of spam not blocked by
blacklists, etc. is growing thin.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
On 8/9/06, Cerebus cerebus <[EMAIL PROTECTED]> wrote:
I really believe IPv8 is workable,
Just Say No to crack!
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ent of blocking spam (which is *really* based on
"solicited" status). However, the *social* issues of today's spam
abuse often make content-based filtering a necessary evil.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
e exit node operators from hacking such a
check right back out of the code?
This is a better idea, but still has a bit of defeats-the-whole-point
to it, as it would depend on people obeying that header voluntarily.
Social vs. technological divide, again.
--
-- Todd Vierling <[EMAIL PROTECTED]
the
technology, y'know.
so Kevin Day's purpose is not served.
If the point of the technology is to add a degree of anonymity, you
can be pretty sure that a marker expressly designed to state the
message "Hi, I'm anonymous!" will never be a standard feature of said
t
HTTP + HTTPS cover a pretty huge chunk
of traffic and user involvement. Certainly some other common
protocols could be filtered for anonymizing purposes in their own
ways.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
at which point the
proxy could generate a "valid" (from the browser's POV) cert for any
remote site.
All this is an exercise in social vs. technical
vulnerability/security. You cannot fix social vulnerabilities via
solely technical methods, and vice versa.
--
-- Todd Vierling &
axMind and other providers, whereas
some data is scraped from WHOIS or provided by inference from
end-users.)
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
On 5/12/06, Barry Shein <[EMAIL PROTECTED]> wrote:
On May 12, 2006 at 14:51 [EMAIL PROTECTED] (Todd Vierling) wrote:
> The complexity added by TLDs has one extremely critical good side
> effect: distribution of load by explicitly avoiding a flat entity
> namespace.
convince on the order of sqrt(-1)
people.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ell you providing access to Manhattan island.
I'll offer you advice once offered to me. Read the sign on the padded
cell: "Do not feed the troll."
Peter's about 51 cards shy of a full deck when it comes to TLDs. I
still have a back-of-my-head suspicion that he's a n
viders
in the middle suck at any given time.
(ObAdvertisingSquelch: I have direct involvement in this subject, so
I won't discuss vendor names on-list to avoid conflict of interest.)
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
cause of the short
> skirt he was wearing?
And, if a service were available to the public *as a matter of courtesy* (or
even as a matter of accident) and not *advertised to the public*, then those
using the [unadvertised] service must cope if and when the service
disappears, or even starts mis
around?
Where "wrapping" depends on the size of a time value in the device's OS.
(Note that if the devices crash because of bad input, I can hardly see that
as legally actionable, since the devices never had the permission to use the
data source in the first place. ;)
--
-- To
ts home:
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
the market where
Xen shines.
If it really were an OS-specific issue, then "Linux shops" might as well use
UML. ( )
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
t version of the virtualization extensions en
masse, this will probably get more steam from providers.
If a Xen-instrumented kernel is available for the desired OS, that would
still be preferable, of course.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
e Linux, which I went out of my way to heckle (with technically
sound arguments, mind you) at an IETF when it was proposed as a method
of virtualization. The sad part is, some folks bought the drivel and
actually set up businesses using UML as a virtualization layer.
--
-- Todd V
modem says I *could*
attain better than 9Mbps down and 2Mbps up, were such service available to
consumer low-lifes like myself. )
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
t then stop spreading FUD.
>
> No.
> Talk to you after the first worm.
That's just about as good of a statement as a demand for a phallus size
check. If you can't back up claims, it is FUD by definition. So, just like
BB wrote above:
> > [...] stop spreading FUD.
urage you to look up the English definition of "censor" sometime.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ng, and even if it weren't, it is not a valid
argument for "let the swamp in".
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ent dictator, for that matter.
FUD.
2826.
Old news. Old thread. Blood stain marking former site of equine.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
starting to offer the
ability for traffic to go out a "transit" neighbor so long as some
containing prefix is advertised (even if it's not the most specific).
Traffic engineering is happening on both ends of the BGP mesh *today*, so
you should present any proposed solution in that context.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
On Fri, 17 Feb 2006, Todd Vierling wrote:
> > I might be crazy, but couldn't you just prepend the route enough to
> > effectively poison it at ingress to 'backup-isp' ?
>
> Some route decision override schemes don't care what the path length is at
> al
With the development of source traffic engineering schemes, prepending is no
longer reliable as a means of affecting routing on the remote side. That
perception will have to die with it (hopefully sooner rather than later).
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
be a smart-ish routing device or
scheme in play that overrides normal BGP decision making.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
NXDOMAIN, for any
unassigned addresses in the /64.
Don't get me wrong, I'm not one for security through obscurity in the
primary case. But attack vector minimization is still useful for this
particular angle.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
more than one hex digit's worth of randomness in the scan in
order to find a next-level delegation, increasing the cost of scanning that
namespace quite a bit.
(Having delegations at every nybble level would be ... alarming at best,
given the amount of PTR redirection that implies. :)
--
e fixed in the foreseeable future, so we have
to settle for an imperfect technical solution -- for now. For some
operations, the spew level is so high that blanket blocking CNNIC is the
only reasonably maintainable option.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
they leave enough
headroom for the in-progress IPTV or VoIP.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
to do this ONCE!
>
> Kurt, and our friends at CNW, you realize this is fairly bad
> for this list?
s/for this list//
C/R schemes do not scale, and form one of the major channels of backscatter
(not to mention annoyance).
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> type stuff
>
> I guess what they actually should do is filtering inbound connections
> FROM port 25 to any port.
That's why I said that it is misconfigured. The inbound packet filter has
the wrong matching criterion.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
block
outbound connections to port 25, which is good -- but they are also blocking
*inbound* connections to a local SMTP receiver, which protects nothing and
simply annoys those of us who have a clue.)
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
t fail, the path an IPv6 user takes to reach us (and
> vice-versa) is less optimal than the IPv4 route.
(If a user is implementing 6to4, it usually means that the v4 route *is*
better, so 6to4 becomes a routing policy suggestion as well.)
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
in both 2
and 4 byte AS representations is to go completely 4-byte internally on the
router, and treat the 2-byte sessions as a backwards compatibility case.
In such an implementation, there is also no such thing as a "2-byte AS",
because all ASs are represented in 4 bytes.
--
-- Todd V
s -- because you have
to use metadata beyond the 4 bytes to represent which "type" of AS you have.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
kely to attract the attention of the correct people. It also
becomes a much bigger argument for proper implementation of SMTP AUTH at
that point.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ly used on the Internet today;
SMTP shouldn't be considered all that different anymore. The MUA and MDA
leaf roles have clearly defined separation from the MTA infrastructure, and
MTA-to-MTA communication should be perfectly capable of in-band error
signaling in the modern Internet.
--
-- T
cting with 5xx during the SMTP transaction does not have this undesired
behavior. In that case, the connecting MTA, which should have a much better
idea of who sent the virus-worm instance, receives the rejection in-band.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
-malware
notices to forged senders), and your first priority should be stopping that
spew at the source BEFORE asking uninvolved third parties to help, you're
going to continue to look like the self-absorbed crack smoker you've made
yourself out to be.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
That's not exactly hyperbole. My antivirus-spew counter on my 9-user SMTP
server rolled past 1M more than a year ago.
Per incident, it isn't more than 1M; moire like ~50k, but that is still well
beyond DDoS level.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
t;false positive".
Put down the crackpipe and walk away from the keyboard before you say
something else your employer will regret. (These might be "your opinions",
but it's telling if a company continues to employ someone who doesn't
understand said company's mark
ave an ulterior motive
(hmm...), or you haven't been using e-mail for very long. In any case, you
are reflecting a *really* bad image on your mail domain (and thus your
employer) by being so completely lost in your own world.
I stand by my T. Roll conclusion.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ent of the virus, not the (almost
surely forged) sender. Don't cost shift the burden onto third parties, and
don't try to rebrand spew that *never* hits the real original sender as some
kind of "DSN".
"Paging a T. Roll to the white courtesy clue-phone"
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
It is the responsibility of the *SENDER* not to send UBE.
If this is still not clear, you're working in the wrong industry.
===
On Fri, 9 Dec 2005, Steven J. Sobol wrote:
> I'd like someone UNBIASED to take up his side of the discussion, please.
> I'm really not inclined to
omes from otherwise "reputable" MTAs,
whereas the spam comes form zombies that are often already blacklisted, or
are in known dynamic pools that are blocked here. Thus the zombies get
blocked long before DATA, but the "reputable" MTAs sending the backscatter
don't get c
what color of shirt the virus
"warning" wears; if sent to a forged address, it is UBE and deserved to be
treated as such.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ooks, walks, and quacks like a UBE duck.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
heless, DSNs are not Unsolicited Bulk Email.
I don't see how this is relevant to my paragraph above. I was not equating
DSNs to UBE -- I specifically mentioned virus "warnings". Whether those
warnings are look like DSNs, smell like DSNs, or taste like DSNs is wholly
irrelevant; t
ur poison). However, if the
server cannot verify that the MAIL FROM:<> is not forged with reasonable
certainty, the server should not send a DSN, period. Otherwise, it's a
direct contributor to the UBE problem.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
hin a DSN.
If you're still sending to a forged address, how is this not still UBE...?
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
are vendors still have a large amount
of fault on their shoulders.
Things like clamav have had the option properly separated for some time, but
I'm mainly counting the slow-moving, commercial anti-malware products in the
prior pragraph.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
to forged envelope/From: addresses? Think carefully before answering.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
>
> It's a simple switch in the GUI of Barracuda Networks to turn of this
> annoyance. More operator error than Barracuda's fault, IMHO.
If it is on by default, it is a bug, and not operator error.
(Virus "warnings" to forged addresses are UBE, plain and simple.)
-
ance Policy[tm]....
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
milar clause in [YOU-]CAN-SPAM, because the DMA wanted it.
But then, the DMA got a lot of wishes granted in that piece-of-cr^Wlaw.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ng $vendor2 because $vendor has decided
to let security flaws stew, it's time for $vendor to reevaluate that
business model -- at least a little.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ing blocks in routing tables
make writing the physical routing code much easier, and in many cases makes
the forwarding operation much faster."
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
On Tue, 25 Oct 2005, Florian Weimer wrote:
> >> Two possible explanations:
> >
> > 2+2=5, right? :)
>
> Oops. 8-)
No, you got it right. The [third] option at the end, "play nice", has only
a passing association to the realm of possibility.
--
-- Todd
onsible for keeping the knowledge resources to do that problem-hunt.
It's another side effect of the choice to outsource the multihoming
responsibility, and is one of the factors to consider when choosing a
redundancy approach.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ch more than 1% of an employee's time to keep running smoothly.
Obtaining single-homed connectivity from a Tier-2 mostly "outsources"
network support, and small to medium size businesses tend to like that.
It's not the only leaf end solution to the problem, but it's a viable one
(and can be less costly to the rest of the world in turn).
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
s
aggregations, that means one less ASN and one or more less routes in the
global table.
It's a Good Thing(tm).
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
On Wed, 19 Oct 2005, Brandon Butterworth wrote:
> "Gartner said every location that requires mission-critical
> internet connectivity, including externally hosted
> websites, should be multi-homed"
200k routes, here we come!
--
-- Todd Vierling <[EMAIL PROTECT
for telephony is because,
unlike TCP streams, telephone circuits are comparatively large streams with
much longer keepalive times.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ce, it may not be such a
big deal.)
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
kes 6to4 more complex, compared to a plain IPIP (or
GRE, or any other point-to-point vanilla tunnel protocol) tunnel is that the
far-side endpoint changes based on the tunneled payload.
That said, it should *not* be an unsurmountable problem -- if the demand is
there. Has anyone seen if the chicken la
yummy tunnel slowness. Instead, my return traffic for 6to4 clients uses
*zero* third party v6 tunnels.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
keep stacking up.
The rest of us use actual *Internet* root DNS servers and will never see
these problems.
(I need to find my glasses, because that sign on the road ahead is hard to
read -- something about feeling droll? Wait, that's not right....)
--
-- Todd Vierling <[EMAIL PROTECTED]
ng) than single-homing to a tier-1.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
citing it. Neither Google *nor* intermediaries
should be responsible for illegal content -- to them, it's just bits moving.
The only responsibility that *either* one should bear is the ability to
provide an audit trail to the real culprit, no more.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ervers. Google just indexes the information,
the search engine argued, and feels it is not its place to censor
information contained throughout the Web.
=
Well, isn't that "fun"?
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ss
about what the market implications are -- I care that end users are f00ked
over in the aftermath.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
y capable of transiting those packets?
The thinly veiled implication there is that "full mesh" is not a long term
effective way to run the backbone level transit, because dropping one peer
without an alternate path means that we get broken transit. Yum.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
doing that. (Hell, they have lots
> > of spare capacity now. :)
>
> Most also have a clause to cover the inter-AS links, making sure that they are
> not overloaded.
What nature of clause? I consider deliberately filtering prefixes or origin
ASs to be a violation of common backbone BG
tworks
there. Of course, there aren't enough North America v6 nets, either.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
u to come to the
same realization, but I can still try to echo a common sentiment directly to
you, rather than through a third party such as Mr. Dambier.)
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
, but resolves to *empty or nonexistent*, then the mail should
bounce. When a DNS server is unreachable, it can hardly return a NXDOMAIN
back to the requestor. 8-P
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
s.
Failure to resolve != resolves to NXDOMAIN/empty. A failure to resolve
(SERVFAIL) should result in the same queueing behavior that the remote SMTP
server uses for failure to establish a TCP connection.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
If this isn't just a pingable address with the resolutions left to
> all of us, this is not enough time for testing.
#.#.1.2 is pingable in all three of the Cymru-announced networks.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ew times?
I did get a private response indicating that X.X.1.2 is pingable in all of
the above.
--
-- Todd Vierling <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
1 - 100 of 235 matches
Mail list logo
