idnits 2.17.1 draft-richardson-database-resolve-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 7 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1996) is 10119 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Steven J. Richardson 2 Internet Draft Merit Network, Inc. 3 July 1996 4 Expire in six months 6 A Proposal for an IETF "Problems To Be Solved" Database 7 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the Internet- 24 Drafts Shadow Directories on ftp.is.co.za (Africa), 25 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 26 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 28 2. Abstract 30 This document proposes that an list or database of problems to be 31 solved be maintained by the IETF, along with a discussion of the 32 benefits of so doing. A short discussion of possible enhancements to 33 a simple list is also included. 35 3. Motivation 37 The IETF is getting significantly larger than it used to be. As a 38 result, there is an explosion of Working Groups, BOFs, and email 39 discussions, with the consequence that it becomes more and more 40 difficult for individuals to remain informed on the day-to-day 41 progress of work in the IETF, including the current status of such 42 work. This size increase and concomitant work volume increase pose 43 some interesting challenges and dangers; in particular, while more is 44 presumably being done, it may well be that coordination and focus 45 which used to be maintained by an informed group of IETF old-timers/ 46 insiders/leaders is being affected in a such a way that important 47 work which needs to be done is being overlooked. 49 These sorts of considerations led the author to writing this draft, 50 in an attempt to generate some discussion about methods of 51 maintaining the focus and coordination of the work of the IETF as a 52 whole. 54 4. "To Do" or "Problems To Be Solved" List 56 In order to better manage the tasks before the IETF, it is the 57 author's proposal that some body create and maintain a list/database 58 of problems to be solved by the IETF (including problems for which 59 there are insufficient solutions as yet). This list should include 60 problems of various urgencies (i.e., long-term problems as well as 61 more pressing, immediate issues), and should be viewed as an open 62 call for the creation of Working Groups, the formation of BOFs, etc., 63 for work on any of the listed problems. In light of this, it may be 64 desirable to categorize problems in terms of the existing Areas-- 65 perhaps along with a category of "Other" or "Miscellany"--of the IETF 66 upon entry into this list. However, it is more important to create 67 and maintain the list itself than to worry about designing the 68 ultimate problems-to-be-solved database; such considerations should 69 not needlessly delay the implementation of this list/database. 71 It is envisioned that individuals or existing Working Groups would 72 submit potential problems via email to a group or groups which would 73 review these submissions and compare them with existing problem 74 statements (to avoid duplication or overlap) and with the charter of 75 the IETF (to avoid inclusion of inappropriate problems)--probably 76 conferring with the submitter to clean up or clarify wording, reword, 77 etc.--before entering the problem statement into the database. It is 78 further envisioned that Area Directors/the IESG and the IAB would 79 have input into this process; in fact, the review group or groups may 80 be comprised of these groups or some subset of them. In any event, 81 the IESG and IAB should review the new submissions and review the 82 database periodically, in part to exercise their proper functions in 83 this process and in part to stay in touch with this list of work 84 items. 86 Clearly, the timely processing of submitted problem statements is 87 important; perhaps these could be dealt with on a weekly or biweekly 88 basis. 89 5. Advantages of Having a "Problems To Be Solved" Database 91 There are many advantages of having such a database, among them: 93 - the ability to better coordinate the work of the IETF; 95 - aiding in guiding the IETF along the most productive path; 96 - the ability to better track the progress of the IETF 97 on unsolved problems; 99 - having a single place for researchers or IETF participants 100 to look for ideas for new work which is germane to the 101 IETF's charter. 103 In conjunction with the last item, it is important to note that, 104 especially in the case of "long-term" problems, this list could be 105 useful to the IRTF in terms of suggesting potential areas for 106 research. This would aid in the coordination of IRTF/IETF work on 107 the problems of Internetworking. 109 There are other advantages of course, including the fact that, as 110 problems are worked upon and solved, the "Problems To Be Solved" 111 database is slowly transformed into a "Solved Problems" database, a 112 history of accomplishments of the IETF. 114 6. Some Possible Refinements 116 Clearly, the "Problems To Be Solved" can be implemented as a simple 117 list; however, greater utility can be achieved via implementation as 118 a more refined database. Some refinements could be: 120 - a field for the date the problem was added; 122 - current status of the problem, such as, e.g., "open", "partially 123 solved", "in process (Working Group)", "solved", etc.; 125 - a classification of problems by urgency, i.e., "immediate/short- 126 term", "intermediate-term", "long-term"; 128 - a classification of problems according to which Area of the 129 IETF they fall under; 131 - a bibliography of relevant material associated with each 132 problem, along with date tags for when the work was done. 134 6. Conclusion and Next Steps 136 The author hopes that this document will spark some further discussion of 137 this topic, which should ultimately result in the creation of some sort of 138 database of problems to be solved. The next step, if there is sufficient 139 interest, could be the formation of a discussion email list to help further 140 shape and refine the form of this proposal. 142 7. Security Considerations 144 Security considerations are not discussed in this document. 146 8. Acknowledgements 148 The author would like to thank Sue Hares of Merit Network, Inc. for her 149 encouragement of this document. Additionally, he would like to 150 thank both Ms. Hares and Elise Gerich (also of Merit Network, Inc.) 151 for reviewing this document. 153 9. Author's Address 155 Steven J. Richardson 156 Merit Network, Inc. 157 4251 Plymouth Rd., Suite C 158 Ann Arbor, MI 48105-2785 160 email: sjr@merit.edu 161 phone: (313) 647-4813 162 fax: (313) 647-3185