- KICTANet - KICTANet

kictanet] Day 5 - Statistics on Affordability - CCKInternetStudyReport
by bitange＠jambo.co.ke 04 May '07

04 May '07

Dear All, I think you are getting it wrong on the World Bank Loan. The purpose of the loan is to stimulate demand a head of cheap bandwidth from the fibre cable. Areas that we thought needed stimulation include Rural ICT Centres, the Government, Universities and Colleges and BPOs. The procurement of subsidized bandwidth is to be done openely where all operators would have a chance. This does not in anyway compromise any private sector because they would be paid the market rate of bandwidth. The participation of Government in construction of Terrestrial fibre networks and the undersea cable was to fast track availability of cheap bandwidth that would in turn help the economy to grow faster. Secondly, we needed an open access model that would help SMEs in this country to compete with the big boys. With this network we shall see SMEs competing with the likes of Jamii, KDN on an equal footing. Thirdly, the private sector had failed to provide necessary infrastructure for economic development and finaly no operator was interested in rural Kenya until the Government made the business case for rural ICTs. In any case the Government has no interest in competing with the private sector. Our role is to facilitate development. Infrastructure in the ICT sector had lagged behind and what we have done is simply to facilitate its development and leave the private sector to compete in an open access platform. We have the obligation to enable every Kenyan citizen to play a role in economic development especially our SMEs that consititute 95% of businesses in this country. Therefore, there is absolutely nothing wrong with borrowing from the WB to stimulate demand for the investment we are making in the ICT sector. Some of the funds will be used to develop capacity to utilize ICTs and development of local content. In essense we are stimulating demand that would become consumers of private sector products. Regards Bitange Ndemo. ---------------------------------------------- This message has been scanned for viruses and dangerous content by Jambo MailScanner, and is believed to be clean. --------------------------------------------- "easy access to the world"

1 0

Statistics on Affordability - CCK InternetStudy Report
by Mr President 03 May '07

03 May '07

Hi AllMy take on the affordability of the internet is basically simpleHow many rural home have electricityHow many have telephone linesHow many rural towns have cybers that earn an incom solely form internet services ?That is the basics, go to secondary issues like priorities for income usage??To buy food, kerosene etc or surf ?Taking I.T to the rural areas should be unde r the universal coverage policy and not for profit unless for value added services ama??Njenga M.P those who fear to fail.will never try to succeded,for to fail to plan is to plan to FAIL _______________________________________________ No banners. No pop-ups. No kidding. Make My Way your home on the Web - http://www.myway.com

1 0

Re: [kictanet] Listserver problem
by John Walubengo 03 May '07

03 May '07

Dear Listers, I must admit and apologise that we are experiencing some technical hitches on the listserver but the engineers are working around the clock to resolve the issue. Plse continue with your contributions since they are getting logged onto the central servers and will be re-played once the technical hitches are resolved. I would also add that in light of this development, the remaining two themes will taken early next week but this also gives us more time to dwell on the affordability issues... walu. >>> "Bill Kagai" <mediacorp.research(a)mediacorp.co.ke> 05/03/07 12:16PM >>> On 5/3/07, Eric Osiakwan <eric(a)afrispa.org> wrote: > > > The danger in allowing everybody to do everything is; > 1. enumorse duplication of investment in the highend of the market > ????? Nini hii??

1 0

Technical Glitches
by Alex Gakuru 03 May '07

03 May '07

I have not received any of the messages attached and I had to dig the kictanet archives to view them. This is about my fourth time to complain about my messages being affected by this glitch. One feels it would be good practice for the technicians responsible to ensure online freedom of information while we collectively front advocacy for the same from government. Should the continued glitches affect only some subscribers, then there would be good grounds to seek alternative kictanet list hosting server, just like we had kiplist in Canada then for fear of government censorship. A thorough reply would be appreciated Regards Alex --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos.

2 1

test 20070502 12.35p.m EAT - ignore
by John Walubengo 03 May '07

03 May '07

testing. walu. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

6 7

ICT BILL & PUBLIC CONFIDENCE
by Wainaina Mungai 03 May '07

03 May '07

ICT BILL WILL IMPROVE PUBLIC CONFIDENCE IN TECHNOLOGY Source: http://www.madeinkenya.org/forum_files/forum0507.php A few weeks ago, many Kenyans were amazed to hear that Police had tracked down Matheri, the most wanted criminal in Kenya, by monitoring his mobile phone. This news led many to ask if they were also being watched and if someone was reading their SMS messages and keeping track of their movements. --- Wainaina Mungai http://www.madeinkenya.org SUSTAINABLE DEVELOPMENT is development that meets the needs of the present without compromising the ability of future generations to meet their own needs.

1 0

in case of interest.. IP , rootservers, et al
by Rebecca Wanjiku 03 May '07

03 May '07

just in case you have been wondering about the whole jargon of IP, TLD, ccTLD and stuff, here is a simplified version.. its long but makes good reading.... bex The Internet Protocol Journal - Volume 10, No. 1 Geographic Implications of DNS Infrastructure Distribution by Steve Gibbard, Packet Clearing House The past several years have seen significant efforts to keep local Internet communications local in places far from the well-connected core of the Internet. Although considerable work remains to be done, Internet traffic now stays local in many places where it once would have traveled to other continents, lowering costs while improving performance and reliability. Data sent directly between users in those areas no longer leaves the region. Applications and services have become more localized as well, not only lowering costs but keeping those services available at times when the region's connectivity to the outside world has been disrupted. I discussed the need for localization in a previous paper, "Internet Mini-Cores: Local connectivity in the Internet's spur regions." [1] What follows here is a more specific look at a particular application, the Domain Name System (DNS). Most Internet applications depend on the DNS, which maps human-readable domain names to the Internet Protocol (IP) addresses computers understand. Two Internet hosts may have connectivity to each other but be unable to communicate because no DNS server can be reached. This article examines the placement of DNS servers for root and top-level domains and the implications of that placement on the reliability of the services these servers provide in different parts of the world. It is not a "how-to" guide to the construction of DNS infrastructure and does not contain recommendations on DNS policy; it is rather a look at the placement of DNS infrastructure as currently constructed. Although it is possible to access Internet resources without the DNS by entering numeric IP addresses directly, this type of access is not generally done. IP addresses, such as 209.131.36.158, are difficult to remember, are generally unpublished outside the DNS, and often change without notice. Local caching of DNS information can mask temporary problems with DNS data for commonly accessed domain names, but caches are emptied when caching resolvers are restarted, data in caches expires, and nothing is cached until the first time it is accessed by a local user. It should be noted that information about DNS deployment is changing rapidly. Several organizations are working on new DNS deployment. Information in this article can be considered current, to the best of my knowledge, as of May 2006. DNS Hierarchy The DNS is a hierarchy of domains within domains. The levels of the hierarchy are separated by dots. At the top of the hierarchy is the root, usually invisible but sometimes represented as a trailing dot. Using www.yahoo.com as an example, the com domain is contained within the root. Com contains yahoo, and yahoo contains www. Domains in the position com takes in this example are known as Top-Level Domains, or TLDs; they are the first level in the root domain. Domains in the position of yahoo are known as Second-Level Domains. In this example, www occupies the third level, and so forth. The information that makes up the Domain Name System is stored on DNS servers. That information is divided into zones, which for our purposes are synonymous with domains. Each zone is stored on a set of authoritative servers, which are queried when users or applications attempt to access a service on the Internet. In the simplest case, a domain name query works like the following: A caching resolver (so named because it caches information it receives) that has not yet cached any DNS zone data receives a query for www.yahoo.com. Because its cache is empty, it uses the hints distributed with the DNS software to contact one of the root servers and asks, "Where is www.yahoo.com?" The root server replies with a list of servers for .com. The caching server then asks one of the .com servers, "Where is www.yahoo.com?" and gets a response that directs it to servers for yahoo.com. It asks the same question of those servers and finally gets an answer to the question it was asking. Generally several servers can answer questions about any domain, but if all the servers for any single level are broken or unreachable, the query fails and the service the user is looking for is unreachable. It is therefore important that the DNS be reliable, and that the servers for each zone throughout the hierarchy be reachable from anywhere the servers they point at are being used. Root Servers Without root servers, none of the DNS works. As of this writing, 117 root servers exist worldwide, operated by 12 different organ-izations. [2] Root servers are added frequently, so the number may be significantly greater by the time this article is in circulation. Because of protocol limitations, the root servers can use only 13 IP addresses. Each root-server operator is responsible for one or two of those addresses. Using a technique called anycast, which allows servers in separate locations to share a single IP address, six of those operators operate multiple servers using the same IP address [3], meaning that only 13 of them are visible at the same time from any single location, but those 13 should in most cases include the topologically closest one. [4] The distribution of root servers is rather uneven. North America and Europe have similar numbers: 38 in North America and 35 in Europe. The 35 in Europe are distributed fairly evenly, with the largest concentrations (four each) in London and Amsterdam, Europe's two largest Internet hubs. North America has 8 in Washington, D.C., 8 in the San Francisco Bay Area, and 5 in Los Angeles. In the United States, all cities that host root servers are on the coasts except Atlanta and Chicago. All seven of the remaining IP addresses represented by only a single server, known as unicast roots, are in the Washington, D.C., San Francisco, and Los Angeles areas. Australia has two root servers in Brisbane, one in Perth, and one in Sydney. New Zealand has two, one in Wellington and one in Auckland. Singapore and the wealthier parts of East Asia are well-covered, and there are two root servers in Jakarta and one each in Bangkok and Kuala Lumpur. A year ago, there were none in the vast expanse between Bangkok and Dubai, but three have recently been added in India, along with others in Dhaka and Karachi. Mainland China and the former USSR each have two. There are three in Africa: two in Johannesburg and one in Nairobi. Another will be installed in Nairobi shortly, but most of the rest of Africa lacks direct connectivity to Johannesburg or Nairobi and must cross satellite or intercontinental fiber links to reach the nearest root servers. All four of the root servers in South America are in Brazil and Chile, with two in Sao Paulo and one each in Brasilia and Santiago de Chile. With some exceptions, root-server density tends to correlate strongly with per-capita income. This fact is not surprising—it is true for other forms of infrastructure as well—but it means that those with the greatest dependence on external infrastructure are those least able to pay for external connectivity. Root-Server Placement In areas that have local root servers, finding the name servers for a top-level domain should be fairly reliable. In areas without local root servers, the ability to query the root servers is dependent on other long-distance infrastructure. In some places this infrastructure is well-developed, so this problem is not a significant one. Elsewhere long-distance infrastructure is slow, expensive, and unreliable, consisting of satellite links or a single fiber connection that may take several days to fix if it breaks. Sri Lanka, for example, is connected to the rest of the world by a single fiber connection, which was cut in 2004 by a ship that dragged anchor in the Colombo harbor. [5] Although Sri Lanka has an exchange point that should have allowed connectivity to local Internet services, news reports said that Sri Lanka's "Internet and long-distance phone service" had been cut off. I have not received a good account of what Internet connectivity looked like from anyone in Sri Lanka at the time, but it is likely that even local Internet connections would not have worked without a local root server. Sri Lanka is not an isolated case. The dots in Figure 1 show the locations of all root servers. The light grey areas are regions in which multiple fiber paths are available to root servers. The remainder of the world can reach root servers only by a single fiber path or by satellite. Large areas of the world are poorly covered. Figure 1: Root Server Locations and Areas of Redundant Connectivity Root-Server Expansion Four of the 12 root-server operators are presently working to install root servers in areas that lack them. Although the 117 root servers currently in operation are a big improvement over the 13 that were in operation three years ago, many regions still do not have any. Those root-server operators are installing servers wherever they can get the funding to do so. Funding is generally provided either by grants, especially from the Asia Pacific Network Information Centre (APNIC) in the Asia-Pacific region, by local governments or Internet Service Provider (ISP) associations. Because the addition of new anycast copies of root servers is relatively easy given sufficient funding, the main limitation preventing the installation of root servers in new locations is lack of funding. One question probably best addressed in a more central manner is whether it makes sense to have many copies of one or two root-server IP addresses in some regions or whether it would be better to have more of a mix of root-server IP addresses. Currently, only 6 of the 13 root-server addresses are anycasted, only 4 are anycasted in large numbers, and 2 of those focus on specific regions, meaning that in many of the more remote parts of the world the only nearby root servers are Internet Systems Consortium (ISC)'s "F" and Autonomica's "I" roots, and some places have several of one of those closer than the next one of the other. Because some DNS resolvers have their own mechanisms for finding the closest server and for handling failures of types that do not include route withdrawals, having multiple IP addresses nearby seems like a good thing. A more complex question is whether it would be worthwhile to anycast all 13 of them widely, or if there is some smaller number that would be sufficient to have nearby. Previous research on this topic has assumed a limit of 13 root servers, producing conclusions that are not applicable to the modern Internet. [6] This article should not be seen as a criticism of the places with large numbers of root servers. Although the U.S. distribution looks strange, with the San Francisco Bay and D.C. area clusters perhaps excessive, it comes close to following the Internet topology in the United States. Indeed, the U.S. concentration may be appropriate to handle server load. Western Europe's dense but relatively even distribution of root servers through the region appears to be an optimal distribution, because most populated areas have multiple root servers nearby. Likewise, Jakarta is one of the very few cities in the developing world to have more than one, and that provides local redundancy that much of the developing world lacks. If root-server deployment were funded from a single global budget, the distribution across the world's regions would look very unfair. But because Internet infrastructure is mostly funded locally, Jakarta and Western Europe are examples other regions could emulate. TLD Distribution Use of the DNS also requires access to TLD servers. To access something in the .com domain, a user's local DNS resolver must be able to reach the .com servers. This statement is true for any TLD, whether it is a generic TLD (gTLD), such as .com, .net, and .org, or a country code TLD (ccTLD). Unlike the root, it is not necessary that all TLDs be reliable from all locations; if a TLD is not used to name local resources in a region, having local access to that TLD will not help if that the region gets cut off from the rest of the world. gTLD Distribution Of the gTLDs, .com is by far the largest. It is well-connected to the Internet core, the area with well-meshed internal connectivity mainly comprising North America, Western Europe, East Asia, and Singapore. (See Figure 2.) The .com servers are located in Australia, Brazil, Japan, South Korea, the Netherlands, Sweden, the United Kingdom, and the U.S. states of California, Florida, Georgia, Virginia, and Washington. The .com servers are well-connected to areas well-connected to those regions but poorly connected to Africa, South Asia, and parts of South America. Figure 2: Server Locations for .com and .net and Areas of Redundant Connectivity UltraDNS, the operator of .org, .info, .mobi, and .coop among others, is also somewhat well-connected to the Internet core, although not to the extent the .com servers are. It has publicly accessible servers in four metropolitan areas in the United States as well as in London and Hong Kong. It has a couple of noncore locations, in Delhi and Johannesburg. UltraDNS also has servers in other locations, accessible only to the resolvers of certain large ISPs. Because those servers are not available to the general public in their regions, they are omitted from discussion here. (See Figure 3.) Figure 3: Server Locations for .org, .info, and .mobi and Areas of Redundant Connectivity Other gTLDs do not do considerably better. Table 1 shows the locations of all the gTLDs. Table 1: Locations of TLD Servers gTLD Locations by Country or U.S. State .aero Switzerland, Germany, India, Hong Kong, United Kingdom, and the following states in the United States: California, Illinois, and Virginia .biz Australia, Hong Kong, Netherlands, New Zealand, Singapore, United Kingdom, and the following states in the United States: California, Florida, Georgia, New York, Virginia, and Washington .com Australia, Brazil, Canada, Japan, South Korea, Netherlands, Sweden, Singapore, United Kingdom, and the following states in the United States: California, Florida, Georgia, Virginia, and Washington .coop United Kingdom and the following states in the United States: California, Illinois, and Massachusetts .edu Netherlands, Singapore, and the following states in the United States: California, Florida, Georgia, and Virginia .gov Canada, Germany, and the following states in the United States: California, Florida, New Jersey, Pennsylvania, and Texas .info India, Hong Kong, South Africa, United Kingdom, and the following states in the United States: California, Illinois, and Virginia .int Netherlands, United Kingdom, and California in the United States .jobs Netherlands, Singapore, and the following states in the United States: California, Florida, Georgia, and Virginia .mil The following states in the United States: California, Maryland, Virginia, and other unknown locations .mobi India, Hong Kong, South Africa, United Kingdom, and the following states in the United States: California, Illinois, and Virginia .museum Sweden and California in the United States .name Singapore, United Kingdom, and the following states in the United States: California, Florida, Georgia, Virginia, and Washington .net Australia, Brazil, Canada, Japan, South Korea, Netherlands, Sweden, Singapore, United Kingdom, and the following states in the United States: California, Florida, Georgia, Virginia, and Washington .org India, Hong Kong, South Africa, United Kingdom, and the following states in the United States: California, Illinois, and Virginia .pro Canada and the following states in the United States: Illinois and Texas .travel Australia, Hong Kong, Netherlands, New Zealand, Singapore, United Kingdom, and the following states in the United States: California, Florida, Georgia, New York, Virginia, and Washington Although gTLDs are typically marketed for their applicability to specific types of organization, or in the case of .com because it is the only domain many people have heard of, geography should also be considered in selecting domains. Most of the gTLDs have reasonable coverage throughout the Internet core region, but there are exceptions. The .int and .museum domains are hosted only in North America and Europe, and .pro is hosted only in North America. Outside the Internet core there is little gTLD presence. Only .biz, .travel, .com, and .net are present in Australia and New Zealand. South Africa and India have .aero, .info, .mobi, and .org, making them the only gTLDs hosted in either Africa or the South Asian region. South America hosts only .com and .net, with servers in two cities in Brazil. Taken together, these are the only Southern Hemisphere gTLD locations as of this writing, and no gTLD has any presence in parts of the world without external fiber-optic connectivity, although that may be changing. Where gTLDs should be hosted, and with what scope, are somewhat open questions. Should these domains address resources anywhere, or should their scope be local? This question is really one for the Internet Corporation for Assigned Names and Numbers (ICANN), or for the gTLD sponsors or registries, and beyond the scope of this article. Verisign, the company that administers .com, and .net, points out that database replication with the amount of changes in the .com zone is a significant problem over slow network links. ccTLD Distribution Questions about where ccTLDs, the top-level domains assigned to individual countries, ought to work seem more straightforward. Working effectively in their own countries seems like the top priority, with connectivity to the Internet core and to other regions with which people in the country communicate regularly being somewhat lower priorities. Just over two-thirds of ccTLDs are hosted in their own countries; refer to Figure 4 for the bigger countries, and the online appendices for the full list. Although the third of ccTLDs not hosted in their own countries include some marketed more for international use than global use—Cocos Island's .cc, Tonga's .to, Turkmenistan's .tm, and Tuvalu's .tv, among others—those are very much the exception. Indonesia has local access to the root and to its ccTLD (.id). Pakistan has a root server, but no local access to its ccTLD (.pk). Let's compare what happens when someone in Indonesia does a lookup on an .id domain name with what happens when someone in Pakistan does a lookup of a name in the .pk domain. In Indonesia, the query goes to a root DNS server at the Indonesian Internet Exchange in Jakarta, where it is answered with the locations of the .id servers, several of which are also in Indonesia. The query then goes to the local .id server and is answered locally, whereupon the user can start sending traffic to the host he or she was trying to connect to, which is presumably also local. The traffic need not leave Indonesia, and if all the parties involved are in Jakarta it need not leave town. The Pakistani case is quite different. Until early 2006, there were no root servers in Pakistan, nor were there local servers for the .pk domain. There is now a root server in Karachi, but lacking servers for any TLDs it is of limited utility. DNS resolvers start out querying the local root server, but the response directs them to servers for the .p domain, all located in the United States, at least 10 time zones away. They then send their lookup packets across the single fiber connection all the way to the United States and wait for the response. At best, this process is slow. If that fiber connection goes down, or if there is any other problem between Pakistan and these U.S. servers, local communications in Pakistan are crippled. The situation with traditional gTLDs (.com, .net, and .org) in Indonesia and Pakistan is somewhat different. In Indonesia, local root servers provide addresses for the .com, .net, and .org servers. The .com and .net, lookups can be handled in Singapore, 18 milliseconds away. Theoretically, .org lookups can be handled in Hong Kong, but traceroutes indicate .org queries being answered in California instead. Thus, in Indonesia, .id is hosted mostly locally, .com and .net are nearby, and .org is considerably farther away. In Pakistan, in contrast, .pk queries and .org queries are answered from the United States, more than 200 milliseconds away, while .com and .net are answered from Singapore, 80 milliseconds away. For Pakistani users of all TLDs, there are single points of failure, but .com and .net do appear to be somewhat better connected than .pk. In Nairobi, Kenya, there are local copies of a root server and the local ccTLD (.ke). All external connectivity is by satellite, and most ISPs have only a single satellite link. Two Internet users in Nairobi wanting to communicate can do a lookup on the local root server to find the servers for .ke and can do a lookup on a local .ke server to find the servers for a subdomain of .ke. Assuming the subdomain being used is served locally, they can do a local lookup for a host within that subdomain and then send data across the local exchange point. Thus the two users in the same town can send data back and forth without having to send any data elsewhere. According to Verisign, Nairobi will soon have servers for .com and .net as well. In contrast, to use the .org domain they can again obtain addresses of the .org server from their local root server, but the lookup of the .org domain must go over a satellite link to Europe in order to be answered by a server in London. If the satellite link is up, this process adds half a second of latency to the query. If the satellite link is down, whatever local resource they are trying to connect to is out of reach. Figure 4: Countries that Host Their Own ccTLDs in Grey; Those that Do Not in Black There is also a concern about ccTLDs not served from the global core; if their region or upstream provider is cut off from the Internet outside their region, the rest of the world is unable to see that ccTLD. (See Table 2.) This situation may or may not be of concern; if all Internet resources within that ccTLD become unreachable in the same outage, the DNS portion of the outage may have no additional effect. However, if there is anything in that ccTLD that is not in the ccTLD's region, or if people or systems outside prefer to get a DNS response for an unreachable IP address rather than no DNS response at all, it may be of concern. Indeed, having servers that are well-connected to "the Internet as a whole" is a recommendation of RFC 2182, though the RFC does not consider the case of large portions of the Internet not being well-connected to each other. Table 2: TLDs Not Served in the "Internet Core" Region TLD Country Location of DNS Servers BB Barbados Barbados BD Bangladesh Bangladesh BH Bahrain Bahrain CN China China EC Ecuador Ecuador GF French Guiana French Guiana and Guadeloupe JM Jamaica Jamaica KG Kyrgyzstan Kazakhstan KW Kuwait Kuwait MP Northern Mariana Islands Guam MQ Martinique Guadeloupe and Martinique PA Panama Brazil, Chile, Costa Rica, and Panama PF French Polynesia French Polynesia QA Qatar Qatar SR Suriname Suriname TJ Tajikistan Tajikistan ZM Zambia South Africa and Zambia Lack of Exchange Points and Local Peering In the "Internet Mini-Cores" article [1], I noted that local hosting of critical infrastructure is moot if there is not either a local exchange point or a monopoly transit provider in the region. If data needed in a poorly connected region must leave the area and return to reach the user requesting it, the communication has double the latency, and possibly double the reliability problems, that it would have if it were hosted somewhere in the core. For the specific examples used in this article, I have mostly chosen areas that do have exchange points. I have not analyzed the underlying local infrastructure in all countries. Methodology The addresses of DNS servers for a TLD are available through several means: by looking at the root zone, by doing digs for the name servers, and by looking in the Internet Assigned Numbers Authority (IANA) whois data, among others. I did lookups against an anycast root server on my own network, because that seemed easiest to automate. My script then did a lookup for the address of each name server, stripped off the last octet, and produced a list of TLDs hosted in each /24 subnet. There are 635 /24s containing name servers for TLDs; 142 of them host multiple TLDs; the rest host just one. I assumed that all DNS servers in a given /24 were likely to be in the same or nearby locations. This situation appears not to be the case for the UUNet name servers, and there are probably a few other exceptions that will show up as errors in my data. I looked at a few automated geolocation systems to attempt to attach locations to the DNS servers, but none of them appeared to be producing accurate information. Instead, I guessed at the locations of the 600 subnets, using traceroutes from a variety of locations, paying attention to DNS, latency, and the results of whois queries for address space along the way. I also asked lots of questions of DNS operators and others and am particularly grateful to several anycast DNS operators, whose locations would not have all been found by my traceroutes. Some of my guesses are likely incorrect, and corrections are appreciated. I may be missing some information about the UltraDNS TLD servers, because UltraDNS has locations it regards as confidential. This information about UltraDNS servers is from Afilias's .net application, traceroutes from a variety of locations, and UltraDNS. [7] Locations of root servers are easier to find; they are listed at http://www.root-servers.org. Some supplemental information about j.root-servers.net was supplied by Verisign. If there are operational root servers not included on www.root-servers.org other than the J-roots, I did not count them. The full lists of locations of all TLDs and TLD servers are in the appendices to this article, at: http://www.pch.net/resources/papers/infrastructure-distribution/dns-distrib…. References [1] Steve Gibbard, "Internet Mini-Cores: Local connectivity in the Internet's spur regions" (2005). [2] Root Server Technical Operations Association. [3] Joe Abley, "Hierarchical anycast for global service distribution," ISC Tech Notes (2003). [4] Bradley Huffaker, "Two days in the life of three DNS root servers" (2006). [5] Tim Richardson, "Ship's anchor cuts cable to Sri Lanka," The Register, August 24, 2004. [6] Tony Lee, Bradley Huffaker, Marina Fomenkov, and kc claffy, "On the problem of optimization of DNS root servers' placement" (2003). [7] Afilias, ".NET Application Form". STEVE GIBBARD is a Network Architect for the nonprofit organization, Packet Clearing House, based in Berkeley, California. He runs an anycast DNS network that hosts the top-level domains for several countries and several of the "I" root anycast DNS servers, maintains PCH's network of route collectors and route servers at exchange points around the world, and researches the interconnection of Internet networks. In addition, Steve carries out network architecture and peering work as a consultant for several ISPs in the San Francisco Bay Area and elsewhere. Steve is a former Senior Network Engineer at Cable & Wireless, and has held network engineering positions at Digital Island and World Wide Net. E-mail: scg(a)pch.net Contacts & Feedback | Help | Site Map © 1992-2007 Cisco Systems Inc. All rights reserved. Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks of Cisco Systems Inc. Rebecca Wanjiku, journalist, p.o box 33515, Nairobi.00600 Kenya. Tel. 254 720 318 925 blog:http://beckyit.blogspot.com/ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Week 1 Online Discussion Summaries- CCK Internet Report(Resending)
by John Walubengo 02 May '07

02 May '07

Hi all, I went off-air for a while - actually I travelled upcountry to my parents home in Bungoma -its a remote town from NRB(450Km away) but the 2nd largest town in Western Province and yes, Internet access in those parts of the world is quite a challenge. But that's a story for another day... Today, I thought it would be nice to reflect on last weeks contributions before we move into the this final week's discussion. Tomorrow we start on the theme 'The Statistics on Affordability', but below I have put together what I think was last weeks summary contribution and hope you can go through it and raise final (if any) comments on last weeks themes. These were International Bandwidth, Heirarchy of Providers(ISP/IGO) and the Statistics on Infrastructure. ---Last weeks summary begin----- Week 1 Summary. Day 1:Background Concepts/Overview Mr. J. Walubengo gave an overview of the Internet Study report saying that it aimed to establish the status of Internet Infrastructure, Internet Affordability and Internet Use & Dispersion in Kenya. He reported that the study had various recommendations aimed at improving on the above internet indicators. This included amongst others; getting the government intervention in extending the domestic internet infrastructure, introducing further competition both within the Fixed Line and Mobile subsectors, utilizing the Universal access fund to extend Internet reach, promoting creation and use of local content as well as supporting Consumer Awareness initiatives. Mr. A. Gakuru lauded the study as well as its recommendations but noted that a similar study would be required that focused on the demand-side rather than the Supply-side of the internet market. He was glad that the Regulator was finally making deliberate efforts to support consumer awareness initiatives. He wondered if naming and shaming those ISPs that failed to route traffic through the local internet exchange point (KIXP) would help in enhancing the use of KIXP. Day 2: International & Domestic Bandwidth Usage In his opening remarks, Mr. Walubengo said that the report indicated that the International Internet Traffic was skewed (90%) towards external sources (content). Kenya was a net importer of Internet content and was therefore a consumer rather than a creator of Internet content. Value (economic or otherwise) goes to the creators of Internet Content and Kenya should aim to be a generator rather than just consumers of Internet Content. Mr. M. Michuki observed that most Kenyans visited external sources due to lack of local content. He suggested that ISPs should come up with pricing smodels that encouraged the creation of and access to local content. For example, geo-specific tariffs could be designed that would deliberately make it cheaper to access local (.KE) conent i.e. users could be charged less if and when they accessed or used local services(local websites, emails, etc) as opposed to foreign services. In addition, ISPs could come up with time-based tariffs that took advantage of the traffic models registered on the KIXP i.e. provide even lower rates for local content during evenings and weekends.He however conceded that Online Government Services, eHealth, eBanking, eLearning, etc would have to be in place in order to make such pricing models successful. Mr. J. Ngunjiri added that training or capacity building initiatives must also be supported to further gaurantee the success of the initiative. Day 3: Hierarchy of Internet Service Providers (IGO,ISP) The Internet Study Report recommended that the seperation between Internet Gateway Operators (IGO) and Internet Service Providers be dissolved with expected results being cheaper and higher quality services. In his opening remarks, Mr. Walubengo asked members to react to this recommendation. Lucy Kimani wondered if IGO would be able to cope with the technical and administrative overheads experienced by ISPs such as a larger number of customer accounts, increased need for support services, etc. She added that the cost of services may not come necessarily come down as expected due to the need to cover such overheads. Mr. Walubengo cited the case of TKL (Telkom Kenya) who are currently operating at both the Gateway and the ISP level without significant cost reductions in their Internet Service. Mr. S. Buruchara felt that historically, ISPs have had a rough time in trying to set up their own Internet Gateway Operations - having been forced by regulation to route their traffic through expensive and monopolistic Internet Gateways. He argued that if the upstream providers (IGO) were expensive, it was only natural that these costs would be passed downstream to the consumers. In addition, he noted that even todate the Licensing requirements were still prohibitive (expensive) for ISPs to move into the IGO level and if they did, they may need to recoup their (Licensing & other) investments at the expense of offering cheaper Internet Access rates. Mr. Kai Wulff commented that giving ISPs the IGO facilities may not necessarily reduce prices, citing case of Uganda where internet costs are still high despite many ISPs having IGO facilities. Day 4: Statistics on Infrastructure The report indicated that ISPs (internet services) were only operating in 30% of the districts in Kenya. The leased line services were mainly concentrated in urban centers (NRB & MSA) meaning that Internet Infrastructure was clearly challenged and the Report urges Government to intervene by leading the build-up of Internet/Network infrastructure accross the country. In her reaction, Alice Munyua, said that a comprehensive, multi-pronged approach must be made to avoid having infrastructure that would eventually serve no purpose. Aggressive infrastructure build up without content would be an exercise in futility since the internet pipes would be idle and underutilised most of the time. She added that additional initiatives such as Construction and Supply of Electrical Power, Literacy Initiatives, Local Content and 'Demand-side' Internet Requirements must move side by side with the infrastructure roll-out. Day 5- Statistics on Affordability will be on tomorrow (thrs 3rd May) morning. Today is open for final comments on the Day 1, 2, 3 & 4 Themes. walu. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Week 1 Online Discussion Summaries- CCK Internet Report
by John Walubengo 02 May '07

02 May '07

Hi all, I went off-air for a while - actually I travelled upcountry to my parents home in Bungoma -its a remote town from NRB(450Km away) but the 2nd largest town in Western Province and yes, Internet access in those parts of the world is quite a challenge. But that's a story for another day... Today, I thought it would be nice to reflect on last weeks contributions before we move into the this final week's discussion. Tomorrow we start on the theme 'The Statistics on Affordability', but below I have put together what I think was last weeks summary contribution and hope you can go through it and raise final (if any) comments on last weeks themes. These were International Bandwidth, Heirarchy of Providers(ISP/IGO) and the Statistics on Infrastructure. ---Last weeks summary begin----- Week 1 Summary. Day 1:Background Concepts/Overview Mr. J. Walubengo gave an overview of the Internet Study report saying that it aimed to establish the status of Internet Infrastructure, Internet Affordability and Internet Use & Dispersion in Kenya. He reported that the study had various recommendations aimed at improving on the above internet indicators. This included amongst others; getting the government intervention in extending the domestic internet infrastructure, introducing further competition both within the Fixed Line and Mobile subsectors, utilizing the Universal access fund to extend Internet reach, promoting creation and use of local content as well as supporting Consumer Awareness initiatives. Mr. A. Gakuru lauded the study as well as its recommendations but noted that a similar study would be required that focused on the demand-side rather than the Supply-side of the internet market. He was glad that the Regulator was finally making deliberate efforts to support consumer awareness initiatives. He wondered if naming and shaming those ISPs that failed to route traffic through the local internet exchange point (KIXP) would help in enhancing the use of KIXP. Day 2: International & Domestic Bandwidth Usage In his opening remarks, Mr. Walubengo said that the report indicated that the International Internet Traffic was skewed (90%) towards external sources (content). Kenya was a net importer of Internet content and was therefore a consumer rather than a creator of Internet content. Value (economic or otherwise) goes to the creators of Internet Content and Kenya should aim to be a generator rather than just consumers of Internet Content. Mr. M. Michuki observed that most Kenyans visited external sources due to lack of local content. He suggested that ISPs should come up with pricing smodels that encouraged the creation of and access to local content. For example, geo-specific tariffs could be designed that would deliberately make it cheaper to access local (.KE) conent i.e. users could be charged less if and when they accessed or used local services(local websites, emails, etc) as opposed to foreign services. In addition, ISPs could come up with time-based tariffs that took advantage of the traffic models registered on the KIXP i.e. provide even lower rates for local content during evenings and weekends.He however conceded that Online Government Services, eHealth, eBanking, eLearning, etc would have to be in place in order to make such pricing models successful. Mr. J. Ngunjiri added that training or capacity building initiatives must also be supported to further gaurantee the success of the initiative. Day 3: Hierarchy of Internet Service Providers (IGO,ISP) The Internet Study Report recommended that the seperation between Internet Gateway Operators (IGO) and Internet Service Providers be dissolved with expected results being cheaper and higher quality services. In his opening remarks, Mr. Walubengo asked members to react to this recommendation. Lucy Kimani wondered if IGO would be able to cope with the technical and administrative overheads experienced by ISPs such as a larger number of customer accounts, increased need for support services, etc. She added that the cost of services may not come necessarily come down as expected due to the need to cover such overheads. Mr. Walubengo cited the case of TKL (Telkom Kenya) who are currently operating at both the Gateway and the ISP level without significant cost reductions in their Internet Service. Mr. S. Buruchara felt that historically, ISPs have had a rough time in trying to set up their own Internet Gateway Operations - having been forced by regulation to route their traffic through expensive and monopolistic Internet Gateways. He argued that if the upstream providers (IGO) were expensive, it was only natural that these costs would be passed downstream to the consumers. In addition, he noted that even todate the Licensing requirements were still prohibitive (expensive) for ISPs to move into the IGO level and if they did, they may need to recoup their (Licensing & other) investments at the expense of offering cheaper Internet Access rates. Mr. Kai Wulff commented that giving ISPs the IGO facilities may not necessarily reduce prices, citing case of Uganda where internet costs are still high despite many ISPs having IGO facilities. Day 4: Statistics on Infrastructure The report indicated that ISPs (internet services) were only operating in 30% of the districts in Kenya. The leased line services were mainly concentrated in urban centers (NRB & MSA) meaning that Internet Infrastructure was clearly challenged and the Report urges Government to intervene by leading the build-up of Internet/Network infrastructure accross the country. In her reaction, Alice Munyua, said that a comprehensive, multi-pronged approach must be made to avoid having infrastructure that would eventually serve no purpose. Aggressive infrastructure build up without content would be an exercise in futility since the internet pipes would be idle and underutilised most of the time. She added that additional initiatives such as Construction and Supply of Electrical Power, Literacy Initiatives, Local Content and 'Demand-side' Internet Requirements must move side by side with the infrastructure roll-out. Day 5- Statistics on Affordability will be on tomorrow (thrs 3rd May) morning. Today is open for final comments on the Day 1, 2, 3 & 4 Themes. walu. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Fwd: [Idlelo2] FW: dgCommunities Invited to Attend World Bank Global Dialogue Events & Live Webcasts
by Judy Okite 01 May '07

01 May '07

FYI Kind Regards, ---------- Forwarded message ---------- From: Fouad Riaz Bajwa <fouadbajwa(a)gmail.com> Date: Tue, 1 May 2007 02:33:20 +0500 Subject: [Idlelo2] FW: dgCommunities Invited to Attend World Bank Global Dialogue Events & Live Webcasts To: idlelo2(a)fossfa.net, openstds(a)ipjustice.org, ugabytes(a)ugabytes.org From: e-government(a)developmentgateway.org [mailto:e-government@developmentgateway.org] Sent: Monday, April 30, 2007 11:47 PM Subject: dgCommunities Invited to Attend World Bank Global Dialogue Events & Live Webcasts Dear Members, For your interest I am writing to alert you to a series of World Bank Global Dialogues on e-government and ICT. The World Bank's e-Development Thematic Group invites all interested dgCommunities members to participate in its upcoming e-government/ICT related Global Dialogues by means of live webcast/online discussion, via videoconference (in several countries which will be connected) or in person (if in Washington DC). The following are details of these sessions: Open Systems for e-Government (May 02, 9:00 - 11.30 am EST) While open source software has achieved growing acceptance in the marketplace, open standards are also increasingly seen as key enablers of the transfer and use of information across organizations, systems, and devices. This seminar focuses on the embrace of open information and communications technology systems by governments and businesses alike in the face of growing demands for the effective, customer-centric delivery of services. What does "open" mean in the context of software, standards, and document formats, and is it relevant to the experience and challenges faced by developing and transition countries? Can open source, open standards, and ODF be leveraged to maximize the impact of ICT investments in public-sector reform and modernization efforts? A panel including experts from the World Bank, IBM, Microsoft, Open Source Institute, and the ODF Alliance will gather to discuss this interesting topic. Please click here for more information: http://go.worldbank.org/OPRW4CL1N0 Prioritizing e-Services - The case of Pakistan (May 09, 9:00 - 11:30 am EST) Many e-Government program initiatives are faced with a myriad of choices for e-Services; hence there is an obvious need to prioritize due to various constraints. There are different methodologies available for identifying and prioritizing these e-services, and all governments implementing such programs have gone through this phase with varying outcomes. The e-Services prioritization process is therefore an essential component of e-Government programs, and selecting and applying the appropriate methodology is fundamental for e-Government program success. The session experts and practitioners will present a general overview of the various methodologies available for prioritization of e-Services and will discuss the experience of Pakistan, one of the latest case studies from the field. More information about this event will be available online shorlty at http://www.worldbank.org/edevelopment. Additional Upcoming Events: e-Government Portals (May 30, 9:00 - 11:30 am EST) Designing e-Government Strategies (June 19, 9:00-11:30 am EST) About the World Bank e-Development Thematic Group The e-Development Thematic Group's mission is to promote the efficient use of ICT in development and World Bank operations by facilitating knowledge sharing on good practices in e-development, and more frequent dialogue among interested parties thus catalyzing specific program and project proposals. The e-Development Thematic Group was created in 2003 in response to the increasing demand from various countries and sectors that are involved in the design and implementation of a variety of e-development and e-government projects, on the basis of the e-Government Thematic Group. The e-Development Thematic Group is open for participation by both World Bank staff and external clients and partners. For more information about the Group and its events, knowledge-base, toolkits and other resources, please visit the website at http://www.worldbank.org/edevelopment. To find out how to participate in these events, join the mailing list or partner with e-TG, please write to edevelopment(a)worldbank.org or contact Oleg Petrov at +1202-473-8861. Best regards, Mike Pereira ___________________________________ Mike Pereira Director, Global Online Communities Development Gateway Foundation 1889 F Street NW Washington DC 20006 202-572-9259 202-572-9290 (fax) http://home.developmentgateway.org/?intcmp=906 http://topics.developmentgateway.org/?intcmp=906 _______________________________________________ Idlelo2 mailing list Idlelo2(a)fossfa.net http://mailman.dst.gov.za/mailman/listinfo/idlelo2 -- Judy Ann Okite, +254-721237507,+254-734252336 P.O. BOX 2228 00100, NAIROBI,KENYA. "Even if you are on the right track, you'll still get run over if you just sit there."

1 0