home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-richardson-database-resolve-00.txt < prev    next >
Text File  |  1996-07-15  |  8KB  |  236 lines
  1.  
  2. Network Working Group                               Steven J. Richardson
  3. Internet Draft                                       Merit Network, Inc.
  4.                                                                July 1996
  5.                                                     Expire in six months
  6.  
  7.         A Proposal for an IETF "Problems To Be Solved" Database
  8.                  <draft-richardson-database-resolve-00.txt>
  9.  
  10. 1. Status of this Memo
  11.  
  12.         This document is an Internet-Draft.  Internet-Drafts are working
  13.         documents of the Internet Engineering Task Force (IETF), its
  14.         areas, and its working groups.  Note that other groups may also
  15.         distribute working documents as Internet-Drafts.
  16.  
  17.         Internet-Drafts are draft documents valid for a maximum of six
  18.         months and may be updated, replaced, or obsoleted by other
  19.         documents at any time.  It is inappropriate to use Internet-
  20.         Drafts as reference material or to cite them other than as
  21.         ``work in progress.''
  22.  
  23.         To learn the current status of any Internet-Draft, please check
  24.         the ``1id-abstracts.txt'' listing contained in the Internet-
  25.         Drafts Shadow Directories on ftp.is.co.za (Africa),
  26.         nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  27.         ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  28.  
  29. 2. Abstract
  30.  
  31.    This document proposes that an list or database of problems to be
  32.    solved be maintained by the IETF, along with a discussion of the
  33.    benefits of so doing.  A short discussion of possible enhancements to
  34.    a simple list is also included.
  35.  
  36. 3. Motivation
  37.  
  38.    The IETF is getting significantly larger than it used to be.  As a
  39.    result, there is an explosion of Working Groups, BOFs, and email
  40.    discussions, with the consequence that it becomes more and more
  41.    difficult for individuals to remain informed on the day-to-day
  42.    progress of work in the IETF, including the current status of such
  43.    work.  This size increase and concomitant work volume increase pose
  44.    some interesting challenges and dangers; in particular, while more is
  45.    presumably being done, it may well be that coordination and focus
  46.    which used to be maintained by an informed group of IETF old-timers/
  47.    insiders/leaders is being affected in a such a way that important
  48.    work which needs to be done is being overlooked.
  49.  
  50.  
  51.  
  52.  
  53. S. J. Richardson                                                ^L[Page 1]
  54.  
  55.  
  56.  
  57.  
  58.  
  59. INTERNET-DRAFT                                                March 1996
  60.  
  61.  
  62.    These sorts of considerations led the author to writing this draft,
  63.    in an attempt to generate some discussion about methods of
  64.    maintaining the focus and coordination of the work of the IETF as a
  65.    whole.
  66.  
  67. 4. "To Do" or "Problems To Be Solved" List
  68.  
  69.    In order to better manage the tasks before the IETF, it is the
  70.    author's proposal that some body create and maintain a list/database
  71.    of problems to be solved by the IETF (including problems for which
  72.    there are insufficient solutions as yet).  This list should include
  73.    problems of various urgencies (i.e., long-term problems as well as
  74.    more pressing, immediate issues), and should be viewed as an open
  75.    call for the creation of Working Groups, the formation of BOFs, etc.,
  76.    for work on any of the listed problems.  In light of this, it may be
  77.    desirable to categorize problems in terms of the existing Areas--
  78.    perhaps along with a category of "Other" or "Miscellany"--of the IETF
  79.    upon entry into this list.  However, it is more important to create
  80.    and maintain the list itself than to worry about designing the
  81.    ultimate problems-to-be-solved database; such considerations should
  82.    not needlessly delay the implementation of this list/database.
  83.  
  84.    It is envisioned that individuals or existing Working Groups would
  85.    submit potential problems via email to a group or groups which would
  86.    review these submissions and compare them with existing problem
  87.    statements (to avoid duplication or overlap) and with the charter of
  88.    the IETF (to avoid inclusion of inappropriate problems)--probably
  89.    conferring with the submitter to clean up or clarify wording, reword,
  90.    etc.--before entering the problem statement into the database.  It is
  91.    further envisioned that Area Directors/the IESG and the IAB would
  92.    have input into this process; in fact, the review group or groups may
  93.    be comprised of these groups or some subset of them.  In any event,
  94.    the IESG and IAB should review the new submissions and review the
  95.    database periodically, in part to exercise their proper functions in
  96.    this process and in part to stay in touch with this list of work
  97.    items.
  98.  
  99.    Clearly, the timely processing of submitted problem statements is
  100.    important; perhaps these could be dealt with on a weekly or biweekly
  101.    basis.
  102. 5. Advantages of Having a "Problems To Be Solved" Database
  103.  
  104.    There are many advantages of having such a database, among them:
  105.  
  106.            - the ability to better coordinate the work of the IETF;
  107.  
  108.            - aiding in guiding the IETF along the most productive path;
  109.  
  110.  
  111.  
  112.  
  113. S. J. Richardson                                                ^L[Page 2]
  114.  
  115.  
  116.  
  117.  
  118.  
  119. INTERNET-DRAFT                                                March 1996
  120.  
  121.  
  122.            - the ability to better track the progress of the IETF
  123.              on unsolved problems;
  124.  
  125.            - having a single place for researchers or IETF participants
  126.              to look for ideas for new work which is germane to the
  127.              IETF's charter.
  128.  
  129.    In conjunction with the last item, it is important to note that,
  130.    especially in the case of "long-term" problems, this list could be
  131.    useful to the IRTF in terms of suggesting potential areas for
  132.    research.  This would aid in the coordination of IRTF/IETF work on
  133.    the problems of Internetworking.
  134.  
  135.    There are other advantages of course, including the fact that, as
  136.    problems are worked upon and solved, the "Problems To Be Solved"
  137.    database is slowly transformed into a "Solved Problems" database, a
  138.    history of accomplishments of the IETF.
  139.  
  140. 6. Some Possible Refinements
  141.  
  142.    Clearly, the "Problems To Be Solved" can be implemented as a simple
  143.    list; however, greater utility can be achieved via implementation as
  144.    a more refined database.  Some refinements could be:
  145.  
  146.         - a field for the date the problem was added;
  147.  
  148.         - current status of the problem, such as, e.g., "open", "partially
  149.           solved", "in process (Working Group)", "solved", etc.;
  150.  
  151.         - a classification of problems by urgency, i.e., "immediate/short-
  152.           term", "intermediate-term", "long-term";
  153.  
  154.         - a classification of problems according to which Area of the
  155.           IETF they fall under;
  156.  
  157.         - a bibliography of relevant material associated with each
  158.           problem, along with date tags for when the work was done.
  159.  
  160. 6. Conclusion and Next Steps
  161.  
  162.    The author hopes that this document will spark some further discussion of
  163.    this topic, which should ultimately result in the creation of some sort of
  164.    database of problems to be solved.  The next step, if there is sufficient
  165.    interest, could be the formation of a discussion email list to help further
  166.    shape and refine the form of this proposal.
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173. S. J. Richardson                                                ^L[Page 3]
  174.  
  175.  
  176.  
  177.  
  178.  
  179. INTERNET-DRAFT                                                March 1996
  180.  
  181.  
  182. 7. Security Considerations
  183.  
  184.    Security considerations are not discussed in this document.
  185.  
  186. 8. Acknowledgements
  187.  
  188.    The author would like to thank Sue Hares of Merit Network, Inc. for her
  189.    encouragement of this document.  Additionally, he would like to
  190.    thank both Ms. Hares and Elise Gerich (also of Merit Network, Inc.)
  191.    for reviewing this document.
  192.  
  193. 9. Author's  Address
  194.  
  195.    Steven J. Richardson
  196.    Merit Network, Inc.
  197.    4251 Plymouth Rd., Suite C
  198.    Ann Arbor, MI  48105-2785
  199.  
  200.    email:  sjr@merit.edu
  201.    phone:  (313) 647-4813
  202.      fax:  (313) 647-3185
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233. S. J. Richardson                                                ^L[Page 4]
  234.  
  235.  
  236.