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

John C Klensin <john-ietf@jck.com> Tue, 08 July 2008 20:04 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 9DB2628C2E6; Tue, 8 Jul 2008 13:04:28 -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 D542228C2E5; Tue, 8 Jul 2008 13:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.441
X-Spam-Level:
X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599]
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 JhRnvl5H6CgR; Tue, 8 Jul 2008 13:04:26 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id B9BE928C2CC; Tue, 8 Jul 2008 13:04:25 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1KGJQQ-000FBU-09; Tue, 08 Jul 2008 16:04:34 -0400
Date: Tue, 08 Jul 2008 16:04:33 -0400
From: John C Klensin <john-ietf@jck.com>
To: Pete Resnick <presnick@qualcomm.com>, ietf@ietf.org
Subject: Re: Call for review of proposed update to ID-Checklist
Message-ID: <DA239261F08994CDC795CDD5@p3.JCK.COM>
In-Reply-To: <p06250117c4996966b0d4@[75.145.176.242]>
References: <20080708184427.5D55F28C0EC@core3.amsl.com> <p06250117c4996966b0d4@[75.145.176.242]>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: IETF Chair <chair@ietf.org>, iesg@ietf.org, IETF Announcement list <ietf-announce@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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi.

I'm likely to have some other comments on this once I get
through studying it, but the recent notes from Pete and Dave
make a start on some of them.  Rather than trying to put
together a single long note...

--On Tuesday, 08 July, 2008 14:17 -0500 Pete Resnick
<presnick@qualcomm.com> wrote:

>...
> Insert in the Introduction, before or at the beginning of
> "Notes:"
> 
> -----
> This memo uses the terms "MUST", "REQUIRED", "SHOULD", and
> "RECOMMENDED",  similarly to the use of these terms in RFC
> 2119. In particular, when they appear in ALL CAPS in this memo:
> 
>    -"MUST" or "REQUIRED" means that if you do not do this in
> your I-D, the IESG will not accept the I-D for any review
> until the item is complete.
> 
>    - "SHOULD" or "RECOMMENDED" means that there may be valid
> reasons to ignore the item, but an explanation must be given,
> either in the text of the document or as part of the
> submission to the IESG, as to why the item is being ignored.
> Otherwise, the IESG may not accept the I-D for review.
> -----
> 
> This text both (a) puts draft authors on notice as to what the
> hard requirements are in order to avoid late surprises, and
> (b) puts reviewers of this memo on notice so that consensus
> can be reached on what are or are not real showstoppers for
> IESG review.

While I agree, I believe that it would be of great help if the
IESG  gave indications of the situations in which an exception
to a "SHOULD" would be appropriate.  The last thing the
community needs, as a consequence of this document or otherwise,
is to expand the basis on which the IESG can block a document
for reasons that are essentially non-technical and that come as
a surprise to authors.

For at least the MUST list, if we are going down this path, it
would be good to improve efficiency and reduce AD workload by
getting the IESG out of the loop entirely.   As an alternative,
as Pete suggested about one specific case in a different note,
treat a "MUST" as "note and move on, with final approval
contingent on getting the issue fixed".   In other words, if
something is a MUST condition, then either the document
shepherd, the secretariat, or both should be able to verify that
condition and block or flag the document if it is not met.  We
should not be wasting AD time that way unless the ADs really
have nothing better to do with their time.
 
IMO, the IESG should be spending energy evaluating only those
conditions that require judgment as to appropriateness, i.e.,
the SHOULDs.

    john


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