Re: [ietf-outcomes] "Instances" column

Dave CROCKER <> Sun, 14 February 2010 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C1A43A774B for <>; Sun, 14 Feb 2010 10:53:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.566
X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4aagECUAaVRd for <>; Sun, 14 Feb 2010 10:53:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DB88F3A7711 for <>; Sun, 14 Feb 2010 10:53:45 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id o1EIt6F1020393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Feb 2010 10:55:12 -0800
Message-ID: <>
Date: Sun, 14 Feb 2010 10:55:07 -0800
From: Dave CROCKER <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: David Harrington <>
References: <> <0ac101caad3d$30530d40$> <> <0ad301caada2$8e1e2d50$>
In-Reply-To: <0ad301caada2$8e1e2d50$>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.92/10390/Sat Feb 13 14:32:57 2010 on
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Sun, 14 Feb 2010 10:55:12 -0800 (PST)
Subject: Re: [ietf-outcomes] "Instances" column
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Outcomes Wiki discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 14 Feb 2010 18:53:52 -0000


On 2/14/2010 10:21 AM, David Harrington wrote:
> Hi Dave,
> I would like to see more consistency with existing IETF terminology.
> RFC2026 defines three levels of standard.
> Proposed requires an agreed upon document.
> Draft requires implementations.
> Standard requires operational experience.

Well, that's certainly a worthy discussion and it would be great to get the list 
engaged on it.

And indeed, I'd guess that ++ and Full Standard ought to correlate highly.

There is an underlying question that I'd suggest you post an answer to:

       Why should the two be linked?

       What benefit derives?

       On what basis would it make sense for them /not/ to be linked?

For example, the standards label is a formal, political process.  It's rare and 
difficult to get to Full.  (The YAM wg has embarked on a test of this, and the 
experience so far is not pretty.)

The wiki is intended as an extremely informal and flexible process.

The difference between these is fundamental.

> RFC2026 doesn't talk about instances and usage, it talks about
> implementations and operational experience.

For Draft it is only required to talk about /two/ implementations.

Full Standard pretty much /is/ in terms of usage.

> Your "instances" column is about implementations, but uses different
> terminology than is already in use in the IETF.

If your concern is 'instance' vs. 'implementation', that's to keep the column 
narrower.  And no, I'm not kidding.  If there is a real indication of community 
misunderstanding, then the disparity is important.  However the idea that the 
community cannot tolerate synonyms -- especially given how loose people tend to 
be with their vocabulary -- should be documented.

If your concern is something else, please elucidate.

> Your "adoption" column is about operational experience, but uses
> different terminology than IETF process.

What do you believe is established terminology that achieves the same purpose as 
the Adoption column is trying to serve?

> I would like to see the results wiki use terminology consistent with
> our standards process.

That's an inclination that has intuitive appeal.

However we need to be careful that it does not produce slavish adherence that 
undermines actual utility.  Since the standards process and the wiki are not 
identical instruments, it's entirely possible they need disparate terminology.

I'm not saying I'm sure they do, but merely that the decision needs to be made 

> I think using terminology consistent with our process would make these
> adoption categories much more intuitive to IETF participants, AND to
> those who follow the IETF, such as journalists.

Again, that has intuitive appeal.  Note, however, that essentially everyone but 
serious, longer-term IETF geeks have no feel for the standards levels at all. 
So I am not sure I see how the link makes anything intuitive for the larger 
community.  (FWIW, I'm not happy about that observation, but I think it's 
factually correct.)

> I think even to an
> IETF newbie, the engineering distinction between implementation and
> operational experience would be clear; I do not think the distinction
> between instances and adoption is very clear.

You still have not answered the underlying question I've asked a couple of times:

    Implementation is interesting only for standards that have not been very 
successfull.  As such it is a secondary measure.

    Why elevate it to primary?

> It would also be nice if somewhere in the "implementation/instances"
> page hierarchy, we had pointers to BCP 9 (RFC 5657) "Guidance on
> Interoperation and Implementation Reports for Advancement to Draft
> Standard", and to specific implementation reports found at
> This might help
> encourage implementers to file actual implementation reports.

David, you keep wanting to turn the wiki into an extension of formal processes, 
when it is carefully designed to be quite different from it.

We have extensive community assessment that the formal process is problematic in 
effort and vagaries.  The wiki is designed to be informal, simple and direct. 
It asks only one question:  Did an expensive community effort succeed?

For each change you suggest, please think hard about the value proposition of 
the change and look for ways that an otherwise-reasonable value proposition 
might actually /not/ be true.


   Dave Crocker
   Brandenburg InternetWorking