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]