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:
<idnits complaints go here>
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:
<verification tool complaints go here>
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