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

Mark Nottingham <mnot@mnot.net> Thu, 16 September 2021 08:31 UTC

Return-Path: <mnot@mnot.net>
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 E64613A2024; Thu, 16 Sep 2021 01:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=chUIvi2T; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oE/zkYkA
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 CqHPaI-p_jPL; Thu, 16 Sep 2021 01:31:35 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC2933A2022; Thu, 16 Sep 2021 01:31:35 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id EA1275C008D; Thu, 16 Sep 2021 04:31:34 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 16 Sep 2021 04:31:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=r 0BVCJHZf+GAVrk7GOEZULnoE4gXaN8XhFmuxQ0/Lkk=; b=chUIvi2TbhxUWAzXT Yyd9t5gNhsRYvBWau5iJ3SOvoOZYRCTJ2uRkzsnZenl7i/HHI+c+krCy171jYVb0 bv4KLAcpQBksoOJqpl9IlswNzl3whfswbKslGTQ+hsECLdlLO8Qw+SS5iq2kI+OB hSbeMFatg3IF+yKWTdz4cUX79n9qzE1VfI6MRD+Ds6M47UJMee5OGbI3DVWyf0N3 rPlVHhc20MOVdgb3QC8Ky4lDDTBzc72Y2cOHm12D7romK9tcCMI6uowCgow6JCkF +QC5xVHvelLx+JqH7QZ/KfVP3p74JDbPV4haBLKPDVCLpa1nULH4IDxVZSqOExC6 oOTmw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=r0BVCJHZf+GAVrk7GOEZULnoE4gXaN8XhFmuxQ0/L kk=; b=oE/zkYkAixBq89vWZplLi/tWS8HnSfIxA6V5RFZilv5H0r2vftIvBzKO3 lccpPRo4KO88XoVHsnaDuzhMAHLkGPPgUQAf5s5Xm7jsIRJTom4o6dCfZsTUFDJU FvzMNhkhAmifC77FLzI5O7aFWAWHEGaLhWyE1vgTJvtywfDo5rvw3bsefebxpNL0 QJGh0Qni8svkp6W39mOMiISZMxeX5sT6kv1nR5mLLDiO3poFDij7HNN82CvZiwOO 4kSukc/vLNl6V08LI/y8uNk87XxBaDEb9cTbhDx+GLcPNxhheraGVuvIpaPPYTIT GdCZ5ED6+DbwMTsPBH5lLqnwFyNxA==
X-ME-Sender: <xms:5ABDYYo-QZ4C-Z_azMnXoNihNy-IbIYmHb7jRY2_fapLZYylTufxeA> <xme:5ABDYeq4JZur22QQZGZFQDGdCiUBQBBQSBhIXXLcia4Tf9dwP5N42WvNr5aFZRDZ6 CRtCJkNSGD3I8I9DQ>
X-ME-Received: <xmr:5ABDYdNPSk4ammnkdtuODHbr6erVcvVD0B19_Jqu3KVQ7ThHmkN_hFv73OOS1mCKAgj-hGCAl3akkG-890BYyTxAktwCVa-uSb6SPfoZkSNFXDaZETdZorjE>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudehgecutefuodetggdotefrodftvfcurf hrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcupfho thhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnh epfeegvdfgjeegvdetuedukeevfefhheelieevjeejkefhffehkeejieekjedtheejnecu ffhomhgrihhnpehivghtfhdrohhrghdpmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:5ABDYf76wu6-8rKb9yClCnkGE9ZUKiQq3ftCAR9Tk5Ya9nnOFI_v3w> <xmx:5ABDYX7W8LjzF5Gwal_4xQ3WNnQs8ogxB5t6czr0SN-CIRFLLUkhhQ> <xmx:5ABDYfgjT6CoGn1dEE7DJ60wla720B0Sk1cJf1iI-IzmNXt-3eAGJA> <xmx:5gBDYdTbZ5B0bdoFs_rli0ySnBfIC7JHDwZQCsyzc90o0HqAFYsOTw>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 16 Sep 2021 04:31:30 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: [Tools-discuss] Content at notes.ietf.org is not archival
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <B6A2905B-6EB9-4A22-AD1A-10C4910408A2@tzi.org>
Date: Thu, 16 Sep 2021 18:31:27 +1000
Cc: Working Chairs <wgchairs@ietf.org>, IETF discussion list <ietf@ietf.org>, tools-discuss <tools-discuss@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A8104337-AA2E-40B3-B461-F9E92A77BD87@mnot.net>
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>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/udagAFZxUaCls0TqGukzMrtemq8>
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 08:31:42 -0000

It was a very serious proposal.

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.


> On 16 Sep 2021, at 6:07 pm, Carsten Bormann <cabo@tzi.org> wrote:
> 
> 
>> On 16. Sep 2021, at 09:46, Mark Nottingham <mnot@mnot.net> wrote:
>> 
>> Or, just automatically delete notes 30 days after creation.
> 
> (Again, I don’t know whether this was a serious proposal.
> I’ll treat is as such for the purpose of this message.)
> 
> Or, don’t offer the service at all?
> (Probably better than deleting it 30 days after creation (!).)
> 
> Most of the people who have done work in the IETF know about the value of accessing random traces of that work from the past.
> After a couple of decades, we mostly got rid of the 6-month ideology around Internet-Drafts; I wouldn’t want to repeat that painful experience.
> 
> 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.
> 
> Crippling such a service because we can’t figure out how to keep up some ideology strikes me as an expression of contempt for the work of the IETF’s contributors.
> You don’t have to feel the same way, but it should be well understood that this is the signal that is being sent.
> 
> Grüße, Carsten
> 
>>> On 16 Sep 2021, at 5:39 pm, Carsten Bormann <cabo@tzi.org> wrote:
>>> 
>>> On 15. Sep 2021, at 21:21, Eric Rescorla <ekr@rtfm.com> wrote:
>>>> 
>>>> Hi Robert,
>>>> 
>>>> This is the kind of PSA that is often made and ignored and then people come to rely on the existing state of affairs, making it hard to change, ISTM that if you want to actually have it be easy to deprecate the data then you probably want to make it actively unreliable now.
>>> 
>>> I’m not sure there isn’t an emoticon missing from this message…
>>> 
>>> The message reminds me a bit of Windows UAC and the idea that users are responsible for the reliability of their operating systems.
>>> (One main reason that this never can work is that users have work to do and are not in a mode to interrupt their work for arcane unrelated activities.)
>>> 
>>> Here, users are effectively asked to make manual backups of work that has been done in notes.ietf.org.
>>> Many people already occasionally make such backups, stash them away in some unreliable way; others won’t and will start making queries of who has a backup and whether that is the most recent one.  (This already has happened.  Don’t ask.)
>>> 
>>> Instead of burdening everyone with their own unstructured backup mechanisms, maybe it does make sense to keep something going at the IETF side.
>>> 
>>> (Being able to underlay a git repository would be the best technical solution that still keeps most responsibility on the user side.
>>> But I don’t want to talk mechanism here, just that it is not enough to issue another RFC 6919 "MUST (BUT WE KNOW YOU WON’T)”.)
>>> 
>>> Grüße, Carsten
>>> 
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 
> 

--
Mark Nottingham   https://www.mnot.net/