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

Jari Arkko <jari.arkko@piuha.net> Sun, 11 September 2011 11:48 UTC

Return-Path: <jari.arkko@piuha.net>
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 8EEAC21F8540 for <ietf@ietfa.amsl.com>; Sun, 11 Sep 2011 04:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.575
X-Spam-Level:
X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 gtNlxTfLPc9p for <ietf@ietfa.amsl.com>; Sun, 11 Sep 2011 04:48:48 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id EC0F521F853B for <ietf@ietf.org>; Sun, 11 Sep 2011 04:48:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3849D2CEFF; Sun, 11 Sep 2011 14:50:38 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F23qEs0QBu8L; Sun, 11 Sep 2011 14:50:37 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 918662CE32; Sun, 11 Sep 2011 14:50:37 +0300 (EEST)
Message-ID: <4E6CA08B.3040407@piuha.net>
Date: Sun, 11 Sep 2011 14:50:35 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
Subject: Re: Conclusion of the last call on draft-housley-two-maturity-levels
References: <20110728121904.2D22AD7A76F@newdev.eecs.harvard.edu> <4E5D4570.9080108@piuha.net> <6.2.5.6.2.20110902090159.09e97af0@resistor.net> <4E6147D4.2020204@santronics.com> <DF7F294AF4153D498141CBEFADB17704C352657343@EMBX01-WF.jnpr.net> <20110906161108.GI31240@shinkuro.com> <CEDD8840-BE2D-405E-872A-271C25A9A59D@network-heretics.com> <01O5QFMUPV8S014O5Z@mauve.mrochek.com> <96633252-503F-4DCD-B6FD-B6B9DEA1FC66@network-heretics.com> <01O5RIOBEGP0014O5Z@mauve.mrochek.com> <201109100133.p8A1XFvS003894@cichlid.raleigh.ibm.com>
In-Reply-To: <201109100133.p8A1XFvS003894@cichlid.raleigh.ibm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Sun, 11 Sep 2011 11:48:48 -0000

Thomas,

I am in full agreement that document revision and bug fixing is the more important activity for IETF. Not just in my opinion, but I think we can also see it from the numbers of bis documents versus numbers of advancing documents.

But I think some amount of bug fixing and revision is compatible with advancing a document. Clarifications. Removing cruft that no one ever implemented. Documenting security or other concerns better. I don't think it is quite as black and white as you wrote ("you cannot revise a spec in a real meaningful way"). Its just a question of how big surgery the specification needs.

That being said, I do agree with you that the reasons behind lack of work are complex and often have little to do with IETF processes. It is indeed often the case that people with real capability to do something about a specification are either not interested in too minor changes or have vested interests in not causing their implementations to become non-compliant due to bigger changes. There is little that we can do in the IETF process about this, except maybe make the overall RFC publication easier. The industry will come to the IETF when they have a common incentive for a standard or an update thereof *and* they believe they can actually get the work done.

But bringing ourselves back to the topic of process changes, I agree that Russ' draft is not solving our biggest problems. (I personally view it as a tiny effort to remove an unused feature from our process. It could have removed two levels instead of one, but would that have made it easier or harder to find consensus for the change?) But more importantly, I know that you have driven several process and administration related efforts. Do you have a suggestion on what kind of useful thing we could do to address some of the bigger issues? Or better, a draft in your desk drawer that I could take forward?

Jari