Internet RFCs as social policy: Network design from a regulatory perspective

Authors


Abstract

The Internet has come to fill centrally important economic, social, political, and cultural functions during a period in which policy-making, too, has been undergoing significant change. The Internet “Requests for Comments” (RFC) process is both the venue technical decision-making and for the development of Internet governance procedures and institutions. Because this process casts decisions in technical terms, it has largely been without policy scrutiny. This paper offers a preliminary analysis of the RFC discourse for ways in its decision-making contributes to, operationalizes, influences, or conflicts with the laws of geopolitically recognized governments, and for ways in which the discourse itself serves as the means through which the more formal institutions and practices of Internet governance developed. The paper opens with a discussion of the gap between the technical and legal Internet discourse communities. Policy functions filled by Internet RFCs include explicit policy-making, explicit policy analysis, and implicit policy analysis (insights into policy issues that are not expressly discussed but that can be elicited from the texts through policy analysis). As a discourse matrix, the RFCs have several features that enable the conversation to fill additional policy-related functions that include defining the policy subject (the Internet), establishment of Internet design processes, policy implementation programs, conflict and conflict resolution, informal problem resolution, and political analysis.

Introduction

The Internet developed and came to fill centrally important economic, social, political, and cultural functions during a period in which the nature of policy-making has been undergoing change. The Internet “Requests for Comments” (RFC) discourse is important to both. It is the process by which the Internet is technically designed, and it is the process through which a new set of practices for policy-making has developed that is already in use in other decision-making communities. Because these processes cast decisions in technical terms, building a communication network often quite different in pertinent details from that of popular and law-maker conceptualizations, it has largely been without policy scrutiny.

This paper reports on preliminary findings of analysis of the RFC discourse. Almost 5,500 RFC documents have been produced since the process began in 1969, almost all freely available on a website maintained by the Internet Engineering Task Force (IETF). This research addresses two questions: How do the RFCs contribute to, operationalize, influence, or conflict with the laws of geopolitically recognized governments? What are the features of the RFCs as a discourse, and what policy functions do those features enable? The goal of the research is to contribute to the formation of a shared discursive space involving both technical and legal decision-makers. In the Internet environment, failure to bridge the distance between the two discursive communities is of particular concern because of fears that technical standards, free of public interest requirements commonly found in governmental regulation, can undermine efforts to achieve social policy goals. We are aware of divergences and convergences in meaning between technical and legal definitions of concepts important to both communities (Burk, 2005). There have been calls for the translation of rules for information flows imposed by networked technologies into terms understandable by policy-makers (Reidenberg, 1998) and for the same type of translation in the reverse direction (Hampton, 2004). The suggestion that “social impact statements” for system design features (Schneiderman & Rose, 1995) should be required makes a policy tool out of Star's (1989) insight into the value of a “Durkheim Test,” rather than the Turing Test, when evaluating networks. Technological discourses with policy consequences, such as the Internet RFCs, require additional development of the methods used for policy analysis (Whitley & Hosein, 2005). Finding ways of making the technical discourse accessible to the public and to policy-makers is necessary in order to fully obtain public input into technical decision-making processes while those processes are still underway rather than after the fact, when technologies based upon standard protocols are already in place (Winter, 2006).

The technical decision-making conducted through the RFCs is one of three forms of Internet governance. The Internet Corporation for Assigned Names and Numbers (ICANN) makes management decisions. ICANN's control over the Internet addressing system (the domain name system) has created a quasi-legal system through flow-down contracts (Abbate, 1999; Mueller, 2002). Via these contracts, signatories – including individuals who agree to license terms in order to gain access through their Internet service providers – accept conditions of use that would not otherwise be acceptable under U.S. and other laws. National and regional governments continue to make law to govern uses of the Internet.

The paper begins by looking at technology design and network architecture as forms of social policy before turning to what can be learned about the Internet design discourse as a source of policy and as a policy discourse.

Technical Decisions as Social Policy

Analysis of technical decision-making as social policy did not begin with the Internet. There has been growing appreciation of the salience of large-scale technical systems such as the telecommunications network, however, in recent decades.

Social Implications of Large-Scale Technical Design

Analysis of Internet RFCs as policy documents takes place within the context of a history of research on the social implications of technological decisions that includes attention to both social (Layton, 1974) and governmental (Bullard, 1988) goals. Problems raised by gaps between the technical knowledge of system designers and the economic, political, and social knowledge required to achieve policy goals are familiar from earlier systems such as those for intelligence (Berkowitz & Goodman, 1989) and weaponry (Demchak, 1991; Pearton, 1984). Precursors to the analytical approach used here can be found in decision theory (beginning with March & Simon, 1963), critical theory (De Landa, 1991), evolutionary theories that treat species as composite organisms united through their information flows (Dyson, 1997), sociology (Suchman, 2006; Star & Ruhleder, 1996), and in organizational practices (Bowker, 1994; Gorman & Malecki, 2000).

Telecommunications Network Design from a Policy Perspective

While national governments have always appreciated the political value of control over networks (Horwitz, 1989), the same has not always been true for those building the technologies involved. Kling (1980, 1996) introduced discussions of power and politics into the study of information technologies, and Pool (1983) correctly predicted the legal problems that would arise from networked computing. Ferguson (1986) defined network infrastructure design as social policy on the same order as decision-making that affects wealth distribution, and by the mid-1990s Vice President Gore's use of this idea made it publicly acceptable. The argument that policy effects of network design can be accomplished by default as well as through deliberate effort is supported by structuration theory (Orlikowski & Barley, 2001; Giddens, 1984), actor-network theory (Latour, 2005; Law & Hassard, 1999), and work on the politics of objects (Bijker, 1995; Bijker & Law, 1992; Winner, 1986). Several factors increased the salience of network design as policy. Reports to the French (Nora & Minc, 1980), Swedish (Tengelin, 1981), and British (Wasik, 1991) governments in the 1980s highlighted vulnerabilities created by dependence on the network infrastructure. The “big bang” of telecommunications policy reform brought social, cultural, and economic dimensions of network design into political view (Cowhey, 1990). Innovations forced regulatory agencies to engage with design issues (Mueller, 2002). Policy analysts described design decisions as legislative because the system is the means of democratic participation (Dutton, 1990). The risk that technical standards would diverge from the public interest was significantly heightened when the Internet became commercialized (Morris & Davidson, 2003), a problem exacerbated by homeland security concerns and the privatization of government functions. Those in science, technology, and society (STS) studies began to develop theories specific to the problem of incorporating human values in technology design (Friedman, 2004). Appreciation of the political nature of network design decisions has been evident across disciplines. First Amendment specialists began to examine patents through the lens of their impact on freedom of expression (Kahin, 1994), and privacy advocates fear that it is more difficult to protect this constitutional right through retrofitting the network rather than designing such protections in from the beginning (Trubow, 1989). Historians discovered interactions between social structure and network design both within (Lipartito, 1989) and across (Pircher, 1987) societies. Innovation researchers find what Tuomi (2004) describes as the co-evolution of technical architectures and social differentiation. Sociologists look at the impact of Internet design on national identities and priorities (Schlesinger, 2004). Many users, too, understand their desire to influence design decisions as a political matter (Fortunati, 2006; Qvortrup, 1988; T. Taylor, 2006). Practicing attorneys actively involved in defining information infrastructure concepts have been aware of the importance of these negotiations for the economy because the resulting protocols so affect the structure and competitiveness of network-based markets (Bruce, Cunard, & Director, 1986). Harmonization of legal systems across national borders was a key feature of the late 20th century stage of the development of the information society, but in situations in which neither the law nor local network design are harmonized, knowledge of discourse about protocols such as RFCs can be helpful (Latzer, 1989). By the mid-1990s, the need to treat RFCs as policy documents was explicitly discussed (Kahin & Keller, 1997). Within a few years the distinct features of Internet decision-making as policy-making processes was also receiving attention (Yu, 2004). Today it is commonly agreed that technical standards are a means of regulating user behavior (Benoliel, 2004), even when mediated by institutions (Shah & Kesan, 2004). A telecommunications policy approach to technical design issues was offered by Mansell and Silverstone (1996). Manipulation of design can be used to escape scrutiny by policy-makers and competitors (Mansell, 1993) or, on the other hand, to achieve policy goals to which protocols present barriers (Ewers, et al., 2005). Technical protocols that successfully accomplish one task, however, may exacerbate other problems (Pau, 2002). Lessig (1999) popularized the then-decade-old insight that Internet design and programming code can serve law-like functions, noting that architectural features can alter the referents of legal concepts such as the distinction between searching and monitoring. Explicit uses of code for regulatory purposes to date include the development of protocols for the purposes of protecting security and privacy (Biegel, 2001), and, in China, to combat Internet addiction (R. Taylor, 2006). There are many more calls for policy analysis of Internet protocols (e.g., Galloway, 2004; Langlois, 2005), however, than there are actual analyses. Indeed, Solum and Chung (2004) found 58 items in the legal literature at the time that they wrote that mention the importance of Internet architecture – without going into any further detail – to particular legal problems. Mueller and Chango (2007) provide a particularly superb example of the value of incorporating Internet RFCs into analyses of interactions between technical standard-setting and other decision-making entities and processes for the Internet. RFCs do not always support decisions made by other sources of policy-making. There is deep concern about the use of Internet design processes to get around rules of legal procedure and constitutional law (Froomkin, 2000). There are tensions when RFCs result in rules that differ from those of policy-makers, as has happened with Internet-based telephony – RFCs set up standards that differ from those developed for other kinds of telephony by the International Telecommunications Union. In other cases, though, there are explicit efforts to coordinate with rules already in place, as is the case with RFCs 3187 and 3188, which recommend using existing numbering systems for books and other print materials as their identification numbers on the web. Networked computing history rarely deals with policy (Haigh, 2004). Those histories of the Internet that do emphasize the democratic nature of RFCs (Rosenzweig, 1998) provide a story somewhat different from that pictured by those who specifically attend to actual Internet decision-making processes (Davidson, et al., 2002; Mueller, 1989).

The RFCs and Policy

Research on the Internet RFCs as a discourse falls within a history of growing use of discourse analysis for policy purposes. It also incorporates features specific to the technical environment.

The discourse matrix

Literary historian Davis (1983) argues that economic, political, cultural, and social factors joined Locke's concept of the fact in developing distinctions among historical, fictional, journalistic, and other narratives for legal purposes out of a previously undifferentiated discourse matrix of narrative forms. This notion is valuable for understanding the RFCs as a largely still-undifferentiated policy discourse matrix of narrative forms. To date policy discourse analysis has dealt only with the well-developed genres of established geopolitical entities, but the RFCs are evolutionary in several senses: the subject matter of the discourse (the Internet) keeps changing, the decision-making entities and processes both created and documented by the discourse keep developing, and the narrative forms that comprise the discourse and the discourse itself also evolve. Authors of RFCs reflect some awareness of factors affecting the conversation. When the process began, the documents had almost a 19th century character, appearing in letters exchanged in hard copy through the postal system. Over time, the development of alternative venues for discussion such as email and bulletin boards, the growing economic and social importance of decisions made, personal styles of figures particularly important to the design process, and the struggle to make the RFCs official all had an influence (RFC 2555). Insights of those in the humanities were important, too, as demonstrated by RFC 1776 – “The Address is the Message” – with its evocation of Marshall McLuhan's famous saying that the medium is the message. A wide range of narrative types has appeared in the RFCs (Salus, 1995). These include humor (RFC 527 is a take-off on Lewis Carroll's “Jabberwocky;” RFC 1149 explains how to send messages by carrier pigeon), glossaries (RFC 1983; RFC 2119; RFC 2828), writing instructions (RFC 2360), bibliographies (RFC 1176; RFC 2007), biographies (RFC 1336; RFC 2468), poetry (RFC 1121), and discursive (RFC 2555) and chronological histories, including the widely used Hobbes' Internet Timeline (RFC 2235). Sub-genres were invented along the way. RFC 1818 defined and launched the Best Current Practices (BCP) series. The FYI series is used to identify information on speciific topics and fix texts (FYI 17 [RFC 3160], for example, was a specific version of a web page maintained by the Internet Engineering Task Force [IETF] Secretariat known as “The Tao of the IETF”), and FYI 30 [RFC 2151] is always the current version of “A Primer on Internet and TCP/IP Tools and Utilities”). What is now the official RFC database – the RFC Editor, published by the Internet Society – classifies documents by “status.” Standards track RFCs include standards, draft standards, and proposed standards. Other RFCs are classified as experimental, informational, historic, and early. The three sub-series, which provide a second set of identification numbers for documents involved, are Standards (STD), Best Current Practice (BCP), and For Your Information (FYI). This database also includes some information on the relation of documents to each other, month of publication, and authorship.

Defining the Internet

The Internet itself was defined through RFCs. Just as Rutkowski (1983) pointed out regarding another set of telecommunications network standards, the definition of the Internet has several faces ranging from an ideal conceptualization to concrete networks. RFC 1602 explicates three such definitions – the Internet as a set of standards, the process of developing the standards, and the physical network itself. Definition of the Internet as a “network of networks,” influential in policy circles after its introduction there by Noam (1994), first appeared in RFC 1122, authored by Braden, in 1989.

Establishing Internet design processes

RFCs are used to design Internet decision-making processes themselves. RFC 2014, for example, described how the Internet Research Task Force is supposed to work, RFC 2028 specifies each of the organizations to be involved in Internet standard-setting, and RFC 2727 details the procedures by which the Internet Advisory Board (IAB) and Internet Engineering Steering Group (IESG) should nominate and recall committee members. RFC 2350's explanation of what can reasonably be expected from the Computer Security Incident Response organization lists issues and topics to be considered relevant to the security community and specifies the types of information incident response teams should provide. RFC 2418 defines formal

The RFCs as a Policy Discourse

The RFCs are unusual as a policy discourse: Rather than issuing from established political entities, the RFC process was conceived in 1968 during a meeting of a few graduate students and staff members from the four institutions then involved with network design. Instead of being mediated by other players before reaching the public, the RFCs were collected, archived, and aggressively edited by just a couple of individuals integral to the process for most of their existence (RFC 2555). In addition to providing a record, RFC narratives range from jokes to the establishment of policy-making organizations and processes themselves. Rather than assertions, the RFCs are dialogic in nature. The RFCs have been described as “the nearest documents the Internet has to an Articles of Confederation (Loshin, 2000, p. ix) and as “a rich archive that sheds light on the historic and present controversies surrounding the Internet” (Hanseth, Monteiro, & Hatling, 1996, p. 422, n. 7). The RFCs have become the decision-making model for other decision-making communities (RFC 2555). Widespread norms and practices important to governmentality, such as netiquette, too, derive from RFCs. The first RFC, written by Steve Crocker on April 7, 1969, dealt with host software but also coined the phrase “requests for comments” and described the RFCs as the primary documentation for the Internet (RFC 1). The second launched the RFCs as a dialogue by responding to the first document's suggestions (RFC 2). The third (RFC 3) specified the types of communications to be included in the discourse, emphasizing openness regarding participation and narrative form as well as informality. With these three documents several fundamental elements of Internet design practice were put in place, including additionally the role of working groups in experimentation and wide distribution of documents. Other RFCs of historical importance include the first contribution by Tim Berners-Lee, designer of the World Wide Web (RFC 1630), which introduced what we now know as URLs; establishment of the domain name system in RFC 819 and 920; and the recommendation that a next generation protocol was needed in RFC 1602. Recent RFCs include documents dealing with such matters as expanding the Internet object naming system to emergency services (RFC 5031) and electronic product codes (RFC 5134), proposed standards for Internet filtering techniques (e.g., RFC 5228, 5235), prioritization of Internet telephony resource (RFC 5115), and a description of an experiment with an ephemeral organizational form, Exploratory Groups, as an additional step in decision-making processes (RFC 5111). Policy issues currently being addressed by those involved with RFCs include those raised by the extension of the network into the physical environment (Tennenhouse, 2000); interactions between property rights and access to information (Davidson, et al., 2002); the possibility that third parties could modify content as it flows from a producer to a user (Morris & Davidson, 2003); user control of identities shared across devices (Schacham, et al., 2007); the creation of “federated” identities across administrative domains (Saklikar & Saha, 2007); prevention of denial of service attacks (Peng, et al., 2007), spam (Ramachandran, et al., 2007), and and e-commerce vulnerabilities (Ouyang & Billington, 2004); and facilitating multilingual websites (Starr, 2005). The following sub-sections offer preliminary findings from analysis of the RFCs as a source of policies and as a policy discourse. RFC documents exemplifying what can be found in each category are presented in chronological order.

RFCs as Policy

RFCs serve a number of different policy functions. These include explicit policy-making, explicit policy analysis, and implicit policy analysis (insights into policy issues that are not expressly discussed but that can be elicited from the texts through policy analysis).

Explicit policy-making

RFCs have been used to announce explicit policy positions. RFC 2458, for example, defines Internet telephony services, and RFC 2804 places consideration of wiretapping concerns outside the scope of the standard-setting process.

Other RFCs are explicit responses to U.S. government law. RFC 799 points out that direct connection paths may not be possible under certain regulatory conditions. Antitrust concerns are highlighted by RFC 1015 and RFC 1192. RFC 3978 articulates the intellectual property rights status of documents in the RFCs. RFC 4096 explains why a mandate by the U.S. Congress to include particular types of information in email subject lines will not effectively defeat spam. RFC 4869 proposes cryptographic interfaces specifically designed to comply with U.S. National Security Agency specifications. RFC 4734, which defines activities carried out by modem, fax, and text telephony signals, responds to power signal regulations. RFC 5066 provides specifications for ethernet interfaces that meet the requirements of spectrum regulations. A number of legal issues are addressed by RFCs. Legal problems endemic to communications irrespective of medium that receive attention in this discourse inclucde fraud, crime as a generic concept, pornography, censorship, and open access of varying kinds. Privacy is acknowledged to be an extremely important issue, discussed in over 12.5% of the RFCs published. Legal and policy problems indigenous to the Internet environment also receive attention, including phishing (fraudulently soliciting personal information), spam, viruses, worms, and malware (damaging software). Not all issues of concern to the legal community are present in the RFCs, however. Libel, for example, is an important liability issue for individuals and service providers, but has so far been addressed in only 1 RFC.

Laws of governments outside of the U.S. are also evident. RFC 101 details Canadian government goals for the Internet design process. RFC 3536 specifically discusses internationalization. RFC 3837 notes that service providers may be in danger of legal threats of which they are not even aware because so many different jurisdictions are involved. RFC 4237 mentions the need to protect descriptive information about voice messaging because of the privacy concerns of numerous national governments.

Explicit policy analysis

Many RFCs examine the pros and cons of various policy options. RFCs 1633, 2430, 2474, and 2475 provide background for understanding current battles over “network neutrality.” RFC 2008 reviews a number of possible Internet address routing and ownership rules for policy implications; RFC 1355 examines privacy and accuracy issues raised by Network Information Center databases; RFC 2227 considers hit-metering and usage-limiting techniques of concern from a censorship perspective; and RFC 2505 looks at a variety of ways of combating spam.

In some issue areas, examination of RFCs provides support for critics. Analysts of the digital divide experienced by those with disabilities (Kaye, 2000/2006) are supported by the fact that disabilities are mentioned only twice, both times in discussions of how to meet requirements for access to the Internet in schools. Children are mentioned in over 120 RFCs – again prompted by statutory requirements – but the elderly not at all.

n other issue areas, however, the RFCs provide counter-evidence to critics. For example, those concerned about English-language domination of the Internet commonly assert or imply that those who designed the Internet were either oblivious to the problem or actively chose to limit access in this way (Warschauer, 2000) but the RFCs provide evidence that there was active and explicit attention to the issue (see, e.g., RFC 2277).

Implicit policy analysis

Close reading of the RFCs shows that at least in some areas technical approaches to problem-solving introduce distinctions of policy importance that have not yet, or not successfully, been incorporated into either policy analysis or laws and regulations. The conceptualizations that these yield may be described as a form of implicit policy analysis. The number of dimensions in which refinements to privacy law should be possible that are suggested by RFCs dealing with the cookies that track user behaviors on the web is illuminating in this regard. Just a few examples: RFC 1004 distinguishes between threat and trust environments, and between securing the sender and receiver as opposed to securing the link. RFC 1094 emphasizes the difference between stateless and stateful files and directories, a distinction related to but usefully different from the notion of accessing data in aggregate as opposed to individually identifiable forms. The notion of cookie destruction, discussed in RFC 2109 and today practiced by many Internet users, could be extrapolated into other privacy-sensitive environments, as could the idea of placing limits on the number of information-collecting transactions should be allowed to take place from the same RFC. Notification of the user when the state of information about the user changes is suggested in RFC 2965.

The entire body of RFCs dealing with cookies makes clear that regulations dealing with privacy must be re-examined in response to each technological innovation and standard-setting decision. Decisions by the technical community to reject ideas put forth after experimentation can also be extremely valuable, making it possible to avoid problems such as those identified in RFC 4096's analysis of why a policy put in place by the U.S. Congress would not be effective in achieving its goal of stopping spam.

RFCs as Policy Discourse

As a discourse, the RFCs have several features that enable the conversation to fill several additional policy-related functions. After looking at the RFCs as a discourse matrix, this sub-section introduces the effects of RFCs on the definition of the Internet, Internet design processes, policy implementation programs, conflict and conflict resolution, informal problem resolution, and political analysis.

The discourse matrix

Literary historian Davis (1983) argues that economic, political, cultural, and social factors joined Locke's concept of the fact in developing distinctions among historical, fictional, journalistic, and other narratives for legal purposes out of a previously undifferentiated discourse matrix of narrative forms. This notion is valuable for understanding the RFCs as a largely still-undifferentiated policy discourse matrix of narrative forms. To date policy discourse analysis has dealt only with the well-developed genres of established geopolitical entities, but the RFCs are evolutionary in several senses: the subject matter of the discourse (the Internet) keeps changing, the decision-making entities and processes both created and documented by the discourse keep developing, and the narrative forms that comprise the discourse and the discourse itself also evolve.

Authors of RFCs reflect some awareness of factors affecting the conversation. When the process began, the documents had almost a 19th century character, appearing in letters exchanged in hard copy through the postal system. Over time, the development of alternative venues for discussion such as email and bulletin boards, the growing economic and social importance of decisions made, personal styles of figures particularly important to the design process, and the struggle to make the RFCs official all had an influence (RFC 2555). Insights of those in the humanities were important, too, as demonstrated by RFC 1776 – “The Address is the Message” – with its evocation of Marshall McLuhan's famous saying that the medium is the message.

A wide range of narrative types has appeared in the RFCs (Salus, 1995). These include humor (RFC 527 is a take-off on Lewis Carroll's “Jabberwocky;” RFC 1149 explains how to send messages by carrier pigeon), glossaries (RFC 1983; RFC 2119; RFC 2828), writing instructions (RFC 2360), bibliographies (RFC 1176; RFC 2007), biographies (RFC 1336; RFC 2468), poetry (RFC 1121), and discursive (RFC 2555) and chronological histories, including the widely used Hobbes' Internet Timeline (RFC 2235). Sub-genres were invented along the way. RFC 1818 defined and launched the Best Current Practices (BCP) series. The FYI series is used to identify information on speciific topics and fix texts (FYI 17 [RFC 3160], for example, was a specific version of a web page maintained by the Internet Engineering Task Force [IETF] Secretariat known as “The Tao of the IETF”), and FYI 30 [RFC 2151] is always the current version of “A Primer on Internet and TCP/IP Tools and Utilities”).

What is now the official RFC database – the RFC Editor, published by the Internet Society – classifies documents by “status.” Standards track RFCs include standards, draft standards, and proposed standards. Other RFCs are classified as experimental, informational, historic, and early. The three sub-series, which provide a second set of identification numbers for documents involved, are Standards (STD), Best Current Practice (BCP), and For Your Information (FYI). This database also includes some information on the relation of documents to each other, month of publication, and authorship.

Defining the Internet

The Internet itself was defined through RFCs. Just as Rutkowski (1983) pointed out regarding another set of telecommunications network standards,11 the definition of the Internet has several faces ranging from an ideal conceptualization to concrete networks. RFC 1602 explicates three such definitions – the Internet as a set of standards, the process of developing the standards, and the physical network itself. Definition of the Internet as a “network of networks,” influential in policy circles after its introduction there by Noam (1994), first appeared in RFC 1122, authored by Braden, in 1989.

Establishing Internet design processes

RFCs are used to design Internet decision-making processes themselves. RFC 2014, for example, described how the Internet Research Task Force is supposed to work, RFC 2028 specifies each of the organizations to be involved in Internet standard-setting, and RFC 2727 details the procedures by which the Internet Advisory Board (IAB) and Internet Engineering Steering Group (IESG) should nominate and recall committee members. RFC 2350's explanation of what can reasonably be expected from the Computer Security Incident Response organization lists issues and topics to be considered relevant to the security community and specifies the types of information incident response teams should provide. RFC 2418 defines formal relationships among IETF participants and provides guidelines for working procedures. RFC 2850 is the Charter of the Internet Architecture Board.

Other features of technical Internet decision-making are also created by RFCs. RFCs 1122 and 1123, for example, detail how to write proposed standards in the most effective and useful manner. RFC 1602 describes the three stages of Internet standards development. RFC 1652 looks at relationships between RFC e-mail standards and previously unrelated standards for the coding and representation of diverse data types. RFC 1752 sets up a quarterly report system for standards updates. RFC 2026 covers specification review processes and copyright issues. Responding to governmental and civil society complaints that Internet decision-making is non-democratic, RFC 3797 offers a random (algorithmically-driven) selection process for public members of IETF.

Time taken for Web searching

Establishing policies and figuring out how to implement them are two different things. Implementation explanations are offered to technical experts in RFC 1359 (issues with which connecting institutions must deal), RFC 1930 (guidelines for creating internal networks), RFC 2050 (rules for the allocation of IP addresses), and RFC 2196 (a handbook on site security).

Lay users are addressed in RFC 1178 (how to name computers), RFC 1635 (how to use FTP), and RFC 1709 (networking guidelines for K-12 education). “Netiquette” was introduced in RFC 1855. RFC 2504 offers a plain language discussion of online risks and how to avoid them, and RFC 2635 does the same for spam.

Conflict and conflict resolution

RFCs are one among many sites for conflicts among vendors over standards. Thus Toshiba published RFC 2098 to announce its router architecture, and Cisco used RFC 2105 to do the same for a “tag switching architecture.”

RFCs have also been used for conflict resolution. Stimulated by a Motorola claim that a particular protocol inappropriately involved a company patent, for example, RFC 1915 outlines procedures used for resolution of such disputes.

Informal problem-solving

Informal problem-solving efforts, too, appear in RFCs. In one important example, after it had become clear that the original Internet address space would be overwhelmed with demand, two documents propose temporary solutions – RFC 1917 appeals to the Internet community to return unused addresses to the responsible authority, and RFC 1918

Political analysis

Studying the RFCs as a discourse provides evidence of use for the purposes of political, as well as policy, analysis. RFC discussions of the concepts of citizenship and jurisdiction, for example, are pertinent for those studying transformations of the state, the development of global citizenship, and globalization of the law, for example. Those RFCs that discuss citizenship include some that refer to relationships to geopolitically recognized governments such as the United States, but the majority are concerned instead with the notion of network citizenship. Similarly, RFCs that incorporate the concept of jurisdiction (the bounding of the space within which specific legal or law-like authorities govern) move back and forth between references to jurisdiction as it is defined geopolitically and as it is defined by Internet domain.

Conclusions

It is one thing to state theoretically that governance and governmentality are as important as government during periods of turbulence in state-society-law relations, but another to develop methodologies for actually engaging in policy analysis for these quite different decision-making environments. Preliminary analysis of the Internet RFCs as a highly influential decision-making discourse that has also provided a model for other decision-making involving technical matters demonstrates that this will be a fruitful approach for understanding how decisions about technology design and network architecture are, today, de facto social policy. This decision-making will not replace that of governments, but better understanding the effects of technical decisions should enhance the effectiveness of governmental policy-making, expand the range of policy tools available, and provide a space within which technical and political decision-makers can think together.

Acknowledgements

This material is based upon work supported by the National Science Foundation under rant No. 0823265. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author and do not necessarily reflect the views of the National Science Foundation.

RFCs Cited

  • RFC 1, Host Software, S. Crocker, April, 1969.

  • RFC 2, Host Software, B. Duvall, April, 1969.

  • RFC 3, Documentary Conventions, S. Crocker, April, 1969.

  • RFC 101, Notes on the Network Working Group Meeting, R. W. Watson, February, 1971.

  • RFC 527, Arpawocky, R. Merryman, May, 1973.

  • RFC 799, Internet Domain Names, D. L. Mills, September, 1981.

  • RFC 819, Domain Naming Convention for Internet User Applications, Z. Su & J. Postel, August, 1982.

  • RFC 920, Domain Requirements, J. Postel & J. K. Reynolds, October, 1984.

  • RFC 1004, Distributed-Protocol Authentication Scheme, D. L. Mills, April, 1987.

  • RFC 1015, Implementation Plan for Interagency Research Internet, B. M. Leiner, July, 1987.

  • RFC 1094, NFS: Network File System Protocol Specifications, Sun Microsystems, March, 1989.

  • RFC 1121, Act one: The poems, J. Postel, L. Kleinrock, V. G. Cerf, & B. Boehm, September, 1989.

  • RFC 1122, Requirements for Internet Hosts: Communication Layers, R. Braden (Ed.), October, 1989.

  • RFC 1123, Requirements for Internet Hosts: Application and Support, R. Braden (Ed.), October, 1989.

  • RFC 1149, Standard for the Transmission of IP Datagrams on Avian Carriers, D. Waitzman, April, 1990.

  • RFC 1176, Interactive Mail Access Protocol: Version 2, M. R. Crispin, August, 1990.

  • RFC 1178, Choosing a Name for Your Computer, D. Libes, August, 1990.

  • RFC 1192, Commercialization of the Internet: Summary Report, B. Kahin (Ed.), November, 1990.

  • RFC 1336, Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members, G. Malkin, May, 1992.

  • RFC 1355, Privacy and Accuracy Issues in Network Information Center Databases, J. Curran & A. Marine, August, 1992.

  • RFC 1359, Connecting to the Internet: What Connecting Institutions Should Anticipate, ACM SIGUCCS, August, 1992.

  • RFC 1602, The Internet Standards Process: Revision 2, Internet Architecture Board, Internet Engineering Steering Group, March, 1994.

  • RFC 1630, Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as Used in the World-Wide Web, T. Berners-Lee, June, 1994.

  • RFC 1633, Integrated Services in the Internet Architecture: An Overview, R. Braden, D. Clark, & S. Shenker, June, 1994.

  • RFC 1635, How to Use Anonymous FTP, P. Deutsch, A. Emtage, & A. Marine, May, 1994.

  • RFC 1652, SMTP Service Extension for 8bit-MIME Transport, J. Klensin, N. Freed, M. Rose, E. Stefferud, & D. Crocker, July, 1994.

  • RFC 1709, K-12 Internetworking Guidelines, J. Gargano & D. Wasley, November, 1994.

  • RFC 1752, The Recommendation for the IP Next Generation Protocol, S. Bradner & A. Mankin, January, 1995.

  • RFC 1776, The Address is the Message, S. Crocker, April, 1995.

  • RFC 1818, Best Current Practices, J. Postel, T. Li, & Y. Rekhter, with the endorsement of the Internet Engineering Steering Group, August, 1995.

  • RFC 1855, Netiquette Guidelines, S. Hambridge, October, 1995.

  • RFC 1915, Variance for the PPP Compression Control Protocol and the PPP Encryption Control Protocol, F. Kastenholz, February, 1996.

  • RFC 1917, An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the Internet Assigned Numbers Authority (IANA), P. Nesser, II, February, 1996.

  • RFC 1918, Address Application for Private Internets, Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. deGroot, & E. Lear, February, 1996.

  • RFC 1930, Guidelines for Creation, Selection, and Registration of an Autonomous System (AS), J. Hawkinson & T. Bates, March, 1996.

  • RFC 1983, Internet Users' Glossary, G. Malkin (Ed.), August, 1996.

  • RFC 2007, Catalogue of Network Training Materials, J. Foster, M. Isaacs, & M. Prior, October, 1996.

  • RFC 2008, Implications of Various Address Allocation Policies for Internet Routing, Y. Rekhter & T. Li, October, 1996.

  • RFC 2014, Internet Research Task Force (IRTF) Research Group Guidelines and Procedures, A. Weinrib & J. Postel, October, 1996.

  • RFC 2026, The Internet Standards Revision Process: Revision 3, S. Bradner, October, 1996.

  • RFC 2028, The Organizations Involved in the Internet Engineering Task Force (IETF) Standards Process, R. Hovey & S. Bradner, October, 1996.

  • RFC 2050, Internet Registry IP Allocation Guidelines, K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, & J. Postel, November, 1996.

  • RFC 2098, Toshiba's Router Architecture Extensions for ATM: Overview, Y. Katsube, K. Nagami, & H. Esaki, February, 1997.

  • RFC 2105, Cisco Systems' Tag Switching Architecture Overview, Y. Rekhter, B. Davie, D. Katz, E. Rosen, & G. Swallow, February, 1997.

  • RFC 2109, HTTP State Management Mechanism, D. Kristol & L. Montulli, February, 1997.

  • RFC 2119, Key Words for Use in RFCs to Indicate Requirement Levels, S. Bradner, March, 1997.

  • RFC 2151, A Primer on Internet and TCP/IP Tools and Utilities, G. Kessler & S. Shepard, June, 1997.

  • RFC 2196, Site Security Handbook, B. Fraser, September, 1997.

  • RFC 2227, Simple Hit-Metering and Usage-Limiting for HTTP, J. Mogul & P. Leach, October, 1997.

  • RFC 2235, Hobbes' Internet Timeline, R. Zakon, November, 1997.

  • RFC 2277, IETF Policy on Character Sets and Languages, H. Alvestrand, January, 1998.

  • RFC 2350, Expectations for Computer Security Incident Response, N. Brownlee & E. Guttman, June, 1998.

  • RFC 2360, Guide for Internet Standards Writing, G. Scott, June, 1998.

  • RFC 2418, IETF Working Group Guidelines and Procedures, S. Bradner, September, 1998.

  • RFC 2430, A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE), T. Li & Y. Rekhter, October, 1998.

  • RFC 2458, Toward the PSTN/Internet Inter-Networking: Pre-PINT Implementations, H. Lu, M. Krishnaswarmy, L. Conroy, S. Bellovin, F. Burg, A. DeSimone, K. Tewani, P. Davidson, H. Schulzrinne, & K. Vishwanathan, November, 1998.

  • RFC 2468, I Remember IANA, V. Cerf, October, 1998.

  • RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, K. Nichols, S. Blake, F. Baker, & D. Black, December, 1998.

  • RFC 2475, An Architecture for Differentiated Service, S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, & W. Weiss, December, 1998.

  • RFC 2504, Users' Security Handbook, E. Guttman, L. Leong, & G. Malkin, February, 1999.

  • RFC 2505, Anti-Spam Recommendations for SMTP MTAs, G. Lindberg, February, 1999.

  • RFC 2555, 30 Years of RFCs, RFC Editor, et al., April, 1999.

  • RFC 2635, DON'T SPEW: A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam), S. Hambridge & A. Lunde, June, 1999.

  • RFC 2727, Internet Architecture Board (IAB) and Internet Engineering Steering Group (IESG) Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees, J. Galvin, February, 2000.

  • RFC 2804, IETF Policy on Wiretapping, IAB & IESG, May, 2000.

  • RFC 2828, Internet Security Glossary, R. Shirey, May, 2000.

  • RFC 2850, Charter of the Internet Architecture Board (IAB), Internet Architecture Board, B. Carpenter (Ed.), May, 2000.

  • RFC 2965, HTTP State Management Mechanism, D. Kristol & L. Montulli, October, 2000.

  • RFC 3160, The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force, S. Harris, August, 2001.

  • RFC 3187, Using International Standard Book Numbers as Uniform Resource Names, J. Hakala & H. Walravens, October, 2001.

  • RFC 3188, Using National Bibliography Numbers as Uniform Resource Names, J. Hakala, October, 2001.

  • RFC 3536, Terminology Used in Internationalization in the IETF, P. Hoffman, May, 2003.

  • RFC 3797, Publicly Verifiable Nominations Committee (NomCom) Random Selection, D. Eastlake, III, June, 2004.

  • RFC 3837, Security Threats for Open Pluggable Edge Services (OPES), A. Barbir, O. Batuner, B. Srinivas, M. Hofmann, & H. Orman, August, 2004.

  • RFC 3978, IETF Rights in Contributions, S. Bradner (Ed.), March, 2005.

  • RFC 4096, Policy-Mandated Labels such as “Adv:” in Email Subject Headers Considered Ineffective at Best, C. Malamud, May, 2005.

  • RFC 4237, Voice Messaging Directory Service, G. Vaudreuil, October, 2005.

  • RFC 4734, Definition of Events for Modem, Fax, and Text Telephony Signals, H. Schulzrinne & T. Taylor, December, 2006.

  • RFC 4869, Suite B Cryptographic Suites for IPsec, L. Law & J. Solinas, May, 2007.

  • RFC 5031, A Uniform Resource Name (URN) for Emergency and Other Well-Known Services, H. Schulzrinne, January, 2008.

  • RFC 5066, Ethernet in the First Mile Cooper (EFMCu) Interfaces M1B, E. Beli, November, 2007.

  • RFC 5111, Experiment in Exploratory Group Formation within the IETF, B. Aboba & L. Dondeti, January, 2008.

  • RFC 5115, Telephony Routing over IP (TRIP) Attribute for Resource Priority, K. Carlberg & P. O'Hanlon, January, 2008.

  • RFC 5134, A Uniform Resource Name Namespace for the EPCglobal Electronic Product Code (EPC) and Related Standards, M. Mealing, January, 2008.

  • RFC 5228, Sieve: An Email Filtering Language, P. Guenther & T. Showalter (Eds.), January, 2008.

  • RFC 5235, Sieve Email Filtering: Spamtest and Virustest Extensions, C. Daboo, January, 2008.

Footnotes

  1. 1

    1 Rutkowski was writing about the Integrated Services Digital Network (ISDN) protocols, which were the first to be agreed upon in order to enable the creation of a public telecommunications network that would simultaneously support transmission of data, voice, images, and any other kind of digitized information. Decision-making for the ISDN took place in a standard-setting committee (the CCITT) of the International Telecommunications Union (ITU), and were approved in 1980, releasing a spate of network-building and manufacturing activities around the world that, a decade later, merged with those of the Internet.

Ancillary