Review of draft-foobar-subject-matter-00 by A. Nonymous Internet-Drafts and RFCs are required to meet certain criteria: [R1.Checklist] (see also references in that document), [R2.ID], [R3.Instruct]. These can be checked by using the "idnits" tool: [R4.idnits]. That tool noted the following regarding the document: The document contains: [ ] MIB [R5.STD17] [ ] ABNF [R6.RFC2234] [ ] Internet message (or fragment) Verification tools are available at [R7.verify] and/or [R8.mparse]. Verification tools yielded the following results: The wording of the document is poor. [R9.editor62] may be useful. The formatting of the document is atrocious. See [R10.formatting] and [R11.formatting]. The (intended) status of the document is: [X] Not indicated [ ] Experimental [ ] Informational [ ] Proposed Standard [ ] Draft Standard [ ] Internet Standard [ ] Best Current Practice However, the status as defined in [R12.BCP9] should be: [ ] Experimental (typically denotes a specification that is part of some research or development effort, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process) [ ] Informational (published for the general information of the Internet community, does not represent an Internet community consensus or recommendation, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process) [ ] Proposed Standard (generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, appears to enjoy enough community interest to be considered valuable, has no known technical omissions) [ ] Draft Standard (at least two independent and fully interoperable implementations from different code bases have been developed, sufficient successful operational experience has been obtained, unused options and features have been removed, well-understood, known to be quite stable both in its semantics and as a basis for developing an implementation, must have been Proposed Standard for at least six months) [ ] Internet Standard (significant implementation and successful operational experience has been obtained, characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community, must have been Draft Standard for at least four months) [ ] Historic (A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete, must have been Standards Track) [ ] Best Current Practice (a way to standardize practices and the results of community deliberations, subject to the same basic set of procedures as standards track documents, the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function, common guidelines for policies and operations which are generally different in scope and style from protocol standards, not well suited to the phased roll-in nature of the three stage standards track and instead generally only make sense for full and immediate instantiation) [X] None of the above (see discussion) The document suffers from the following serious defects: [X] missing or inadequate IANA considerations [X] missing or inadequate security considerations [X] missing or inadequate internationalization considerations [X] incompatible with the Internet Architecture [X] incompatible with one or more approved Internet specifications [X] uses non-standard, inconsistent, or poorly-defined terminology which may lead to confusion, misinterpretation, and loss of interoperability [X] not backwards compatible with widely deployed, standards-conforming infrastructure [X] [R13.BCP14] is referenced, but keywords are not used, or are used inappropriately [X] based on a lack of understanding or misunderstanding of fundamental principles Please carefully review the references and resources indicated: [X] [R1.Checklist] [X] [R2.ID] [X] [R3.Instruct] [X] [R4.idnits] [X] [R6.RFC2234] [X] [R7.verify] [X] [R8.mparse] [X] [R9.editor62] [X] [R10.formatting] [X] [R11.formatting] [X] [R5.STD17] [X] [R12.BCP9] [X] [R13.BCP14] [X] [R14.FYI17] [X] [R15.FYI18] [X] [R16.FYI36] [X] [R17.STD10], [R18.STD10], [R19.STD10] [X] [R20.STD11] [X] [R21.STD13], [R22.STD13] [X] [R23.BCP18] [X] [R24.BCP22] [X] [R25.BCP26] [X] [R26.BCP32] [X] [R27.BCP37] [X] [R28.BCP41] [X] [R29.BCP44] [X] [R30.BCP56] [X] [R31.BCP61] [X] [R32.BCP72] [X] [R33.BCP82] [X] [R34.BCP90] [X] [R35.BCP95] [X] [R36.BCP97] [X] [R37.BCP104] [X] [R38.RFC1796] [X] [R39.RFC1925] [X] [R40.RFC1958] [X] [R41.RFC1982] [X] [R42.RFC2223] [X] [R43.RFC2231] [X] [R44.RFC2821] [X] [R45.RFC2822] [X] [R46.RFC3092] [X] [R47.RFC3117] [X] [R48.RFC3254] [X] [R49.RFC3330] [X] [R50.RFC3426] [X] [R51.RFC3439] [X] [R52.RFC3444] [X] [R53.RFC3467] [X] [R54.RFC3523] [X] [R55.RFC3536] [X] [R56.RFC3724] [X] [R57.RFC3849] [X] [R58.RFC3929] [X] [R59.Errata] [X] [R60.Fields] The following applies to the document being reviewed: [ ] The document seems promising, but needs work. [X] The document needs substantial rework before serious review can take place. [ ] The document is a disaster. It should be withdrawn. References: [R1.Checklist] Wijnen, B., "Checklist for Internet-Drafts (IDs) submitted for RFC publication", February 2005, http://www.ietf.org/ID-Checklist.html [R2.ID] Fenner, B., "Guidelines to Authors of Internet-Drafts", March 2005, ftp://ftp.ietf.org/ietf/1id-guidelines.txt [R3.Instruct] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors" (draft-rfc-editor-rfc2223bis-08.txt), July 2004. [R4.idnits] http://ietf.levkowetz.com/tools/idnits/ [R5.STD17] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB-II", STD 17, RFC 1213, March 1991. [R6.RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [R7.verify] TOOLS, "Available Verification Tools", http://tools.ietf.org/verif-tools [R8.mparse] Internet Message Format validating parser, http://users.erols.com/blilly/mparse/index.html [R9.editor62] RFC Editor, "Tutorial Slides", ftp://ftp.rfc-editor.org/in-notes/rfc-editor/tutorial62.pdf [R10.formatting] RFC Editor, "Formatting RFCs and Internet Drafts", http://www.rfc-editor.org/formatting.html [R11.formatting] Lilly, B., "Writing Internet-Drafts and Requests For Comments using troff and nroff" (draft-lilly-using-troff-04.txt), (draft-lilly-using-troff-04.ps), (draft-lilly-using-troff-04.pdf), May 2005. [R12.BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [R13.BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [R14.FYI17] Harris, S., "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force", RFC 3160, August 2001. [R15.FYI18] Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996. [R16.FYI36] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000. [R17.STD10] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. [R18.STD10] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995. [R19.STD10] Partridge, C., "Mail routing and the domain system", STD 10, RFC 974, January 1986. [R20.STD11] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [R21.STD13] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [R22.STD13] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [R23.BCP18] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [R24.BCP22] Scott, G., "Guide for Internet Standards Writers", BCP 22, RFC 2360, June 1998. [R25.BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [R26.BCP32] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. [R27.BCP37] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [R28.BCP41] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [R29.BCP44] Moore, K. and N. Freed, "Use of HTTP State Management", BCP 44, RFC 2964, October 2000. [R30.BCP56] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002. [R31.BCP61] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, August 2002. [R32.BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [R33.BCP82] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. [R34.BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [R35.BCP95] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, October 2004. [R36.BCP97] Bush, R. and T. Narten, "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level", BCP 97, RFC 3967, December 2004. [R37.BCP104] Klensin, J., "Terminology for Describing Internet Connectivity", BCP 104, RFC 4084, May 2005. [R38.RFC1796] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are Standards", RFC 1796, April 1995. [R39.RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, April 1996. [R40.RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996. [R41.RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. [R42.RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997. [R43.RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997. [R44.RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [R45.RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [R46.RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology of "Foo"", RFC 3092, April 2001. [R47.RFC3117] Rose, M., "On the Design of Application Protocols", RFC 3117, November 2001. [R48.RFC3254] Alvestrand, H., "Definitions for talking about directories", RFC 3254, April 2002. [R49.RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. [R50.RFC3426] Floyd, S., "General Architectural and Policy Considerations", RFC 3426, November 2002. [R51.RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, December 2002. [R52.RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003. [R53.RFC3467] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, February 2003. [R54.RFC3523] Polk, J., "Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology", RFC 3523, April 2003. [R55.RFC3536] Hoffman, P., "Terminology Used in Internationalization in the IETF", RFC 3536, May 2003. [R56.RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004. [R57.RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004. [R58.RFC3929] Hardie, T., "Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF", RFC 3929, October 2004. [R59.Errata] RFC-Editor errata page, http://www.rfc-editor.org/errata.html [R60.Fields] Lilly, B., "Implementer-friendly Specification of Message and MIME-Part Header Fields and Field Components" (draft-lilly-field-specification-04.txt), June 2005. Reviewer's Address Ann Nonymous Acme Widget Company 123 Main St. Anytown, XX 12345-6789 Telephone: tel no. Fax: fax no. Email: a.nonymous@example.com URL: http://www.example.com/foo