The talk was fantastic. He never stooped to Microsoft bashing, but when asked, he convincingly drove home the very why he thought MS would be come irrelevent: it's happened before!
Eric told us a story, of the three ages of networking.
The first age, from about the mid-sixties until some way into the seventies, networks were a big experiment. IP was around, but TCP wasn't - the top layer was NCP.
Then networking got popular and companies like DEC and IBM and countless others brought out their own proprietary protocols. And you had to choose. And if you chose DECnet over another, you were making a bet that DECnet would eventually succeed and the others would fail, because they were all incompatible and you could only talk with other DECnet users.
So the market split into a series of monopolies where the cost of moving from one protocol to another was way too high to justify the advantages. And like in any monopoly situation, prices proceeded to rise.
And then along came this strange little open standard called TCP. Because it was open, it started to spread, and because it spread, prices started to fall.
So while the costs of the proprietary systems were continually rising, the cost of running a TCP network kept falling, until the difference was greater than the cost of transitioning - at which point the bottom fell out of the proprietary protocol market! (and ESR practically leaped off the stage, and I nearly fell out of my chair).
And so it's not just that it looks like open systems will prove themselves over closed systems - it's that it's already happened.
That's just one small part of an amazing talk. I've never seen anyone who really believes in Open Source as strongly as he does, or argue its merits as coherently. If you listen to him for a while you can't help but think a little differently about things when you leave.
Perl does a lot of things well. A lot of things do specific things that Perl does better.
Reasons why Perl is dominant:
It's good enough
Everyone knows it
It's very well documented
It's easy to pick up
It's powerful once you get to know it
It's a bit like C, only nicer
Using C or C++ for CGI scripts will not give you the performance gains you might think. We are no longer talking about mega-applications which are highly CPU-bound. This goes double if you make sensible use of the built-in functions in Perl, which are themselves written in C.
Rather, you are more likely to come across one of these bottlenecks:
Forking a process or two for every single web request
Disk I/O
Network I/O
In real life that means: the amount of runtime that could be saved by writing the script in a compiled language is dwarfed by other factors - notably the effort of context-switching an entire program in and out every time the script is called. This is a fundamental problem with CGI, and a big one if you want all or most of your site to be dynamic.
So where do you turn from here? Well, chuck CGI and build the scripting language into the web server. This isn't as painful as it sounds. The obvious one is mod_perl for Apache - but Perl, though cool, is BIG and you do not necessarily want a half dozen copies of it resident in memory at all times.
My favorites - and I use these all the time these days, are:
Don't be put off by the name! AOLserver used to be called Naviserver, until the company was bought out by you-know-who. It's a rock-solid web server that I've been using it for years. Its embedded scripting language is Tcl, which is not fun to debug, but is extremely elegant once you are used to it.
There are others, but speaking from my own experience these two have allowed me to turn entire sites dynamic that would not otherwise have been possible - usually hobby sites that are running on old and donated hardware.
Everyone seems worried about how this will stop people registering similar-looking names... that's not the problem.
The problem is those enterprising guys who get in fast with a useful domain, run a legitimate site off it, and then attract the attention of The Big Guy(tm). Big Guy hits Little Guy with a lawsuit. It doesn't matter whether or not the lawsuit has a hope of winning, or whether the claim is legitimate. Little Guy invariably doesn't have the resources to defend himself, and so must give up the domain by default.
Now I know nothing about the American legal system, and the CNN article doesn't give me much insight. But the way I read it, if the bill makes it a criminal offense, then it's up to the US equivalent of the Director of Public Prosecutions to follow up. This would mean that the decision to prosecute lies with an essentially neutral third party - who is much more likely to decide that an individual is making real use of a domain and is not interested in selling - rather than the lawyers of Big Guy who will happily take the risk of losing on the basis that they probably won't have to fight the case at all.
If, on the other hand, it's a civil matter, then this is just one more weapon for the Big Guy on top of trademark infringement, and a completely redundant one at that. Oh well.
There are techies on the ICANN board. The ASO is a blatantly techie group I was there. I helped select the three European members of the ASO.
This has been a more open process than people seem to believe. There is seems to be an attitude of "I didn't see a Slashdot article on this, therefore I wasn't represented". A slashdot poll, or any kind of net election, is not a good way to have everyone's voice heard. Net polls are fun, but I have never seen any "democratic" concept more abused than that, including student politics.
This has been an open process, and anyone who has web or email access has had a voice. RIPE, ARIN and APNIC - the three regional registries representing in equal parts Europe, America and Asia-Pacific - made a proposal on how to form the ASO. Another joint proposal came from CIX, EuroISPA and eCOM-LAC. Comments were invited, and received, and recognised, on both proposals. (I made mine).
In the end, the proposal from the registries was accepted as the most open and fair way forward - with an acknowledgement that no solution is perfect and so the ASO will need to answer to an ad-hoc committee in the initial stages to ensure that true representation is occurring.
The process of selecting ASO members was itself open. RIPE is a completely open group - you do not need to be a customer of the RIPE NCC to attend its meetings or take part in its working groups - and ARIN and APNIC are rapidly heading in that direction. Bear in mind that the Canadian member of the board was chosen has the representative for ARIN, the RR for America writ large, North and South.
To anyone who thinks that this method of decision doesn't work, or doesn't properly represent anyone, remember that this is the same method by which any progress has been made in the last ten years. A group of techies meet (IETF, RIPE, NANOG, whatever) representing their various companies, ISPs and customers, thrash out the issues of the day - IPv6 allocation, too many updates in the RIPE database, how to measure network performance between Amsterdam and New York - and walk away knowing what direction to proceed in.
The process is not the flawed democratic principle whereby an uninformed electorate is given a bad bunch of choices (picked by a mysterious process which the population at large has no control over) and asked to pick the one which the least people hate most. It is a process where anyone with a good idea can make a proposal, and anyone with a problem with that proposal can have their voice heard, and have it fixed. Or looking at the another way, "If you don't like this option, fine, but I'll want to hear some better ones please."
It's an open-source election, people. Please don't abandon it in favour of a trumped up slashdot poll.
I doubt this is as precedent-setting as it looks. It is a trademark issue rather than a domain name issue. I find it difficult to believe that the issue of trading under the same translated name has never occurred before. I just wish I had the legal experience to say whether it had.
A lot of people are expending a lot of energy and hype every time a new legal challenge comes up. They're making the same mistake as the censors - this can often be dealt with under existing legislation and precendent, and if not, it should be. Enacting new laws and setting new precendents for the same issue in every popuylar new medium is awkward and sloppy, and will not keep up.
Just like writing good code. Make no assumptions, and abstract as far as you can!
That's an entirely legitimate concern and I dare say (from my uninformed viewpoint) that it was one of the main bones of contention that made this compromise so hard to reach.
NSI will be contractually obligated to provide equivalent access to the Shared Registration System to all registrars accredited by ICANN (including NSI acting as a registrar) and to ensure that the revenues and assets of the registry are not utilized to advantage NSI's registrar activities to the detriment of other registrars.
Hopefully this will be enough. It's not easy. NSI has the database and has been claiming for some time now that it owns it, period. It looks like ICANN has successfully coaxed them down from this position and is moving in the right direction.
Slowly, yes. But the right direction is unbelievably important. A head on clash between ICANN and NSI would drag in the root server operators, major ISPs, minor ISPs, every administrators' root.hints files, and - eventually - governments. One would not be able to ensure that legitimate domains would resolve. It would be ugly and disruptive, and would do the internet zero good. And worst of all, the eventual outcome is almost certain not to be the best one. Thank whatever powers you believe in that we've got compromise here, folks.
In the long term:
The term of the Registry Agreement is four years from its signing. If ownership of NSI's registry and registrar operations is fully separated within 18 months, and the registry functions are performed by an entity that is not affiliated with a registrar and promises never to affiliate with a registrar, the term would be extended for four additional years.
This gives NSI the carrot of an extended period as registrar if the separation of registry and registrar proceeds speedily. Again, a good one. It's been mentioned elsewhere on this forum that NSI at least has experience in running the root zone. I don't mind them leaving longer between reviews if that major bone of contention - separation of registry and registrar - is removed.
Dave
[As usual, my opinions, not necessarily those of my employer. And worse, they're based on a cursory reading of the agreement, and some pretty shaky opinions on the nature of the root...]
It basically states that if NSI and ICANN feel they aren't makeing enough money, they can raise the prices accordingly.... Does anyone else see a problem with this?
Nope, no problem. NSI is a commercial entity. Fair enough. ICANN is a nonprofit, advised in these matters by its Domain Name Supporting Organisation, made up of representatives of these groups.
The intention here is that ICANN plays the role of arbitrator. Much effort has gone into ensuring that ICANN is properly transparent and properly representative of the community on these matters.
Personally, I preferred it when Jon Postel ran the entire internet, but after countless green papers, white papers, and input from many, many interested parties, ICANN is set up to do a decent job of achieving consensus.
Dave
[My opinions, not necessarily those of my employer]
You have competition - that's wonderful.. but without rules it's gonna get vicious in a hurry. Is there an arbitration committee with the power to enforce it's rulings? No.
Depends on how you look at it. Which two parties are you worried about here? If it's NSI and some other registry - indeed, any two registries, then the group with the power to enforce its rulings is undoubtedly the group that allocated registry status in the first place - IANA or, these days, its successor.
If NSI (or anyone else) is arguing with the very people who ostensibly hold that authority, and is thus challenging that authority, well that's ugly, and doesn't have a simple answer.
Second problem - you're maintaining multiple independent databases. Anybody who's used SQL for more than 10 minutes knows that this is a HUGE data integrity issue. Widget Enterprises decides to register widget.com, so they call up NSI and get the order put in. I can't see how the current system can support multiple root servers - they'll be constantly out of sync with the others!
Nay, nay and thrice nay. There remains one central database and, just like all the other zones in the world, one primary root server. Type dig . soa on a UNIX machine and you'll see from the SOA that the primary name server is A.ROOT-SERVERS.NET, run by - surprise - NSI.
The multiple root servers referred to in the document are, by my understanding, the ordinary secondary name servers for the root domain. DNS is neat like that, it allows you to spread the load for efficient bandwidth use, or CPU use, or reliability, or all three.
Same for the.COM,.NET and.ORG servers. Every domain registered in these TLDs must go through the operators of A.ROOT-SERVERS.NET. This is what the $9 charge is for. It is rather unfortunate that the operators of the primary server are themselves registering.COM domains, but there weren't no easy way out of that one, 'cos NSI was never gonna give up all its hard work (and revenue stream) that easily.
Dave
[My opinions, not necessarily those of my employer]
The GPS rollover didn't go so bad. We have a clock on the roof of our building using the GPS system as its time source; it was fine, and so were the other 40 or so like it around Europe.
Here in Ireland and around the U.K., there was one marine report of difficulties due to the rollover. Bad weather over that period, poor visibility and the failure of his GPS equipement all conspired to get him lost and he had to radio in. There were several other shipping problems over that weekend, but none due to the rollover.
Java was and is a great idea. Sun saw it for what it is. They marketed it, they put it out there, they tried to take over the world with it.
They got it an image problem when they stuck it into buggy browsers on slow machines, but that's a discussion for another time.
Linux didn't start out like that. Linux wasn't some germ of an idea that needed incubation and careful marketing. Linus didn't make deals with $large_software_company to include it with every copy of $popular_application. He coded it and stuck it out there.
And it stuck.
Guys, Linux has nothing to prove. The mindset is already there. The people who need to trust it most, trust it. We know when it can be used. We know when it can't. We can prove it.
Once we have that, we can work on the PHBs, and no dodgy benchmarks are going to change that.
This is not some ivory-tower dismissive. It's a reminder: in an industry awash with false promises and vapourware, Linux delivered long ago. It will remain as long as it is useful.
WIth an even more exciting methodology, the OS Sucks/Rules-o-meter uses highly refined mass survey techniques to survey the relative merits of different Operating Systems!
Translation: search Alta Vista for "Linux sucks", "Windows rules" etc., and graph the results.
Gene Spafford (co-author of the O'Reilly book on security, many seminal papers on Computer security, and minder of such tools as Tripwire - the man knows what he's talking about) had this to say some years ago on security challenges:
He lists so many good reasons (eight) to distrust this sort of challenge that it is difficult to summarise the message here. Best to click and read it yourself.
The point goes for every package where the author tries to "prove" security in this way - be it Sidewinder, Qmail or Microsoft. In many cases, the only result is to damage security by giving miscreants some "free time" to try and crack the system, for free, without fear of punishment.
Tiger teams have their place in a properly designed, properly managed security audit. Using unpaid tiger teams as the principal means is useless and dangerous. Will Microsoft move to assure its customers that this is simply a small part of a large, thorough security audit?
[These links are long. If they get broken, go to www.cisco.com and search for "Committed Access Rate".]
Some of the more interesting versions of the Cisco IOS (the 11.1CA and CC tree I think, and v12 if you're feeling brave) will perform incoming and outgoing traffic shaping. The closest to what you'd like is probably Committed Access Rate.
It can be applied directly to an interface to limit all IP traffic, or you can define an access list so that it will limit all traffic that matches a particular protocol, QOS flag... or your customer's IP subnet.
This last option is useful to limit a customer's access to the internet at large while still giving them full speed access to, say, your local mail or FTP server. You perform the limit on your connection to the rest of the world, using a different rate limit for each customer.
The v12.0 documentation is linked above, or check this CCO search.
Guys, a plea from someone who spends time at both ends of the postmaster address.
This sounds weird and useless when faced with an ISP that seems to be complicit in the abuse of your mailbox. But some ISPs, bless 'em, do still take this sort of thing seriously.
I make it a point to read, reply and act on every mail sent to postmaster@ or abuse@ my employer. It's thankfully a small trickle, since we don't do any kind of dialup. But it's sad to say that the important (technical) parts of these reports are often misdirected or swallowed up in threats of litigation or violence.
Think of it this way: every extra minute the abuse guy has to spend divining info from your report is one less minute he can spend fixing the problem between now and 5:00pm.
Know what headers you can trust
When making a technical report, make sure you get the facts right. Forwarding the spam to postmaster, abuse and domain-holder@every address in the spam will go to a lot of people who can't deal with the problem, which doesn't help anyone.
The only Received: header your can really trust is the one where it entered your systems. That'll usually have come from a dialup (sorted) or an open relay (messier). If it came from a relay, report it (see below) and by all means check the headers further down - but at least check them for sanity. They're often forged, and spammers are slowly learning just how many people get thrown off the scent by this.
The From: line can't be trusted at all. Forging it is trivial. And, of course, just 'cause someone says they're from Slashdot or AOL or Hotmail doesn't mean it's so. Concentrate on the network that really sent you the spam, not the one they say they are.
If there's a website mentioned in the spam (hint: if you see http://long-integer-address/, use "ping integer-address" to get it back into dotted-quad in a hurry) then traceroute and mail the upstream, but make it clear that you're reporting a site named in a mail abuse, not a host that spammed you. In other words: use a separate message.
Be polite!
You've heard this one before, but hell, it's worth iterating. It's amazing how refreshing it is to have a polite message from an obviously clueful individual land on your desk. Threats and foul language won't have spammers and spamlovers quaking in their boots, but it will give decent postmasters pause for thought before replying, and it will make the real evidence in your message harder to find.
And believe it or not, there are people out there who genuinely don't realise that their brand new UNIX machine came with a buggy sendmail. A bit of patience and cooperation works great with these people. Unpleasantness gets you blocked at the router.
I'll climb down off the soapbox now. Thanks for listening. I'm sure as hell not out to defend spammers or negligent ISPs. I don't think any of the above will help them. But I hate to see ISPs that do give a shit having to replace their Real Live Postmaster with a mailbot or clueless helpdesk just because the signal:noise ratio in reports has gone to hell.
Postmaster mail, like any RFC requirement, is binding by consensus only. Use it, early and often. Just please don't encourage its demise.
You're quite right, blocking tools can be used to screen things one doesn't like, but that one really, really ought to be reading.
The problem isn't the software here. The problem is the closed minded individuals who've decided they don't want to read your column, or my comment, or Rob's Quickies.
Take a look at what's happened to Usenet, Jon. Back when it was 2 articles per day, all was fine. Then it kinda scaled out of control. The result is a medium that some swear by, but most - in my humble experience - just dismiss as unusable.
So what are we to do? I hate to see good, level headed moderation referred to as censorship. Censorship is an attack on free speech. Moderation is a defence against those who would destroy a forum.
Yeah, I know, there are bad moderators. And hell, they probably outnumber the good ones and all. What can you do. But Jon, much as I take your point, I fail to see an alternative. Please don't condemn us all to a network full of flamers and First Comment posters.
Slashdot Mirror
The talk was fantastic. He never stooped to Microsoft bashing, but when asked, he convincingly drove home the very why he thought MS would be come irrelevent: it's happened before!
Eric told us a story, of the three ages of networking.
The first age, from about the mid-sixties until some way into the seventies, networks were a big experiment. IP was around, but TCP wasn't - the top layer was NCP.
Then networking got popular and companies like DEC and IBM and countless others brought out their own proprietary protocols. And you had to choose. And if you chose DECnet over another, you were making a bet that DECnet would eventually succeed and the others would fail, because they were all incompatible and you could only talk with other DECnet users.
So the market split into a series of monopolies where the cost of moving from one protocol to another was way too high to justify the advantages. And like in any monopoly situation, prices proceeded to rise.
And then along came this strange little open standard called TCP. Because it was open, it started to spread, and because it spread, prices started to fall.
So while the costs of the proprietary systems were continually rising, the cost of running a TCP network kept falling, until the difference was greater than the cost of transitioning - at which point the bottom fell out of the proprietary protocol market! (and ESR practically leaped off the stage, and I nearly fell out of my chair).
And so it's not just that it looks like open systems will prove themselves over closed systems - it's that it's already happened.
That's just one small part of an amazing talk. I've never seen anyone who really believes in Open Source as strongly as he does, or argue its merits as coherently. If you listen to him for a while you can't help but think a little differently about things when you leave.
Dave
--
Mozillazine speedily got permission to post a mirror of the article:
http://www.mozillazine.org/evolt_mirror/
Dave
--
Perl does a lot of things well. A lot of things do specific things that Perl does better.
Reasons why Perl is dominant:
Using C or C++ for CGI scripts will not give you the performance gains you might think. We are no longer talking about mega-applications which are highly CPU-bound. This goes double if you make sensible use of the built-in functions in Perl, which are themselves written in C.
Rather, you are more likely to come across one of these bottlenecks:
In real life that means: the amount of runtime that could be saved by writing the script in a compiled language is dwarfed by other factors - notably the effort of context-switching an entire program in and out every time the script is called. This is a fundamental problem with CGI, and a big one if you want all or most of your site to be dynamic.
So where do you turn from here? Well, chuck CGI and build the scripting language into the web server. This isn't as painful as it sounds. The obvious one is mod_perl for Apache - but Perl, though cool, is BIG and you do not necessarily want a half dozen copies of it resident in memory at all times.
My favorites - and I use these all the time these days, are:
Don't be put off by the name! AOLserver used to be called Naviserver, until the company was bought out by you-know-who. It's a rock-solid web server that I've been using it for years. Its embedded scripting language is Tcl, which is not fun to debug, but is extremely elegant once you are used to it.
There are others, but speaking from my own experience these two have allowed me to turn entire sites dynamic that would not otherwise have been possible - usually hobby sites that are running on old and donated hardware.
Dave
--
Everyone seems worried about how this will stop people registering similar-looking names... that's not the problem.
The problem is those enterprising guys who get in fast with a useful domain, run a legitimate site off it, and then attract the attention of The Big Guy(tm). Big Guy hits Little Guy with a lawsuit. It doesn't matter whether or not the lawsuit has a hope of winning, or whether the claim is legitimate. Little Guy invariably doesn't have the resources to defend himself, and so must give up the domain by default.
Now I know nothing about the American legal system, and the CNN article doesn't give me much insight. But the way I read it, if the bill makes it a criminal offense, then it's up to the US equivalent of the Director of Public Prosecutions to follow up. This would mean that the decision to prosecute lies with an essentially neutral third party - who is much more likely to decide that an individual is making real use of a domain and is not interested in selling - rather than the lawyers of Big Guy who will happily take the risk of losing on the basis that they probably won't have to fight the case at all.
If, on the other hand, it's a civil matter, then this is just one more weapon for the Big Guy on top of trademark infringement, and a completely redundant one at that. Oh well.
Dave
--
Guys,
There are techies on the ICANN board. The ASO is a blatantly techie group I was there. I helped select the three European members of the ASO.
This has been a more open process than people seem to believe. There is seems to be an attitude of "I didn't see a Slashdot article on this, therefore I wasn't represented". A slashdot poll, or any kind of net election, is not a good way to have everyone's voice heard. Net polls are fun, but I have never seen any "democratic" concept more abused than that, including student politics.
This has been an open process, and anyone who has web or email access has had a voice. RIPE, ARIN and APNIC - the three regional registries representing in equal parts Europe, America and Asia-Pacific - made a proposal on how to form the ASO. Another joint proposal came from CIX, EuroISPA and eCOM-LAC. Comments were invited, and received, and recognised, on both proposals. (I made mine).
In the end, the proposal from the registries was accepted as the most open and fair way forward - with an acknowledgement that no solution is perfect and so the ASO will need to answer to an ad-hoc committee in the initial stages to ensure that true representation is occurring.
The process of selecting ASO members was itself open. RIPE is a completely open group - you do not need to be a customer of the RIPE NCC to attend its meetings or take part in its working groups - and ARIN and APNIC are rapidly heading in that direction. Bear in mind that the Canadian member of the board was chosen has the representative for ARIN, the RR for America writ large, North and South.
To anyone who thinks that this method of decision doesn't work, or doesn't properly represent anyone, remember that this is the same method by which any progress has been made in the last ten years. A group of techies meet (IETF, RIPE, NANOG, whatever) representing their various companies, ISPs and customers, thrash out the issues of the day - IPv6 allocation, too many updates in the RIPE database, how to measure network performance between Amsterdam and New York - and walk away knowing what direction to proceed in.
The process is not the flawed democratic principle whereby an uninformed electorate is given a bad bunch of choices (picked by a mysterious process which the population at large has no control over) and asked to pick the one which the least people hate most. It is a process where anyone with a good idea can make a proposal, and anyone with a problem with that proposal can have their voice heard, and have it fixed. Or looking at the another way, "If you don't like this option, fine, but I'll want to hear some better ones please."
It's an open-source election, people. Please don't abandon it in favour of a trumped up slashdot poll.
Dave
--
I doubt this is as precedent-setting as it looks. It is a trademark issue rather than a domain name issue. I find it difficult to believe that the issue of trading under the same translated name has never occurred before. I just wish I had the legal experience to say whether it had.
A lot of people are expending a lot of energy and hype every time a new legal challenge comes up. They're making the same mistake as the censors - this can often be dealt with under existing legislation and precendent, and if not, it should be. Enacting new laws and setting new precendents for the same issue in every popuylar new medium is awkward and sloppy, and will not keep up.
Just like writing good code. Make no assumptions, and abstract as far as you can!
Dave
--
That's an entirely legitimate concern and I dare say (from my uninformed viewpoint) that it was one of the main bones of contention that made this compromise so hard to reach.
In the short term, the summar y fact sheet says that:
Hopefully this will be enough. It's not easy. NSI has the database and has been claiming for some time now that it owns it, period. It looks like ICANN has successfully coaxed them down from this position and is moving in the right direction.
Slowly, yes. But the right direction is unbelievably important. A head on clash between ICANN and NSI would drag in the root server operators, major ISPs, minor ISPs, every administrators' root.hints files, and - eventually - governments. One would not be able to ensure that legitimate domains would resolve. It would be ugly and disruptive, and would do the internet zero good. And worst of all, the eventual outcome is almost certain not to be the best one. Thank whatever powers you believe in that we've got compromise here, folks.
In the long term:
This gives NSI the carrot of an extended period as registrar if the separation of registry and registrar proceeds speedily. Again, a good one. It's been mentioned elsewhere on this forum that NSI at least has experience in running the root zone. I don't mind them leaving longer between reviews if that major bone of contention - separation of registry and registrar - is removed.
Dave
[As usual, my opinions, not necessarily those of my employer. And worse, they're based on a cursory reading of the agreement, and some pretty shaky opinions on the nature of the root...]
--
Nope, no problem. NSI is a commercial entity. Fair enough. ICANN is a nonprofit, advised in these matters by its Domain Name Supporting Organisation, made up of representatives of these groups.
The intention here is that ICANN plays the role of arbitrator. Much effort has gone into ensuring that ICANN is properly transparent and properly representative of the community on these matters.
Personally, I preferred it when Jon Postel ran the entire internet, but after countless green papers, white papers, and input from many, many interested parties, ICANN is set up to do a decent job of achieving consensus.
Dave
[My opinions, not necessarily those of my employer]
--
Depends on how you look at it. Which two parties are you worried about here? If it's NSI and some other registry - indeed, any two registries, then the group with the power to enforce its rulings is undoubtedly the group that allocated registry status in the first place - IANA or, these days, its successor.
If NSI (or anyone else) is arguing with the very people who ostensibly hold that authority, and is thus challenging that authority, well that's ugly, and doesn't have a simple answer.
Nay, nay and thrice nay. There remains one central database and, just like all the other zones in the world, one primary root server. Type dig . soa on a UNIX machine and you'll see from the SOA that the primary name server is A.ROOT-SERVERS.NET, run by - surprise - NSI.
The multiple root servers referred to in the document are, by my understanding, the ordinary secondary name servers for the root domain. DNS is neat like that, it allows you to spread the load for efficient bandwidth use, or CPU use, or reliability, or all three.
Same for the .COM, .NET and .ORG servers. Every domain registered in these TLDs must go through the operators of A.ROOT-SERVERS.NET. This is what the $9 charge is for. It is rather unfortunate that the operators of the primary server are themselves registering .COM domains, but there weren't no easy way out of that one, 'cos NSI was never gonna give up all its hard work (and revenue stream) that easily.
Dave
[My opinions, not necessarily those of my employer]
--
The GPS rollover didn't go so bad. We have a clock on the roof of our building using the GPS system as its time source; it was fine, and so were the other 40 or so like it around Europe.
Here in Ireland and around the U.K., there was one marine report of difficulties due to the rollover. Bad weather over that period, poor visibility and the failure of his GPS equipement all conspired to get him lost and he had to radio in. There were several other shipping problems over that weekend, but none due to the rollover.
Dave
--
Everyone is missing one vital point.
Linux has its place
Java was and is a great idea. Sun saw it for what it is. They marketed it, they put it out there, they tried to take over the world with it.
They got it an image problem when they stuck it into buggy browsers on slow machines, but that's a discussion for another time.
Linux didn't start out like that. Linux wasn't some germ of an idea that needed incubation and careful marketing. Linus didn't make deals with $large_software_company to include it with every copy of $popular_application. He coded it and stuck it out there.
And it stuck.
Guys, Linux has nothing to prove. The mindset is already there. The people who need to trust it most, trust it. We know when it can be used. We know when it can't. We can prove it.
Once we have that, we can work on the PHBs, and no dodgy benchmarks are going to change that.
This is not some ivory-tower dismissive. It's a reminder: in an industry awash with false promises and vapourware, Linux delivered long ago. It will remain as long as it is useful.
Dave
--
WIth an even more exciting methodology, the OS Sucks/Rules-o-meter uses highly refined mass survey techniques to survey the relative merits of different Operating Systems!
Translation: search Alta Vista for "Linux sucks", "Windows rules" etc., and graph the results.
Dave
--
Gene Spafford (co-author of the O'Reilly book on security, many seminal papers on Computer security, and minder of such tools as Tripwire - the man knows what he's talking about) had this to say some years ago on security challenges:
http://www.netsys.com/fire walls/firewalls-9511/0743.html
He lists so many good reasons (eight) to distrust this sort of challenge that it is difficult to summarise the message here. Best to click and read it yourself.
The point goes for every package where the author tries to "prove" security in this way - be it Sidewinder, Qmail or Microsoft. In many cases, the only result is to damage security by giving miscreants some "free time" to try and crack the system, for free, without fear of punishment.
Tiger teams have their place in a properly designed, properly managed security audit. Using unpaid tiger teams as the principal means is useless and dangerous. Will Microsoft move to assure its customers that this is simply a small part of a large, thorough security audit?
Dave--
Performing it straight on an interface shouldn't hurt too much - although I gotta admit, I've got no numbers to back me up here.
Matching per IP address is rather CPU intensive though, according to the documentation.
Dave
--
[These links are long. If they get broken, go to www.cisco.com and search for "Committed Access Rate".]
Some of the more interesting versions of the Cisco IOS (the 11.1CA and CC tree I think, and v12 if you're feeling brave) will perform incoming and outgoing traffic shaping. The closest to what you'd like is probably Committed Access Rate.
It can be applied directly to an interface to limit all IP traffic, or you can define an access list so that it will limit all traffic that matches a particular protocol, QOS flag... or your customer's IP subnet.
This last option is useful to limit a customer's access to the internet at large while still giving them full speed access to, say, your local mail or FTP server. You perform the limit on your connection to the rest of the world, using a different rate limit for each customer.
The v12.0 documentation is linked above, or check this CCO search.
Dave
--
Guys, a plea from someone who spends time at both ends of the postmaster address.
This sounds weird and useless when faced with an ISP that seems to be complicit in the abuse of your mailbox. But some ISPs, bless 'em, do still take this sort of thing seriously.
I make it a point to read, reply and act on every mail sent to postmaster@ or abuse@ my employer. It's thankfully a small trickle, since we don't do any kind of dialup. But it's sad to say that the important (technical) parts of these reports are often misdirected or swallowed up in threats of litigation or violence.
Think of it this way: every extra minute the abuse guy has to spend divining info from your report is one less minute he can spend fixing the problem between now and 5:00pm.
Know what headers you can trust
When making a technical report, make sure you get the facts right. Forwarding the spam to postmaster, abuse and domain-holder@every address in the spam will go to a lot of people who can't deal with the problem, which doesn't help anyone.
The only Received: header your can really trust is the one where it entered your systems. That'll usually have come from a dialup (sorted) or an open relay (messier). If it came from a relay, report it (see below) and by all means check the headers further down - but at least check them for sanity. They're often forged, and spammers are slowly learning just how many people get thrown off the scent by this.
The From: line can't be trusted at all. Forging it is trivial. And, of course, just 'cause someone says they're from Slashdot or AOL or Hotmail doesn't mean it's so. Concentrate on the network that really sent you the spam, not the one they say they are.
If there's a website mentioned in the spam (hint: if you see http://long-integer-address/, use "ping integer-address" to get it back into dotted-quad in a hurry) then traceroute and mail the upstream, but make it clear that you're reporting a site named in a mail abuse, not a host that spammed you. In other words: use a separate message.
Be polite!
You've heard this one before, but hell, it's worth iterating. It's amazing how refreshing it is to have a polite message from an obviously clueful individual land on your desk. Threats and foul language won't have spammers and spamlovers quaking in their boots, but it will give decent postmasters pause for thought before replying, and it will make the real evidence in your message harder to find.
And believe it or not, there are people out there who genuinely don't realise that their brand new UNIX machine came with a buggy sendmail. A bit of patience and cooperation works great with these people. Unpleasantness gets you blocked at the router.
I'll climb down off the soapbox now. Thanks for listening. I'm sure as hell not out to defend spammers or negligent ISPs. I don't think any of the above will help them. But I hate to see ISPs that do give a shit having to replace their Real Live Postmaster with a mailbot or clueless helpdesk just because the signal:noise ratio in reports has gone to hell.
Postmaster mail, like any RFC requirement, is binding by consensus only. Use it, early and often. Just please don't encourage its demise.
Dave
--
Jon,
You're quite right, blocking tools can be used to screen things one doesn't like, but that one really, really ought to be reading.
The problem isn't the software here. The problem is the closed minded individuals who've decided they don't want to read your column, or my comment, or Rob's Quickies.
Take a look at what's happened to Usenet, Jon. Back when it was 2 articles per day, all was fine. Then it kinda scaled out of control. The result is a medium that some swear by, but most - in my humble experience - just dismiss as unusable.
So what are we to do? I hate to see good, level headed moderation referred to as censorship. Censorship is an attack on free speech. Moderation is a defence against those who would destroy a forum.
Yeah, I know, there are bad moderators. And hell, they probably outnumber the good ones and all. What can you do. But Jon, much as I take your point, I fail to see an alternative. Please don't condemn us all to a network full of flamers and First Comment posters.
Cheers, Dave
--