Re: Call for review of proposed update to ID-Checklist

"Bert Wijnen \(IETF\)" <bertietf@bwijnen.net> Sat, 09 August 2008 19:59 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB5E3A6DC3; Sat, 9 Aug 2008 12:59:54 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 888C73A6DDD for <ietf@core3.amsl.com>; Sat, 9 Aug 2008 12:59:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.18
X-Spam-Level:
X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7-NO86LL7IL for <ietf@core3.amsl.com>; Sat, 9 Aug 2008 12:59:52 -0700 (PDT)
Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 41A953A6DC3 for <ietf@ietf.org>; Sat, 9 Aug 2008 12:59:52 -0700 (PDT)
Received: (qmail 93846 invoked from network); 9 Aug 2008 19:53:12 -0000
Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 9 Aug 2008 19:53:12 -0000
Message-ID: <34A11819D6D4490CA56321EC26704A32@BertLaptop>
From: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
To: Theodore Tso <tytso@mit.edu>, Pete Resnick <presnick@qualcomm.com>
Subject: Re: Call for review of proposed update to ID-Checklist
Date: Sat, 09 Aug 2008 21:35:20 +0200
Organization: Consultant
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
x-mimeole: Produced By Microsoft MimeOLE V6.0.6001.18000
Cc: ietf@ietf.org, iesg@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Ted, a glib response would be:

     We can ask the RC-Editor to fix everything that is broken

But do we (IETF/ISOC) really want to spend a lot of real money on
payed RFC-Editor to fix up things that authors/editors can easily do,
specifically with a ID-Checklist in hand that points out the many
simple "things-to-fix" that we often found in many submitted
I-Ds?

My take is that we should put that responsibility with the
authors/editors and the WG chairs. That is what the document
does, and that is also what a WG chair is asked to check
when they fill out the questionaire in RFC4848 in section
3.1, The shepherd (often WG chair) is asked to confirm that he did check
the document to meet the ID-Checklist (see question 1.g on page 6).

And that SAVES a lot of time on already overloaded ADs/IESG
and also SAVES real dollars in the RFC-Editor cycle.

Bert
Editor for ID_Checklist

----- Original Message ----- 
From: "Theodore Tso" <tytso@mit.edu>
To: "Pete Resnick" <presnick@qualcomm.com>
Cc: "IETF Chair" <chair@ietf.org>; <ietf@ietf.org>; <iesg@ietf.org>
Sent: Tuesday, July 08, 2008 11:35 PM
Subject: Re: Call for review of proposed update to ID-Checklist


Re: Call for review of proposed update to ID-ChecklistOn Tue, Jul 08, 2008 
at 02:27:41PM -0500, Pete Resnick wrote:
> The document says:
>
> "If ABNF is used, you MUST include a normative reference to RFC 4234."
>
> To quote two fine radio personalities here in the states, this one seems
> "boooooooooogus". Yes, any I-D that uses ABNF must include a normative
> reference to RFC 4234, but for the IESG to not engage in review until it
> is in there is silly beyond belief. Make a note to the author that they
> need the reference and continue consideration.

Stupid question ---- isn't this specific thing something we should
allow the secretariat to fix as part of the RFC publishing process,
and in fact give them instructions to add the reference if they find
it missing?  They do things like fix/update references IIRC, and this
is only a minor step beyond that, and should be well within their
capabilities, I would think.

Sure, we can ask document editors to add the reference to RFC 4234,
and maybe we can even do things like include a reference to RFC 4234
in an RFC template file with a note to remove if the standard ends up
not using ABNF, but there must be a class of things which could be
streamlined to save time on both the document editors, reviewers, and
AD's time.

Regards,

                                                - Ted
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf