Re: The Evils of Informational RFC's

Jari Arkko <jari.arkko@piuha.net> Fri, 10 September 2010 12:24 UTC

Return-Path: <jari.arkko@piuha.net>
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 E530A3A685A for <ietf@core3.amsl.com>; Fri, 10 Sep 2010 05:24:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.397
X-Spam-Level:
X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.202, 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 jA6pVDoeUzAW for <ietf@core3.amsl.com>; Fri, 10 Sep 2010 05:24:56 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id BEE283A6A36 for <ietf@ietf.org>; Fri, 10 Sep 2010 05:24:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 382832CC3C for <ietf@ietf.org>; Fri, 10 Sep 2010 15:25:22 +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 VDvD6FFbjHrr for <ietf@ietf.org>; Fri, 10 Sep 2010 15:25:21 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id C58BB2CC30 for <ietf@ietf.org>; Fri, 10 Sep 2010 15:25:21 +0300 (EEST)
Message-ID: <4C8A23B1.7040605@piuha.net>
Date: Fri, 10 Sep 2010 15:25:21 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: IETF Discussion <ietf@ietf.org>
Subject: Re: The Evils of Informational RFC's
References: <4C815335.4050209@bennett.com> <4C81554D.5060000@gmail.com> <4C8169DF.7010202@bennett.com> <4C8172AC.9060202@gmail.com> <4C817866.7040400@bennett.com> <4C817C6F.8070303@gmail.com> <4C818963.4090106@bennett.com> <21B56D7B-F058-47C8-8CBB-B35F82E1A0D2@standardstrack.com> <0ECC03C0-63B9-401F-B395-ACFBDF427296@gmail.com> <7F4C5F55-E722-4DF4-8E84-8D25628C55A3@standardstrack.com> <038B62A2-6B53-4FC2-8BDD-E1C9D6BDFB82@bbn.com> <4C880393.2070701@gmail.com> <9EEABCD0-9A34-4857-80FE-0CDBF06EEE22@bbn.com> <4C881E26.6090502@gmail.com>
In-Reply-To: <4C881E26.6090502@gmail.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Fri, 10 Sep 2010 12:24:58 -0000

I do think informational RFCs (both IETF and non-IETF) are valuable.

I would suggest though that their value is mostly NOT about ease of 
access, archival, those great ASCII graphics, or any other practical 
matter. The value is in our assessment of them being worthy of being 
published as RFCs. (Our = the IETF community, IESG and other reviews, 
RFC Editor board decisions, etc) I generally treat all information as 
suspect, even full standard RFCs (horror!) but I still think that across 
a number of different information sources even a vendor's protocol spec 
as an independent submission is pretty reliable.

So yes, lets keep on publishing informational, experimental, and 
individual and independent submission RFCs. They are not the primary 
source of technical information in Internet technology, but for me at 
least they do provide a lot of value.

Sam: about the binding Informational documents. I also do recognize that 
we sometimes make choices, say, about architectures or requirements and 
that we should stick with those decisions in future work. However, I 
would like to make two comments on this. First, many decisions of this 
sort are soft rather than hard. As an example, we often compromise on a 
requirement in order to reach a feasible solution. I'm not sure we want 
to bind ourselves to decisions of this type in any formal sense. Second, 
I think it is easier to think of the bindingness in terms of the history 
of the document and the practical situation than as a binary attribute 
of the document class.

Jari