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 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, . [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 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, . [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, . 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, . [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, . [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. [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, . [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, . [1] [2] [3] [4] [5] [6] [7] [8] Malamud Expires June 1, 2005 [Page 24] Internet-Draft Interim Report December 2004 [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [32] [33] Malamud Expires June 1, 2005 [Page 25] Internet-Draft Interim Report December 2004 [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] Malamud Expires June 1, 2005 [Page 26] Internet-Draft Interim Report December 2004 [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [69] [70] [72] [73] Malamud Expires June 1, 2005 [Page 27] Internet-Draft Interim Report December 2004 [74] [75] [76] [77] [78] [79] [80] 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 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 . 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 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 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]