Re: Conclusion of the last call on draft-housley-two-maturity-levels

John C Klensin <john-ietf@jck.com> Sun, 11 September 2011 00:12 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 4625F21F873A for <ietf@ietfa.amsl.com>; Sat, 10 Sep 2011 17:12:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.587
X-Spam-Level:
X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 Ac7cFT+gw3UL for <ietf@ietfa.amsl.com>; Sat, 10 Sep 2011 17:12:54 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 280D721F84DB for <ietf@ietf.org>; Sat, 10 Sep 2011 17:12:54 -0700 (PDT)
Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1R2Xh6-000Gjj-4R; Sat, 10 Sep 2011 20:14:44 -0400
X-Vipre-Scanned: 0069C4B80028C30069C605-TDI
Date: Sat, 10 Sep 2011 20:14:43 -0400
From: John C Klensin <john-ietf@jck.com>
To: Sam Hartman <hartmans-ietf@mit.edu>, ned+ietf@mauve.mrochek.com
Subject: Re: Conclusion of the last call on draft-housley-two-maturity-levels
Message-ID: <8B7527001A3F8DB5DA8E35CA@[192.168.1.128]>
In-Reply-To: <tslwrdgtaxy.fsf@mit.edu>
References: <20110728121904.2D22AD7A76F@newdev.eecs.harvard.edu> <4E5D4570.9080108@piuha.net> <85BEBBFE35549CAF8000DCE9@PST.JCK.COM> <DF7F294AF4153D498141CBEFADB17704C349D75F42@EMBX01-WF.jnpr.net> <197BAAF4-B98F-4C7C-BC48-E311869CFE28@network-heretics.com> <4E615925.1060506@piuha.net> <01O5L1H6RLZ600RCTX@mauve.mrochek.com> <tslwrdgtaxy.fsf@mit.edu>
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: Keith Moore <moore@network-heretics.com>, 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: Sun, 11 Sep 2011 00:12:55 -0000

--On Saturday, September 10, 2011 16:11 -0400 Sam Hartman
<hartmans-ietf@mit.edu> wrote:

> I do not think the following types of comments should be
> considered as objections when judging this sort of consensus:
> 
> 1) You are not solving the most important problem

Sure.  As long as we differentiate between than and "this will
not solve the problem it claims to solve", "the problem this
addresses is not worth solving", and "this may make things
worse".   While I agree with many of the meta-comments that have
been made about this discussion, I think the some of the
supporters of the proposal have tended to lump comments along
the lines of those three together with the one you cite and its
close relatives, "you should solve some other problem instead"
and "you aren't solving all of the problem".   They are
different, at least IMO.

> 2) This will not do any good

Again, I agree, but I suggest that is different from the
argument Dave Crocker makes frequently (and better than I can)
which, if I may paraphrase, is that any process change has
significant coats and some risks and therefore it should be a
requirement that anyone advocating such a change show a
compelling need for it.  I can accept "this will not do any
good" as a category of position that should not be considered an
objection iff "no compelling requirement and/or advantage for
this has been demonstrated" still counts as legitimate objection.

If that were not the case, I can think of any number of protocol
specifications  that could be decorated with a sufficient number
of optional-and-useless features to make the most option- and
profile-happy of SDOs dance with joy.  Such decorations would be
of particular interest in the security area where we have
traditionally felt that options that are useless and likely to
be badly-implemented and little-used often increase risk by
providing unnecessary attack vectors. :-(

   john


    john