Re: Making the Tao a web page

Eric Burger <eburger-l@standardstrack.com> Sun, 03 June 2012 21:40 UTC

Return-Path: <eburger-l@standardstrack.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D809021F86C9 for <ietf@ietfa.amsl.com>; Sun, 3 Jun 2012 14:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.74
X-Spam-Level:
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFb-v4qPaYpc for <ietf@ietfa.amsl.com>; Sun, 3 Jun 2012 14:40:29 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 3943221F86C8 for <ietf@ietf.org>; Sun, 3 Jun 2012 14:40:28 -0700 (PDT)
Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:53225 helo=[192.168.15.135]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <eburger-l@standardstrack.com>) id 1SbIX9-0006NB-Qo; Sun, 03 Jun 2012 14:40:24 -0700
Subject: Re: Making the Tao a web page
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Eric Burger <eburger-l@standardstrack.com>
In-Reply-To: <98BC45C2-3C58-4DC6-89FA-766B426778BF@vpnc.org>
Date: Sun, 3 Jun 2012 17:40:21 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDB80324-3064-4282-8502-A26C8BFB08AF@standardstrack.com>
References: <20120530225655.19475.74871.idtracker@ietfa.amsl.com> <CE474406564976FC0A885D95@PST.JCK.COM> <DAEDF66E-8FB3-4A00-846A-FECE181E2EC3@vpnc.org> <4FC7FF09.4020701@inex.ie> <98BC45C2-3C58-4DC6-89FA-766B426778BF@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: IETF-Discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sun, 03 Jun 2012 21:40:30 -0000

What we have now *is* sclerotic. See Russ' email above yours.

Can we PLEASE eat our own dog food? Wikipedia managed not to melt down when they decided NOT TO BUILD WALLS so there were no gates for the barbarians to crush.

Let's just turn on a wiki. Wiki's have a lot of technical measures to deal with problem edits as well as social measures to ensure quality. Unlike a protocol that needs one editor, I do not think we will run into interoperability problems by having an open Wiki. Yes, you and I and others can think of exactly four individuals who will try to crash the party. There are technical measures to keep them out without burdening one or even four people with keeping up the wiki.


On Jun 1, 2012, at 5:33 PM, Russ Housley wrote:
> I have a concern here.  When I did the AD review for this document, I was quite surprised how stale it had become.  For example, the document told people to send I-Ds to the Secretariat for posting instead of pointing to the online I-D submission tool.  If we put it in a wiki, there will be more people that can make update, but the publication process ensure that an end-to-end read takes place when an update published as an RFC.
> 
> So, I am left with a few questions:
> - What is the similar forcing function if we use a wiki?
> - Will the number of people that can make updates eliminate the need for such a forcing function?
> - Who designates the editor-in-chief of the wiki?
> 
> Russ


On May 31, 2012, at 7:50 PM, Paul Hoffman wrote:

> On May 31, 2012, at 4:30 PM, Nick Hilliard wrote:
> 
>> On 01/06/2012 00:04, Paul Hoffman wrote:
>>> Works for me, other than it should not be a "wiki". It should have one
>>> editor who takes proposed changes from the community the same way we do
>>> it now. Not all suggestions from this community, even from individuals
>>> in the leadership, are ones that should appear in such a document.
>> 
>> In practice, if this is to be a living document then it should be open for
>> inspection and poking rather than preserved in formaldehyde and put in a
>> display case, only to be opened occasionally when the curator decides the
>> glass needs some dusting.  That way leads to sclerosis.
> 
> Thank you for that most colorful analogy. :-) What I proposed is exactly what we are doing now, except that the changes would appear on the web page instead of an Internet-Draft and, five years later, an RFC. Are you saying that the current system (which you have not commented on until now) is sclerotic (a word that I have wanted to use since I learned it in high school)?
> 
>> Please put it on a wiki and put all changes through a lightweight review
>> system.  If someone makes a change which doesn't work, then it can be
>> reverted quickly and easily.  This approach is much more in line with the
>> ietf approach of informality / asking for forgiveness rather than
>> permission / rough consensus + running code / etc.
> 
> 
> In the IETF approach, only the authors of an Internet-Draft can change the contents of that draft. I hope you are not proposing a change to that as well.
> 
> --Paul Hoffman
>