[extropy-chat] Agreement on principles. (was Microsoft)

[Eugen Leitl]

On Sun, May 21, 2006 at 11:17:19AM -0400, John K Clark wrote:
> "Eugen Leitl" <eugen at leitl.org>
> 
> > democracy can NEVER work better than a free market in the long run.

I wrote that with a giant tongue in cheek, of course. To lead
KAZ's position ad absurdum. I'm sorry you took this at face value.
 
> You are absolutely positively 100% correct Eugen, and that's why I find your
> position puzzling. A bunch of Linux nerds voted on a E mail standard in a

Calling the IETF a 'bunch of Linux nerds' is like calling James 
Watt and Rudolf Diesel car mechanics. 

http://www.garykessler.net/library/ietf_hx.html

It is often said that the Internet is one of the best success stories of anarchy or, even, socialism in modern history. The Internet has proven itself to be an example of cooperation between countries, (often-competing) commercial entities, government agencies, and educational institutions for the sole purpose of enhancing communication. Yet even this loose cooperative requires some central administrative authority for such things as operational guidelines, protocol specifications, and address assignment.

The key to the success of communication over the Internet is the use of a standard set of protocols, based on TCP/IP. The Internet Engineering Task Force (IETF) is the group that oversees the Internet standards process. This chapter will focus on the history of the IETF, its organization and function, and, in particular, its role in developing Internet security specifications.

The Evolving Administration of the Internet

The Internet began as a project funded by the U.S. Department of Defense (DoD), as an experiment in the use of packet switching technology. Starting with only four nodes in 1969, the ARPANET spanned the continental U.S. by 1975 and was reaching to other continents by the end of the 1970s.

In 1979, the Internet Control and Configuration Board (ICCB) was formed. The charter of the ICCB was to provide an oversight function for the design and deployment of protocols within the connected Internet.

In 1983, the ICCB was renamed as the Internet Activities Board (IAB). With an original charter similar to that of the ICCB, the IAB evolved into a full-fledged de facto standards organization dedicated to ratifying standards used within the Internet. The Chairman of the IAB was called the Internet Architect. That individual's major function was to coordinate the activities of numerous task forces within the IAB, each of which focused on a specific architectural or protocol issue.

In 1984, the ARPANET was split into two components: the ARPANET, used for research and development, and MILNET, used to carry unclassified military traffic. With this division, designation of TCP/IP as the official protocol suite, and subsequent National Science Foundation (NSF) funding, the modern Internet was born.

In 1986, the IAB was reorganized to provide an oversight function for a number of subsidiary groups. The Internet Research Task Force (IRTF) was put into place to oversee research activities related to the TCP/IP protocol suite and the architecture of the Internet. The activities of the IRTF are coordinated by the Internet Research Steering Group (IRSG). The IETF was formed to concentrate on short-to-medium term engineering issues related to the Internet.

The U.S. Internet has historically received funding from government agencies, such as the DoD, Department of Energy, NASA, and the NSF. By the end of the 1980s, it became apparent that this funding would decrease over time. In addition, the introduction of commercial users and an increasing number of commercial Internet service providers foreshadowed the loss of a dominate central administration which, in turn, threatened the long-term process for making Internet standards.

In January 1992, the Internet Society (ISOC) was formed with a charter of providing an institutional home for the IETF and the Internet standards process. ISOC provides a number of services in support of this role including sponsoring conferences and workshops, and raising funds from industry, government, and other sources. Although headquartered in the U.S., the ISOC is an international organization providing administrative support for the international Internet. Included in this administrative structure is the IAB, IETF, IRTF, and the Internet Assigned Number Authority (IANA)1.

To reflect its new role as a part of ISOC, the Internet Activities Board was renamed the Internet Architecture Board in June 1992. ISOC provides support for the IETF and IRTF, as they have historically been a part of the IAB.

The relationship between ISOC and the IETF has changed slightly each year as they both determine exactly what that relationship should be. In June 1995, the ISOC Board of Trustees confirmed that their main goal remains to "keep the Internet going." It is still committed to providing services that facilitate the standards process as carried out by the IETF.

IETF Overview and Charter

The IETF provides a forum for working groups to coordinate technical developments of new protocols. Its most important function is the development and selection of standards within the Internet protocol suite.

When the IETF was formed in 1986, it was a forum for technical coordination by contractors for the U.S. Defense Advanced Projects Agency (DARPA) working on the ARPANET, Defense Data Network (DDN), and Internet core gateway system. Since that time, the IETF has grown into a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet.

The IETF mission includes:

   1. Identifying, and proposing solutions to, operational and technical problems in the Internet.
   2. Specifying the development or usage of protocols and the near-term architecture to solve technical problems for the Internet.
   3. Facilitating technology transfer from the IRTF to the wider Internet community.
   4. Providing a forum for the exchange of relevant information within the Internet community between vendors, users, researchers, agency contractors, and network managers. 

Figure 1 shows the general hierarchy of the IETF. Technical activity on any specific topic in the IETF is addressed within working groups, which are organized roughly by function into nine areas. Each area is led by one or more Area Directors who have primary responsibility for that one aspect of IETF activity. Together with the Chair of the IETF, these technical directors compose the Internet Engineering Steering Group (IESG).

FIGURE 2. Internet Engineering Steering Group and IETF Areas

The WGs form the backbone of the IETF. In general, each WG is formed with a relatively narrow focus rather than looking at large problems. Furthermore, the WGs usually start with, or quickly define, a limited number of options with which to achieve their goals. When formed, each WG defines a charter with a specific set of goals and milestones. In addition, each WG maintains an Internet electronic mail discussion list and an on-line archive.

The working groups conduct business during IETF plenary meetings, meetings outside of the IETF, and via electronic mail. The IETF holds week-long plenary sessions three times a year. These meetings include working group sessions, technical presentations, network status reports, working group reports, and an open IESG meeting. Proceedings of each IETF plenary are published, which include reports from each area, each working group, and each technical presentation, as well as a summary of all current standardization activities. Meeting reports, working group charters and mailing list information, and general information on current IETF activities are available on-line via anonymous FTP and the World Wide Web (WWW).

Unlike most other "standards" groups, the plenary sessions and proceedings are not the only place where important work is accomplished and documented. In fact, most final decisions are made via e-mail or, at the very least, circulated by e-mail. One reason for this apparent looseness is that WG meetings and discussions are open to anyone within the Internet community (which includes just about everyone) with something to contribute.

In another departure from other "standards" groups, the IETF WGs do not require unanimity before progressing with work. Furthermore, only proven and working protocols become standards. One of the guiding forces of the Working Groups is the IETF Credo, attributed to David Clark:

    We reject kings, presidents, and voting.
    We believe in rough consensus and running code. 

The effect of this principle is that there is no formal voting within the WGs. Instead, disputes are resolved by discussion and demonstrations of working models. These discussions take place at the plenaries and on the discussion lists.

The result of the WG activities is the publication of various Internet documents. The IETF publishes two types of documentation:

    * Internet-Drafts (ID) are working documents, and referred to as a "work in progress." IDs have no official status and expire after 6 months; they are not archived beyond their expiration date. The IETF Secretariat distributes the announcement for new Internet-Drafts.
    * Request for Comments are the literature of the Internet. In particular, they are the series of documents that provide an historical record of the IAB. RFCs are edited, assigned a number, and announced by the RFC Editor. 

There are four categories of RFC:

    * Historic refers to an RFC that is important for historic purposes, but is unlikely to become (or remain) an Internet standard either due to lack of interest or because it has been superseded by later work. Examples include the Common Management Information Services over TCP/IP (CMOT) specification (RFC 1189) and the Border Gateway Protocol version 3 (BGP-3; RFCs 1267 and 1268).
    * Experimental refers to an RFC describing experimental work related to the Internet and not a part of an operational service offering. Examples (as of November 1995) are the Stream Protocol Version 2 (ST2; RFC 1819)and UNARP (RFC 1868).
    * Informational refers to RFCs that provide general, historical, and tutorial information for the Internet community; these are usually produced by a standards organization or other group or individual outside of the IESG. Examples are the Novell IPX Over Various WAN Media (IPXWAN) specification (RFC 1634) and A Primer on Internet and TCP/IP Tools (RFC 1739).
    * Standards Track refers to RFCs that are intended to become Internet standards. 

There are three classes of Standards Track RFCs:

    * A Proposed Standard is a complete, credible specification that has a demonstrated utility for use on the Internet. A Proposed Standard has an expiration date from between 6 months and 2 years of the publication date, by which time it must be elevated to a higher status, updated, or withdrawn.
    * A Draft Standard is written only after there have been several independent, interoperable implementations of a specification. Draft Standards usually reflect some limited operational experience, but enough knowledge that the specification seems to work well. A Draft Standard has an expiration date from between 4 months and 2 years of the publication date, by which time it must be moved to a different status, updated, or withdrawn. Examples (as of November 1995) are the HyperText Markup Language (HTML) version 2 (RFC 1866) and Relative Uniform Resource Locators (URLs; RFC 1808).
    * An Internet Standard is "the real thing" and refers to specifications with demonstrated operational stability; examples are IP (RFC 791; also known as STD 5) and TCP (RFC 793; also known as STD 7). An RFC can stay as a Standard forever or may be reclassified as Historic. 

> democratic election and you regard their decree as gospel, Holy Writ, a
> fundamental law of the universe. Meanwhile the free market has decided that
> it prefers a different standard set by outlook express and you treat it
> with contempt.

Again, there are "no different standards", one suiting for anybody to pick.
Choosing on which side of the road to drive is not open to subjective
interpretation.  

If you choose the default MUA of a particular desktop OS which has a known
bug (being unable to parse RFC2015 signatures), I recommend you submit a
bug report with your vendor. Or choose a MUA which has no such issues:

http://www.spinnaker.de/mutt/rfc2015.html

The list is out of date, though. You might or might not be able
to read RFC2015 signed messages with PGP installed -- no gurantees, though.
 
> And by the way Eugen, it's a tribute to how much I value your messages that
> I took the trouble to open a attachment and then scroll continuously to the
> right as your words wandered aimlessly off my screen; but I don't think I
> can keep that up much longer.

Again, I'm sorry you choose to stick to a broken system.
This behaviour you describe is unacceptable, but I'm not
responsible for a broken implementation, and I won't sign
inline for unrelated, technical reasons.

-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820            http://www.ativel.com
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE