TOC |
|
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 http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 1, 2005.
Copyright (C) The Internet Society (2004).
This document is an interim status report and focuses on workflow characterization of IETF support processes.
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 carl@media.org 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..
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
TOC |
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:
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.
TOC |
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.
TOC |
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 ietf.org domain. I made mirrors of efforts from other people, such as Geoff Huston's bgp.potaroo.net, Noritoshi Demizu's www.watersprings.org, and the IESG's tracker at datatracker.ietf.org. I also drew on a variety of other resources including www.imc.org maintained by Paul Hoffman, the tools maintained by Henrik Levkowetz, and as always, I drew heavily on xml.resource.org, 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 www.ietf.org, ftp.ietf.org, noc.ietf.org, www.iana.org, and www.rfc-editor.org), semi-official sites (such as aps.ietf.org, ops.ietf.org, rtg.ietf.org, sec.ietf.org, and edu.ietf.org), 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 www.isoc.org, www.iab.org, and www.irtf.org.
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.
TOC |
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 ftp.ietf.org/ietf-mail-archive, 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 ietf.org 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.
TOC |
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 ops.ietf.org, 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 www.imc.org 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 ietf.org 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.
TOC |
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.
TOC |
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 https://datatracker.iesg.org/ 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.
TOC |
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:
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.
$0.02, YMMV.
TOC |
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.
TOC |
There are no direct security considerations in this document.
TOC |
There are no direct IANA considerations in this document.
TOC |
[.] | 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] | rt.psg.com, "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. |
TOC |
Carl Malamud | |
Memory Palace Press | |
PO Box 300 | |
Sixes, OR 97476 | |
US | |
EMail: | carl@media.org |
TOC |
Periodic full dumps of the www.iana.org 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.
TOC |
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 |
Notes:
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.
TOC |
The file http://www.rfc-editor.org/queue.html 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 |
Notes:
Raw data, processed files, and diffs for this exercise can be found at http://public.resource.org/adminrest/interim_report/editor_queue/. 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 = "http://relaxng.org/ns/compatibility/annotations/1.0" 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
TOC |
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 www.GraphViz.org. This technique seemed simpler than attempting to decipher the original GIF images.
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)
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)
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; s15->s16; 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, ftp://ftp.rfc-editor.org/in-notes/rfc-editor/rfc-editor-process.gif
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).
TOC |
Top 50 Current IETF Mailing Lists Archived on ftp.ietf.org, 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 |
Notes:
TOC |
Source: Current and Concluded Working Group Charters
Domain Name in Reverse Order | Kbytes |
---|---|
au.edu.monash.eng.webcamserver | 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 |
com.toshiba.www | 16,088 |
com.trusecure.honor | 13,864 |
com.udcast.www | 16,208 |
edu.isi.ai | 32 |
edu.isi.east.www | 99,824 |
edu.isi.ftp | 24 |
edu.merit.www | 117,200 |
edu.mit.mailman | 13,320 |
edu.mit.web | 24 |
edu.uoregon.darkwing | 880 |
edu.uoregon.www | 544 |
edu.wisc.doit.ipfix | 37,088 |
net.6bone.www | 18,792 |
net.ericsson.standards | 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 |
org.ietf.edu | 5,544 |
org.ietf.ftp | 5,048,544 |
org.ietf.ops | 532,400 |
org.ietf.rtg | 1,103,880 |
org.ietf.sec | 2,592 |
org.ietf.tools | 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 |
uk.ac.abdn.erg.www | 11,760 |
TOTAL | 13.125 Gbytes |
Notes:
TOC |
Domain Name | Service Provider | OS Type | Relative Size |
---|---|---|---|
datatracker.ietf.org | cnrl-gw.customer.alter.net | unknown | 45.33ms/12.03 kbps |
edu.ietf.org | starhub.net.sg | FreeBSD 4.X | 4113ms/13.87 kbps |
ftp.ietf.org | foretec.com via bos1.alter.net | Linux 2.[4|5].X | 85.93ms/67.67kbps |
ops.ietf.org | psg.com via verio.net | FreeBSD 5.2-CURRENT on x86 | 43.79ms/70.77 kbps |
rtg.ietf.org | ip.att.net | FreeBSD 5.X on x86 | |
sec.ietf.org | research.att.com | SGI IRIX? | 45.53ms/81.24 kbps |
tools.ietf.org | telia.com | Linux 2.4.X|2.6.X, Pace embeded | 60.09ms/8.54 kbps |
www.apps.ietf.org | mrochek.com via marina-atm1.interworld.net | Sonicwall Pro 200 Firewall :) | 97.73ms/35.64 kbps |
www.ietf.org (host51.foretec.com) | cnrl-gw.customer.alter.net | Linux 2.4.X|2.5.X | 74.16ms/79.58 kbps |
www1.ietf.org | cnrl-gw.customer.alter.net | Linux 2.4.X|2.5.X | 72.45ms/77.61 kbps |
Notes:
TOC |
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 |
Notes:
TOC |
Analysis of the mailing lists maintained at www.imc.org 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 |
Notes:
TOC |
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Funding for the RFC Editor function is currently provided by the Internet Society.