Re: [ietf-outcomes] "Instances" column

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 14 February 2010 18:44 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: ietf-outcomes@core3.amsl.com
Delivered-To: ietf-outcomes@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DBCA3A7374 for <ietf-outcomes@core3.amsl.com>; Sun, 14 Feb 2010 10:44:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.862
X-Spam-Level:
X-Spam-Status: No, score=-0.862 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
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 6UkNWddXkYee for <ietf-outcomes@core3.amsl.com>; Sun, 14 Feb 2010 10:44:43 -0800 (PST)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id C16E33A71FA for <ietf-outcomes@ietf.org>; Sun, 14 Feb 2010 10:44:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 76B74430030; Sun, 14 Feb 2010 10:46:11 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from [192.168.1.16] (unknown [96.245.81.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id EB41D43003C; Sun, 14 Feb 2010 10:46:10 -0800 (PST)
Message-ID: <4B7844F2.5060209@joelhalpern.com>
Date: Sun, 14 Feb 2010 13:46:10 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: David Harrington <ietfdbh@comcast.net>
References: <4B7721D4.7070402@dcrocker.net> <0ac101caad3d$30530d40$0600a8c0@china.huawei.com> <4B781883.70905@bbiw.net> <0ad301caada2$8e1e2d50$0600a8c0@china.huawei.com>
In-Reply-To: <0ad301caada2$8e1e2d50$0600a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ietf-outcomes@ietf.org, 'Dave CROCKER' <dcrocker@bbiw.net>
Subject: Re: [ietf-outcomes] "Instances" column
X-BeenThere: ietf-outcomes@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Outcomes Wiki discussion list <ietf-outcomes.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-outcomes>, <mailto:ietf-outcomes-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-outcomes>
List-Post: <mailto:ietf-outcomes@ietf.org>
List-Help: <mailto:ietf-outcomes-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-outcomes>, <mailto:ietf-outcomes-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Feb 2010 18:44:45 -0000

David,
     The purpose of this is something simple, and easily readable.
     Factors like the maturity of the documents on the standards track 
are basically outside the scope of what we are trying to do here.  If we 
can not figure out a simple way to look at things and saying clear 
things about whether the work does or has mattered to a significant 
community, or whether this work is still developing, then I think we are 
just confusing ourselves.
     Note that the point is not to argue about whether one work effort 
is better than another, or even whether it is more used than another.
     To try to capture subtle distinctions in this would complicate 
things without adding significant value.  This is, as I read things, 
intended as a broad brush, subjective effort to capture things where we 
can say whether it is a success, a failure, or still still growing.  I 
would not be surprised if relatively new efforts don't even fit in the 
chart. (There is no point in listing the ForCES effort yet.)

Yours,
Joel


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.
> 
> RFC2026 doesn't talk about instances and usage, it talks about
> implementations and operational experience.
> Your "instances" column is about implementations, but uses different
> terminology than is already in use in the IETF.
> Your "adoption" column is about operational experience, but uses
> different terminology than IETF process.
> I would like to see the results wiki use terminology consistent with
> our standards process.
> 
> 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. 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.
> 
> 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
> http://www.ietf.org/iesg/implementation-report.html. This might help
> encourage implementers to file actual implementation reports.
> 
> dbh
> 
>> -----Original Message-----
>> From: Dave CROCKER [mailto:dcrocker@bbiw.net] 
>> Sent: Sunday, February 14, 2010 10:37 AM
>> To: David Harrington
>> Subject: Re: [ietf-outcomes] "Instances" column
>>
>> David,
>>
>> On 2/13/2010 10:16 PM, David Harrington wrote:
>>> Hi,
>>>
>>> I think there should be one column for implementations and 
>> another for
>>> adoption (i.e. usage).
>> Hmmm.  Isn't that essentially what is accomplished by having 
>> the current 
>> Adoption (use) column and the new Instances column?
>>
>> What would you like to see that is different (but still 
>> simple)... and why?
>>
>>
>>> You already set up the ability to have a link to an additional
> page
>>> via the comments column.
>> Yeah.  I thought about that when Ray raised the issue, but 
>> decided that a 
>> Comments column pointer was generic; it could be for 
>> anything.  While the 
>> Instances column would be entirely specific. The premise 
>> justifying the new 
>> column  is that that specific information is worth implicitly 
>> asking for.
>>
>>
>>>   I recommend making it possible to have an
>>> implementation column with a legend (++ through --) and an
> optional
>>> link to a page with a list of implementations (and possibly 
>> links from
>>> that page to implementation reports).
>> There is a particular benefit in being able to read through a 
>> list of names and 
>> pointers to their implementations. It gives serious substance 
>> to a claim of success.
>>
>> What is the benefit in 'rating' the degree of implementation 
>> success, as 
>> separate from Use?  What question is it answering that 
>> affects IETF work, and 
>> for whom?
>>
>>
>>> The same could be done for the usage column - allow an iptional
> link
>>> to a page listing known usages, with possible deployemnt 
>> reports (and
>>> if usage is what we are measuring in the adoption column, then the
>>> column should probably be called usage).
>> "Reports" for such things as deployment moves this entire 
>> activity into a world 
>> of formal accounting that is common among some standards 
>> efforts, but relatively 
>> foreign to the IETF.  It's the sort of thing entailing 
>> significant effort, for 
>> little apparent benefit.  But feel free to enlighten me...
>>
>> As for changing adoption to usage, i suspect you are right.  
>> Want to make that 
>> suggestion to the list?  (I'm posting too much there, as it 
>> is, and really want 
>> others to take initiative, as you have been.)
>>
>> d/
>> -- 
>>
>>    Dave Crocker
>>    Brandenburg InternetWorking
>>    bbiw.net
>>
> 
> _______________________________________________
> ietf-outcomes mailing list
> ietf-outcomes@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-outcomes
>