Network Working GroupC. Malamud
Internet-DraftMemory Palace Press
Expires: June 1, 2005December 1, 2004

Interim Status Report on Data Flows


Status of this Memo

This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at

This Internet-Draft will expire on June 1, 2005.

Copyright Notice

Copyright (C) The Internet Society (2004).


This document is an interim status report and focuses on workflow characterization of IETF support processes.

Discussion and Document Source

This document may be found in alternative formats at the location listed in the self-citation. [.]Malamud, C., Interim Status Report on Data Flows, December 2004. Comments may be sent directly to the author at or to the appropriate IETF mailing list.


The key words "YMMV", "Cruft", "Rat Hole", "Good Thing", "Clue", and "IMHO" in this document are to be interpreted as described in [FOLDOC]Howe, D., Ed., Free On-Line Dictionary of Computing, 2004..

Table of Contents

1.  Context
2.  Formal Methodologies for Comprehensive Data Flow Requirements
3.  Alternative Methodology Used
4.  Archives
5.  Hosting
6.  Meetings
7.  Data Flows and Tracking
8.  Analysis
9.  Acknowledgments
10.  Security Considerations
11.  IANA Considerations
12.  References
§  Author's Address
A.  Analysis of IANA Activity
B.  Analysis of IESG Activity
C.  Analysis of RFC Editor Queue Movements
D.  Analysis of State Transition Diagrams
    D.1  IESG State Transition Table
    D.2  Generic Pause State Transitions
    D.3  RFC Editor State Transitions
    D.4  Analysis of the Analysis
E.  Analysis of Mailing List Archives
F.  IETF-Related Mirrors
G.  Main Hosts in the IETF Domain
H.  Statistics On IETF Mail List Traffic
I.  Statistics On IMC Mail List Traffic
§  Intellectual Property and Copyright Statements


1. Context

This document is one of several deliverables under a consulting contract in support of administrative restructuring activities, the text of which is included in Appendix A of [I-D.malamud-consultant-report]Malamud, C., IETF Administrative Support Functions, September 2004.. That contract specified a scope of work with three types of activities:

  1. Administrative restructuring: documentation and support, as appropriate, to the continued evolution of the restructuring effort, which shall be periodically reviewed by the IAB, IESG and other appropriate parts of the IETF community of interest.
  2. Data Flow: a comprehensive set of requirements for implementing appropriate tracking of IETF/IAB documents and reporting of status across support organizations.
  3. Negotiated contracts, per the above, that are acceptable to all concerned parties and are ready for execution.

In support of Deliverable 1, [I-D.malamud-consultant-report]Malamud, C., IETF Administrative Support Functions, September 2004. was issued as part of a chain of activities, including plenary presentations, extensive IETF list discussions, and a variety of other drafts, including [RFC3716]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004., [I-D.daigle-adminrest]Daigle, L., A Proposal for IETF Administrative Restructuring, February 2004., [I-D.wasserman-iasa-bcp]Wasserman, M., Austein, R., Daigle, L. and B. Wijnen, Structure of the IETF Administrative Support Activity (IASA), October 2004.. A joint IAB/IESG Recommendation in [I-D.iab-iesg-adminrest-rec]Hollenbeck, S., IAB and IESG Recommendation for IETF Administrative Restructuring, October 2004. has resulted in a working draft of a BCP RFC with the Internet Society in [I-D.ietf-iasa-bcp]Austein, R. and B. Wijnen, Structure of the IETF Administrative Support Activity (IASA), December 2004..

This document focuses primarily on Deliverable 2. In Deliverable 1, the author spoke in what has been referred to as the "ambiguous first person plural" which meant that there were lots of sentences that attempted to avoid presupposing community consensus on any given topic, however one might define that topic. For the present document, the author hopes the community will forgive me for speaking in the first person singular and I hope I don't offend anybody by doing so. As always, all opinions are strictly my own.


2. Formal Methodologies for Comprehensive Data Flow Requirements

In an attempt to provide a formal analysis of the data flow issues, a variety of formal methodologies were examined including [WRM]Hollingsworth, D. and Workflow Management Coalition, The Workflow Reference Model, January 1995., [YAWL]van der Aalst and A. ter Hofstede, YAWL: Yet Another Workflow Language (Revised version), 2003., and [UML-Patterns]Dumas, M. and A. ter Hofstede, UML Activity Diagrams as a Workflow Specification Language, 2001.. While many of these techniques appear potentially quite useful in other circumstances, they don't appear directly applicable to the task at hand, though it was certainly interesting to look at flash animations of various workflow patterns (see, e.g., [WFPattern]van der Aalst and V. Almering, Flash Animation of Interleaved Parallel Routing Workflow, 2003.).

If the IETF were a single organization with a unified chain of command, such an analysis might be a useful step. However, providing a formal model of the data flows without considering the political realities of several different support institutions, several decision making bodies, and an uncertain MIS structure just didn't seem like it would yield useful results in a measurable timeframe.


3. Alternative Methodology Used

An another approach seemed possible by carefully parsing the words "document data flows" with a fairly liberal interpretation so that the phrase reads "make a copy of all the data and see what is there." As such, I began a systematic effort to mirror any IETF-related data on the key IETF sites. In addition, I began a process of scouring the net looking for archives that are stored outside of the domain. I made mirrors of efforts from other people, such as Geoff Huston's, Noritoshi Demizu's, and the IESG's tracker at I also drew on a variety of other resources including maintained by Paul Hoffman, the tools maintained by Henrik Levkowetz, and as always, I drew heavily on, which is maintained by Marshall T. Rose.

In addition, I've attempted to track closely the organized work taking place throughout the IETF, in particular the newtrk and tools groups. The IANA has recently released a queue report, as does the RFC-Editor.

To make sure I understood the formal data flows, I examined IANA activity (see Appendix AAnalysis of IANA Activity), IESG activity (see Appendix BAnalysis of IESG Activity), RFC-Editor queue movements (see Appendix CAnalysis of RFC Editor Queue Movements), and the published state transition diagrams (see Appendix DAnalysis of State Transition Diagrams). I also mirrored and looked closely at "official" web sites (such as,,,, and, semi-official sites (such as,,,, and, and followed as many links as I could from those pages (e.g., mailing list archives and web sites maintained on other sites). I deliberately ignored several sites, such as,, and

These data were used to look at a variety of issues, including archives (a key requirement of [RFC3716]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004.), hosting, meeting support, and overall data flow and tracking.


4. Archives

The most striking conclusion I reached was that the IETF archives are a bit of a mess. Foretec maintains a complete archive of Internet-Drafts, as do a variety of other volunteer efforts. All but 200 of the RFCs are on-line and are heavily mirrored. [RFC-Online]RFC Editor, Current Status of the RFC-Online Project, November 2004. Documentation of meetings has been done quite well, with the on-line Proceedings. But, archives are more than Internet-Drafts, RFCs, and minutes. They include mailing list traffic, web sites, jabber chat room logs, and paper such as meeting sheets or formal transmissions from other bodies (e.g., transmittals from SDOs and subpoenas). A more expansive definition would include video and audio from meetings.

Simply put, the IETF does not systematically archive data. Mailing lists are the most striking example. Of the core lists archived on, 39 groups had null archives in November, 2004 (see Appendix EAnalysis of Mailing List Archives). In addition, a large number of mailing lists are archived outside of the domain, and many of those have gone missing as well (see Appendix FIETF-Related Mirrors).

While the mail archives are incomplete, most other data are simply not archived. No efforts are made, as far as I could tell, to keep copies of the more ephemeral material such as jabber logs or other material in a central archive.

What is heartening, however, is the number of volunteer efforts that have sprung up to maintain archives. It is possible that, in the long run, the archiving function can be a distributed one, carried out by a variety of groups around the net. However, before that is possible a systematic effort will have to be made to recover some data that is desiccating from neglect.

How big an archive are we talking here? A comprehensive archive of all our data, with the exception of streaming media, will fit comfortably for many years inside of 100 gigabytes. My current mirror of IETF-related resources is about 23 gigabytes, which is missing some data and duplicates other data.

Archives are not one of those "nice to have" things. A comprehensive set of meeting proceedings mailing list archives are a full requirement of [RFC2026]Bradner, S., The Internet Standards Process -- Revision 3, October 1996. and are a requirement for the IETF to be a full-fledged standard body with all that entails such as limitations of liability for participants.


5. Hosting

The IETF maintains a set of public servers, several of which are maintained by Foretec. They maintain a status page for the core systems which handle mail, draft tracking and two systems for the web. In addition, a variety of systems are maintained by volunteers as semi-official area web sites, trouble ticket tracking, and other functions.

In Appendix GMain Hosts in the IETF Domain, I used some simple tools on some of these hosts to try and determine some basic information, such as the operating system, bandwidth, and performance. I did not do a comprehensive analysis, which would have required multiple observation points on the net andsamples over time.

What was clear, however, is that the IETF maintains even core web sites (e.g., sites for areas) in many different places. The sites vary from very high-performance, such as, which is maintained by Randy Bush with OC3 connectivity and a variety of other accouterments, to some with lower performance characteristics.

In addition to web and ftp hosting, I did some simple analysis on the numbers of messages, average size, and amount of time to deliver messages on various mailing list. Appendix HStatistics On IETF Mail List Traffic shows the traffic for ietf-discuss and Appendix IStatistics On IMC Mail List Traffic shows similar data for a variety of lists maintained at by Paul Hoffman. As with other services that make up the IETF support infrastructure, mail is widely distributed and control is highly decentralized.

How "big" an operation is needed to support the core part of the IETF? That depends on how the pieces get stitched together. However, just to give an order of magnitude, one can look at the current system. As discussed in the previous section, we fit inside of 100 gigabytes comfortably, though we have to spread our operations over a half-dozen systems in order to serve the information effectively to the net. Bottom line: a well-provisioned rack, probably replicated in a few places, would definitely do the trick in terms of computing power and storage.

In terms of bandwidth, the current central systems sit inside of approximately 1.5-3Mbps of capacity. It would not be extremely difficult, as discussed in the closing analysis, to use a variety of peering points and/or hosting facilities to providing a sustained throughput of several tens of Mbps, which appears more than adequate for our traffic.


6. Meetings

The IETF is, in one sense, the result of the paper flow: decisions and announcements, publication of drafts, publication of RFCs, updating of IANA registries. On the other hand, it is a community where we learn from each other, make each other's work better, and achieve interoperability and consensus. Meetings are an important part of keeping that community alive. Although attendance at meetings is not a single defining aspect of participation in the IETF, meetings are where some key decisions and non-decisions are made.

Meeting support has evolved over the years. Meetings began on a college model, then grew to the point where hotels and professional meeting planning became a necessity. That is clearly still the case and the IETF administrative support activity needs to continue to include professional meeting planning support.

There is more to meetings than the rooms, however, and a defining characteristic of IETF meetings is a state-of-the-art network. This has always been carried out by our hosts for a particular meeting and by other volunteers. At first, the IETF used the "sponsor" model where some poor engineer gets delivered the news by management ("I signed us up to host the next IETF, can you do something about these computers?").

Supplementing the hosts have always been a network of volunteers known as the Network Operating Center (NOC) team. Over the last few years, the NOC has become increasingly important as we have shifted away from a model where the "host" bears the brunt to one where a stable set of NOC team members help coordinate each meeting, supplemented by a large number of other resources drawn from sponsors and contributors.

Assembling the gear, bits, and bodies required to support an IETF meeting is a non-trivial task. We have come to expect the kind of network where a high-speed somewhat-secure LAN has to coexist with, for example a requirement to route IPv6 throughout the meeting network while still taking care of little details like inadvertent ad hoc networks or sick operating systems spewing anything from ARP to worms. In addition to this infrastructure (which gets typically installed in under 48 hours, sometimes in a window as short as 8 hours), we've also come to expect high-performance, large-scale chat rooms and, of course, audio and video transmissions.

All these activities are being done by volunteers. But, there is evidence that we have to change how we support these volunteers if we expect to have the same quality show network in the future.

Simply put, the IETF as an organization has made no systematic efforts to support meeting network infrastructure. Audio/video streaming is a good example of this. Based on a "wild idea" by Allison Mankin, starting in 1992 audio transmissions from the meeting were sent out to 20 or so users by a team that included Stephen Casner, Stephen Deering, Van Jacobson, and many other noted participants. [IETF-TV]Casner, S. and S. Deering, First IETF Internet Audiocast, June 1992. From 1995 onwards, Evi Nemeth led a team of graduate students to provide the service for many IETF meetings. And, since IETF 49 in December 2000, a similar service has been provided by the University of Oregon's VideoLab (who have also consistently provided coverage for NANOG, ARIN, and other important meetings). A variety of other groups and hosts have also pitched in from time to time.

Perhaps it is the nature of a volunteer-driven network, but in the short period of time I've been going to IETF meetings [IETF19]The IETF, Proceedings of the Nineteenth IETF Meeting, December 1990., the "terminal room" and the "ietf-tv" efforts have always seemed to lurch from meeting to meeting. Only in the last few years has some stability been achieved with the two teams that have signed up to support us. But, this is not a long-term solution, as was underscored at the BOF held at IETF 61 in Washington, D.C. where the future of the "ietf-tv" effort was discussed in uncertain terms.


7. Data Flows and Tracking

My original goal in attempting this study was to examine how one might arrive at a "comprehensive set of requirements for implementing appropriate tracking of IETF/IAB documents and reporting of status across support organizations."

I step here onto somewhat thin ice, but in many cases, this appears to be the wrong thing to be looking for. Let us start with the tracking of IESG documents, the most demanding part of the IETF machine in some respects simply because it is the beginning of the process and thus receives the most documents (see Appendix BAnalysis of IESG Activity).

The document tracking system at presents an interface for end users (e.g., document authors) and expanded access for Area Directors. Interviews with IESG members indicate that the presence of this datatracker has had a very strong impact on their productivity, freeing them from myriad tasks.

The datatracker has also automated a variety of tasks that were previously manually preformed and thus subject to manual errors. The current system handles ballot management, approval completion, last call generation for documents, and document approval announcements. Version or type errors are no longer introduced into announcements as the system is able to track multiple revisions of a draft. Mail is automatically created for area directors to alert them of a revision and working group chairs and editors are notified of state changes to their documents. The bulk of the agendas for the bi-weekly IESG teleconference calls are automatically generated.

This datatracker tool, which was developed at the request of the IESG using funds from IETF meeting attendees, is certainly not the only approach, but the current system clearly works. If further automation steps are necessary and other approaches prove more cost-effective or productive, it will not be difficult to transition the current system into other databases and other interfaces. The current system seems to meet the goal of being able to track documents and report status. Clearly some administrative assistance is needed for the IESG to support their work, but the core work flow seems pretty well defined.

The only issue I've found in looking at this portion of the data flow is that the source code for the datatracker is not visible and the database cannot be trivially mirrored, making it much harder for volunteers to work with and enhance the system. Since the development of this system was funded through the IETF, there are no intellectual property reasons this information should not be available.

In my opinion, Foretec should make a copy of the source code and regular dumps or phpmyadmin access to the IETF's datatracker available to the IETF community as soon as possible. If the IESG feels that certain parts of that system should remain confidential (e.g., the notes and comments used for their own deliberations), they should publish an announcement detailing which portions should remain under access control within the same timeframe.

[RFC3716]Advisory, IAB., The IETF in the Large: Administration and Execution, March 2004. spoke a lot about the IANA and the RFC Editor, as well as the IETF Secretariat. The core issue with the IETF Secretariat has been quite simple: a 1989 agreement between CNRI and NSF [NSF]National Science Foundation, Support for Research Internetting, August 1997 Amendment, August 1995. to support our activities expired and the community failed to replace that agreement with something else after the U.S. government got out of the business of funding the IETF.

In the case of the IANA and the RFC Editor, however, there is a paper trail, and so I think, and here ymmv, that there is a deeper issue than a simple lack of a formal contract. The issue seems not so much lack of specificity in the data flows as sincere disagreements over how things should be done or perhaps over who says to whom that something should be done.

When we treat the maintenance of registries and the publication of our archival series as vendor tasks, we're falling into a Taylor Trap of turning members of our community into the SDO-equivalent of cogs in some great machine that churns out standards. There is a flip side to that observation: as participants in our community, the IANA and the RFC Editor are not autonomous states or judicial bodies appointed in perpetuity: they draw their authority from the community. The IANA, for example, allocates ports, names and many other resources on behalf of the IETF community. There needs to be a consensus in the community on how these functions operate because they are such a vital part of our standards-making machinery.

A good illustration of this community relationship is in the case of the Office of the RFC Editor, upon which I'd like to spend a few cycles, though one could perform a similar analysis upon many of our other offices, groups, or procedures.

The institution of the RFC Editor is very real. Indeed it predates the IETF. It is an archival series of great importance, not only in the conventional sense of standards documents as ways for computers to interoperate, but as a fundamental scientific and cultural contribution. RFCs are unique, and they are unique because of the people who have produced those documents as authors, and because of the stewards of the series, Jon Postel, Bob Braden, Joyce Reynolds, Aaron Falk, and many others.

I examined the Office of the RFC Editor for a variety of reasons. Some were obvious: the Office is the single largest explained line item in the IETF budget (there might be larger expenses, but I am unable to break out "network infrastructure" or "support for the IESG" as separate line items).

I've read the Statement of Work and the contract. I've also spent a lot of time looking at the operation of the RFC publication machine. In the case of the basic function, which is to edit and publish the RFC series, the contract is pretty specific and I've never heard anybody question the exemplary qualifications and record of public service that the team has. The issue doesn't seem to be tweaking one of the existing contract parameters, such as reducing targetted turnaround time for RFC publication. If the problem isn't in "clarity of the contractual relationship", where is it?

There does appear to be a sincere disagreement about editorial policy. For example, [I-D.rosenberg-mankin-newtrk-rfc]Rosenberg, J. and A. Mankin, What's In a Name: RFC, October 2004. makes an extremely persuasive case that the independent submission process has been abused by some document authors. Rosenberg-Mankin cite as evidence two sets of standards, one the product of a working group and published as experimental, another sent in as an independent submission as informational. Compare, for example, [RFC3435]Andreasen, F. and B. Foster, Media Gateway Control Protocol (MGCP) Version 1.0, January 2003., which, with the powerful designation of the "RFC Brand", appears to some to have equal weight to the true product of a working group [RFC3525]Groves, C., Pantaleo, M., Anderson, T. and T. Taylor, Gateway Control Protocol Version 1, June 2003.. Rosenberg-Mankin are not alone in voicing concerns about the independent submission process, but the issue isn't a financial one: from August through October of 2004, of the 86 submissions to the RFC Editor queue only one was an independent submission. [RFC-Editor]RFC Editor, RFC Editor Report, November 2004.

I happen to disagree with the Rosenberg-Mankin conclusion that this means we should have fewer independent submissions and certainly disagree with the more extreme view that the RFC Editor should have no discretion whatsoever. My own opinion is that instead it means we need some clearer editorial policy direction, such as some pretty clear rules that anything that "looks like" it was "part of the standards process" and was not the product of a real working group should be edited out by the RFC Editor.

And, just so this isn't labeled as some unilateral attack on the RFC Editor, I do think the IESG could use a variety of state-of-the-art techniques in the front of any RFC they think might be misconstrued. For example, the IESG could insert a note which used CAPITAL LETTERS TO EMPHASIZE THEY DISAPPROVE, thus subtly but effectively emphasizing their non-association with the contents of the document.

Editorial policy is not the only area where the community appears to have an interest. For example, though the format of RFCs are officially governed by the mandatory requirements of the Informational [RFC2223]Postel, J. and J. Reynolds, Instructions to RFC Authors, October 1997., in reality authors must conform to the work-in-progress [I-D.rfc-editor-rfc2223bis]Reynolds, J. and R. Braden, Instructions to Request for Comments (RFC) Authors, July 2004., or choose the alternative interpretation of [I-D.hoffman-rfc-author-guide]Hoffman, P., Instructions to Request for Comments (RFC) Authors, September 2004.. And, of course, the majority of authors appear to prefer the cookbook approach presented in [RFC2629]Rose, M., Writing I-Ds and RFCs using XML, June 1999. or the work-in-progress [I-D(!).mrose-writing-rfcs]Rose, M., Writing I-Ds and RFCs using XML (revised), April 2004..

Finally, a series of proposals are going through the newtrk working group that could create a new Internet Standards Track[I-D.ietf-newtrk-proposals]Black, D. and B. Carpenter, Proposals for a New IETF Standards Track, July 2004. a new class of meta-document, the ISD™, [I-D.ietf-newtrk-repurposing-isd]Klensin, J. and J. Loughney, Internet Standards Documentation (ISDs), September 2004. and a new category of standards action, the decrufting of the standards corpus[I-D.ietf-newtrk-cruft]Alvestrand, H. and E. Lear, Getting rid of the cruft: A procedure to deprecate old standards, October 2004.. And, of course, we shouldn't forget the period rat holes that surface on the ietf-discuss list on the question of the format of documents, the use of better graphics, or the appropriate role of ultramodern bleeding-edge technologies such as XML.

This may have been familiar ground to many readers, but I went over it for a simple reason: I don't see how better specificity of a contract with the Office of the RFC Editor is going to reduce the turn around time, lead to more efficient operations, or reduce lost token issues. And, more importantly, I don't see how such an contracting exercise will resolve any of the more fundamental issues. But, I do think that working together much more closely, actively considering the issues, and trying to find common ground might yield some real results over time.


8. Analysis

I have arbitrarily split administrative support for the IETF into several inter-related categories:

In going over this ground, I've presented a series of carefully selected facts, figures, and citations. The facts are open to much interpretation: I did not conduct a longitudinal study, did not make observations from several locations, did not vary the parameters and conduct a regression analysis, nor was my methodology subjected to extensive peer review. I did not tie my experimental techniques rigorously to the theoretical literature. Nonetheless, here is my analysis of the situation.

It has been tempting throughout the administrative restructuring exercise to think in monoliths: "the IETF" or "the IETF support infrastructure." There has been lots of talk about hiring professionals to do support and formalizing structures. There has been lots of talk about how we should bring professionals in to do certain jobs.

It is important here that the word professional is not misused. Most participants in the IETF process are volunteers, in the sense that their salary is not paid directly or indirectly by the IETF. However, these professionals voluntarily participate in working groups, author documents, chair working groups, take on AD or IAB responsibilities, and, as has been demonstrated in this document, carry out a huge number of MIS and meeting support tasks. In other words, the issue is not "volunteers" versus "professionals", the question is whether IETF participants will do a particular task or whether a contractor or employee will be paid by the IETF administrative and support activity or through other support avenues.

There are clearly some areas where some full-time help makes sense. The functions of the "Clerk's Office" are demanding, requiring intensive support for the the IESG and other bodies. Whether that function should consist simply of a couple of additional employees in the Office of the IAD or some form of contract is an open question and is not addressed here. Some other functions where professional help might make sense would be a full-time sysadmin, a program manager (e.g., the IAD), and some meeting planning assistance. However, it is important that the temptation to look for a single monolithic "turnkey solution" from a single vendor as that may tend to prevent us from considering more granular or efficient solutions and might make it harder for us to leverage the resources of our volunteer community.

There are large parts of our support infrastructure where, quite frankly, we're going to simply have to do at least some of it ourselves. After all, we're the ones with the "domain knowledge" and many in the community have formidable programming skills. Writing a simple tool for automated submission of Internet-Drafts, or enhancing the data tracker with new functionality doesn't seem like rocket science: this all fits in a small mySQL database with a few thousand tuples and it is not a huge deal to add a few PHP scripts on top of the database to show the status of a document or enter comments and actions. Simply put: our "MIS needs" are really not that great.

This doesn't mean, however, that the IETF shouldn't bring in professional contractors to help on specialized tasks. Our web sites, for example, could probably use a makeover. There are some very good people who do this kind of work for a living, it would take a lot of heavy lifting to sift through our complicated content, and issuing a contract makes sense.

The point is that this is a case-by-case analysis. What is needed is not a decision today on how we should support the IETF, but a decision-making structure that allows us to decide what we want on an on-going basis.

What concrete actions might we take? I don't know what the right answer is, but I will advance 3 concrete actions that, in my personal opinion, might help:

  1. Form Standing Working Groups Focused on Operations and Other Support Issues. My strongest recommendation is that the IETF should form some working groups to look at issues such as :

    The current General Area has very few active efforts oriented towards "operations": tools is not a formal working group and icar, ipr, and newtrk are all more "substance" than "operations." Beefing up the General Area might be a good way to get more community involvement in support and operational activities and would fit our existing organizational structure.

  2. Start a Program For Students For Meeting Support. Serving as a NOC team member or learning how to stream audio and video is operational experience that would be a feather in any student's cap attempting to pad a resume, impress a future employer, or simply to learn from some of the best practitioners in the world.

    If we want students staffing our NOC team and our streaming media efforts, we have to pay their expenses. If we had 20 students participating, that would cost USD 40,000 per meeting. If we want students who aren't eternal newbies, we'd want to require that they attend a minimum number of consecutive meetings.

    A student program could easily attract a dedicated sponsor, and there is no reason why corporations couldn't be induced to loan and/or donate their latest and greatest equipment on an on-going basis. Some equipment might need to be purchased, but I suspect that the IETF community has fairly deep tendrils into many corporations and a well-conceived student program would attract a lot of support.

  3. Get some computers, a *lot* more bandwidth, and hire somebody with a clue® to coordinate a combination of volunteers, contractors, and maybe a couple of full-timers. We are clearly stumbling when it comes to deploying production-quality systems for our mail, our core web sites, and hosting facilities for working groups, directorates, advisory bodies, design teams, or other organized activities. We can do better.

    Getting a full-time technical director on board who understands "carrier grade" is not a FedEx customer satisfaction survey and that "plone" is not a type of CSU would be a big plus. Our core computer services really should be rock-solid: mail should be highly responsive even at large volumes and have appropriate spam protection, our web sites should be able to take large traffic spikes, our FTP servers need to be able handle large numbers of mirrors. This really does need to be 24x7 and pretty darn close to 100% availability.

    The IETF is one of those "blessed" non-profit activities that are highly attractive places for companies to contribute equipment and bandwidth. It would be trivial, for example, to secure a rack of co-lo space in Europe, Asia, and the United States with carrier-grade connectivity. And, it would not be hard to get some computers and routers donated.

    Having a production-quality core network on-line would make it much easier to deploy new applications: while an individual might be able to code up a new program, that is a different kettle of fish than assuring 24x7 availability, adequate bandwidth, and hot failovers among sites. Having a stable, general-purpose infrastructure would help in many respects. If we were to launch an archiving effort, for example, there is no place today where the working group handling that effort could place their data. And, speaking of working groups, why aren't we making it really easy for them to deploy a new web site? A simple LAMP environment be enough for most working groups to run with.

  4. Create an IETF-General(s) List(s). Much as I enjoy the large proportion of adminrest-related messages on IETF-discuss, this topic seem to have reached the point where messages of direct relevance to the General Area probably ought to have their own list. Needless to say, any items of interest beyond the general area should get popped up to the even-more-general ietf-discuss list, but it seems only fair that we remember the ancient proverb that each rat hole should have it's own rat hole.

  5. Create an IETF "fellows" Program. The IETF community includes some incredibly talented people. PIR or other appropriate bodies in ISOC as described in [I-D.ietf-iasa-bcp]Austein, R. and B. Wijnen, Structure of the IETF Administrative Support Activity (IASA), December 2004. could fund an IETF fellows program (not the lowercase use of the non-title) as a supplement and complement to the operational responsibilities of the IASA and ISOC by providing funding for "skunkworks" projects that might have future utility to IETF administration and support activities. The fellowship program would fund concrete projects by members of the community selected for their potential for long-term contributions, the quality of their previous work, and the benefit of their project to the rest of the community.

$0.02, YMMV.


9. Acknowledgments

The author would like to thank the following for their helpful reviews of earlier drafts: Harald Alvestrand, Scott Bradner, Leslie Daigle, Allison Mankin, and Michael St. Johns.

All opinions contained herein are strictly the personal opinions of the author and are not shared or endorsed by any particular reviewer.


10. Security Considerations

There are no direct security considerations in this document.


11. IANA Considerations

There are no direct IANA considerations in this document.


12 References

[.] Malamud, C., "Interim Status Report on Data Flows", draft-malamud-interim-data-flows-00 (work in progress), December 2004.
[DOT] Gansner, E., Koutsofios, E. and S. North, "Drawing graphs with dot", Feburary 2002.
[FOLDOC] Howe, D., Ed., "Free On-Line Dictionary of Computing", 2004.
[I-D(!).mrose-writing-rfcs] Rose, M., "Writing I-Ds and RFCs using XML (revised)", draft-mrose-writing-rfcs (work in progress), April 2004.
[I-D.daigle-adminrest] Daigle, L., "A Proposal for IETF Administrative Restructuring", draft-daigle-adminrest-00 (work in progress), February 2004.
[I-D.hoffman-rfc-author-guide] Hoffman, P., "Instructions to Request for Comments (RFC) Authors", draft-hoffman-rfc-author-guide-01 (work in progress), September 2004.
[I-D.iab-iesg-adminrest-rec] Hollenbeck, S., "IAB and IESG Recommendation for IETF Administrative Restructuring", draft-iab-iesg-adminrest-rec-00 (work in progress), October 2004.
[I-D.ietf-iasa-bcp] Austein, R. and B. Wijnen, "Structure of the IETF Administrative Support Activity (IASA)", draft-ietf-iasa-bcp-01 (work in progress), December 2004.
[I-D.ietf-newtrk-cruft] Alvestrand, H. and E. Lear, "Getting rid of the cruft: A procedure to deprecate old standards", draft-ietf-newtrk-cruft-00 (work in progress), October 2004.
[I-D.ietf-newtrk-proposals] Black, D. and B. Carpenter, "Proposals for a New IETF Standards Track", draft-ietf-newtrk-proposals-00 (work in progress), July 2004.
[I-D.ietf-newtrk-repurposing-isd] Klensin, J. and J. Loughney, "Internet Standards Documentation (ISDs)", draft-ietf-newtrk-repurposing-isd-00 (work in progress), September 2004.
[I-D.malamud-consultant-report] Malamud, C., "IETF Administrative Support Functions", draft-malamud-consultant-report-01 (work in progress), September 2004.
[I-D.rfc-editor-rfc2223bis] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-08 (work in progress - do not cite as a normative reference), July 2004.
[I-D.rosenberg-mankin-newtrk-rfc] Rosenberg, J. and A. Mankin, "What's In a Name: RFC", draft-rosenberg-mankin-newtrk-rfc (work in progress), October 2004.
[I-D.wasserman-iasa-bcp] Wasserman, M., Austein, R., Daigle, L. and B. Wijnen, "Structure of the IETF Administrative Support Activity (IASA)", draft-wasserman-iasa-bcp-01 (work in progress), October 2004.
[IETF-TV] Casner, S. and S. Deering, "First IETF Internet Audiocast", ConneXions: The Interoperability Report, Vol. 6, No. 6, Reprinted in ACM Computer Communication Review (Vol. 22, No. 3, July, 1992), June 1992.
[IETF19] The IETF, "Proceedings of the Nineteenth IETF Meeting", December 1990.
[Mankin] Mankin, A. and B. Fenner, "IESG Operations—Behind the Drafts", IETF61 IESG Status Report, November 2004.
[NSF] National Science Foundation, "Support for Research Internetting, August 1997 Amendment", Cooperative Agreement NCR-9528103, (Expiration: November 30, 1997), Award Value: USD 1,126,018, August 1995 (Prior award no. 8820945 for USD 5,205,280).
[RFC-Editor] RFC Editor, "RFC Editor Report", 61st IETF Meeting, November 2004.
[RFC-Online] RFC Editor, "Current Status of the RFC-Online Project", November 2004.
[RFC-SOW] Internet Society, "Statement of Work—RFC Editor", Undated.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997 (TXT, HTML, XML).
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999 (TXT, HTML, XML).
[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[RFC3525] Groves, C., Pantaleo, M., Anderson, T. and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003.
[RFC3716] Advisory, IAB., "The IETF in the Large: Administration and Execution", RFC 3716, March 2004.
[RT], "iasa-bcp trouble ticket queue", 2004.
[RelaxNG] Clark, J., Ed. and M. Murata, "RELAX NG Specification", Organization for the Advancement of Structured Information Standards [OASIS], December 2001.
[UML-Patterns] Dumas, M. and A. ter Hofstede, "UML Activity Diagrams as a Workflow Specification Language", Proceedings of the UML'2001 Conference, 2001.
[WFPattern] van der Aalst and V. Almering, "Flash Animation of Interleaved Parallel Routing Workflow", 2003.
[WRM] Hollingsworth, D. and Workflow Management Coalition, "The Workflow Reference Model", Document Number TC00-1003, Issue 1.1, January 1995.
[YAWL] van der Aalst and A. ter Hofstede, "YAWL: Yet Another Workflow Language (Revised version)", Queensland University of Technology, QUT Technical Report FIT-TR-2003-04, 2003.


Author's Address

  Carl Malamud
  Memory Palace Press
  PO Box 300
  Sixes, OR 97476


Appendix A. Analysis of IANA Activity

Periodic full dumps of the were created and diff's generated across subsequent versions.

Beginning Dump Ending Dump Diff
2004-10-06 2004-10-12 Diff 
2004-10-12 2004-10-15 Diff 
2004-10-15 2004-10-20 Diff 
2004-10-20 2004-10-22 Diff 
2004-10-22 2004-10-26 Diff 
2004-10-26 2004-10-29 Diff 

In addition, a variety of IANA registries were examined to determine the feasibility of translating existing registries into machine-readable formats. A simple XML schema ( dtd, RelaxNG Compact, RelaxNG) was used and the results can be seen on the aaa-parameters and acap-registrations registries. (Hint: if you view the XML in a web browser and all you see is a jumble of text, trying the "view source" command.)

Recent efforts by the IANA have resulted in publication of the current queue status which would make possible an analysis similar to that shown in Appendix CAnalysis of RFC Editor Queue Movements. Of course, since everybody seems to be running MySQL, it would be more straightforward if everybody simply executed the following SQL query:

GRANT SELECT on *.* TO 'ietf'@% IDENTIFIED BY 'ietf'

While it is understood that each support organization has some information that may be considered private or confidential, a policy of allowing read access to most databases would certainly make it easier to analyze activity. Rsync- or ftp- based access to the htdocs root of the various web servers would be even easier.


Appendix B. Analysis of IESG Activity

This material was derived directly from the material presented by Allison Mankin and Bill Fenner at the IETF 61 plenary. [Mankin]Mankin, A. and B. Fenner, IESG Operations—Behind the Drafts, November 2004.

State 59->60 Transactions 59->60 Trans/Week 60->61 Transactions 60->61 Trans/Week
Requested 169 7.68 87 6.21
Approved 148 6.73 103 7.36
Returned to AD Watch 9 0.41 5 0.36
Dead 37 1.68 5 0.36
Requested & Approved 41 1.86 14 1.00
Totals 404 18.36 214 15.29


An alternative measure of IESG activity can be derived from the frequent reports by the IETF Chair to the community. For example, at IETF 61 the following statistics were reported for the three-month period between IETF 60 and IETF 61:

These metrics have all shown consistent improvement. For example, the rate of IESG approvals has steadily increased over the last two years.


Appendix C. Analysis of RFC Editor Queue Movements

The file was saved at various points in time and subjected to various manipulations.

Queue1 Queue2 Days DocsOut DocsIn DocsRec StateTrans
10-28 11-01 2 8 9 0 0
10-27 10-28 1 2 9 0 3
10-26 10-27 1 1 6 0 14
10-22 10-26 2 0 1 0 2
10-21 10-22 1 8 0 1 1
10-19 10-21 2 0 0 0 7
10-18 10-19 1 0 5 0 8
10-13 10-18 3 0 5 0 12
10-12 10-13 1 0 0 1 6
10-11 10-12 1 0 0 1 7
10-08 10-11 1 2 5 0 14
10-07 10-08 1 4 0 0 3
10-05 10-07 2 3 2 2 2
10-01 10-05 2 7 5 0 22
  TOTALS 21 35 41 5 101
  AVERAGES   1.67/day 2.24/day 0.24/day 4.81/day


Raw data, processed files, and diffs for this exercise can be found at The analysis used a simple perl program to transform the published queue files into the following [RelaxNG]Clark, J., Ed. and M. Murata, RELAX NG Specification, December 2001. schema as an interim format, then did simple diffs across successive queue iterations:

namespace a = ""

ATEXT = string
TEXT = text
queue = element queue { attlist.queue, states, set* }
attlist.queue &=
  [ a:defaultValue = "" ] attribute src { ATEXT }?,
  [ a:defaultValue = "" ] attribute type { ATEXT }?,
  [ a:defaultValue = "" ] attribute revdate { ATEXT }?
states = element states { attlist.states, state* }
attlist.states &= empty
state = element state { attlist.state, (TEXT | ref)* }
attlist.state &=
  [ a:defaultValue = "" ] attribute type { ATEXT }?,
  [ a:defaultValue = "" ] attribute date { ATEXT }?
set = element set { attlist.set, item* }
attlist.set &= [ a:defaultValue = "" ] attribute name { ATEXT }?
item = element item { attlist.item, state* }
attlist.item &=
  [ a:defaultValue = "" ] attribute name { ATEXT }?,
  [ a:defaultValue = "" ] attribute submission_date { ATEXT }?,
  [ a:defaultValue = "" ] attribute filename { ATEXT }?,
  [ a:defaultValue = "" ] attribute url { ATEXT }?,
  [ a:defaultValue = "" ] attribute individual_submission { ATEXT }?
ref = element ref { attlist.ref, TEXT }
attlist.ref &= empty
start = queue


Appendix D. Analysis of State Transition Diagrams

State transition diagrams are expressed in the dot language [DOT]Gansner, E., Koutsofios, E. and S. North, Drawing graphs with dot, Feburary 2002., more information on which can be found at This technique seemed simpler than attempting to decipher the original GIF images.

D.1 IESG State Transition Table

View as jpg, png, svg, ismap/png->datatracker

digraph IESG {

  iesg01 [shape=box,label="I-D Exists"] ;
  iesg02 [shape=box,label="Publication Requested"] ;
  iesg03 [shape=box,label="AD Evaluation"] ;
  iesg04 [shape=box,label="Expert Review"] ;
  iesg05 [shape=box,label="Last Call Requested"] ;
  iesg06 [shape=box,label="In Last Call"] ;
  iesg07 [shape=box,label="Waiting for Writeup"] ;
  iesg08 [shape=box,label="Waiting for AD Go-Ahead"];
  iesg09 [shape=box,label="IESG Evaluation"];
  iesg10 [shape=box,label="IESG Evaluation - Defer"];
  iesg11 [shape=box,label="Approved-announcement to be sent"];
  iesg12 [shape=box,label="Approved-announcement sent"];
  iesg13 [shape=box,label="RFC Ed Queue"];
  iesg14 [shape=box,label="RFC Published"];
  iesg15 [shape=box,label="DNP-Waiting for AD Note"];
  iesg16 [shape=box,label="DNP-Announcement to be sentsent"];
  iesg17 [shape=box,label="AD is watching"];
  iesg18 [shape=box,label="Dead"];
  iesg01 -> iesg02 ; iesg01 -> iesg17 ;
  iesg02 -> iesg03 ; iesg02 -> iesg17 ; iesg02 -> iesg18 ;
  iesg03 -> iesg04 ; iesg03 -> iesg09 ; iesg03 -> iesg05 ; iesg03 -> iesg17 ;
  iesg04 -> iesg03 ;
  iesg05 -> iesg06 ;
  iesg06 -> iesg07 ; iesg06-> iesg08 ;
  iesg07 -> iesg08 ;
  iesg08 -> iesg09 ;
  iesg09 -> iesg10 ; iesg09 -> iesg11 ; iesg09 -> iesg15 ;
  iesg10 -> iesg09 ;
  iesg11 -> iesg12 ;
  iesg12 -> iesg13 ;
  iesg13 -> iesg14 ;
  iesg14 -> iesg18 ;
  iesg15 -> iesg16 ;
  iesg16 -> iesg18 ;
  iesg17 -> iesg02 ;

Source: State Diagram (GIF file)

D.2 Generic Pause State Transitions

View as jpg, png, svg

digraph "Generic Pause" {
  s00 [ shape=tripleoctagon, label="X" ] ;
  s01 [ shape=box, label="Point Raised-Writeup Needed"] ;
  s02 [ shape=box, label="AD Followup"] ;
  s03 [ shape=box, label="Revised ID Needed"];
  s04 [ shape=box, label="External Party"];

  s00 -> s01 ;
  s01 -> s02 ;
  s02 -> x ; s02 -> s03 ; s02 -> s04 ;
  s03 -> s02 ; 
  s04 -> s02 ; s04 -> s03 ;

Source: State Diagram (GIF file)

D.3 RFC Editor State Transitions

View as jpg, png, svg

digraph "RFC Editor Queue" {

  // individual submission process
  subgraph cluster0  {
    label="Individual Submission Process" ;
    s1 [shape=house, color=greenyellow, 
        label="START: individual submission"];
    s4 [shape=Mdiamond, label="ISR: Review for Suitability"];
    s5 [shape=Mdiamond, label="TO: IESG 4 week timeout"];
    s6 [shape=Mdiamond, label="ISR: RFC Editor final review"];
    s7 [shape=house, color=hotpink, label="STOP: DNP"];
    s1 -> s4 [label="request arrives w/ID"] ;
    s4 -> s1 [label="comments to authors"] ;
    s4 -> s5 [label="ok"];
    s4 -> s7 [label="NO"];
    s5 -> s6 [label="IESG: DNP"];
    s6 -> s7 [label="NO"];

  // over the wall
  s2 [shape=house, color=greenyellow, label="START: IETF submission"];
  s3 [shape=house, color=greenyellow, label="START: IAB submission"];

  // main process
  subgraph cluster1 {
    label="POST-IESG REVIEW PROCESS" ; labeljust=left ; 
    labelloc = bottom ; 

    // main process
     s8 [shape=box, label="EDIT: nroff, grammar, spelling"];
     s9 [shape=box, label="IANA: waiting for IANA"] ;
    s10 [shape=octagon, label="IESG: fix"];
    s11 [shape=octagon, label="AUTH: fix"];
    s12 [shape=box, label="RFC EDITOR: final review"];
    s13 [shape=box, label="REF: waiting for normative references"]
    s14 [shape=house, color=hotpink, label="STOP: withdrawn"];
    s15 [shape=box, label="assign RFC #"];
    s16 [shape=box, label="AUTH48: authors 48 hour review"];
    s17 [shape=octagon, label="AUTH: fix"];
    s18 [shape=box, label="Make available to global repositories"];
    s19 [shape=box, label="Send publication announcements"];
    s20 [shape=house, color=grey, label="STOP: publish"];
    null1 [ shape=none, label="" ] ;

     s5 -> s8 [label="OK"];
     s6 -> s8 [label="OK"];
     s8 -> s9 ; s9->s12 ;
     null1 -> s9 [label="numbers assigned",style="dotted"];
     s12->s11 [label="Editorial Problems"];
     s11->s8 ;
     s12->s10 [label="Technical Problems"];
     s10->s8 ; 
     s12->s13; s13->s15;
     s16->s17; s17->s16;
     s16->s18; s18->s19;s19->s20;
     null2 [ shape=none, label="" ] ;
     null2 ->s14 [style=dotted];
     { rank = same ; s14; s16 ; }
     { rank = same ; s12 ; s11 ; }
     { rank = same ; s9 ; s10 ; }
  s2 -> s8 [label="IESG: protocol/document action"];
  s3 -> s8 [label="request arrives w/ ID"];

Source: Aaron Falk, November 4, 2002,

D.4 Analysis of the Analysis

Overall, this analysis yields little useful information, though it could be extended to create a "unified" state transition diagram spanning all support organizations. This same software, btw, can be used to analyze other forms of relationships, such as mail traffic (just for fun, the "Shuffle Those Deck Chairs" thread in the adminrest discussion can be viewed here).


Appendix E. Analysis of Mailing List Archives

Top 50 Current IETF Mailing Lists Archived on, Sorted By Amount of Traffic

List Name Megabytes Messages
mobileip 407.57 35073
ietf 159.31 30612
ietf-announce-old 122.63 32915
megaco 115.81 16809
sip 113 18777
ipngwg 109.67 20849
mpls 91.55 15793
pkix 85.25 16376
sigtran 82.67 10498
simple 67.87 9825
ips 60.92 9643
asrg 56.22 10303
manet 55.85 10129
aaa 55.03 11580
sipping 50.04 6622
seamoby 45.29 7215
calsch 43.63 8258
avt 38.74 5606
marid 36.98 8522
dhc 36.92 7229
ldapext 36.55 6276
ipcdn 31.7 1823
dnsext 31.12 8609
idn 28.76 6424
webdav 28.62 5875
dhcipv6 28.09 4659
idr 28.04 4707
ngtrans 27.55 4256
tsvwg 27.09 4954
disman 25.34 3761
nsis 25.31 4074
krb-wg 23.99 4479
nfsv4 23.96 4068
ipfix 23.93 2404
dhcwg 23.85 3633
rsvp 22.47 4331
multi6 21.71 5826
v6ops 21.71 4433
nemo 21.41 3766
smime 20.3 4658
pana 20.26 3494
isis 19.98 3969
midcom 19.69 3607
enum 19.48 3974
diffserv 19 4138
pilc 18.77 4213
atommib 18.18 1263
mmusic 18.08 2475
ippm 17.83 2663
pim 17.07 3182



Appendix F. IETF-Related Mirrors

Source: Current and Concluded Working Group Charters

Domain Name in Reverse Order Kbytes 320
com.att.research.www 7,096
com.bell-labs.www 40
com.elistx.lists 37,896
com.frascone.mail 63,488
com.icsalabs.honor 32
com.lsoft.ease.peach 1,976
com.machshav.www 7,368
com.mail-archive.www 32
com.permeo.socks.archive 5,104
com.snmp.www 99,560
com.snowshore.flyingfox 5,816
com.sobco.www2 64
com.softarmor.www 472
com.sstanamera.www 12,200
com.sun.playground 361,984
com.telcordia.research.ftp 34,240 16,088
com.trusecure.honor 13,864
com.udcast.www 16,208 32
edu.isi.east.www 99,824
edu.isi.ftp 24
edu.merit.www 117,200 13,320 24
edu.uoregon.darkwing 880
edu.uoregon.www 544
edu.wisc.doit.ipfix 37,088
net.6bone.www 18,792 11,104
net.izerv.www 11,080
net.onecall.cell 16
net.piuha.hip 2,712
net.shrubbery.www 24
nl.surfnet.listserv 24
no.alvestrand.www 32,648
org.beepcore.lists 40
org.cert.www 560
org.iana.www 37,000
org.icir.www 11,928
org.ietf.apps.www 381,944
org.ietf.datatracker 1,728 5,544
org.ietf.ftp 5,048,544
org.ietf.ops 532,400
org.ietf.rtg 1,103,880
org.ietf.sec 2,592 199,456
org.ietf.www 3,828,680
org.ietf.www1 904
org.imc.www 1,180,096
org.ipcdn.www 12,168
org.mip4.www 24
org.mobilenetworks.www 54,872
org.mosis.www 24
org.openldap.www 32,296
org.treese.www 944
org.vpnc.www 248,232
org.watersprings.www 3,875,936
org.wrec.www 12,192
org.xmpp.www 534,160
se.cafax.www 27,176 11,760
TOTAL 13.125 Gbytes



Appendix G. Main Hosts in the IETF Domain

Domain Name Service Provider OS Type Relative Size unknown 45.33ms/12.03 kbps FreeBSD 4.X 4113ms/13.87 kbps via Linux 2.[4|5].X 85.93ms/67.67kbps via FreeBSD 5.2-CURRENT on x86 43.79ms/70.77 kbps FreeBSD 5.X on x86 SGI IRIX? 45.53ms/81.24 kbps Linux 2.4.X|2.6.X, Pace embeded 60.09ms/8.54 kbps via Sonicwall Pro 200 Firewall :) 97.73ms/35.64 kbps ( Linux 2.4.X|2.5.X 74.16ms/79.58 kbps Linux 2.4.X|2.5.X 72.45ms/77.61 kbps



Appendix H. Statistics On IETF Mail List Traffic

Analysis of the IETF-Discuss Mail Archives for 2003 and 2004

File Total Kbytes Bytes/Message #Messages AvgSecs AvgHops
2003-01.mail 1430 2683 316 6540 6.43
2003-02.mail 958 2901 216 3848 5.53
2003-03.mail 1929 1571 607 3804 5.50
2003-04.mail 1620 1743 441 4299 6.92
2003-05.mail 2182 1717 602 4233 7.17
2003-06.mail 2485 1618 697 3947 7.33
2003-07.mail 615 1352 195 3792 7.18
2003-08.mail 839 1819 218 6496 7.91
2003-09.mail 2353 1897 614 5896 7.57
2003-10.mail 1366 1828 345 7855 8.01
2003-11.mail 1319 1958 329 6494 7.65
2003-12.mail 2293 2004 552 3909 7.83
2004-01.mail 1693 1872 409 3690 8.49
2004-02.mail 1405 2517 299 3821 8.26
2004-03.mail 2423 2410 521 1953 8.46
2004-04.mail 1057 2374 202 4761 9.84
2004-05.mail 2690 2120 511 5261 10.78
2004-06.mail 1226 2071 239 12815 10.90
2004-07.mail 977 2252 195 6810 9.00
2004-08.mail 1589 3329 282 5135 6.80
2004-09.mail 2762 2571 547 2067 7.36
2004-10.mail 2156 2240 470 5853 6.87
22 files 37.367 Mbytes 4,794 Bytes 8,807 Messages 4,794 Seconds 7.7 Hops



Appendix I. Statistics On IMC Mail List Traffic

Analysis of the mailing lists maintained at using the same methodology as in Appendix HStatistics On IETF Mail List Traffic.

List Total Kbytes Bytes/Message #Messages AvgSecs AvgHops
atom-protocol 528 1312 153 167 4.99
ietf-openproxy 19430 4371 3192 1149 4.34
atom-syntax 35291 1573 10227 366 4.56
ietf-pkix 19545 3809 3455 562 4.82
idn-reg-policy 877 2405 205 300 3.93
ietf-pop3ext 665 2282 177 907 3.85
ietf-822 16166 1780 4814 1824 3.85
ietf-sacred 3116 3299 643 642 4.57
ietf-apps-tls 1413 2284 404 1350 3.36
ietf-sasl 6531 2306 1685 454 3.93
ietf-calendar 35749 3782 6770 438 3.40
ietf-schema-reg 1162 4240 218 512 3.61
ietf-ediint 9302 4066 1743 1313 3.67
ietf-smime-examples 869 3135 189 1301 3.45
ietf-fax 12865 5952 1727 674 4.15
ietf-smime 10014 3206 2132 1957 4.09
ietf-imap-voice 290 2807 70 376 3.33
ietf-smtp 5310 2276 1358 442 3.89
ietf-imapext 7450 1778 2179 263 3.78
ietf-weird 532 3009 125 2558 3.87
ietf-ldup 15295 6512 1935 816 3.73
ietf-whois 843 1839 263 498 3.48
ietf-ltans 1392 5035 204 1218 4.88
ietf-xml-mime 3516 2191 977 697 3.57
ietf-mailsig 614 2201 146 353 4.49
ietf-xml-use 1906 2977 425 1073 3.73
ietf-medfree 4911 3226 1131 2457 3.45
imc-cml 1211 4332 216 694 3.10
ietf-message-xml 105 1637 33 2187 3.33
imc-pfl 674 2212 201 1359 3.36
ietf-mime-direct 526 4533 92 3238 3.34
imc-sfl 2932 4238 533 2457 3.39
ietf-msgtrk 1391 3709 273 2161 3.76
imc-smime-dev 109 3563 23 1124 3.26
ietf-mta-filters 6609 2035 1852 870 3.82
imc-snacc 1826 4205 327 574 3.34
ietf-mxcomp 22334 2279 5270 1293 4.77
mail-ng 2788 1993 725 749 4.37
ietf-openpgp 8690 2093 2704 2715 3.55
39 Lists 264.777 Mbytes 2,884 Bytes 58,796 messages 981 seconds 4.07 hops



Intellectual Property Statement

Disclaimer of Validity

Copyright Statement