Re: Making the Tao a web page

John C Klensin <john-ietf@jck.com> Sun, 03 June 2012 22:46 UTC

Return-Path: <john-ietf@jck.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 0CCBD21F8753 for <ietf@ietfa.amsl.com>; Sun, 3 Jun 2012 15:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.608
X-Spam-Level:
X-Spam-Status: No, score=-101.608 tagged_above=-999 required=5 tests=[AWL=-0.868, BAYES_20=-0.74, USER_IN_WHITELIST=-100]
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 vTi5cow2A8fr for <ietf@ietfa.amsl.com>; Sun, 3 Jun 2012 15:46:58 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4D37B21F8752 for <ietf@ietf.org>; Sun, 3 Jun 2012 15:46:58 -0700 (PDT)
Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1SbJTW-000PKz-MW; Sun, 03 Jun 2012 18:40:42 -0400
Date: Sun, 03 Jun 2012 18:46:44 -0400
From: John C Klensin <john-ietf@jck.com>
To: Eric Burger <eburger-l@standardstrack.com>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: Making the Tao a web page
Message-ID: <EA537FE44DD2C0CD3FA67A3F@PST.JCK.COM>
In-Reply-To: <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> <CDB80324-3064-4282-8502-A26C8BFB08AF@standardstrack.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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 22:46:59 -0000

--On Sunday, June 03, 2012 17:40 -0400 Eric Burger
<eburger-l@standardstrack.com> wrote:

> 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.

Eric,

FWIW, I think Paul is completely correct.  First of all, what is
sclerotic is RFC 4677.  Paul has been updating the I-D which is
much less of a problem.   Most of those "in the know" point
people to the I-D.  I think that having 4677 be the official
copy that some people consult as authoritative is a problem, but
it is another problem.

Those wiki technical measures depend on someone actively
watching for changes and having the time to step in.  I don't
think we can count on that, at least without a greater level of
effort that is required for an editor to receive comments and
integrate them.  I might change my mind if you, personally,
agreed to monitor the wiki in real time and alert the IETF list
to any possibly-questionable postings _and_ there was consensus
that those on the list wanted that additional traffic.

FWIW, I had a need on Friday to look up some details and
information that are fairly directly related to the IETF and its
relationships to some other bodies and decided to check the
Wikipedia pages that showed up in the search.  I'd give what I
found a score on accuracy and completeness of "joke" -- a few
identifiable falsehoods and a lot of convenient omissions (I
don't know or care whether those are the result of carelessness,
ignorance, or malice).  The most relevant of those pages wasn't
even flagged with "may be incomplete", "insufficient
references", or "may be biased", etc.  If you want to
demonstrate how well the Wiki system works, drop me a note
volunteering to fix the primary page involved and I'll tell you
what it is and, if you can't figure it out on your own in under
two minutes, where to get authoritative information.   In
principle, I could do it myself, but I just don't have time...
and that, and the fact that no one with the facts and time has
spotted those pages, is a large part of the problem with doing
something like the Tao by Wiki.

Also, perhaps because I have a more vivid (or paranoid)
imagination than you do, I can think of a lot more than four
individuals who would be inclined to wreck the party.  Some of
the individuals I can think of also have multiple personalities
or collections of sympathetic fellow-travelers (not just
multiple email addresses).  And, while I would hope they
wouldn't engage in such thing, if only because of the risk of
getting caught, I can think of a large and well-endowed
organization or three who might have incentives to put highly
distorted information onto an IETF Wiki that described how the
IETF worked, copy that material before it were taken down, and
then quote it in other sources.

Finally, as far as "our dogfood" is concerned, I just made a
careful search through the RFC index and a few other sources and
couldn't find an IETF Standards Track document describing the
Wiki technology and approach.  I couldn't even find an
Informational document.  So, unless I've missed something, this
particular food belongs to some other dog.  _Our_ dog food would
be to follow the precedent set with RFC 5000.  And I think that
is exactly what Paul and several others, including myself, have
been suggesting.

  best,
    john