Re: [Tools-discuss] Content at notes.ietf.org is not archival

Carsten Bormann <cabo@tzi.org> Thu, 16 September 2021 09:02 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: wgchairs@ietfa.amsl.com
Delivered-To: wgchairs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9D63A210C; Thu, 16 Sep 2021 02:02:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nk3KKtkEOWjX; Thu, 16 Sep 2021 02:02:43 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74043A210E; Thu, 16 Sep 2021 02:02:42 -0700 (PDT)
Received: from [192.168.217.118] (p548dcf6e.dip0.t-ipconnect.de [84.141.207.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4H9B1X0vSWz2xHv; Thu, 16 Sep 2021 11:02:40 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Subject: Re: [Tools-discuss] Content at notes.ietf.org is not archival
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <36F7F377-FA9C-4A26-82D7-2F64E7F1045F@mnot.net>
Date: Thu, 16 Sep 2021 11:02:39 +0200
Cc: Working Chairs <wgchairs@ietf.org>, IETF discussion list <ietf@ietf.org>, tools-discuss <tools-discuss@ietf.org>
X-Mao-Original-Outgoing-Id: 653475759.741195-54a729c4f5d8819b6942282e12a675b3
Content-Transfer-Encoding: quoted-printable
Message-Id: <BC4BDC66-307C-4A69-8FC4-E3020F036633@tzi.org>
References: <f2ea0c4f-9500-391d-b8d1-dcc3ac4a7b1c@nostrum.com> <CABcZeBOeKxO6KOWyC8WBqUxYyqAwqYdKOesBN+2nxtWAy17Mbg@mail.gmail.com> <ADDEE9BD-790B-4E44-982B-DAA15F50722A@tzi.org> <2B11D777-9D50-490F-B7C6-9DD769C789A6@mnot.net> <B6A2905B-6EB9-4A22-AD1A-10C4910408A2@tzi.org> <A8104337-AA2E-40B3-B461-F9E92A77BD87@mnot.net> <0114BD23-BD49-46D5-A824-7D76D8730AB4@tzi.org> <36F7F377-FA9C-4A26-82D7-2F64E7F1045F@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/6kKHUVu-KKAI7GmzXv4sgdf_WQA>
X-BeenThere: wgchairs@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Working Group Chairs <wgchairs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wgchairs/>
List-Post: <mailto:wgchairs@ietf.org>
List-Help: <mailto:wgchairs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/wgchairs>, <mailto:wgchairs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Sep 2021 09:02:48 -0000

On 2021-09-16, at 10:53, Mark Nottingham <mnot@mnot.net> wrote:
> 
>> On 16 Sep 2021, at 6:34 pm, Carsten Bormann <cabo@tzi.org> wrote:
>> 
>> On 2021-09-16, at 10:31, Mark Nottingham <mnot@mnot.net> wrote:
>>> 
>>> We already have a large number of places that people need to look for data. Adding another is not optimal, especially when the purpose of the tool is collaborative editing, NOT long-term reference.
>> 
>> Sure.  I just don’t know how crippling notes.ietf.org will help with Google docs, hackmd.io, and all these other places.  Actually, it will drive people back to those.
> 
> I have so many questions :)

… and that is completely OK, because different WGs have different ways to do work, so this all may not be obvious.

> Why is it an issue that people use those other services for scratch documents? 

It is not an issue; it is a missed opportunity.
I wrote:

>> Collecting notes in our own service (as opposed to hackmd.io or Google docs) gives us more control.
>> Another benefit of having a common service is that, after a while, everybody knows how to use it and we can integrate it into other tools.

> If temporary documents aren't appropriate, what guarantees do you need regarding archival storage, reliability, availability, etc?

Reasonable care.
The point is not that this needs to be protected against nuclear attacks, but that we keep some basic level of service that is not intentionally throwing away other people’s work.

> Why does the IETF have to run this service, instead of relying on a third party?

See above.
It doesn’t “have” to run this service; it just historically has done so and it turned out to be useful (much more useful after the switch to CodiMD/Hedgedoc).

> How do these now long-lived documents interact with RFCs, Internet-Drafts, Datatracker and meeting proceedings (the various sources of truth we currently have)? In particular, when someone references a document there and presumes it's IETF-sanctioned?

Then they are wrong.  But they already can do that with Internet-Drafts.
If that helps, add an obnoxious disclaimer at the top.

> Who determines that it's worth the cost of providing such a long-lived service?

I don’t know the cost, but it seemed to be limited.
(Etherpad was available for a long time, but was having availability problems.
Kudos to Robert for “creating” this problem in the first place by switching to a more reliable software base.)

Who determines the value?  The users.  I think we have a clear result there (maybe not in your quarters of the IETF).

Grüße, Carsten