<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
   <channel>
      <title>Renesys Blog</title>
      <link>http://www.renesys.com/blog/</link>
      <description></description>
      <language>en</language>
      <copyright>Copyright 2010</copyright>
      <lastBuildDate>Thu, 08 Jul 2010 07:00:00 -0500</lastBuildDate>
      <generator>http://www.sixapart.com/movabletype/?v=4.25</generator>
      <docs>http://blogs.law.harvard.edu/tech/rss</docs> 

      
      <item>
         <title>What happened to Sprint?</title>
         <description><![CDATA[<p>
As our regular readers know, 
Renesys computes daily rankings of all the service providers in the world: 
globally, by geography, and by market segment.  
The rankings are a rather crude measure of <em>size</em>, 
as they are based entirely on the quantity of IP space ultimately transited by each provider.
However, it's the ranking <em>trends</em> that are more revealing than any absolute number. Who is adding customers?  Who is losing them or just standing still?
All of the rankings and the reasons for any changes are updated daily and available via our 
<a href="http://www.renesys.com/products_services/market_intel/">Market Intelligence</a>
offering.
For the past couple of Decembers
(<a href="http://www.renesys.com/blog/2009/12/a-bakers-dozen-in-2009.shtml">2009</a>,
<a href="http://www.renesys.com/blog/2008/12/winners-and-losers-for-2008.shtml">2008</a>),
we've also provided a glimpse into some of this data via year-end blogs devoted to the top global providers.
Halfway through 2010,
we decided to revisit this topic and highlight some recent changes:
the fall of Sprint and rise of Tinet being perhaps the most interesting.
</p>]]></description>
         <link>http://www.renesys.com/blog/2010/07/what-happened-to-sprint.shtml</link>
         <guid>http://www.renesys.com/blog/2010/07/what-happened-to-sprint.shtml</guid>
         <category>Business</category>
         <pubDate>Thu, 08 Jul 2010 07:00:00 -0500</pubDate>
      </item>
      
      <item>
         <title>Two Strikes For the I-root</title>
         <description><![CDATA[<p>
Here we go again.
In March we wrote a blog entitled
<a href="http://www.renesys.com/blog/2010/03/fouling-the-global-nest.shtml">Accidentally Importing Censorship</a>
which described how incorrect DNS answers were returned in response to certain queries to the I-root.
The problem was tracked down to a single instance of the I-root located in China.
Queries to this server for domains blocked in China, such as Facebook,
would return seemingly arbitrary answers.
As we noted, countries, and even companies, 
can impose their own standards on the Internet and block anything they want.  
This story was only noteworthy because those blocks (via bad DNS answers) became
visible <em>outside of China</em>.
Well, guess what?
We are once again seeing the Beijing I-root from outside of China.
</p>]]></description>
         <link>http://www.renesys.com/blog/2010/06/two-strikes-i-root.shtml</link>
         <guid>http://www.renesys.com/blog/2010/06/two-strikes-i-root.shtml</guid>
         <category>Internet</category>
         <pubDate>Wed, 09 Jun 2010 15:04:04 -0500</pubDate>
      </item>
      
      <item>
         <title>IPv6: Are we there yet?</title>
         <description><![CDATA[<p>
For an advanced technology that we all depend upon,
it sure seems that the Internet has more than its fair share of problems:
spam, viruses, malware, spyware, phishing, worms, trojans, DDoS attacks, hijacks, DNS cache poisoning, botnets, keystroke loggers, etc.
We need an entirely new vocabulary just to talk about this stuff.
Most of it appears to come out of the blue,
forcing the rest of the world to react.
But the good news is that there is at least one problem we can do something about 
<em>in advance</em>.
Unfortunately, not everyone has been taking the problem seriously enough and we are 
about to <a href="http://en.wikipedia.org/wiki/Hitting_the_wall">hit the wall</a>.
</p>

<p>
I'm talking about the impending exhaustion of IP addresses, 
IPv4 addresses to be exact. 
Every computer on the Internet needs access to at least one unique address in order to be connected.
Around the dawn of the 
<a href="http://en.wikipedia.org/wiki/Internet">Internet</a>,
32-bit IPv4 addresses, 
which allow for 4,294,967,296 different possibilities,
seemed like more than enough.
This was a simpler time when computers cost millions and no one imagined a phone you could put in your pocket.
As the Internet grew,
it soon became obvious that the seemingly inexhaustible supply of 4 billion addresses wasn't quite enough.
And so, a 128-bit IPv6-based Internet was proposed, 
this one with 340,282,366,920,938,463,463,374,607,431,768,211,456 different addresses.
(We're not going to make that mistake again!)
The only problem was that the new Internet wasn't interoperable with the old one we already knew and loved.
Without a 
<a href="http://en.wikipedia.org/wiki/Y2K">Y2K-type</a> hard deadline to focus on,
we kept barreling along toward the edge of the IPv4 cliff.
Now that the edge is clearly in sight,
this blog looks at how far we have come in adopting the not-so-new-anymore IPv6 Internet and, perhaps more importantly,
how much further we need to go.
</p>]]></description>
         <link>http://www.renesys.com/blog/2010/04/ipv6-are-we-there-yet.shtml</link>
         <guid>http://www.renesys.com/blog/2010/04/ipv6-are-we-there-yet.shtml</guid>
         <category>Internet</category>
         <pubDate>Wed, 28 Apr 2010 05:00:00 -0500</pubDate>
      </item>
      
      <item>
         <title>How To Build A Cybernuke</title>
         <description><![CDATA[<p>The Internet infrastructure has been having a bad month.  Not as bad as, say, the world's <a href="http://www.bloomberg.com/apps/news?pid=newsarchive&sid=ar4Bv0kc8XgE">aviation infrastructure</a>, but bad enough.    </p>
<p>First, Chinese Internet censorship leaked out to a few massively unlucky users of the <a href="http://www.renesys.com/blog/2010/03/fouling-the-global-nest.shtml">I root server</a>.    Then China Telecom failed to filter someone who <a href="http://www.theregister.co.uk/2010/04/09/china_bgp_interweb_snafu">leaked thousands of hijacked routes</a> to other people's networks through them, probably by accident.</p>
<p> And then, inexplicably, Forbes went where no one had gone before (with a wink to <a href="http://www.wired.com/threatlevel/2010/03/cyber-hype/">Wired</a>), and asked whether China might actually be testing a "<a href="http://blogs.forbes.com/firewall/2010/04/09/is-china-testing-cybernukes/"><strong>cybernuke</strong></a>".</p>

<p>At first, this irritated me.   Journalists and bloggers and blogger-journalists are fanning the flames of US unease about the growing role of China in world affairs.   But then I realized that I could probably make tens of thousands of people read my blog, too, by jumping on the bandwagon.   By all means, then, grab an <a href="http://en.wikipedia.org/wiki/Meal,_Ready-to-Eat">MRE</a> and hunker down in your Internet bomb shelter while I try to answer some of the obvious questions that came our way in the wake of the Forbes article:</p>

<ul>
<li>How would anyone build a cybernuke?    What is that? 
<li>Could a single actor, state-sponsored or otherwise, actually take down the global or regional Internet infrastructure of 2010, disrupt financial markets, throw civilization into chaos?  
<li>How do I get my cybernuke movie screenplay optioned by <a href="http://www.hollywood.com/celebrity/195797/Jerry_Bruckheimer">Jerry Bruckheimer</a>?   His people won't return my calls.
</ul></p>]]></description>
         <link>http://www.renesys.com/blog/2010/04/how-to-build-a-cybernuke.shtml</link>
         <guid>http://www.renesys.com/blog/2010/04/how-to-build-a-cybernuke.shtml</guid>
         <category>Internet</category>
         <pubDate>Thu, 22 Apr 2010 05:30:00 -0500</pubDate>
      </item>
      
      <item>
         <title>Accidentally Importing Censorship</title>
         <description><![CDATA[<p>
With advancements in hardware and software,
sophisticated filtering technologies are increasingly being applied to restrict access to the Internet.
This happens at the level of both governments and corporations.
Renesys is headquartered in the 
<a href="http://en.wikipedia.org/wiki/Live_Free_or_Die">"Live Free or Die"</a> US state of 
New Hampshire.
In our 
<a href="http://en.wikipedia.org/wiki/Hanover,_New_Hampshire"</a>small town of roughly 10,000 folks,
we know of a local company who tries to restrict <em>non-work related</em> (e.g., shopping) websites from their employees.  
Unfortunately, someone who works there can't read about Amazon's cloud computing as a result &mdash; a small bit of collateral damage.
Entire countries act in much the same way.
The <a href="http://map.opennet.net/">OpenNet Initiative</a> keeps track of such state-sponsored restrictions and publishes interesting maps based on the level of filtering by topic.
But given the open nature of the trust-based Internet,
one country's restrictions, if not handled very carefully, 
can easily foul the global Internet nest we all live in.
This blog is about one such story of Internet restrictions in China becoming visible (seemingly at random) from other parts of the world and <b>going undetected for 3 weeks</b>.
Given the increasing complexity of this technology, 
the difficulty in controlling a very open Internet, 
and the strong desire of some to do just that,
this could be a harbinger of things to come.
</p>]]></description>
         <link>http://www.renesys.com/blog/2010/03/fouling-the-global-nest.shtml</link>
         <guid>http://www.renesys.com/blog/2010/03/fouling-the-global-nest.shtml</guid>
         <category>Internet</category>
         <pubDate>Tue, 30 Mar 2010 16:00:00 -0500</pubDate>
      </item>
      
      <item>
         <title>The Geopolitics of Iranian Connectivity</title>
         <description><![CDATA[
As Iran celebrates the anniversary of the 1979 Islamic Revolution, it seems like an opportune time to look in on the evolving state of their Internet connectivity.   When we last looked, after the <a href="http://www.renesys.com/blog/2009/06/strange-changes-in-iranian-int.shtml">disputed elections in June 2009</a>, the picture was one of uneasy stability: logically diverse but physically constrained transit via the United Arab Emirates, backup transit via Turkey.   Today, a third way out of the bottle is visible in the routing table: <em>substantial amounts of Internet transit have materialized through a Russian provider.</em>  And there, in those obscure entries in the global Internet routing table, may lie echoes of Iran's larger geopolitical strategy.  <p>]]></description>
         <link>http://www.renesys.com/blog/2010/02/irans-internet-the-geopolitics.shtml</link>
         <guid>http://www.renesys.com/blog/2010/02/irans-internet-the-geopolitics.shtml</guid>
         <category>Internet</category>
         <pubDate>Thu, 11 Feb 2010 07:59:18 -0500</pubDate>
      </item>
      
      <item>
         <title>Much Ado About Baidu</title>
         <description><![CDATA[<p>
As our faithful readers know,
Renesys monitors routing on the global Internet in real time and uses that information in a variety of ways.
For example, we can instantly let you know which networks a 
<a href="http://www.renesys.com/blog/2008/09/ike-brings-biggest-multistate.shtml">hurricane</a> has disabled or even
tell you when a 
<a href="http://www.renesys.com/blog/2008/08/georgia-clings-to-the-net.shtml">war</a> has left things pretty much as they were.
In short, we keep an eye on the Internet, the entire Internet,
but this is all done at the level of IP addresses and the paths they follow.
</p>

<p>
The recent 
<a href="http://www.theregister.co.uk/2009/12/18/dns_twitter_hijack/">attack</a> on Twitter got us thinking.   
Maybe we should be keeping an eye on a few more things?
While your IP addresses and routes to them might be completely stable, 
the average user doesn't know about those.
In other words, when was the last time you typed ...
<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://216.239.59.104">http://216.239.59.104</a>
<br>
instead of ...
<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://www.google.com">http://www.google.com</a>
<br>
into your browser?
</p>

<p>
What if someone manages to point your domain name to some other IP addresses?
You would still be operational as far as the Internet routers were concerned,
but no humans would probably be reaching you. 
And that's the problem we'll briefly consider in this blog.
</p>
]]></description>
         <link>http://www.renesys.com/blog/2010/01/baidu.shtml</link>
         <guid>http://www.renesys.com/blog/2010/01/baidu.shtml</guid>
         <category>Security</category>
         <pubDate>Wed, 13 Jan 2010 05:58:00 -0500</pubDate>
      </item>
      
      <item>
         <title>A Baker&apos;s Dozen in 2009</title>
         <description><![CDATA[<p>
As our regular readers know, 
Renesys collects a lot of Internet routing data,
using it to create reports and products based on hard facts and objective analysis.
Perhaps the only controversial thing we do with our data is to <em>rank</em> all the service providers in the world: globally, by geography, and by market segment.  
The rankings are a rather crude measure of <em>size</em>, 
as they are based entirely on the quantity of IP space ultimately transited by each provider.
However, it's the ranking <em>trends</em> that are more revealing than any absolute number. Who is adding customers?  Who is losing them or just standing still?
Changes in IP transit answer these questions and more.
Although there are obvious shortcomings in this approach, 
it is certainly objective and the process is fully automated.
All of our rankings are updated daily and available via our 
<a href="http://www.renesys.com/products_services/market_intel/">Market Intelligence</a>
offering.
In this posting,
we will take a look at the top 13 providers in the world for 2009 and
how they have jockeyed for position throughout the year,
similar in spirit to our 
<a href="http://www.renesys.com/blog/2008/12/winners-and-losers-for-2008.shtml">December 2008 blog,</a>
which provides more details about our methodology.
We will see what a difference a year has made and highlight some of the more interesting changes.
</p>
]]></description>
         <link>http://www.renesys.com/blog/2009/12/a-bakers-dozen-in-2009.shtml</link>
         <guid>http://www.renesys.com/blog/2009/12/a-bakers-dozen-in-2009.shtml</guid>
         <category>Business</category>
         <pubDate>Thu, 31 Dec 2009 23:59:59 -0500</pubDate>
      </item>
      
      <item>
         <title>Bonjour, Y&apos;all! ASN Split Personalities</title>
         <description><![CDATA[<p>Remember when the telephone company came to your house to hook up your phone and gave you a new phone number? This new number was how your friends and family were going to contact you. You counted on the telephone company to ensure that someone hadn't already been issued that number, because if they had, various problems would ensue. What would happen when your mom tried to call your number if it was also assigned to someone else? Could you directly call the other party to work out the problem? Well, in the <a href="http://en.wikipedia.org/wiki/Bgp">BGP</a> realm, something similar has been happening with <a href="http://en.wikipedia.org/wiki/Autonomous_system_%28Internet%29">autonomous system</a> numbers (ASNs).</p>

<p>Organizations need an ASN to run BGP and route on the Internet. They are each assigned globally unique ASN(s) by their local <a href="http://en.wikipedia.org/wiki/Regional_Internet_registry">Regional Internet Registry (RIR)</a>, who get them from <a href="http://www.iana.org/">IANA</a>. A few weeks ago, the <a href="http://nanog.org/">NANOG </a>folks <a href="http://mailman.nanog.org/pipermail/nanog/2009-November/015433.html">noticed </a>that AS1712 had been registered by two different organizations (in France and Texas) that were both using the number to announce their separate <a href="http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing">network prefixes</a>. ARIN issued a <a href="http://mailman.nanog.org/pipermail/nanog/2009-November/015498.html">statement </a>conveying that they were aware of the problem and were working to resolve it. We took a look at the data and found that AS1712 isn't the only dually-assigned ASN out there. In fact, even a root server didn't escape unscathed.</p>]]></description>
         <link>http://www.renesys.com/blog/2009/12/bonjour-yall-asn-split-persona.shtml</link>
         <guid>http://www.renesys.com/blog/2009/12/bonjour-yall-asn-split-persona.shtml</guid>
         <category>Internet</category>
         <pubDate>Tue, 08 Dec 2009 20:59:42 -0500</pubDate>
      </item>
      
      <item>
         <title>IP Backbone: Hard sell, not so much</title>
         <description><![CDATA[<span class="mt-enclosure mt-enclosure-image" style="display: inline;"><a href="http://www.renesys.com/blog/assets_c/2009/11/Kuala_Window-65.shtml" onclick="window.open('http://www.renesys.com/blog/assets_c/2009/11/Kuala_Window-65.shtml','popup','width=450,height=582,scrollbars=no,resizable=no,toolbar=no,directories=no,location=no,menubar=no,status=no,left=0,top=0'); return false"><img src="http://www.renesys.com/blog/assets_c/2009/11/Kuala_Window-thumb-300x388-65.gif" width="200" height="259" alt="Kuala_Window.gif" class="mt-image-right" style="float: right; margin: 0 0 20px 20px;" /></a></span>

<p>Think you're too busy to blog? Think again. Or just ask your boss. After more than 100,000 miles in coach class this year (so far), my backbone may be aching, but the IP backbone market is as agile and dynamic as ever. Sales opportunities abound, but to take advantage, you'd better be savvy, and just a little cagey.</p>

<p>So, as our gleaming 777 departs Kuala Lumpur, I'll just relax in my fully-reclined, ultra-deluxe coach seat and tell you what this globetrotting sales guy has seen, heard and figured out. </p>


<strong>Two new trends<br></strong>
As if the global financial crisis weren't enough, beleaguered NSPs have to rejigger their business plans (yet again) to accommodate encroachment from brazen usurpers and ever more competitive pricing:<p>

<ol>
	<li>Large eyeball networks (5 million+ subscribers) are selling paid peering to the largest content providers. </li>
	<li>There are big price reductions in IP transit all over eastern Europe - now close to parity with western Europe. </li>
</ol>]]></description>
         <link>http://www.renesys.com/blog/2009/11/ip-backbone-hard-sell-not-so-m.shtml</link>
         <guid>http://www.renesys.com/blog/2009/11/ip-backbone-hard-sell-not-so-m.shtml</guid>
         <category>Business</category>
         <pubDate>Fri, 20 Nov 2009 15:14:55 -0500</pubDate>
      </item>
      
      <item>
         <title>Lights Out in Rio</title>
         <description><![CDATA[When the <a href="http://www.bloomberg.com/apps/news?pid=20601087&sid=a5IwDD5qXbkk&pos=8">power goes out</a> to a large part of Brazil, <a href="http://online.wsj.com/article/SB125790382947542827.html?mod=WSJ_hpp_sections_world">as happened last night shortly after 10pm, </a>it's going to have an impact on telecommunications.]]></description>
         <link>http://www.renesys.com/blog/2009/11/lights-out-in-rio.shtml</link>
         <guid>http://www.renesys.com/blog/2009/11/lights-out-in-rio.shtml</guid>
         <category>Security</category>
         <pubDate>Wed, 11 Nov 2009 01:43:25 -0500</pubDate>
      </item>
      
      <item>
         <title>Staring Into The Gorge: Router Exploits</title>
         <description><![CDATA[<p><span class="mt-enclosure mt-enclosure-image" style="display: inline;"><a href="http://www.renesys.com/blog/assets_c/2009/08/gorge-20.shtml" onclick="window.open('http://www.renesys.com/blog/assets_c/2009/08/gorge-20.shtml','popup','width=300,height=400,scrollbars=no,resizable=no,toolbar=no,directories=no,location=no,menubar=no,status=no,left=0,top=0'); return false"><img src="http://www.renesys.com/blog/assets_c/2009/08/gorge-thumb-600x800-20.jpg" width="150" height="200" alt="gorge.jpg" class="mt-image-right" style="float: right; margin: 0 0 20px 20px;" /></a></span><i>I'm writing this blog entry from the campground at <a href="http://en.wikipedia.org/wiki/Quechee,_Vermont">Vermont's beautiful Quechee Gorge</a>, where I took the kids after work.  <strong>Yes,</strong> Renesys is located smack in the middle of some of the nicest hiking, camping, and climbing on earth.  <strong>No,</strong> you shouldn't move here, Northern New England has enough out-of-staters already, thanks.  <strong>Unless, </strong>that is, you are an unusually talented web developer, have worked as a peering coordinator, or know the Internet transit industry inside-out, in which case you should <a href="http://renesys.com/about/careers.shtml">send me your CV</a>, posthaste.  thanks,  --jim</i></p>

<br/><hr/><br/><br/>
<p><strong>Here We Go Again.</strong></p>
<p> Imagine an innocent BGP message, sent from a random small network service provider's border router somewhere in the world.  It contains a payload that is unusual, but strictly speaking, conformant to protocol.  Most of the routers in the world, when faced with such a message, pass it along.  But a few have a bug that makes them drop sessions abruptly and reopen them, flooding their neighbors with full-table session resets every time they hear the offending message.   The miracle of global BGP ensures that<em> every vulnerable router on earth </em>gets a peek at the offending message in under 30 seconds.  The global routing infrastructure rings like a bell, as BGP update rates spike by orders of magnitude in the blink of an eye.  Links congest. Small routing hardware falls over and dies.  It takes hours for things to return to normal.</p>]]></description>
         <link>http://www.renesys.com/blog/2009/08/staring-into-the-gorge.shtml</link>
         <guid>http://www.renesys.com/blog/2009/08/staring-into-the-gorge.shtml</guid>
         <category>Engineering</category>
         <pubDate>Wed, 19 Aug 2009 05:32:31 -0500</pubDate>
      </item>
      
      <item>
         <title>Routing Redundancy: How much is enough?</title>
         <description><![CDATA[<p>
Internet connectivity is a good thing.  
Many of us depend on it for everything from our livelihoods to our entertainment.  
However, the Internet is very fragile and even the 
<a href="http://www.nytimes.com/2009/08/04/business/04road.html?_r=2&partner=rss&emc=rss">
The New York Times</a> is worried about it.  
But they're primarily concerned with overloads that can occur when everyone on the 
planet does the same thing at roughly the same time, 
such as surfing for news about <a href="http://edition.cnn.com/2009/TECH/06/26/michael.jackson.internet/">Michael Jackson</a>.  
Unfortunately, we will never avoid all such scenarios.
Physical systems are designed around average and typical peak loads, 
not around extremely high loads associated with very unlikely events.  
Who would pay for that?
</p>

<p>
And this applies to other complex systems besides the Internet.  
I was in India during <a href="http://en.wikipedia.org/wiki/9/11">9/11</a> and, 
for two days, 
I could not make a traditional phone call to the US.  Why?  
Everyone in India knows <em>someone</em> in NYC, 
and they all picked up the phone at the same time to check in on them.  
The circuits were so overloaded, 
I couldn't even get the friendly "Your call cannot be completed as dialed" message.
</p>

<p>
No system is ever going to be engineered for insanely high loads.  
If everyone in your town decides to take a shortcut through your
neighborhood to avoid an accident on the highway, 
you are going to have trouble getting out of your driveway.  
But rather than give up and wait it out, 
there is something you can do <em>in advance</em> and at
reasonable cost:
build a second driveway to a different street on the
other side of your house, one that isn't fed by the same access roads
from the highway.  
This blog is about building such redundancy into your
Internet connectivity, 
so you aren't disconnected by a single failure.
And while it's good that the New York Times and various governments are watching the problem, 
if your business depends on the Internet, 
you're largely on your own to audit and verify that you are buying a sufficient level of redundancy for your budget. 
A lot of fragility problems could be solved by more informed consumers performing the necessary due diligence.
</p>
]]></description>
         <link>http://www.renesys.com/blog/2009/08/internet-diversity.shtml</link>
         <guid>http://www.renesys.com/blog/2009/08/internet-diversity.shtml</guid>
         <category>Internet</category>
         <pubDate>Sat, 15 Aug 2009 12:17:30 -0500</pubDate>
      </item>
      
      <item>
         <title>The Proxy Fight for Iranian Democracy</title>
         <description><![CDATA[<p>If you put 65 million people in a locked room, they're going to find all the exits pretty quickly, and maybe make a few of their own.  In the case of Iran's <a href="http://www.renesys.com/blog/2009/06/iran-and-the-internet-uneasy-s.shtml">crippled-but-still-connected Internet,</a> that means finding a continuous supply of <a href="http://en.wikipedia.org/wiki/Squid_cache"><strong>proxy servers</strong></a> that allow continued access to unfiltered international web content like Twitter, Gmail, and the BBC. </p>]]></description>
         <link>http://www.renesys.com/blog/2009/06/the-proxy-fight-for-iranian-de.shtml</link>
         <guid>http://www.renesys.com/blog/2009/06/the-proxy-fight-for-iranian-de.shtml</guid>
         <category>Internet</category>
         <pubDate>Mon, 22 Jun 2009 06:30:00 -0500</pubDate>
      </item>
      
      <item>
         <title>Iran and the Internet: Uneasy Standoff</title>
         <description><![CDATA[
<p>We've received enough interest about our <a href="http://www.renesys.com/blog/2009/06/strange-changes-in-iranian-int.shtml">previous notes on Iranian Internet connectivity</a> that I wanted to give a brief update, and some reflections.</p>]]></description>
         <link>http://www.renesys.com/blog/2009/06/iran-and-the-internet-uneasy-s.shtml</link>
         <guid>http://www.renesys.com/blog/2009/06/iran-and-the-internet-uneasy-s.shtml</guid>
         <category>Internet</category>
         <pubDate>Tue, 16 Jun 2009 16:21:25 -0500</pubDate>
      </item>
      
   </channel>
</rss>