Network Working Group Steven J. Richardson Internet Draft Merit Network, Inc. July 1996 Expire in six months A Proposal for an IETF "Problems To Be Solved" Database 1. Status of this Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract This document proposes that an list or database of problems to be solved be maintained by the IETF, along with a discussion of the benefits of so doing. A short discussion of possible enhancements to a simple list is also included. 3. Motivation The IETF is getting significantly larger than it used to be. As a result, there is an explosion of Working Groups, BOFs, and email discussions, with the consequence that it becomes more and more difficult for individuals to remain informed on the day-to-day progress of work in the IETF, including the current status of such work. This size increase and concomitant work volume increase pose some interesting challenges and dangers; in particular, while more is presumably being done, it may well be that coordination and focus which used to be maintained by an informed group of IETF old-timers/ insiders/leaders is being affected in a such a way that important work which needs to be done is being overlooked. S. J. Richardson ^L[Page 1] INTERNET-DRAFT March 1996 These sorts of considerations led the author to writing this draft, in an attempt to generate some discussion about methods of maintaining the focus and coordination of the work of the IETF as a whole. 4. "To Do" or "Problems To Be Solved" List In order to better manage the tasks before the IETF, it is the author's proposal that some body create and maintain a list/database of problems to be solved by the IETF (including problems for which there are insufficient solutions as yet). This list should include problems of various urgencies (i.e., long-term problems as well as more pressing, immediate issues), and should be viewed as an open call for the creation of Working Groups, the formation of BOFs, etc., for work on any of the listed problems. In light of this, it may be desirable to categorize problems in terms of the existing Areas-- perhaps along with a category of "Other" or "Miscellany"--of the IETF upon entry into this list. However, it is more important to create and maintain the list itself than to worry about designing the ultimate problems-to-be-solved database; such considerations should not needlessly delay the implementation of this list/database. It is envisioned that individuals or existing Working Groups would submit potential problems via email to a group or groups which would review these submissions and compare them with existing problem statements (to avoid duplication or overlap) and with the charter of the IETF (to avoid inclusion of inappropriate problems)--probably conferring with the submitter to clean up or clarify wording, reword, etc.--before entering the problem statement into the database. It is further envisioned that Area Directors/the IESG and the IAB would have input into this process; in fact, the review group or groups may be comprised of these groups or some subset of them. In any event, the IESG and IAB should review the new submissions and review the database periodically, in part to exercise their proper functions in this process and in part to stay in touch with this list of work items. Clearly, the timely processing of submitted problem statements is important; perhaps these could be dealt with on a weekly or biweekly basis. 5. Advantages of Having a "Problems To Be Solved" Database There are many advantages of having such a database, among them: - the ability to better coordinate the work of the IETF; - aiding in guiding the IETF along the most productive path; S. J. Richardson ^L[Page 2] INTERNET-DRAFT March 1996 - the ability to better track the progress of the IETF on unsolved problems; - having a single place for researchers or IETF participants to look for ideas for new work which is germane to the IETF's charter. In conjunction with the last item, it is important to note that, especially in the case of "long-term" problems, this list could be useful to the IRTF in terms of suggesting potential areas for research. This would aid in the coordination of IRTF/IETF work on the problems of Internetworking. There are other advantages of course, including the fact that, as problems are worked upon and solved, the "Problems To Be Solved" database is slowly transformed into a "Solved Problems" database, a history of accomplishments of the IETF. 6. Some Possible Refinements Clearly, the "Problems To Be Solved" can be implemented as a simple list; however, greater utility can be achieved via implementation as a more refined database. Some refinements could be: - a field for the date the problem was added; - current status of the problem, such as, e.g., "open", "partially solved", "in process (Working Group)", "solved", etc.; - a classification of problems by urgency, i.e., "immediate/short- term", "intermediate-term", "long-term"; - a classification of problems according to which Area of the IETF they fall under; - a bibliography of relevant material associated with each problem, along with date tags for when the work was done. 6. Conclusion and Next Steps The author hopes that this document will spark some further discussion of this topic, which should ultimately result in the creation of some sort of database of problems to be solved. The next step, if there is sufficient interest, could be the formation of a discussion email list to help further shape and refine the form of this proposal. S. J. Richardson ^L[Page 3] INTERNET-DRAFT March 1996 7. Security Considerations Security considerations are not discussed in this document. 8. Acknowledgements The author would like to thank Sue Hares of Merit Network, Inc. for her encouragement of this document. Additionally, he would like to thank both Ms. Hares and Elise Gerich (also of Merit Network, Inc.) for reviewing this document. 9. Author's Address Steven J. Richardson Merit Network, Inc. 4251 Plymouth Rd., Suite C Ann Arbor, MI 48105-2785 email: sjr@merit.edu phone: (313) 647-4813 fax: (313) 647-3185 S. J. Richardson ^L[Page 4]