Network Working Group C. Malamud
Internet-Draft Memory Palace Press
Expires: June 1, 2005 December 1, 2004
Interim Status Report on Data Flows
draft-malamud-interim-data-flows-00
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
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 Notice
Copyright (C) The Internet Society (2004).
Abstract
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.[.] Comments may be sent directly to the
author at carl@media.org [1] or to the appropriate IETF mailing list.
Malamud Expires June 1, 2005 [Page 1]
Internet-Draft Interim Report December 2004
Terminology
The key words "YMMV", "Cruft", "Rat Hole", "Good Thing", "Clue", and
"IMHO" in this document are to be interpreted as described in
[FOLDOC].
Table of Contents
1. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Formal Methodologies for Comprehensive Data Flow
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Alternative Methodology Used . . . . . . . . . . . . . . . . . 5
4. Archives . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Hosting . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Data Flows and Tracking . . . . . . . . . . . . . . . . . . . 10
8. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26
A. Analysis of IANA Activity . . . . . . . . . . . . . . . . . . 27
B. Analysis of IESG Activity . . . . . . . . . . . . . . . . . . 28
C. Analysis of RFC Editor Queue Movements . . . . . . . . . . . . 30
D. Analysis of State Transition Diagrams . . . . . . . . . . . . 33
D.1 IESG State Transition Table . . . . . . . . . . . . . . . 33
D.2 Generic Pause State Transitions . . . . . . . . . . . . . 34
D.3 RFC Editor State Transitions . . . . . . . . . . . . . . . 34
D.4 Analysis of the Analysis . . . . . . . . . . . . . . . . . 36
E. Analysis of Mailing List Archives . . . . . . . . . . . . . . 37
F. IETF-Related Mirrors . . . . . . . . . . . . . . . . . . . . . 40
G. Main Hosts in the IETF Domain . . . . . . . . . . . . . . . . 44
H. Statistics On IETF Mail List Traffic . . . . . . . . . . . . . 46
I. Statistics On IMC Mail List Traffic . . . . . . . . . . . . . 48
Intellectual Property and Copyright Statements . . . . . . . . 51
Malamud Expires June 1, 2005 [Page 2]
Internet-Draft Interim Report December 2004
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]. 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] was
issued as part of a chain of activities, including plenary
presentations, extensive IETF list discussions, and a variety of
other drafts, including [RFC3716], [I-D.daigle-adminrest],
[I-D.wasserman-iasa-bcp]. A joint IAB/IESG Recommendation in
[I-D.iab-iesg-adminrest-rec] has resulted in a working draft of a BCP
RFC with the Internet Society in [I-D.ietf-iasa-bcp].
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.
Malamud Expires June 1, 2005 [Page 3]
Internet-Draft Interim Report December 2004
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],
[YAWL], and [UML-Patterns]. 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]).
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.
Malamud Expires June 1, 2005 [Page 4]
Internet-Draft Interim Report December 2004
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 ietf.org
domain. I made mirrors of efforts from other people, such as Geoff
Huston's bgp.potaroo.net [2], Noritoshi Demizu's www.watersprings.org
[3], and the IESG's tracker at datatracker.ietf.org. [4] I also drew
on a variety of other resources including www.imc.org [5] maintained
by Paul Hoffman, the tools [6] maintained by Henrik Levkowetz, and as
always, I drew heavily on xml.resource.org [7], 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 [8] and
tools [9] groups. The IANA has recently released a queue report
[10], as does the RFC-Editor [11].
To make sure I understood the formal data flows, I examined IANA
activity (see Appendix A), IESG activity (see Appendix B), RFC-Editor
queue movements (see Appendix C), and the published state transition
diagrams (see Appendix D). I also mirrored and looked closely at
"official" web sites (such as www.ietf.org [12], ftp.ietf.org [13],
noc.ietf.org [14], www.iana.org [15], and www.rfc-editor.org [16]),
semi-official sites (such as aps.ietf.org [17], ops.ietf.org [18],
rtg.ietf.org [19], sec.ietf.org [20], and edu.ietf.org [21]), 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 [22],
www.iab.org [23], and www.irtf.org [24].
These data were used to look at a variety of issues, including
archives (a key requirement of [RFC3716]), hosting, meeting support,
and overall data flow and tracking.
Malamud Expires June 1, 2005 [Page 5]
Internet-Draft Interim Report December 2004
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]
Documentation of meetings has been done quite well, with the on-line
Proceedings. [25] 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 E). 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 F).
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] 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.
Malamud Expires June 1, 2005 [Page 6]
Internet-Draft Interim Report December 2004
5. Hosting
The IETF maintains a set of public servers, several of which are
maintained by Foretec. They maintain a status page [26] 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 G, 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 H shows the traffic for
ietf-discuss [27] and Appendix I shows similar data for a variety of
lists maintained at www.imc.org [28] 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.
Malamud Expires June 1, 2005 [Page 7]
Internet-Draft Interim Report December 2004
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.
Malamud Expires June 1, 2005 [Page 8]
Internet-Draft Interim Report December 2004
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] 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 [29] (who have also
consistently provided coverage for NANOG, ARIN, and other important
meetings). A variety of other groups and hosts have also pitched in
[30] 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
"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.
Malamud Expires June 1, 2005 [Page 9]
Internet-Draft Interim Report December 2004
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 B).
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.
Malamud Expires June 1, 2005 [Page 10]
Internet-Draft Interim Report December 2004
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] 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] 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.
Malamud Expires June 1, 2005 [Page 11]
Internet-Draft Interim Report December 2004
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] 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], 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].
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]
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
Malamud Expires June 1, 2005 [Page 12]
Internet-Draft Interim Report December 2004
have an interest. For example, though the format of RFCs are
officially governed by the mandatory requirements of the
Informational [RFC2223], in reality authors must conform to the
work-in-progress [I-D.rfc-editor-rfc2223bis], or choose the
alternative interpretation of [I-D.hoffman-rfc-author-guide]. And,
of course, the majority of authors appear to prefer the cookbook
approach presented in [RFC2629] or the work-in-progress
[I-D(!).mrose-writing-rfcs].
Finally, a series of proposals are going through the newtrk [32]
working group that could create a new "Internet Standards
Track"[I-D.ietf-newtrk-proposals] a new class of meta-document, the
"ISD(TM)", [I-D.ietf-newtrk-repurposing-isd] and a new category
of standards action, the "decrufting of the standards
corpus"[I-D.ietf-newtrk-cruft]. 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.
Malamud Expires June 1, 2005 [Page 13]
Internet-Draft Interim Report December 2004
8. Analysis
I have arbitrarily split administrative support for the IETF into
several inter-related categories:
o Archiving, which was listed as a special category only because it
is such a mess.
o Basic hosting.
o Meetings.
o Support for paper flow, a category I termed "the Clerk's Office"
in my previous report.
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
Malamud Expires June 1, 2005 [Page 14]
Internet-Draft Interim Report December 2004
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 :
* IETF Meeting Networks. A standing working group used by the
NOC team, streaming media, and others involved in creating and
operating the network to collaborate and coordinate.
* Published Registries Working Group. This working group would
provide a focus for work related to the registries that IANA
maintains for the IETF, how authors should specify new
registries, and other issues that may come up, such as
machine-readable registry publication formats.
* RFC Working Group. A standing working group on how the RFC
and other archival document series operate and how we author
for those series. Topics such as finalization of
[I-D.rfc-editor-rfc2223bis] or an alternative, revision of
[RFC2629] or development of alternative approaches, and more
substantive topics such as editorial policy and independent
Malamud Expires June 1, 2005 [Page 15]
Internet-Draft Interim Report December 2004
submissions are all potential tasks.
* Document Tracking and Distribution. A standing working group
charged with implementing improvements in production of "core"
IETF-related material such as I-D submission and tracking,
working group support environments, systematic sharing of
tools, and other application-oriented tasks. Note that one
could create a "super working group" which incorporates the
RFC Editor and IANA functions, but it seems like the Document
Tracking and Distribution would be initially most productive
if they picked a few pressing targets (e.g., automated
submission of Internet-Drafts) and implemented those rather
than attempting to focus immediately on overall standards and
global architectures. The one "architecture" that probably
should be specified by such a group is an open data access
policy, specifying minimum standards of public access that
need to be met by any IETF-related support groups and
organized activities. For example, such a policy might
specify that web sites with public information should provide
rsynch-based access or some other bulk retrieval mechanism
(e.g., cvs, ftp) for the htdocs directory of the web servers
that contain public information and that source code for any
critical applications be easily examined.
* Archiving. A working group tasked with carrying out a
systematic archival effort, building on the existing
distributed efforts throughout the net. Tasks include finding
"lost" mail archives, conversion of mail archives into a
common set of formats and structure, and similar steps for
other forms of archives. It would not be unreasonble for the
IETF to let a contract for a full-time (highly technical)
archivist to make sure our legal and historical
responsibilities are being fulfilled and to support the effort
of volunteer efforts.
The current General Area has very few active efforts oriented
towards "operations": tools [33] is not a formal working group
and icar [34], ipr [35], and newtrk [36] 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
Malamud Expires June 1, 2005 [Page 16]
Internet-Draft Interim Report December 2004
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(R) 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.
Malamud Expires June 1, 2005 [Page 17]
Internet-Draft Interim Report December 2004
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] 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.
Malamud Expires June 1, 2005 [Page 18]
Internet-Draft Interim Report December 2004
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.
Malamud Expires June 1, 2005 [Page 19]
Internet-Draft Interim Report December 2004
10. Security Considerations
There are no direct security considerations in this document.
Malamud Expires June 1, 2005 [Page 20]
Internet-Draft Interim Report December 2004
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,
<http://www.graphviz.org/Documentation/dotguide.pdf>.
[FOLDOC] Howe, D., Ed., "Free On-Line Dictionary of Computing",
2004, <http://foldoc.doc.ic.ac.uk/foldoc/index.html>.
[I-D(!).mrose-writing-rfcs]
Rose, M., "Writing I-Ds and RFCs using XML (revised)",
draft-mrose-writing-rfcs (work in progress), April 2004,
<http://xml.resource.org/authoring/draft-mrose-writing-rfc
s.html>.
[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
Malamud Expires June 1, 2005 [Page 21]
Internet-Draft Interim Report December 2004
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,
<http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2
223bis-08.txt>.
[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,
<http://www.ietf.org/internet-drafts/draft-rosenberg-manki
n-newtrk-rfc-00.txt>.
[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,
<http://citeseer.ist.psu.edu/casner92first.html>.
[IETF19] The IETF, "Proceedings of the Nineteenth IETF Meeting",
December 1990,
<http://www.ietf.org/proceedings/prior29/IETF19.pdf>.
Malamud Expires June 1, 2005 [Page 22]
Internet-Draft Interim Report December 2004
[Mankin] Mankin, A. and B. Fenner, "IESG Operations--Behind the
Drafts", IETF61 IESG Status Report, November 2004,
<http://www.alvestrand.no/ietf/nov2004-washington/06-Plena
ry-61-Operations.pdf>.
[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,
<http://www.nsf.gov/awardsearch/showAward.do?AwardNumber=9
528103>.
[RFC-Editor]
RFC Editor, "RFC Editor Report", 61st IETF Meeting,
November 2004,
<http://www.alvestrand.no/ietf/nov2004-washington/04-RFCed
nov04-report.pdf>.
[RFC-Online]
RFC Editor, "Current Status of the RFC-Online Project",
November 2004,
<http://www.rfc-editor.org/rfc-online.html#status>.
[RFC-SOW] Internet Society, "Statement of Work--RFC Editor",
Undated,
<http://www.isoc.org/standards/rfceditor/sow.shtml>.
[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.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[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,
<https://ietf:ietf@rt.psg.com/Search/Listing.html?ValueOfS
tatus=open&ValueOfStatus=new&StatusOp=%3D&QueueOp=%3D&Valu
Malamud Expires June 1, 2005 [Page 23]
Internet-Draft Interim Report December 2004
eOfQueue=41&RowsPerPage=50&NewSearch=1>.
[RelaxNG] Clark, J., Ed. and M. Murata, "RELAX NG Specification",
Organization for the Advancement of Structured Information
Standards [OASIS], December 2001,
<http://www.oasis-open.org/committees/relax-ng/spec-200112
03.html>.
[UML-Patterns]
Dumas, M. and A. ter Hofstede, "UML Activity Diagrams as a
Workflow Specification Language", Proceedings of the
UML'2001 Conference, 2001,
<http://tmitwww.tm.tue.nl/research/patterns/download/uml_p
atterns.pdf>.
[WFPattern]
van der Aalst and V. Almering, "Flash Animation of
Interleaved Parallel Routing Workflow", 2003,
<http://tmitwww.tm.tue.nl/research/patterns/download/swf/p
at_17.swf>.
[WRM] Hollingsworth, D. and Workflow Management Coalition, "The
Workflow Reference Model", Document Number TC00-1003,
Issue 1.1, January 1995,
<http://www.wfmc.org/standards/docs/tc003v11.pdf>.
[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,
<http://www.citi.qut.edu.au/pubs/technical/yawlrevtech.pdf
>.
[1] <mailto:carl@media.org>
[2] <http://bgp.potaroo.net/>
[3] <http://www.watersprings.org/>
[4] <https://datatracker.ietf.org/>
[5] <http://www.imc.org/>
[6] <http://ietf.levkowetz.com/tools/>
[7] <http://xml.resource.org/>
[8] <http://www.ietf.org/html.charters/newtrk-charter.html>
Malamud Expires June 1, 2005 [Page 24]
Internet-Draft Interim Report December 2004
[9] <http://tools.ietf.org/>
[10] <http://www.iana.org/draft-status/draft-queue-status-2004-all.h
tml>
[11] <http://www.rfc-editor.org/queue.html>
[12] <http://www.ietf.org/>
[13] <ftp://www.ietf.org/>
[14] <http://noc.ietf.org/>
[15] <http://www.iana.org/>
[16] <http://www.rfc-editor.org/>
[17] <http://aps.ietf.org/>
[18] <http://ops.ietf.org/>
[19] <http://rtg.ietf.org/>
[20] <http://sec.ietf.org/>
[21] <http://edu.ietf.org/>
[22] <http://www.isoc.org/>
[23] <http://www.iab.org/>
[24] <http://www.irtf.org/>
[25] <http://www.ietf.org/proceedings/>
[26] <http://noc.ietf.org/>
[27] <http://www1.ietf.org/mail-archive/web/ietf/current/index.html>
[28] <http://www.imc.org/>
[29] <http://videolab.uoregon.edu/>
[30] <http://town.hall.org/circus/ietf/>
[32] <http://www2.sobco.com/ietf/newtrk.htm>
[33] <http://tools.ietf.org/>
Malamud Expires June 1, 2005 [Page 25]
Internet-Draft Interim Report December 2004
[34] <http://www.ietf.org/html.charters/icar-charter.html>
[35] <http://www.ietf.org/html.charters/ipr-charter.html>
[36] <http://www.ietf.org/html.charters/newtrk-charter.html>
[37] <http://www.iana.org/>
[38] <http://public.resource.org/adminrest/interim_report/iana/www.i
ana.org.20041006_20041012.diff.txt>
[39] <http://public.resource.org/adminrest/interim_report/iana/www.i
ana.org.20041012_20041015.diff.txt>
[40] <http://public.resource.org/adminrest/interim_report/iana/www.i
ana.org.20041015_20041020.diff.txt>
[41] <http://public.resource.org/adminrest/interim_report/iana/www.i
ana.org.20041020_20041022.diff.txt>
[42] <http://public.resource.org/adminrest/interim_report/iana/www.i
ana.org.20041022_20041026.diff.txt>
[43] <http://public.resource.org/adminrest/interim_report/iana/www.i
ana.org.20041026_20041029.diff.txt>
[44] <http://public.resource.org/adminrest/interim_report/iana/iana.
dtd>
[45] <http://public.resource.org/adminrest/interim_report/iana/iana.
rnc>
[46] <http://public.resource.org/adminrest/interim_report/iana/iana.
rng>
[47] <http://public.resource.org/adminrest/interim_report/iana/aaa-p
arameters.xml>
[48] <http://public.resource.org/adminrest/interim_report/iana/acap
-registrations.xml>
[49] <http://www.iana.org/draft-status/draft-queue-status-2004-in-pr
ogress.html>
[50] <http://www.mysql.com/>
[51] <http://www.alvestrand.no/ietf/nov2004-washington/01-Agenda.ppt
>
Malamud Expires June 1, 2005 [Page 26]
Internet-Draft Interim Report December 2004
[54] <http://public.resource.org/adminrest/interim_report/editor_que
ue/process_queue.pl>
[55] <http://www.GraphViz.org/>
[56] <http://public.resource.org/adminrest/interim_report/state_diag
s/dot_iesg.jpg>
[57] <http://public.resource.org/adminrest/interim_report/state_diag
s/dot_iesg.png>
[58] <http://public.resource.org/adminrest/interim_report/state_diag
s/dot_iesg.svg>
[59] <http://public.resource.org/adminrest/interim_report/state_diag
s/dot_iesg.html>
[60] <https://datatracker.ietf.org/state_diagram.gif>
[61] <http://public.resource.org/adminrest/interim_report/state_diag
s/dot_generic.jpg>
[62] <http://public.resource.org/adminrest/interim_report/state_diag
s/dot_generic.png>
[63] <http://public.resource.org/adminrest/interim_report/state_diag
s/dot_generic.svg>
[64] <https://datatracker.ietf.org/state_diagram.gif>
[65] <http://public.resource.org/adminrest/interim_report/state_diag
s/dot_rfced.jpg>
[66] <http://public.resource.org/adminrest/interim_report/state_diag
s/dot_rfced.png>
[67] <http://public.resource.org/adminrest/interim_report/state_diag
s/dot_rfced.svg>
[69] <http://public.resource.org/adminrest/interim_report/email_anal
ysis/>
[70] <ftp://ftp.ietf.org/>
[72] <http://www.ietf.org/html.charters/wg-dir.html>
[73] <http://www.ietf.org/html.charters/OLD/index.html>
Malamud Expires June 1, 2005 [Page 27]
Internet-Draft Interim Report December 2004
[74] <http://www.plone.org/>
[75] <http://httpd.apache.org/docs-2.0/programs/ab.html>
[76] <http://www1.ietf.org/mail-archive/web/ietf/current/index.html>
[77] <http://public.resource.org/adminrest/interim_report/email_anal
ysis/mail_count.pl>
[78] <http://www.imc.org/>
[79] <http://www.imc.org/>
[80] <http://www.vpnc.org/>
Author's Address
Carl Malamud
Memory Palace Press
PO Box 300
Sixes, OR 97476
US
EMail: carl@media.org
Malamud Expires June 1, 2005 [Page 28]
Internet-Draft Interim Report December 2004
Appendix A. Analysis of IANA Activity
Periodic full dumps of the www.iana.org [37] were created and diff's
generated across subsequent versions.
+----------------+-------------+-----------+
| Beginning Dump | Ending Dump | Diff |
+----------------+-------------+-----------+
| 2004-10-06 | 2004-10-12 | Diff [38] |
| | | |
| 2004-10-12 | 2004-10-15 | Diff [39] |
| | | |
| 2004-10-15 | 2004-10-20 | Diff [40] |
| | | |
| 2004-10-20 | 2004-10-22 | Diff [41] |
| | | |
| 2004-10-22 | 2004-10-26 | Diff [42] |
| | | |
| 2004-10-26 | 2004-10-29 | Diff [43] |
+----------------+-------------+-----------+
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 [44], RelaxNG
Compact [45], RelaxNG [46]) was used and the results can be seen on
the aaa-parameters [47] and acap-registrations [48] 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 [49] which would make possible an analysis
similar to that shown in Appendix C. Of course, since everybody
seems to be running MySQL [50], 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.
Malamud Expires June 1, 2005 [Page 29]
Internet-Draft Interim Report December 2004
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]
+------------+------------+-------------+-------------+-------------+
| State | 59->60 | 59->60 | 60->61 | 60->61 |
| | Transactio | Trans/Week | Transaction | Trans/Week |
| | s | | | |
+------------+------------+-------------+-------------+-------------+
| Requested | 169 | 7.68 | 87 | 6.21 |
| | | | | |
| Approved | 148 | 6.73 | 103 | 7.36 |
| | | | | |
| Returned | 9 | 0.41 | 5 | 0.36 |
| to AD | | | | |
| Watch | | | | |
| | | | | |
| Dead | 37 | 1.68 | 5 | 0.36 |
| | | | | |
| Requested | 41 | 1.86 | 14 | 1.00 |
| & Approved | | | | |
| | | | | |
| Totals | 404 | 18.36 | 214 | 15.29 |
+------------+------------+-------------+-------------+-------------+
Notes:
o 59->60 Transactions is the number of transactions between IETF 59
(Seoul) and IETF 60 (San Diego).
o 59->60 Trans/Week is the previous column divided by 22, the number
of weeks in the period.
o 60->61 Transactions is the number of transactions between IETF 60
(San Diego) and IETF 61 (Washington, D.C.)
o 60->61 Trans/Week is the previous column divided by 14, the number
of weeks in the period.
o "Requested & Approved" has some overlap with "Requested" and
"Approved" so the total transaction count may overstate the
activity level.
o One point worth noting from the Mankin-Fenner presentation is the
fact that the IESG has a non-growing transaction queue, a reversal
from prior patterns. The "Requested & Approved" column is, in a
sense, the measure of an ideal state where documents are processed
in a single meeting cycle on a regular basis.
o The fact that in the period immediately following publication of
[I-D.malamud-consultant-report], the IESG suffered a 20%
productivity decrease in the number of transactions accomplished
per week compared to the period immediately preceding publication,
should not necessarily be considered a causal relationship.
Malamud Expires June 1, 2005 [Page 30]
Internet-Draft Interim Report December 2004
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 [51] for the
three-month period between IETF 60 and IETF 61:
o 4 working groups were created, 11 were closed.
o 347 new Internet-Drafts were created, 219 in the last 4 weeks of
the period.
o 462 updates to Internet-Drafts were submitted, 249 of which were
in the last 4 weeks.
o 55 Last Calls were issued by the IESG.
o 94 approvals were issued for publication of documents, some of
which covered multiple documents.
o 92 RFCs were published.
These metrics have all shown consistent improvement. For example,
the rate of IESG approvals has steadily increased over the last two
years.
Malamud Expires June 1, 2005 [Page 31]
Internet-Draft Interim Report December 2004
Appendix C. Analysis of RFC Editor Queue Movements
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 | StateTr |
| | | | | | | ns |
+--------+--------+---------+---------+---------+---------+---------+
| 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 |
| | | | | | | |
| | AVERAG | | 1.67/da | 2.24/da | 0.24/da | 4.81/da |
| | S | | | | | |
+--------+--------+---------+---------+---------+---------+---------+
Notes:
o Queue1 - Beginning Queue Date
o Queue2 - Ending Queue Date
o NumDays - Number of Business Days in Period
Malamud Expires June 1, 2005 [Page 32]
Internet-Draft Interim Report December 2004
o DocsOut - RFCs-to-be leaving the queue through publication or
withdrawal.
o DocsOut - RFCs-to-be entering the queue.
o DocsRec - I-Ds recycled with a higher revision.
o StateTrans - State transitions, such as adding a [REF], [IANA],
[AUTH], or other action.
o RFC Editor expenses for 2004 are estimated at USD 574,000.
[RFC-SOW] Pro-rating per month and dividing by the 182 total
transactions during this period shows a per transaction cost of
approximately USD 262.82. (An alternative measure can be created
using the 2003 USD 516,460 ISOC RFC-Editor expenditures and the
234 RFCs published during that year to yield a cost per RFC of USD
2,207, up slightly from the 2002 figure of USD 2,111 per RFC.)
Needless to say, these simple cost metrics do not reflect the
underlying complexity of the RFC-Editor function and the
additional responsibilities that are borne by that office.
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 [54] to transform the
published queue files into the following [RelaxNG] schema as an
interim format, then did simple diffs across successive queue
iterations:
Malamud Expires June 1, 2005 [Page 33]
Internet-Draft Interim Report December 2004
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
Malamud Expires June 1, 2005 [Page 34]
Internet-Draft Interim Report December 2004
Appendix D. Analysis of State Transition Diagrams
State transition diagrams are expressed in the "dot" language [DOT],
more information on which can be found at www.GraphViz.org [55].
This technique seemed simpler than attempting to decipher the
original GIF images.
D.1 IESG State Transition Table
View as jpg [56], png [57], svg [58], ismap/png->datatracker [59]
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 ;
Malamud Expires June 1, 2005 [Page 35]
Internet-Draft Interim Report December 2004
iesg17 -> iesg02 ;
}
Source: State Diagram (GIF file) [60]
D.2 Generic Pause State Transitions
View as jpg [61], png [62], svg [63]
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) [64]
D.3 RFC Editor State Transitions
View as jpg [65], png [66], svg [67]
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"];
}
Malamud Expires June 1, 2005 [Page 36]
Internet-Draft Interim Report December 2004
// 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,
Malamud Expires June 1, 2005 [Page 37]
Internet-Draft Interim Report December 2004
<ftp://ftp.rfc-editor.org/in-notes/rfc-editor/rfc-editor-process.gif>
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 [69]).
Malamud Expires June 1, 2005 [Page 38]
Internet-Draft Interim Report December 2004
Appendix E. Analysis of Mailing List Archives
Top 50 Current IETF Mailing Lists Archived on ftp.ietf.org [70],
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 |
| | | |
Malamud Expires June 1, 2005 [Page 39]
Internet-Draft Interim Report December 2004
| 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 |
| | | |
Malamud Expires June 1, 2005 [Page 40]
Internet-Draft Interim Report December 2004
| diffserv | 19 | 4138 |
| | | |
| pilc | 18.77 | 4213 |
| | | |
| atommib | 18.18 | 1263 |
| | | |
| mmusic | 18.08 | 2475 |
| | | |
| ippm | 17.83 | 2663 |
| | | |
| pim | 17.07 | 3182 |
+-------------------+-----------+----------+
Notes:
o Source: mirror of <ftp://ftp.ietf.org/ietf-mail-archive/>
o Total size of archive is 3.448 Gbytes.
o Total number of messages successfully parsed is 579,075.
o Total number of groups in archive: 290.
o Total number of groups with 0 megabytes or messages: 39.
Malamud Expires June 1, 2005 [Page 41]
Internet-Draft Interim Report December 2004
Appendix F. IETF-Related Mirrors
Source: Current [72] and Concluded [73] 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 |
Malamud Expires June 1, 2005 [Page 42]
Internet-Draft Interim Report December 2004
| | |
| 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 |
Malamud Expires June 1, 2005 [Page 43]
Internet-Draft Interim Report December 2004
| | |
| 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:
o 110 IETF-related archives were found through parsing current and
expired charters. Of these, the URL's failed to resolve on 42 of
the archives.
o In addition, some sites did not behave well with simple mirroring
tools. For example, the "wget" utility, when presented with a URL
Malamud Expires June 1, 2005 [Page 44]
Internet-Draft Interim Report December 2004
in the www.isi.edu domain, attempts to mirror the entire site.
o Other examples of "difficult" sites are those based on modern
content management systems such as plone. [74] Plone presents a
date-based approach to workflow that allows utilities such as wget
to project pages far out into the indefinite future. Although the
pages are "empty", they exist and are thus mirrored.
Malamud Expires June 1, 2005 [Page 45]
Internet-Draft Interim Report December 2004
Appendix G. Main Hosts in the IETF Domain
+----------------+----------------+----------------+----------------+
| Domain Name | Service | OS Type | Relative Size |
| | Provider | | |
+----------------+----------------+----------------+----------------+
| datatracker.ie | cnrl-gw.custom | unknown | 45.33ms/12.03 |
| f.org | r.alter.net | | kbps |
| | | | |
| edu.ietf.org | starhub.net.sg | FreeBSD 4.X | 4113ms/13.87 |
| | | | kbps |
| | | | |
| ftp.ietf.org | foretec.com | Linux | 85.93ms/67.67k |
| | via | 2.[4|5].X | ps |
| | bos1.alter.net | | |
| | | | |
| ops.ietf.org | psg.com via | FreeBSD | 43.79ms/70.77 |
| | verio.net | 5.2-CURRENT on | kbps |
| | | x86 | |
| | | | |
| rtg.ietf.org | ip.att.net | FreeBSD 5.X on | |
| | | x86 | |
| | | | |
| sec.ietf.org | research.att.c | SGI IRIX? | 45.53ms/81.24 |
| | m | | kbps |
| | | | |
| tools.ietf.org | telia.com | Linux | 60.09ms/8.54 |
| | | 2.4.X|2.6.X, | kbps |
| | | Pace embeded | |
| | | | |
| www.apps.ietf. | mrochek.com | Sonicwall Pro | 97.73ms/35.64 |
| rg | via | 200 Firewall | kbps |
| | marina-atm1.in | :) | |
| | erworld.net | | |
| | | | |
| www.ietf.org | cnrl-gw.custom | Linux | 74.16ms/79.58 |
| (host51.forete | r.alter.net | 2.4.X|2.5.X | kbps |
| .com) | | | |
| | | | |
| www1.ietf.org | cnrl-gw.custom | Linux | 72.45ms/77.61 |
| | r.alter.net | 2.4.X|2.5.X | kbps |
+----------------+----------------+----------------+----------------+
Notes:
o Service provider is determined using "traceroute".
o OS Type is determined using "nmap".
o Additional scanning tools such as "pchar" were employed, but
overuse of these techniques didn't seem polite.
Malamud Expires June 1, 2005 [Page 46]
Internet-Draft Interim Report December 2004
o Relative size is an impressionistic measure of relative server
size as measured from a set of observations from a single point on
the net. The tool used was Apache Benchmark [75] which was
invoked as "ab -n 100 -c 10" against the home page of each site.
The first number is the mean time per request across concurrent
requests (a small number is "better"--for comparison purposes, the
Google home page came in at 32.78ms). The second number is the
transfer rate for bytes received (a bigger number is "better"--for
comparison purposes, the Google home page came in at 67.80 kbps).
Malamud Expires June 1, 2005 [Page 47]
Internet-Draft Interim Report December 2004
Appendix H. Statistics On IETF Mail List Traffic
Analysis of the IETF-Discuss Mail Archives [76] for 2003 and 2004
+------------+----------+----------+----------+----------+----------+
| File | Total | Bytes/Me | #Message | AvgSecs | AvgHops |
| | Kbytes | sage | | | |
+------------+----------+----------+----------+----------+----------+
| 2003-01.ma | 1430 | 2683 | 316 | 6540 | 6.43 |
| l | | | | | |
| | | | | | |
| 2003-02.ma | 958 | 2901 | 216 | 3848 | 5.53 |
| l | | | | | |
| | | | | | |
| 2003-03.ma | 1929 | 1571 | 607 | 3804 | 5.50 |
| l | | | | | |
| | | | | | |
| 2003-04.ma | 1620 | 1743 | 441 | 4299 | 6.92 |
| l | | | | | |
| | | | | | |
| 2003-05.ma | 2182 | 1717 | 602 | 4233 | 7.17 |
| l | | | | | |
| | | | | | |
| 2003-06.ma | 2485 | 1618 | 697 | 3947 | 7.33 |
| l | | | | | |
| | | | | | |
| 2003-07.ma | 615 | 1352 | 195 | 3792 | 7.18 |
| l | | | | | |
| | | | | | |
| 2003-08.ma | 839 | 1819 | 218 | 6496 | 7.91 |
| l | | | | | |
| | | | | | |
| 2003-09.ma | 2353 | 1897 | 614 | 5896 | 7.57 |
| l | | | | | |
| | | | | | |
| 2003-10.ma | 1366 | 1828 | 345 | 7855 | 8.01 |
| l | | | | | |
| | | | | | |
| 2003-11.ma | 1319 | 1958 | 329 | 6494 | 7.65 |
| l | | | | | |
| | | | | | |
| 2003-12.ma | 2293 | 2004 | 552 | 3909 | 7.83 |
| l | | | | | |
| | | | | | |
| 2004-01.ma | 1693 | 1872 | 409 | 3690 | 8.49 |
| l | | | | | |
| | | | | | |
| 2004-02.ma | 1405 | 2517 | 299 | 3821 | 8.26 |
Malamud Expires June 1, 2005 [Page 48]
Internet-Draft Interim Report December 2004
| l | | | | | |
| | | | | | |
| 2004-03.ma | 2423 | 2410 | 521 | 1953 | 8.46 |
| l | | | | | |
| | | | | | |
| 2004-04.ma | 1057 | 2374 | 202 | 4761 | 9.84 |
| l | | | | | |
| | | | | | |
| 2004-05.ma | 2690 | 2120 | 511 | 5261 | 10.78 |
| l | | | | | |
| | | | | | |
| 2004-06.ma | 1226 | 2071 | 239 | 12815 | 10.90 |
| l | | | | | |
| | | | | | |
| 2004-07.ma | 977 | 2252 | 195 | 6810 | 9.00 |
| l | | | | | |
| | | | | | |
| 2004-08.ma | 1589 | 3329 | 282 | 5135 | 6.80 |
| l | | | | | |
| | | | | | |
| 2004-09.ma | 2762 | 2571 | 547 | 2067 | 7.36 |
| l | | | | | |
| | | | | | |
| 2004-10.ma | 2156 | 2240 | 470 | 5853 | 6.87 |
| l | | | | | |
| | | | | | |
| 22 files | 37.367 | 4,794 | 8,807 | 4,794 | 7.7 Hops |
| | Mbytes | Bytes | Messages | Seconds | |
+------------+----------+----------+----------+----------+----------+
Notes:
o Bytes/message is the average number of bytes in the body of the
message.
o #Messages is the number of messages during the time period.
o Number of seconds is the number of seconds elapsed between the
first Received header and the last Received header, throwing out
any outliers (e.g., seconds > 100000). The program used to
process this information [77] can easily be modified to do more
sophisticated analysis (e.g., examining Received headers to
determine the amount of time spent in the ietf.org domain or to
gather various signal-noise ratios to determine how noisy a list
is).
o Number of hops is a count of the number of Received headers.
Malamud Expires June 1, 2005 [Page 49]
Internet-Draft Interim Report December 2004
Appendix I. Statistics On IMC Mail List Traffic
Analysis of the mailing lists maintained at www.imc.org [78] using
the same methodology as in Appendix H.
+------------+----------+----------+----------+----------+----------+
| List | Total | Bytes/Me | #Message | AvgSecs | AvgHops |
| | Kbytes | sage | | | |
+------------+----------+----------+----------+----------+----------+
| atom-proto | 528 | 1312 | 153 | 167 | 4.99 |
| ol | | | | | |
| | | | | | |
| ietf-openp | 19430 | 4371 | 3192 | 1149 | 4.34 |
| oxy | | | | | |
| | | | | | |
| atom-synta | 35291 | 1573 | 10227 | 366 | 4.56 |
| | | | | | |
| | | | | | |
| ietf-pkix | 19545 | 3809 | 3455 | 562 | 4.82 |
| | | | | | |
| idn-reg-po | 877 | 2405 | 205 | 300 | 3.93 |
| icy | | | | | |
| | | | | | |
| ietf-pop3e | 665 | 2282 | 177 | 907 | 3.85 |
| t | | | | | |
| | | | | | |
| ietf-822 | 16166 | 1780 | 4814 | 1824 | 3.85 |
| | | | | | |
| ietf-sacre | 3116 | 3299 | 643 | 642 | 4.57 |
| | | | | | |
| | | | | | |
| ietf-apps- | 1413 | 2284 | 404 | 1350 | 3.36 |
| ls | | | | | |
| | | | | | |
| ietf-sasl | 6531 | 2306 | 1685 | 454 | 3.93 |
| | | | | | |
| ietf-calen | 35749 | 3782 | 6770 | 438 | 3.40 |
| ar | | | | | |
| | | | | | |
| ietf-schem | 1162 | 4240 | 218 | 512 | 3.61 |
| -reg | | | | | |
| | | | | | |
| ietf-ediin | 9302 | 4066 | 1743 | 1313 | 3.67 |
| | | | | | |
| | | | | | |
| ietf-smime | 869 | 3135 | 189 | 1301 | 3.45 |
| examples | | | | | |
| | | | | | |
Malamud Expires June 1, 2005 [Page 50]
Internet-Draft Interim Report December 2004
| ietf-fax | 12865 | 5952 | 1727 | 674 | 4.15 |
| | | | | | |
| ietf-smime | 10014 | 3206 | 2132 | 1957 | 4.09 |
| | | | | | |
| ietf-imap- | 290 | 2807 | 70 | 376 | 3.33 |
| oice | | | | | |
| | | | | | |
| ietf-smtp | 5310 | 2276 | 1358 | 442 | 3.89 |
| | | | | | |
| ietf-imape | 7450 | 1778 | 2179 | 263 | 3.78 |
| t | | | | | |
| | | | | | |
| 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-m | 3516 | 2191 | 977 | 697 | 3.57 |
| me | | | | | |
| | | | | | |
| ietf-mails | 614 | 2201 | 146 | 353 | 4.49 |
| g | | | | | |
| | | | | | |
| ietf-xml-u | 1906 | 2977 | 425 | 1073 | 3.73 |
| e | | | | | |
| | | | | | |
| ietf-medfr | 4911 | 3226 | 1131 | 2457 | 3.45 |
| e | | | | | |
| | | | | | |
| imc-cml | 1211 | 4332 | 216 | 694 | 3.10 |
| | | | | | |
| ietf-messa | 105 | 1637 | 33 | 2187 | 3.33 |
| e-xml | | | | | |
| | | | | | |
| imc-pfl | 674 | 2212 | 201 | 1359 | 3.36 |
| | | | | | |
| ietf-mime- | 526 | 4533 | 92 | 3238 | 3.34 |
| irect | | | | | |
| | | | | | |
| imc-sfl | 2932 | 4238 | 533 | 2457 | 3.39 |
| | | | | | |
| ietf-msgtr | 1391 | 3709 | 273 | 2161 | 3.76 |
| | | | | | |
| | | | | | |
| imc-smime- | 109 | 3563 | 23 | 1124 | 3.26 |
Malamud Expires June 1, 2005 [Page 51]
Internet-Draft Interim Report December 2004
| ev | | | | | |
| | | | | | |
| ietf-mta-f | 6609 | 2035 | 1852 | 870 | 3.82 |
| lters | | | | | |
| | | | | | |
| imc-snacc | 1826 | 4205 | 327 | 574 | 3.34 |
| | | | | | |
| ietf-mxcom | 22334 | 2279 | 5270 | 1293 | 4.77 |
| | | | | | |
| | | | | | |
| mail-ng | 2788 | 1993 | 725 | 749 | 4.37 |
| | | | | | |
| ietf-openp | 8690 | 2093 | 2704 | 2715 | 3.55 |
| p | | | | | |
| | | | | | |
| 39 Lists | 264.777 | 2,884 | 58,796 | 981 | 4.07 |
| | Mbytes | Bytes | messages | seconds | hops |
+------------+----------+----------+----------+----------+----------+
Notes:
o As in Appendix H, the bytes/message statistic refers to the number
of bytes in the body of the message.
o As above, the number of seconds is the time elapsed between the
first and the last Received header as measured in the mail archive
retrieved from the maintainer. As above, this is a very simple
metric for "how long does it take for mail to get through."
o As above, the number of hops is the number of Received headers.
o The www.imc.org [79] cohabitates with www.vpnc.org [80] on a
moderately old 1U Dell box colocated at AboveNet.
o In comparing the numbers above to those in Appendix H, it worth
keeping in mind that the imc.org mailing lists have a total
distribution of 7,640 direct subscribers. The IETF-Discuss list
reportedly has around 2,000 direct subscribers, and the ietf.org
mail servers also processes numerous other lists (see, e.g.,
Appendix E).
Malamud Expires June 1, 2005 [Page 52]
Internet-Draft Interim Report December 2004
Intellectual Property Statement
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.
Disclaimer of Validity
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 Statement
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Malamud Expires June 1, 2005 [Page 53]
