Re: Document review

[Brian E Carpenter <[e-mail]>]

Bruce,

Do you think it's OK for the IESG to kick a draft right back to
the WG by saying

   "This is a mess and fundamentally wrong, but we don't have
    time to tell you why, so you have to go find a reviewer." ?

This is a serious question... my concern is that this is a
surefire way to annoy the whole WG (quite apart from the fact that
it would indicate an enormous failure at an earlier stage).

    Brian

Bruce Lilly wrote:
>>  Re: "straightforward, reasonable, and fair"
>> Date: 2005-05-05 11:41
>> From: Keith Moore <[e-mail]>
> 
> 
> [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: [e-mail]
>    URL: http://www.example.com/foo
> 
> 
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf
> 


_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf