Re: [ietf-outcomes] "Instances" column
Dave CROCKER <dhc@dcrocker.net> Sun, 14 February 2010 18:53 UTC
Return-Path: <dhc@dcrocker.net>
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 5C1A43A774B for <ietf-outcomes@core3.amsl.com>; Sun, 14 Feb 2010 10:53:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.566
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aagECUAaVRd for <ietf-outcomes@core3.amsl.com>; Sun, 14 Feb 2010 10:53:45 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id DB88F3A7711 for <ietf-outcomes@ietf.org>; Sun, 14 Feb 2010 10:53:45 -0800 (PST)
Received: from [192.168.1.43] (adsl-68-122-34-69.dsl.pltn13.pacbell.net [68.122.34.69]) (authenticated bits=0) by sbh17.songbird.com (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: <4B78470B.70106@dcrocker.net>
Date: Sun, 14 Feb 2010 10:55:07 -0800
From: Dave CROCKER <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
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
X-Virus-Scanned: ClamAV 0.92/10390/Sat Feb 13 14:32:57 2010 on sbh17.songbird.com
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 14 Feb 2010 10:55:12 -0800 (PST)
Cc: ietf-outcomes@ietf.org
Subject: Re: [ietf-outcomes] "Instances" column
X-BeenThere: ietf-outcomes@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net
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:53:52 -0000
David, 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 carefully? > 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 > http://www.ietf.org/iesg/implementation-report.html. 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. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
- [ietf-outcomes] "Instances" column Dave CROCKER
- Re: [ietf-outcomes] "Instances" column David Harrington
- Re: [ietf-outcomes] "Instances" column Joel M. Halpern
- Re: [ietf-outcomes] "Instances" column Dave CROCKER
- Re: [ietf-outcomes] "Instances" column David Harrington
- Re: [ietf-outcomes] "Instances" column David Harrington
- Re: [ietf-outcomes] "Instances" column Ray Pelletier