[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]