Re: Alternative Proposal for Two-Stage IETF Standardization

"Russ Housley" <housley@vigilsec.com> Thu, 11 November 2010 08:23 UTC

Return-Path: <housley@vigilsec.com>
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 172F33A68D4 for <ietf@core3.amsl.com>; Thu, 11 Nov 2010 00:23:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.577
X-Spam-Level:
X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 GIqdd4tXciWB for <ietf@core3.amsl.com>; Thu, 11 Nov 2010 00:23:24 -0800 (PST)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 8D5F63A69AD for <ietf@ietf.org>; Thu, 11 Nov 2010 00:23:24 -0800 (PST)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 1EAFB9A4746; Thu, 11 Nov 2010 03:24:01 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id w492XqU2UbbM; Thu, 11 Nov 2010 03:23:50 -0500 (EST)
Received: from mail.smetech.net (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id E38209A472B; Thu, 11 Nov 2010 03:23:59 -0500 (EST)
Received: from 198.180.150.230 (SquirrelMail authenticated user housley@vigilsec.com) by mail.smetech.net with HTTP; Thu, 11 Nov 2010 03:23:59 -0500 (EST)
Message-ID: <1366.198.180.150.230.1289463839.squirrel@mail.smetech.net>
In-Reply-To: <4CDB918C.8090902@dcrocker.net>
References: <4CD967AD.80605@dcrocker.net> <3486.198.180.150.230.1289445298.squirrel@mail.smetech.net> <4CDB7026.5090903@dcrocker.net> <4CDB918C.8090902@dcrocker.net>
Date: Thu, 11 Nov 2010 03:23:59 -0500
Subject: Re: Alternative Proposal for Two-Stage IETF Standardization
From: Russ Housley <housley@vigilsec.com>
To: dcrocker@bbiw.net
User-Agent: SquirrelMail/1.4.8-5.el4_8.8
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
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-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, 11 Nov 2010 08:23:27 -0000

Dave:

This is a significant improvement from my perspective.  We need a
mechanism to implement it.  The mechanism does not need to be heavy
weight, and it might be as simple as some statements in a Last Call,
allowing the community to support or challenge them.

Russ


> Folks,
>
> On 11/11/2010 12:25 PM, Dave CROCKER wrote:
>> To establish the base: It is not possible to achieve widespread use on
>> the
>> Internet without having multiple components interacting. That's called
>> interoperability.
>>
>> However, the interoperability might be among components that are clones
>> of a
>> single code base.
>>
>> So our language needs to be enhanced to cover multiple implementations.
>> And as
>> long as the language hood is up, we might as well put in a turbo-booster
>> that
>> asserts the higher octane 'interoperability' word.
>
>
> A hallway conversation with Russ added an item that simply had not
> occurred to me:
>
>     There might be multiple implementations that rely on on undocumented
> modifications of the spec.  This means that an additional, interoperable
> implementation cannot be made purely from the specification.
>
> Again, I believe the requirement for the document is "merely" to get the
> wording
> right.  I do not believe any of us differ on the actual meaning we are
> trying to
> achieve.  That is, I have not seen anything that indicates we have
> disparity
> about the intended requirement.
>
> Test language: (*)
>
>       (Full) Internet Standard:
>
>       The Internet community achieves rough consensus -- on using
>       the multiple, independent implementations of a specification
>
> and
>
>       3.3.  [Full] Internet Standard (IS)
>
>       This is the existing final standards status, based on attainment of
>       significant community acceptance, as demonstrated by use of
> multiple,
>       independent implementations that conform to the specification.
>
> d/
>
> ps.  I just realized that the original language that Russ cited said "on
> using
> the running code of a specification".  "Of a specification" explicitly
> means
> that the stuff that is running is the spec and, therefore, can't really
> mean
> that it's using hallway agreements.  (However I think it's dandy to make
> the
> Section 3.3 language bullet-proofed against creative misunderstanding.)
>
> (*) This is just from me; it hasn't been vetted with my co-authors.
>
> --
>
>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net
>