> Re: "straightforward, reasonable, and fair"
> Date: 2005-05-05 11:41
> From: Keith Moore <moore@xxxxxxxxxx>
[excerpts]
> No matter how bad the
> document is, the most an AD can generally manage to do is to insist
> on small changes to the text. Yes, in theory the AD could insist
> that the document undergo significant revision, but the pressure from
> both inside and outside the IESG to move even bad documents along is
> considerable. [*]. Sometimes there's no way to fix a document with
> small textual changes. But because of the pressure to either approve
> a document or to ask for fairly small changes to the document text,
> ADs sometimes suggest small changes to the text that end up being
> poor fixes.
>
> The best cure for both of these problems, I suspect, is not to give
> ADs less "favor" in reviewing documents, but to identify such
> problems earlier, at a time when there is less investment in the WG's
> output and less sense of urgency to get the document out the door.
> [*] Bad documents take more time to review than good documents --
> both because they tend to be poorly written and because the AD is
> struggling to think of a simple fix while reading the document -- and
> nobody on IESG wants to review a bad document over and over.
Bad documents take more time to *thoroughly* review... but a document
needing significant rework can and should be pushed back, otherwise
the AD ends up doing the detail work, and the IESG should be dealing
with the broad perspective rather than a myriad of details. Thorough
review takes time in collecting details, pointing out specific problems
and how they can be addressed, etc. Of course, if a document is of
fairly high quality, that's relatively easy. For documents with
significant numbers of problems, a checklist may help. So, in a
somewhat more serious vein than the Slashdot Spam Solution checklist;
cut, paste, add comments, edit to suit, and check boxes:
Review of draft-foobar-subject-matter-00 by A. Nonymous
Internet-Drafts and RFCs are required to meet certain criteria: [R1.ID],
[R2.Instruct]. These can be checked by using the "idnits" tool:
[R3.idnits]. That tool noted the following regarding the document:
<idnits complaints go here>
The document contains:
[ ] MIB
[ ] ABNF [R4.RFC2234]
[ ] Internet message (or fragment)
Verification tools are available at [R5.verify] and/or [R6.mparse].
Verification tools yielded the following results:
<verification tool complaints go here>
The wording of the document is poor. [R7.editor62] may be useful.
The formatting of the document is atrocious. See [R8.formatting] and
[R9.formatting]
The document suffers from the following serious defects:
[ ] missing or inadequate IANA considerations
[ ] missing or inadequate security considerations
[ ] missing or inadequate internationalization considerations
[ ] incompatible with the Internet Architecture
[ ] incompatible with one or more Internet Standards
[ ] uses non-standard terminology which may lead to confusion,
misinterpretation, and loss of interoperability
[ ] not backwards compatible with widely deployed,
standards-conforming infrastructure
[ ] BCP 14 is referenced, but keywords are not used, or are used
inappropriately
Please carefully review the references and resources indicated:
[ ] [R1.ID]
[ ] [R2.Instruct]
[ ] [R3.idnits]
[ ] [R4.RFC2234]
[ ] [R5.verify]
[ ] [R6.mparse]
[ ] [R7.editor62]
[ ] [R8.formatting]
[ ] [R9.formatting]
[ ] [R10.FYI18]
[ ] [R11.FYI36]
[ ] [R12.STD10], [R13.STD10], [R14.STD10]
[ ] [R15.STD11]
[ ] [R16.STD13], [R17.STD13]
[ ] [R18.STD17]
[ ] [R19.BCP9]
[ ] [R20.BCP14]
[ ] [R21.BCP18]
[ ] [R22.BCP22]
[ ] [R23.BCP26]
[ ] [R24.BCP32]
[ ] [R25.BCP41]
[ ] [R26.BCP44]
[ ] [R27.BCP56]
[ ] [R28.BCP61]
[ ] [R29.BCP72]
[ ] [R30.BCP82]
[ ] [R31.BCP90]
[ ] [R32.BCP95]
[ ] [R33.BCP97]
[ ] [R34.RFC1958]
The following applies to the document being reviewed:
[ ] The document seems promising, but needs work.
[ ] The document needs substantial rework before serious review can
take place.
[ ] The document is a disaster. It should be withdrawn.
References
[R1.ID] "Guidelines to Authors of Internet-Drafts", March
2005, ftp://ftp.ietf.org/ietf/1id-guidelines.txt
[R2.Instruct] Reynolds, J., and R. Braden, "Instructions to Request
for Comments (RFC) Authors", Work in progress (August
2004).
[R3.idnits] http://ietf.levkowetz.com/tools/idnits/
[R4.RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[R5.verify] TOOLS, "Available Verification Tools",
http://tools.ietf.org/verif-tools
[R6.mparse] Internet Message Format validating parser,
http://users.erols.com/blilly/mparse/index.html
[R7.editor62] RFC Editor, "Tutorial Slides", ftp://ftp.rfc-
editor.org/in-notes/rfc-editor/tutorial62.pdf
[R8.formatting] RFC Editor, "Formatting RFCs and Internet Drafts",
http://www.rfc-editor.org/formatting.html
[R9.formatting] Lilly, B., "Writing Internet-Drafts and Requests For
Comments using troff and nroff",
http://users.erols.com/blilly/formatting/draft-lilly-
using-troff-04.html
[R10.FYI18] Malkin, G., "Internet Users' Glossary", RFC 1983,
August 1996.
[R11.FYI36] Shirey, R., "Internet Security Glossary", RFC 2828,
May 2000.
[R12.STD10] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, August 1982.
[R13.STD10] Klensin, J., Freed, N., Rose, M., Stefferud, E., and
D. Crocker, "SMTP Service Extensions", STD 10,
RFC 1869, November 1995.
[R15.STD11] Crocker, D., "Standard for the format of ARPA
Internet text messages", STD 11, RFC 822, August
1982.
[R16.STD13] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[R17.STD13] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[R18.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.
[R19.BCP9] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[R20.BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[R21.BCP18] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[R22.BCP22] Scott, G., "Guide for Internet Standards Writers",
BCP 22, RFC 2360, June 1998.
[R23.BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26,
RFC 2434, October 1998.
[R24.BCP32] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level
DNS Names", BCP 32, RFC 2606, June 1999.
[R25.BCP41] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[R26.BCP44] Moore, K. and N. Freed, "Use of HTTP State
Management", BCP 44, RFC 2964, October 2000.
[R27.BCP56] Moore, K., "On the use of HTTP as a Substrate",
BCP 56, RFC 3205, February 2002.
[R28.BCP61] Schiller, J., "Strong Security Requirements for
Internet Engineering Task Force Standard Protocols",
BCP 61, RFC 3365, August 2002.
[R29.BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing
RFC Text on Security Considerations", BCP 72,
RFC 3552, July 2003.
[R30.BCP82] Narten, T., "Assigning Experimental and Testing
Numbers Considered Useful", BCP 82, RFC 3692, January
2004.
[R31.BCP90] Klyne, G., Nottingham, M., and J. Mogul,
"Registration Procedures for Message Header Fields",
BCP 90, RFC 3864, September 2004.
[R32.BCP95] Alvestrand, H., "A Mission Statement for the IETF",
BCP 95, RFC 3935, October 2004.
[R33.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.
[R34.RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
Author's Address
Ann Nonymous
Acme Widget Company
123 Main St.
Anytown, XX 12345-6789
Telephone: tel no.
Fax: fax no.
Email: a.nonymous@xxxxxxxxxxx
URL: http://www.example.com/foo
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf