Shawn Somers wrote:
> Anyone that intentionally uses address space in a manner that they
> know will cause it to become contaminated should be denied on any
> further address space requests.
I couldn't disagree more with this kind of heckler's veto proposal. RBL
operators should not be permited
> I hear this a lot, but how many "linksys default channel 6" end users
> really have more than one subnet, or even know what a subnet is?
>
> ~Seth
Wrong question. The right question is, how many would if reachable address
scarcity weren't a factor.
DS
Patrick W. Gilmore wrote:
> On Nov 4, 2008, at 9:49 AM, David Freedman wrote:
> >> 2. The Internet cannot "route around" de-peering
> >> I know everyone believes "the Internet routes around failures".
> >> While
> >> occasionally true, it does not hold in this case. To "route
> >> around" the
>
Patrick W. Gilmore wrote:
> 4. There is a reason behind ratios which has nothing to do with telco
> "sender-pays"
There is an alleged reason.
> Hot potato routing + very poor ratios puts much more of the cost on
> the receiving network. This is a valid, logical, and costly concern
> for receivi
> Quite frankly, if any potential transit provider tried to make
> noises about
> being able to *guarantee* full connectivity, I'd show him the door.
Let's not make the perfect the enemy of the good. All that's required is
that they promise to make a good faith effort to interconnect with anyone
> Hi,
>
> I recently ran across a situation where a large ISP only accepts IRR
> entries generated by RADB to build their path filters. I use the ARIN
> Routing Registry. Is this a common practice? Should I convert over to
> RADB?
>
> Thanks,
> Craig
Since 2002, the RADB has included entries t
ing that service.)
Some people would really like email to be as reliable as possible, even if
that means they have to wade through a lot of spam. At least this gives them
ability to whitelist sources that are important to them personally.
David Schwartz
<[EMAIL PROTECTED]>
> Yes. It completely marginalizes the remaining positive qualities of the
> Domain Name System as a way to find things, in the name of giving people
> "more options."
That never existed and never made any sense. DNS is a naming scheme.
Entities choose names that are expressive, not informative.
Dave Pooser wrote:
> We had a client whose RFP vanished into thin air because of that-- he sent
> it from a hotel that practiced port 25 hijacking and had had their IP
> blacklisted for spewing much spam and viruses. So our server rejected the
> message, and when it tried to send the NDN to him
> 23 125.187.32.144(H!) 351.850 ms (H!) 359.870 ms (H!) 367.696 ms
>
> But whois keeps telling me:
>
> ReferralServer: whois://whois.apnic.net
Hmm, you might want to follow up with the referral server.
> NetRange: 125.0.0.0 - 125.255.255.255
> CIDR: 125.0.0.0/8
> NetName:APNIC-1
> On Aug 7, 2007, at 4:33 PM, Donald Stahl wrote:
> > If you don't like the rules- then change the damned protocol. Stop
> > just doing whatever you want and then complaining when other people
> > disagree with you.
> I think this last part is the key.
> Remember the old adage: "My network, My
> The point is, if you are the authority, you know how big the packet
> is. If you know it ain't over 512, then you don't need TCP.
>
> Or are you saying you do? Wouldn't it be 'incredibly stupid' for
> recursive servers to -require- TCP, even for < 512 byte packets?
A TCP query is just as val
Combined responses to save bandwidth and hassle (and number of times you
have to press 'd'):
--
> Just because it's behind NAT, does not mean it's unreahcable from the
internet:
Okay, so exactly how many times do you think we have to say in this thread
that by "NAT/PAT", we mean NAT/PAT as typ
> I posit that a screen door does not provide any security. A lock and
> deadbolt provide some security. NAT/PAT is a screen door.
> Not having public addresses is a screen door. A stateful inspection
> firewall is a lock and deadbolt.
This is a fine piece of rhetoric, but it's manifestly fals
14 matches
Mail list logo
