Chapter 5: Growing the Root

 < Day Day Up > 



  1. Matrix News, 9 (December 1999).

  2. Robert Braden, later a major figure in the Internet Activities Board, worked at the UCLA campus computing center at the time and was active in the Network Working Group. Another contemporary UCLA graduate computer science student, Kilnom Chon, returned to his native Korea in 1981 to establish the first TCP/IP network in Asia and later became one of the leaders of the Asia-Pacific toplevel domain administrators.

  3. A history of the Network Working Group and the origins of the RFC series is contained in RFC 1000.

  4. An interview with Keith Uncapher, OH174, conducted by Arthur Norberg on July 10, 1989, Los Angeles, California. Charles Babbage Institute, Center for the History of Information Processing, University of Minnesota, Minneapolis.

  5. Cerf and Kahn, IEEE Transactions on Communication 22 (5): 637-648.

  6. RFC 791, 'DARPA Internet Program Protocol Specification,' September 1981.

  7. Joyce Reynolds, Jon Postel, RFC 870, 'Assigned Numbers,' October 1983.

  8. Clark projected a future 'upper limit of about 1,000 networks.' RFC 814 (July 1982).

  9. '[A] reasonable programming strategy would be to make the name table accessible only through a subroutine interface, rather than by scattering direct references to the table all through the code. In this way, it will be possible, at a later date, to replace the subroutine with one capable of making calls on remote name servers.' David Clark, RFC 814 (July 1982).

  10. Archives of it still exist at <http://www.tcm.org/msggroup/>.

  11. Jon Postel, 'Namedroppers Policy,' November 2, 1983, <http://ittf.vlsm.org/ietf/129.txt>.

  12. 'The general guideline for a second-level domain is that it have over 50 hosts. This is a very soft ‘requirement.' It makes sense that any major organization, such as a university or corporation, be allowed as a second-level domain-even if it has just a few hosts.' Postel, RFC 881 (November 1983).

  13. 'Top-level domains,' Postel wrote in RFC 881, 'must be specially authorized. In general, they will only be authorized for domains expected to have over 500 hosts.'

  14. This May 11, 1984, draft of what became RFC 920 is available at <http:// ittf.vlsm.org/ietf/132.txt>.

  15. Einar Stefferud to namedroppers list, May 13, 1984.

  16. Mark Horton, namedroppers list, November 2, 1985.

  17. Yet, Postel still faced criticism that the Internet administration was 'U.S.-centric' because some thought other countries had to use their country code as a top-level domain, whereas people in the United States didn't. Postel to namedroppers list, May 20, 1984, <http://ittf.vlsm.org/ietf/131.txt>. In arguing against this notion, Postel observed that anyone could register in .com, .edu, or .org.

  18. Ibid.

  19. An X.400 address has an eight-layer hierarchy, starting with a country code. Moreover, each X.400 messaging system is an independent domain and can only be interconnected by agreement among the implementing service providers. The features of the X.400 standard reflect its origins in a telephone monopoly- dominated world.

  20. Jon Postel to msggroup, November 15, 1985.

  21. Steve Kille to namedroppers list, November 15, 1985.

  22. 'Hi. The namedroppers list is for the discussion of the technical issues in the DARPA domain name system. The actual spelling of the name strings, and especially the semantics that people attach to those strings are not part of these technical issues. So please, no messages in this mailing list about the merits of EDU vs US (etc.) as a top-level domain name. Clearly, the choices of top-level names is a highly charged political issue. Please discuss it in the appropriate forum ( msggroup?, poli-sci??).-jon.'

  23. Jon Postel, Namedroppers Policy, August 2, 1987, <http://ittf.vlsm.org/ietf/165.txt>.

  24. 'There was a contract executed in 1988 with DARPA, which I have seen. It contains a set of about 5 or 6 work items which are recognizable as the IANA functions plus the RFC editor and the Internet Monthly Report (which Postel also did). The term 'IANA' was not used in the contract. It's my recollection that this contract was preceded by another long-term contract between DARPA and ISI that included the same functions, but I've never seen that one.' Brian Kahin, email to author, December 19, 2000.

  25. By maintaining both the DNS root and several different top-level domains (.arpa, .com, .edu, .org, .gov, and .mil) the DDN-NIC combined functions that, in a strict implementation of a hierarchical name space, should have been separate. Postel and other members of the technical community recognized this and didn't particularly like it, but accepted it because there was no one else to do the task. See Postel to namedroppers list, May 20, 1984, <http://ittf.vlsm.org/ietf/131.txt>.

  26. As an example, responsibility for ARPANET management was transferred from ARPA to the Defense Communications Agency in 1975. See NAS (1994), 238, and Abbate (2000), 136.

  27. Interview with Charles Brownstein, former NSF division chief, June 2000. See also NAS (1994), 238.

  28. NSFNET cooperative agreement citation.

  29. NSFNET Backbone Services Acceptable Use Policy, June 1992, <http://www.merit.edu/merit/archive/nsfnet/acceptable.use.policy>.

  30. RIPE Terms of Reference, November 29, 1989, <http://www.ripe.net/ripe/docs/ripe-001.html >.

  31. Interview with Daniel Karrenberg, June 20, 2000.

  32. Interview with David Conrad, August 23, 2000.

  33. The proposal was formatted as a recommendation from the Internet Activities Board to the Federal Networking Council and was eventually approved. See sections 5.4.1 and 5.5.1 for more detail about the institutional environment in which these decisions were made.

  34. Jon Postel to msggroup, November 15, 1985.

  35. Interview with John Klensin, November 13, 2000.

  36. The committee was known as the Internet Configuration Control Board (RFC 1160).

  37. Craig Partridge, email communication with author, July 2001.

  38. Steve Crocker, cited in RFC 1000 (August 1987).

  39. Cited in Hofmann (1998, 14).

  40. RFC 1083 (December 1988); RFC 1111 (August 1989); RFC 1120 ( September 1989); RFC 1160 (May 1990); RFC 1200 (April 1991); RFC 1250 (August 1991).

  41. An 'Internet FAQ' written by ISI staff members claimed, 'The task of coordinating the assignment of values to the parameters of protocols is delegated by the Internet Activities Board (IAB) to the Internet Assigned Numbers Authority (IANA).' This document seems to have evolved into RFC 1207 (February 1991).

  42. Interestingly, though, Cerf's major RFC documenting the IAB does not mention name and address assignment as one of its key functions. RFC 1160 defines the IAB functions as '(1) Sets Internet Standards; (2) manages the RFC publication process; (3) reviews the operation of the IETF and IRTF; (4) performs strategic planning for the Internet, identifying long-range problems and opportunities; (5) acts as a technical policy liaison and representative for the Internet community; and (6) resolves technical issues which cannot be treated within the IETF or IRTF frameworks.'

  43. Jon Postel to msggroup, November 15, 1985. See also email, Cerf to Aiken, March 17, 1995; RFC 1174 (August 1990); RFC 1207 (February 1991). The actual RFCs (1032 and 1020) announcing the transfer in 1987 were not written by Postel and do not mention IANA or any delegation from Postel or the IAB.

  44. Email, Cerf to Rutkowski, November 6, 1990, <http://www.wia.org/ISOC/901106.htm >.

  45. Interview with Don Mitchell, December 19, 2000.

  46. Email, Cerf to Rutkowski, November 6, 1990, <http://www.wia.org/ISOC/901106.htm >.

  47. The case of Daniel Bernstein, who contended that his RFC submission had not been handled according to the IETF's documented processes, was another key event in instilling the fear of lawsuits among the IAB/IETF hierarchy. See <http:// ittf.vlsm.org/ietf/16.txt>.

  48. Email, Rutkowski to Cerf, April 5, 1991, <http://www.wia.org/ISOC/910405.htm>.

  49. Interview with Charles Brownstein, May 18, 2000.

  50. Hofmann (1998, 12, 16) does an excellent job of analyzing the mixture of technical, political, and organizational factors that led the bulk of the IETF participants to greet the decision with such revulsion.

  51. The National Research and Education Network Program, A Report to Congress, December 1992. Submitted by the Director, Office of Science and Technology Policy, in response to a requirement of The High Performance Computing Act of 1991 (P.L. 102-194), http://www.eff.org/pub/Legislation/nren_congress.report.

  52. Email, Cerf to Rutkowski, April 3, 1991. See <http://www.wia.org>.

  53. National Science Foundation, Network Information Services, Manager(s) for NSFNET and the NREN, Project Solicitation, March 19, 1992, <http://www.cavebear.com/nsf-dns/internic-solicitation.htm >. NREN stands for National Research and Education Network.

  54. NSI Project Solicitation, October 1992, <http://www.networksolutions.com/en_US/legal/internic/nsf-solicitation/>.

  55. Ibid, section M.

  56. NSF Cooperative Agreement No. NCR-9218742, available at <http://www.networksolutions.com/en_US/legal/internic/cooperative-agreement/index.html >.

  57. David Conrad's description of the Internet technical community, interview with author, August 23, 2000.



 < Day Day Up > 



Ruling the Root(c) Internet Governance and the Taming of Cyberspace
Ruling the Root: Internet Governance and the Taming of Cyberspace
ISBN: 0262134128
EAN: 2147483647
Year: 2006
Pages: 110

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net