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

John C Klensin <john-ietf@jck.com> Sat, 09 August 2008 18:30 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 06DB73A6DD7; Sat, 9 Aug 2008 11:30:27 -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 40C233A6DD6 for <ietf@core3.amsl.com>; Sat, 9 Aug 2008 11:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 i0KMzFrLfD8N for <ietf@core3.amsl.com>; Sat, 9 Aug 2008 11:30:25 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 31E573A6DCB for <ietf@ietf.org>; Sat, 9 Aug 2008 11:30:25 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1KRtCj-00094a-Sa; Sat, 09 Aug 2008 14:30:18 -0400
Date: Sat, 09 Aug 2008 14:30:16 -0400
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net, "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
Subject: Re: Call for review of proposed update to ID-Checklist
Message-ID: <46FE4022D7A994D15EA0F360@p3.JCK.COM>
In-Reply-To: <489DC3E0.3000202@dcrocker.net>
References: <97789FA162BD4EEA9E668BD21E372BAD@BertLaptop> <489DC3E0.3000202@dcrocker.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: IETF Discussion <ietf@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

Bert,

I want to reinforce Dave's comments and perhaps carry them a bit
further.  If the ID-checklist were just the general guidance
that I believe it started out to be, the distinctions I suggest
below would probably be unnecessary.  But we've seen recently
that there are very few steps between having a list and having
everything on that list become rigid, mechanically-applied,
requirements.


--On Saturday, 09 August, 2008 09:20 -0700 Dave Crocker
<dhc2@dcrocker.net> wrote:

> Bert, et al,
> 
> Something that might help further discussions quite a bit is
> considering annotation and re-organization of the document, to
> clarify some basic distinctions.
> 
> For example, labeling the bits that are based on IETF
> standards rules versus the bits that are based on IESG
> requirements?  Equally, what pertains to documentation
> standards versus what pertains to technical/protocol issues?

Many of the bits that "pertain to documentation requirements"
are IESG interpretations of RFC Editor guidelines.  The RFC
Editor has traditionally been much more flexible about their
rules than recent trends in the IESG have been.  Even when the
rules come from the IESG, it would be useful to better
distinguish between firm requirements (e.g., the IPR
boilerplate) and guidance (e.g., things to which one should
either conform or expect to have to explain, convincingly, why
not).

> The document has evolved into a possibly disorganized mixture
> of these and last month's discussions was challenged to
> separate issues, I think.
> 
> This kind of change would not be modification of the Checklist
> semantics, but would add clarity to what is currently there.

But it is precisely the semantics that I think are at issue.
This is less what is in the checklist because I believe we could
agree that everything there is at least good general guidance
than about the apparent tendency for entries in the checklist to
become rigid rules that will be enforced even if specific
circumstances suggest otherwise.

> Any serious effort to clarify the document in this way is
> likely to engender more focused discussion than was possibly
> earlier, if only by offering some specific and relevant
> categorical distinctions.

And, in the case of the distinctions I'm suggesting, permit
meaningful community consideration of whether there is consensus
about particular rules, which may be different from consensus
about general guidance.

regards,
     john


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