Re: Mission statement [Re: Last Call: <draft-hoffman-tao4677bis-15.txt> (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]

John C Klensin <john-ietf@jck.com> Thu, 31 May 2012 14:54 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15C821F86DA for <ietf@ietfa.amsl.com>; Thu, 31 May 2012 07:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.52
X-Spam-Level:
X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20qQwAfrUxRa for <ietf@ietfa.amsl.com>; Thu, 31 May 2012 07:54:05 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5D87921F8723 for <ietf@ietf.org>; Thu, 31 May 2012 07:54:00 -0700 (PDT)
Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1Sa6fM-000I6Y-Ni; Thu, 31 May 2012 10:47:56 -0400
Date: Thu, 31 May 2012 10:53:53 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Eliot Lear <lear@cisco.com>
Subject: Re: Mission statement [Re: Last Call: <draft-hoffman-tao4677bis-15.txt> (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
Message-ID: <C5ABD549485AE1AF8F831363@PST.JCK.COM>
In-Reply-To: <4FC71041.3040609@gmail.com>
References: <20120530225655.19475.74871.idtracker@ietfa.amsl.com> <4FC70E09.30002@cisco.com> <4FC71041.3040609@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
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>
X-List-Received-Date: Thu, 31 May 2012 14:54:07 -0000

--On Thursday, May 31, 2012 07:31 +0100 Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

> On 2012-05-31 07:22, Eliot Lear wrote:
> 
> ...
>>   * I've been told by some that the Mission of the IETF is in
>>   some way out of date.  I don't know whether this is true, 
> 
> That sound like somebody's personal opinion, but it is still a
> BCP and therefore still represents IETF consensus.

Brian,

Regardless of how I feel about this particular case, I don't
understand how to put your comment in context.  In particular,
would you 

* Assert that the IETF is so diligent about its process BCPs
that any that have become out of date, overtaken by events, or
otherwise irrelevant have been immediately and formally declared
obsolete or historic?  I have better ways to spend my time at
the moment, but I imagine that many members of the community
could come up with lists of counterexamples rather quickly
(perhaps starting from how long it took us to get "automatic
review" out of RFC 2026).

* When a document is revised ("updated" or "obsoleted") omitting
a reference that appeared in the earlier version requires a
special consensus call rather than treating consensus on the new
document, once achieved, as atomic?   Granted, the relatively
new provisions requiring identification and explanation of what
was obsoleted or updated are a step toward making sure that
those participating in the consensus process are aware of what
happened but (i) those provisions have, no far, not been
extended to require a discussion of every changed reference and
(ii) are not themselves in a BCP or other document that has been
documented as achieving community consensus on the details.
Independent of that BCP problem, would you advocate making each
new document list all of the references to BCP or Standards
Track documents that were not carried forward and identifying
the reasons?

     john