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
<draft-richardson-database-resolve-00.txt>
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]